A popular DOS extender from the early 1990s. Back then, most advanced PC OSes, such as Microsoft Windows, OS/2 or various flavors of UNIX, didn't allow the programmer full direct access to the hardware, and a lot of game developers relied on this for performance-enhancing tricks. Their own APIs were generally suited to the needs of more serious applications, not video games. That left a PC programmer with MS-DOS as a system of last resort, as it did allow direct access to hardware, but then another problem reared its ugly head: the infamous 640K barrier.
Due to the way the PC's memory was laid out, the maximum amount of memory available for user programs in DOS was just 640 kilobytes; most of the time, even less was available, since DOS itself and device drivers like HIMEM and EMM386 used some RAM as well. Most PCs of the time routinely sported several megabytes of RAM, but DOS couldn't use it because it ran in something called "real mode", where only the first megabyte of RAM is visible. To add insult to injury, DOS was not a multitasking OS and had no support for multithreading or multiple processes running at once; while there were tricks available to fake it, like the "Terminate and Stay Resident" system call, they were unreliable and not terribly useful in a gaming environment. In short, many games under DOS ended up implementing their own OS to make up for DOS's shortcomings.
To overcome this problem, a special kind of middleware appeared — the DOS extender. These were basically just lightweight OS kernels that provided several basic services, such as multitasking, memory management and protection, and often some basic networking support, so the programmers wouldn't have to write all this code from scratch and could concentrate on creating the game itself. However, since it was still DOS, direct access to hardware was still available if the programmer wanted it. There were a lot of them; Phar Lap's DOS/X was one of the first, and DJ Delorie's free port of GCC to DOS, DJGPP, initially used a custom DOS extender called "GO32" (and later switched to CWSDPMI). Even Windows 2.x was used as a kind of DOS extender for the earliest versions of Winword and Excel — as a matter of fact, the DOS-based incarnations of Windows up to 3.1 can be seen as a DOS extender to a degree, having its own device drivers and services whilst relying on DOS for low-level operations. In the end, though, Rational Systems' (now Tenberry Software) product won the race.
Rational's extender existed in two main versions: one for the 24-bit 80286 CPU, allowing the programs to address all 16 megabytes theoretically available for it, and thus called DOS/16M. Another version was developed for the 386 processors and higher, which were 32 bit and could address four gigabytes of RAM, so its name was DOS/4G. But the most widely remembered of them was a free, stripped-down version of DOS/4G that was included with a then very popular C compiler made by Watcom. It was called DOS/4GW and most games from 1992 to 1998, such as Doom, Descent and Duke Nukem 3D, used it.
The DOS/4GW kernel was loaded before the main program started, and it displayed its banner on loading, ensuring that anyone who ever played Doom would have it burned into his brain. Additionally, when the game or app crashed, the kernel would usually plaster error messages all over the screen without any regard for what was going there before and certainly without clearing it, overwriting the now-frozen game image with oversized DOS text, which could result in Nightmare Fuel for those who played a good old game that had crashed right in front of their eyes, which was not helped by the fact that the soundcard would also be usually affected by it, resulting the last sound being played at the time being looped constantly. This also tended to reinforce the popular memory of what else would've been just a footnote in the history of computing.
Flash forward to The New '10s, and strangely enough, the problem of "not enough memory" has occurred once more. While the norm has adopted 64-bit versions of operating systems, extending the amount of available memory to 2^64 bytes (or 16 exabytes, which is 16 trillion trillion bytes), many programs are still run in 32-bit compatibility mode. In Windows, it allows for 2GB of memory available to 32-bit programs by default. A few games (notably The Elder Scrolls V: Skyrim) have exceeded this limit occasionally, resulting in a crash. The only way to get around this is to recompile the program with as 64-bit or with a flag that tells Windows to make the entire 4GB of 32-bit space available.
