Compiling Quake Like It's 1997: A Journey into Retro Development

For the modern developer, the act of "compiling" usually involves a few clicks in a sophisticated IDE or a single command in a terminal, with dependencies handled automatically by a package manager. But in 1997, building a cutting-edge title like Quake was a precarious dance of specific hardware, fragile toolchains, and manual configuration.

Recreating this environment is more than a nostalgia trip; it is a study in the evolution of software engineering and the pragmatic shifts that defined the early 3D era. This guide explores the process of rebuilding the Win32 binaries of Quake using the tools and operating systems of the time.

The Evolution of the Quake Stack

The development of Quake didn't happen in a single environment. The initial executables, quake.exe and vquake.exe, were programmed on HP 712-60 workstations running NeXT and cross-compiled using DJGPP on a DEC Alpha server 2100A. However, as NeXT stagnated, id Software made a pivotal shift in June 1996.

As John Carmack noted, the team moved to Intergraph hardware running Windows NT immediately after shipping Quake. This transition paved the way for winquake.exe, glquake.exe, and QuakeWorld (qwcl.exe and qwsv.exe), all of which were developed and compiled on Windows NT using Visual C++ 4.X.

Recreating the 1997 Environment

To achieve historical accuracy, one must choose a target environment. While the "purist" route involves hunting for an Intergraph RealizM Dual P6-200MHz workstation or a dual Pentium Pro machine, a more accessible approach is using a late 90s PC or a VirtualBox VM running Windows 98SE or Windows NT 4.0.

Setting Up Windows NT 4

Installing Windows NT 4 is a straightforward process, but it reveals the minimalism of the era. Unlike Windows 95/98, NT 4 proudly displayed detected CPUs and RAM during startup without superfluous animations. A key technical quirk of the time was that adding a second CPU to a system wasn't automatically detected; the OS required a full re-installation to implement the Hardware Abstraction Layer (HAL) necessary for SMP (Symmetric Multiprocessing) systems.

The Toolchain: Visual C++ 6

While Quake was originally coded in VC++ 4.X, the project migrated to Visual C++ 6 by 1999. Setting up VC++ 6 today requires sourcing the installer from archives like the Internet Archive or winworldpc.com.

One immediate observation when installing VC++ 6 on modern high-resolution monitors (e.g., 1280x1024) is the awkward layout. The installer was designed for 640x480 or 800x600 resolutions, leaving vast amounts of empty space—a reminder of the display standards of the mid-90s.

The Build Process and Its Pitfalls

Compiling Quake is not as simple as opening a project and clicking "Build." There are several critical traps for the unwary:

Source Integrity: The source code must be obtained from a specific archive (such as the Quake Official Archive). Downloading from GitHub or transferring via FTP in ASCII mode can corrupt the .dsw (workspace) files, leaving the IDE unable to parse the project without providing an error message.
The Assembly Hurdle: A standard "Rebuild All" will initially fail. This is because Quake relies on hand-optimized assembly code by Michael Abrash stored in .s files. These require the ml.exe assembler, which is not included in the base VC++ 6 installation.
The Dependency Chain: To get ml.exe, you must install the VC++ 6 Processor Pack. However, installing the Service Pack 5 (setupsp5.exe) fails unless MDAC 2.5 is installed first. The solution is often hidden in the decompression folder as mdac_typ.exe.

Once these dependencies are resolved, the project finally compiles. By copying the necessary DLLs (PmProXX.dll, WdirXX.dll) and the id1 folder, the game becomes playable.

Reflections on Retro Engineering

Looking back, Visual C++ 6 was a powerhouse for its time. It offered "Go to definition," breakpoints, stack traces, and variable inspection—features that felt like magic in 1998, even if it lacked modern IntelliSense auto-completion.

Community discussions highlight the sheer quality of the Quake codebase. Some developers note that the project compiles with only two warnings, a testament to the rigorous engineering standards held by John Carmack and his team. This level of discipline—using asserts liberally in debug builds and striving for zero warnings—is less common in general game development today.

The Philosophical Shift: Why Win32?

John Carmack's historical perspective on the shift to Win32 provides insight into the industry's trajectory. He viewed Win32 as the inevitable winner, citing the advantages of TCP/IP support, dynamic linking, and powerful virtual memory over the limitations of DOS. While he maintained a deep affection for NeXTSTEP's UI and Unix power, the pragmatic reality of the market and hardware acceleration (OpenGL) made Windows NT the only viable choice for the future of id Software.

Ultimately, compiling Quake in a period-accurate environment is more than a technical exercise; it is a window into a time when developers fought for every cycle of CPU power and every byte of memory, building the foundations of the modern 3D engine.