/Technology

The short answer is that DOS didn't get in the way. A program wanted to write to the screen, it wrote. It wanted to access the disk, it accessed it. There was no layer between the code and the hardware doing validation, translation, or resource management. That explains most of the difference. ## Direct Hardware Access In DOS, writing graphics meant literally copying data to a memory address. Segment `0xA000` was VRAM in graphics mode, `0xB800` in text mode. One `MOV` instruction and the pixels were on screen, with no system calls and no intermediate drivers involved. Windows 3.1 introduced the **GDI (Graphics Device Interface)** to handle all of that. It made sense: with GDI, the same code worked across any printer or video card with a compatible driver. But every call to `DrawLine()` or `BitBlt()` had to pass through several layers before reaching the hardware, including parameter validation, window clipping, and device context management. For simple operations that overhead was barely noticeable. For applications doing thousands of graphics operations per second, it added up. Technical reference: [Raymond Chen, The Old New Thing (Microsoft)](https://devblogs.microsoft.com/oldnewthing/) ## Real Mode vs Protected Mode The 8086 and 286 ran in **real mode**: programs addressed the first megabyte of RAM directly, with no memory protection and no isolation between processes. That was the natural environment for DOS software. Windows 3.1 on 386 systems ran in **386 Enhanced mode**, with virtual memory and segment-based protection. Every context switch between applications, or between a DOS session and the Windows environment, required a CPU mode switch. That cost cycles. On the 286 things were worse. The processor could enter protected mode but had no instruction to return to real mode in software. Windows 2.x handled this by forcing a triple fault, essentially crashing the CPU in a controlled way to trigger a reset and get back to real mode. It worked, but it came with the timing and compatibility problems you'd expect from that kind of approach. Technical reading: [Intel 286 Protected Mode and the Windows Real Mode Switch](https://www.os2museum.com/wp/286-real-mode-switch/) ## Cooperative Multitasking Windows 3.1 used **cooperative multitasking**. Each application was responsible for voluntarily yielding control to the system by calling `GetMessage()` or `PeekMessage()` on a regular basis. If an application got stuck in a processing loop without doing that, the entire system froze, mouse, keyboard, everything. DOS had no multitasking at all. The program had the CPU to itself for as long as it ran. No scheduler interrupting, no other application competing for attention. For games, number-crunching tools, or anything that needed consistent timing, that made a real difference. ## Memory and Swapping The Windows 3.1 memory model was complicated, mostly for historical reasons. It used **moveable and discardable segments**: when RAM filled up, the memory manager moved segments around in the heap, compacted free space, and swapped to disk when needed. Anyone who ran Windows 3.1 on a machine with 4 MB of RAM knows what that looked like in practice, the disk grinding away for several seconds before an application responded. DOS had none of that. If a program fit in available RAM, it ran without the system interfering. ## Questions people were asking at the time **"Why does my DOS game run badly inside a DOS window in Windows 3.1?"** Because Windows kept intercepting hardware interrupts even inside a DOS session, `INT 8` for the timer and `INT 9` for the keyboard. Games that relied on precise hardware timing, especially those driving the **OPL2/OPL3 chip on a Sound Blaster** directly via port I/O, would lose synchronization. The usual workaround was pressing `Alt+Enter` to switch to exclusive mode, which gave the program more direct hardware access. That didn't always fix it completely though. **"Why was printing so slow in Windows 3.1?"** The GDI rendered the entire page as a bitmap in RAM before sending it to the printer. At 300 DPI on an A4 page, that meant several megabytes of data to process at a time when 4 to 8 MB of total RAM was typical. On machines with less memory, part of that rendering ended up going through the swap file. **"Why did Windows programs use so much more memory than DOS equivalents?"** Every Windows application loaded the system DLLs (`GDI.EXE`, `USER.EXE`, `KERNEL.EXE`) into a shared memory space, on top of the message loop overhead, window management structures, and UI resources. A simple DOS utility doing the same job could easily use a fraction of that. ## Other common problems from the same period Performance wasn't the only friction point. A few others that anyone from that era will recognize: **IRQ conflicts** were a persistent headache. Sound cards, modems, and network cards shared a limited set of hardware interrupts. In Windows the virtual interrupt manager (VPICD) tried to arbitrate between them, with mixed results. In DOS a program claimed its IRQ in `CONFIG.SYS` or via physical jumpers and that was that. Simpler, but configuring two cards in the same system without a conflict could take a while. **EMM386 and HIMEM.SYS** were required to access expanded (EMS) or extended (XMS) memory in DOS. The wrong driver configuration, or a conflict with something else loaded at boot, and the program simply wouldn't start. **DPMI** was how DOS games like DOOM got around the 1 MB limit without needing Windows. The DOS Protected Mode Interface let programs run in protected mode and access extended memory from within a plain DOS environment. Reference: [DPMI Specification, Archive.org](https://archive.org/details/bitsavers_intelDPMIecificationVersion1.01992_1528612) ## What Windows 3.1 actually offered Everything above is accurate, but Windows 3.1 was also solving real problems. Shared drivers meant a printer worked across all applications without per-program configuration. A consistent graphical interface lowered the barrier for non-technical users. The shared DLL model, despite its memory overhead, avoided duplicating common code across every running application. Raw performance was lower. But DOS also put the full burden of hardware compatibility, memory management, and interface design on each individual program, which worked fine for specialized software and less well when you needed several things running at once. **Additional sources:** - [Microsoft KB Archive, Windows 3.1 Architecture](https://web.archive.org/web/*/support.microsoft.com/kb/*) - [Fabrice Bellard, Writing a DOS Extender](https://bellard.org/) - [The Starman's Realm, DOS Memory Management](http://www.thestarman.pcministry.com/DOS/DOS4GW.htm) - [OS/2 Museum, Early Windows Internals](https://www.os2museum.com)