The mid-90s was arguably the period in PC history with the most whiplash-inducing changes. The arrival of 3D acceleration cards, the transition from plain-textbox DOS to fancy Windows 95, and the advent of the Internet all happened at once. This rapidly shifting landscape posed quite the challenge for game developers, as they had to consider writing their games for DOS, Windows 95, or both.
In an exceedingly detailed writeup, Fabien Sanglard explains how the OG Quake got its support for TCP/IP and was arguably the only game that used the same executable with native support for both operating systems.
Many games of the era, like Fallout, Grand Theft Auto, and Mortal Kombat 3, would ship separate executables for DOS and Windows 95. However, id Software wanted Quake to use nearly the same executable (and codebase), and it wanted the game to have support for TCP/IP, the Internet communications protocol. Playing remotely with more than one person was the fresh new thing back then; true multiplayer was often limited to home or office networks.
Fulfilling both requirements at once was no easy feat for Quake. DOS was long in the tooth by the time of the game's development and needed a ton of hacks to use all of the hardware capabilities of the time, namely but not only more than 640 KB of memory.
To get around DOS' limitations, games started including DPMI (DOS Protected Mode Interface) extenders like Watcom's DOS/4GW or CWSDPMI. These extenders offered a standardized memory interface, multitasking, and other capabilities. The extender technically served as a micro-kernel, so think of it as a DOS replacement. Typically, games would ship with a target DPMI server and be their single client.
During Quake's development, id wanted to shift from the (at-the-time) proprietary Watcom compiler used in Doom to the open-source djgpp toolkit in a bid to make cross-platform development far easier. Heck, Quake even had a DEC Alpha port, if anyone remembers those. In a shift from the usual arrangement, id asked djgpp's engineers to ensure that its DPMI client supported Windows 95's included DPMI server in addition to CWSDPMI.
The problem was that although DPMI was a standard, its specification was not finalized until the late 90s. That meant that in practice, client software was normally beholden to one specific server. But the djgpp team delivered, and senior Microsoft kernel engineer Raymond Chen put it plainly:
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
"The fact that programs seem to run mostly okay in spite of running under a foreign extender is either completely astonishing or totally obvious, depending on your point of view."
Quake had native TCP/IP support coded in, yes, but since it was cross-platform, it needed a way to interact with Windows 95's Winsock TCP/IP layer. Additionally, in-game match/server browsers were a new concept at the time, so id killed two grunts with one rocket by enlisting the help of Mpath Interactive and integrating its Mplayer match-making software into Quake.
Mplayer's software comprised two pieces: a "Gizmo" game browser that would autodetect any Mplayer-compatible games you had installed and list game rooms for them, and a solution called the "Chunnel", the component that would actually talk to Windows' TCP/IP stack.
To round out cross-compatibility, Quake also shipped with Mpath's genvxd.dll. This is a virtual device driver that translated DOS networking functionality (that itself uses the now-standard BSD socket function calls) to Windows 95's Winsock. Once that was fitted in, the journey was finally complete, and Quake would run seamlessly in both DOS or Windows, without needing separate installers or executables.
Bruno Ferreira is a contributing writer for Tom's Hardware. He has decades of experience with PC hardware and assorted sundries, alongside a career as a developer. He's obsessed with detail and has a tendency to ramble on the topics he loves. When not doing that, he's usually playing games, or at live music shows and festivals.
IIRC, DOS/4G and the like simply checked to see if a DPMI server was already present (example: Windows) and if so, let that already loaded server handle the protected mode interface. Otherwise, it loaded its own server.
That part, at least, wasn't really out of the ordinary.
Maybe it's just me that remembers playing games older than Quake over a network (TCP/IP). I remember doing Dialup connections and local serial connections to play as well. I remember playing Doom (original version) and Doom 2 through a local LAN via Network. Doom was ran through the same exe in Windows and DOS. Other clones such as "Hexin" and "Heretic" also worked. The ability to play "online" was brought to fruition through third party programs like "Kali". There was also the original Warcraft (1&2) that was playable natively with DOS and Windows using the same exe, and local network multiplayer was an easy option to select inside the game. Battle.net for true online play became a thing after Warcraft 2 was already released for a couple years, and they released a new version called "battle.net edition".
There were other games like Spectrum Holybyte's Falcon 3.0, Mig 29 and other versions (plane specific) that let you play together over a network. The cool thing about these games was that you could own a version with a different plane and play with someone else. For example, someone who owned Mig 29 could connect with someone that owned Falcon 3.0 and play together in their respective game/plane.
Some other games I remember playing over LAN from that era were the original Nascar and Indycar. Those also worked in both DOS and Windows.
In my youth in the late 80's and early 90's, we used to get together and have LAN parties before there were routers. We used to have to manually program all IP's (static IP's) to get everything to communicate, because there wasn't a DHCP server to use back then (at least not that we were aware of back then). Most people back then didn't understand networking because it was still new to the public (usually only used in businesses at that time) and therefore didn't really know how to configure games to play, because it wasn't as easy as just "picking a room" like it is now. Back then, you had to program and know the host IP to connect.
Heck, Quake even had a DEC Alpha port, if anyone remembers those.
id Software never made an official port for the Alpha, that was done by open source community members years later. Fabian's article article only says they switched to the djgpp compiler to cross-compile Quake on Alpha servers. For those unfamiliar, cross-compiling means building source code to target a different hardware/software platform from the one used to run the compiler. In this case they were running djgpp on DEC Alpha servers to produce quake.exe for DOS/Windows 95. This was not an unusual practice because the DEC hardware was substantially more powerful than desktop PCs of the time. Today we often cross-compile apps for mobile devices on a PC/Mac.
Windows 2.x and earlier are irrelevant, since DPMI wasn't created until the development of Windows 3.0. Quake would have to run under regular real-mode DOS when launched in those versions (probably required you to exit Windows first in order to load djgpp's DPMI server at all). It's possible Quake was compatible with the DPMI provider present in Windows 3.x since it's largely identical to the one in Windows 95.
However, Quake is unlikely to support networking in any Windows 3.x versions. Windows didn't include a network stack with IPX/SPX or IP until the Windows for Workgroups upgrade for 3.1, which was replaced with a 32-bit Winsock implementation in the final version, Windows for Workgroups 3.11. Maybe the VxD Chunnel setup Quake uses would've been compatible with WfW 3.11, but it seems unlikely if they were targeting Win95's Winsock implementation.
Bah, we had our IPX/SPX for our games and we liked it! Small enough to run in conventional memory, and no DHCP server or manually assigning IP addresses required.
For only two players, many games included support for a null-modem cable as well.
