How Quake.exe Got Its Tcp/ip Stack
Key topics
The article explores how id Software integrated a TCP/IP stack into Quake.exe, allowing for multiplayer gaming over the internet, sparking nostalgia and discussion among commenters about the game's development and the evolution of gaming technology.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
88
0-12h
Avg / period
25.8
Based on 129 loaded comments
Key moments
- 01Story posted
Nov 18, 2025 at 3:18 AM EST
about 2 months ago
Step 01 - 02First comment
Nov 18, 2025 at 4:39 AM EST
1h after posting
Step 02 - 03Peak activity
88 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 24, 2025 at 11:40 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The British guy named Henry might have named it after another feat of engineering completed around the same time.
https://en.wikipedia.org/wiki/Channel_Tunnel
Weird hearing that name now though. Around that time, everybody referred to it as the "Chunnel", but I don't think I've heard it as anything but the "Channel Tunnel" since maybe 2000. I suspect even that usage is now limited to only taking cars on the train from Folkestone. Every time I've travelled on it as a regular passenger from London, it's just been referred to as the Eurostar without any mention of the tunnel at all.
With IP you have an address and the means to route the data to that address and back, with TCP/UDP sockets you have the address:port endpoint so the recipient doesn't need to pass a received packet to the all processes on the system, asking "is that yours".
So if there is already some network stack providing both the addressing and the messaging...
You’d still be talking of stuff like IP addresses and the like with it. Probably with the XTI API instead of BSD sockets, which is a bit more complex but you need the flexibility to handle different network stacks than just TCP/IP, like erm…
Also, Windows did not install TCP/IP components on computers without a network card (most of them until the Millennium era), it was an optional component. You could not “ping” anything, as there was no ping utility, nor libraries it could call. In that aspect, those network-less Windows systems were not much different from network-less DOS systems. The installer probably still works that way (or can be made to, by excluding some dependencies), but it's hard to find hardware without any network connectivity today. I wonder what Windows 11 installer does when there is no network card to phone home...
One of "works fine", "needs a command line trick to continue" or "refuses to work completely" depending on which specific edition of win11 your computer has been afflicted with.
https://en.wikipedia.org/wiki/Trumpet_Winsock
You: I'll show you!
I am the danger.
[Sticks glowing hot screw driver in molten lead]
Later that day...
Years later I learned what flux was, and soldering became quite a bit better and easier.
There wasn't one kind of null modem cable, per se, there were serial and parallel null modem cables.
Originally, there were null modem (serial) adapters that worked with straight through cables but that got expensive, awkward, and complicated. A universal serial null modem cable had a pair of "DB-9" DE-9 female and DB-25 female connectors on both ends so it would work with either system having either type of connector.
A parallel null modem cable had DB-25 male connectors on both ends.
http://www.nullmodem.com/LapLink.htm
Both were used with LapLink and often interchangeably called "LapLink cables" too because the boxed version of LapLink included both cables.
Virtual x86 mode had little to do with what we nowadays think of when someone says ”virtual machine”
[0]: https://en.wikipedia.org/wiki/QuakeC
This hurt performance a bit but in the longer term benefited the modding scene massively.
Virtual 8086 remapped all opcodes and memory accesses to let a program pretend to be on a single, real-mode 8086 when in reality it was one of many programs running in protected mode on a newer chip
AMD-V and whatever the Intel counterpart is do the almost exactly the same thing: re-map all ia32 and amd64 instructions and memory accesses to let a program pretend to be doing ring 0 stuff on an x86 box, when in reality it is one of many programs running with fewer privileges on a newer chip
There are a few more wrinkles in the latter case -- nested page tables, TLB, etc -- but it is the same idea from the viewpoint of the guest.
> From the beginning of the development, id had requested from djgpp engineers that their DPMI client would be able to run on djgpp's DPMI server but also Windows 95 DPMI server.
I'm pretty sure that "DJGPP engineers" is just one guy, DJ Delorie. DJGPP was always open source so I bet he got some contributors, but if the rest of this sentence is true that "id has requested from djgpp engineers", it just means they asked the maker of an open source tool they used to please add a feature. I wonder whether they paid him for it or whether DJ just hacked it all in at id's request for kicks. His "about me" page suggests he does contracting so might be the latter.
DJGPP was spectacularly good back in the day. I didn't appreciate at the time what a monumental effort it must have been to port the entire GCC toolchain and runtime to DOS/Windows. Hats off to DJ Delorie!
I think I remember there was some communication between ID and Charles Sandmann about CWSDPMI, so even though it's worded a bit strange for an open source project there's probably some thruth in it?
Also a bit strange how the author is surprised about Quake running in a 'VM', apparently they don't really know about VM86 mode in x86 processors...
Virtual 8086 mode, as its name somewhat suggests, only runs real mode code.
He is perhaps surprised that it runs _at speed_ in the VM, not that it runs in the VM which he already knows about.
However, the difference between a DOS VM under Windows 9x and a Windows command prompt and a w32 program started from DOS is all very esoteric and complicated (even Raymond Chen has been confused about implementation details at times).
So I just took a look at DJ’s website and he has a college transcript there. Something looked interesting.
Apparently he passed a marksmanship PE course at the first year. Is that a thing in US? I don’t know, maybe its common and I have no idea. I’d love to have a marksmanship course while studying computer science though.
US colleges still have far more options though.
You can still play little game I made in under 10K for the Allegro SizeHack competition in 2000: https://web.archive.org/web/20250118231553/https://www.oocit...
Back then I was also writing a bunch of articles on game development: https://www.flipcode.com/archives/Theory_Practice-Issue_00_I...
I eventually installed Red Hat, started at university and lost most of my free time to study projects.
I took part in a few of the later Speedhacks, around 2004-2005, I think?
Allegro will always have a warm place in my heart, and it was a formative experience that still informs how I like to work on games.
Worked great, and saved a bunch of time vs writing a VDD to enable direct hardware access from NTVDM or a miniport driver from scratch.
IIRC, the underlying problem was that none of the NT drivers for any of the cards we'd tested were able to reliably allocate enough sufficiently contiguous memory to read tapes with unusually large (multi-megabyte) block sizes.
Purely out of curiosity, was that all a volunteer open source effort or was the entire DJGPP group acting as a consulting organization?
And here you are!!
Yeah, the dos to windows transitions was a big deal, but it was a pretty ripe time for innovation then.
Dialing-up to the Internet to play Quake via TCP/IP...shit tons of lag (150+ ms).
What the GP comment was talking about was dial-up Internet being most people's exposure to TCP/IP gaming in the 90s. That was most assuredly laggy. Even the best dial-up Internet connections had at least 100ms of latency just from buffering in the modems.
The QuakeWorld network stack was built to handle the high latency and jitter of dial-up Internet connections. The original Quake's network was fine on a LAN or fast Internet connection (e.g. a dorm ResNet) but was sub-par on dial-up.
It was laggy as there was buffering and some compression (at least for later versions) that most definitely added latency.
And even then they'd often just use the bundled browser.
I remember the first friend who got a cable modem, that shit was insane compared to dial-up.
Which seems to imply that the network stack was about as difficult to implement as the new 3D engine.
There's also the columns he wrote for Dr Dobbs' Journal during development. They're like an expanded, illustrated version of GPBB chapter's first half. https://www.bluesnews.com/abrash/contents.shtml
As well as bug reports: https://github.com/Henrique194/chocolate-quake/issues/57
I personally would love to get some help with my chocolate Doom 3 BFG fork, specially with pesky OpenGL issues: https://github.com/klaussilveira/chocolate-doom3-bfg
Downside is that your framerate was capped to the person with the slowest computer, and there was always that guy with the 486sx25 who got invited to play.
Some configuration, but you don't have to update the port forwarding as often as you would expect.
The reason you can't just play games with your friends anymore is that game companies make way too much money from skins and do not want you to be able to run a version of the server that does not check whether you paid your real money for those skins. Weirdly, despite literally inventing loot boxes, Valve does not suffer from this sometimes. TF2 had a robust custom server community that had dummied out checks so you could wear and use whatever you want. Similar to how Minecraft still allows you to turn off authentication so you can play with friends who have a pirate copy.
By the way, this is why bnetd is illegal to distribute and was ruled such in a court of law: authenticating with battle.net counts as an "effective" copy protection measure under the DMCA, and providing an alternate implementation that skips that therefore counts as "circumvention technology".
It's like in-engine Hamachi. Works really well with P2P games.
Windows 95 and MS-DOS in 2004 worry me a bit more.
When a DOS VM is in windowed mode, Windows must intercept VGA port I/O and video framebuffer RAM access to a shadow framebuffer and scale/bitblt it to display in its hosted window.
In full screen, exclusive VGA access is possible so it doesn't need to do anything special except restore state on task switching.
Quake would be even faster if it didn't have to support DPMI/Windows and ran in "unreal mode" with virtual memory and I/O port protections disabled.
Another fond memory: I was playing Star Wars: Dark Forces (I think that was the one) and was frustrated with the speed of level loading. I think it used DOS/4GW and I recall renaming it, copying in a new dos extender (was it CWSDPMI? not sure), and renaming it to the one Star Wars used. I was shocked when it not only worked, but the level loading was MUCH faster (like 3-5x faster I recall). My guess is whatever one I had swapped in wasn't calling the interrupt in DOS (by swapping back to real mode), but perhaps was calling the IDE disk hw directly from protected mode. Not sure, but it was a ton faster, and I was a very happy kid. The rest of the game had the same performance (which makes sense I think) with the new extender.
FWIW, the Total Entertainment Network (TEN) got Quake later, here's a press release from September 30 1996 [1]. Wikipedia says QTest was released Feb 24, 1996, and I can't find when MPath support launched, so I don't know how long the exclusive period was, but not very long. Disclosure: I was a volunteer support person (TENGuide) so I could get internet access as a teen; I was GuideToast and/or GuideName.
[1] https://web.archive.org/web/20110520114948/http://www.thefre...
Technically true, although tools like Kali existed which could simulate IPX style networks over the internet. I know this because I played a substantial amount of Mechwarrior 2 online when it designed only for local network play!
https://www.ka9q.net/code/ka9qnos/
This worked in DOS, but was easily ported to Linux.
As far as DPMI: I used the CWSDPMI client fairly recently because it allows a 32-bit program to work in both DOS and Windows (it auto-disables its own DPMI functions when Windows detected).
https://en.wikipedia.org/wiki/CWSDPMI
16 more comments available on Hacker News