Let's compile Quake like it's 1997

"VC++6 is remarkably powerful for 1996. It has features such as "Go to definition", breakpoints, stacktrace, and variable inspections (but no Intellisense auto-completion yet). I never used it but it must have felt like a dream at the time."

And here we are, in a generation of people writing blogs that never used VS6. I am now officially old.

I was still using VS6 as late as 2009 btw...also it's from 1998. If you made a list of Microsoft bangers it's in the top 5 with probably windbg, quickbasic and windows 3.11.

> DO NOT get it from github or transfer the files via FTP.

I bet the author doesn't know about FTP's ASCII mode, and especially doesn't know that it is the default.

ASCII mode was a nifty feature, but it never should have been the default. Especially when you consider that most text files are small and easy to re-download if you forget, while binary files are often quite large and the damage done by the line ending conversion is close to impossible to repair. Also, if you forget to convert a text file you can trivially do it on the host afterward.

> Go back and run setupsp5.exe. This time it will work. By now it should feel like you are following the solution of Monkey Island. Nothing makes sense. We are definitely deeeep into the 90s.

Gold.

The whole thing compiles with 2 warnings. Incredible codebase. John Carmack definitely was/is on a different level.

Back when I was making videogames I followed a similar philosophy. No warnings (but in an orders-of-magnitude smaller and less complex codebase). Crash on failed asserts, used liberally, in debug builds. Not sure why but it seems that gamedev doesn't do this kind of rigorous engineering in general (or at least it didn't back then -- and admittedly I never worked in a big studio).

Sean Barrett, author of the stb libraries [0] which are near-ubiquitous in game development, is known among other things for still using visual c++ 6. [1]

[0] https://github.com/nothings/stb

[1] https://m.youtube.com/watch?v=nQrzB5P5NPE

This drips of nostalgia. Quake being the first "lan party" title at college definitely makes me realize my age, but I credit this game for my interest in understanding LAN topologies, networking, latency and learning about multiplayer real-time interaction.

VC++ 6 was awesome, I wouldn't have a career if I didn't have pirated copies of VC++ 6 and Borland Delphi. And look at how clean and crisp it all looks. Every pixel has a purpose.

Man, I love the Visual C++ and Visual J++ interface so much. It was so fast and super clear.

> In June of 1996, having shipped their title but concerned with NeXT stagnation, id Software switched their development stack.

id also decided no more DOS games around that time (well, maybe a year later)

> For Id Software to develop a game, a dll will be most efficient. We have more cpu power, and we can debug it more easily. We are directing significant effort towards making Quake 2 a better GAME, as well as just a better mutliplayer virtual world. Quake 1 was pretty messed up from a game standpoint, and we don't plan on doing that again.

> Speaking of portability, to remove the guesswork that goes on, here are my current opinions on the various platforms:

> Win32 > Win32 rules the world. You are sticking your head in the sand if you think otherwise. The upside is that windows really doesn't suck nowdays. Win 95 / NT 4.0 are pretty decent systems for what they are targeted at. I currently develop mostly on NT, and Quake 2 will almost certainly be delivered on win32 first. Our games should run as well as possible in NT, we won't require any '95 only features.

> DOS > We are not going to do another dos game. No amount of flaming hate mail is going to change my mind on this (PLEASE don't!). The advantages of good TCP/IP support, dynamic linking, powerfull virtual memory, device drivers, etc, are just too much to overcome. Yes, all of those can be provided under dos in various ways, but it just isn't worth it.

> Linux > I consider linux the second most important platform after win32 for id. From a biz standpoint it would be ludicrous to place it even on par with mac or os/2, but for our types of games that are designed to be hacked, linux has a big plus: the highest hacker to user ratio of any os. I don't personally develop on linux, because I do my unixy things with NEXTSTEP, but I have a lot of technical respect for it.

> NeXTStep > My favorite environment. NT and linux both have advantages in some areas, but if they were on equal footing I would choose NEXTSTEP hands down. It has all the power of unix (there are lots of things I miss in NT), the best UI (IMHO, of cource), and it just makes sense on so many more levels than windows. Yes, you can make windows do anything you want to if you have enough time to beat on it, but you can come out of it feeling like you just walked through a sewer.

> In the real world, things aren't on equal footing, and I do most of my work on NT now. I hold out hope that it may not stay that way. If apple Does The Right Thing with rhapsody, I will be behind them as much as I can. NEXTSTEP needs a couple things to support games properly (video mode changing and low level sound access). If apple/next will provide them, I will personally port our current win32 products over.

> If I can convince apple to do a good hardware accelerated OpenGL in rhapsody, I would be very likely to give my win NT machine the cold shoulder and do future development on rhapsody. (I really don't need Quickdraw3D evangelists preaching to me right now, thank you)

Article from February OP

Some more discussion then: https://news.ycombinator.com/item?id=46936274

If you want to play Quake for free on Windows 11, try this: https://quake-remake.en.uptodown.com/windows/download

> Go back and run setupsp5.exe. This time it will work. By now it should feel like you are following the solution of Monkey Island. Nothing makes sense. We are definitely deeeep into the 90s.

Gold.

VC++ 6 was awesome, I wouldn't have a career if I didn't have pirated copies of VC++ 6 and Borland Delphi. And look at how clean and crisp it all looks. Every pixel has a purpose.

Sean Barrett, author of the stb libraries [0] which are near-ubiquitous in game development, is known among other things for still using visual c++ 6. [1]

[0] https://github.com/nothings/stb

[1] https://m.youtube.com/watch?v=nQrzB5P5NPE

> DO NOT get it from github or transfer the files via FTP.

I bet the author doesn't know about FTP's ASCII mode, and especially doesn't know that it is the default.

And here we are, in a generation of people writing blogs that never used VS6. I am now officially old.

I was still using VS6 as late as 2009 btw...also it's from 1998. If you made a list of Microsoft bangers it's in the top 5 with probably windbg, quickbasic and windows 3.11.

The whole thing compiles with 2 warnings. Incredible codebase. John Carmack definitely was/is on a different level.

I would guess that the 1998 era Microsoft compiler didn't have nearly as many warnings as modern compilers do.

Many of those features were already available in MS-DOS and Windows 3.x IDEs from Borland for Turbo Pascal and C++.

Which is why when I got into UNIX development felt like going into the stone age of development tools, thankfully XEmacs was already there.

Which by the way, it was born for Energize C++, in 1993!

https://www.youtube.com/watch?v=pQQTScuApWk

Also here is what NeXTSTEP development environment looked like, used for Quake tooling development, in a 1991 marketing video.

https://www.youtube.com/watch?v=UGhfB-NICzg

Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI, being there at the time, and not being able to use some of these systems, due to the amount of money they required.

You make it sound like he's some young'un, but Fabien has been programming since 1983.

https://fabiensanglard.net/40/

Turbo Pascal had breakpoints, variable inspections in the late 80s. I think it had stack traces too but not 100% sure.

I am not old enough to have used it professionally, but my teacher used it for teaching intro programming in the early 2000s. So I used it quite a lot, the debugger was great and the development loop was so tight. Not until I got into web dev did it ever feel "fast" to make change->see change. To this day it is still bad in most stacks.

Rational Apex Ada is another dev platform that was way ahead of its time in early to late 90's. Multi-user hosted dev environment with incremental compilation and dependency tracking, syntax and semantic error highlighting, semantic search (i.e function signature) across whole repo, its own version control system with a git submodules style structure, automatic formatting as you write code. [Remote] Debugging and emulation features (stack trace, line of code, disassembly, etc), plus excellent VxWorks integration and tooling. Not to mention all the Ada language features which are still not available in modern languages.

I could've sworn VC++6 had Intellisense. I'm not going to dig too far to confirm but Wikipedia seems to agree with me (https://en.wikipedia.org/wiki/Code_completion#Visual_Studio) - it's not a great reference but definitely implies that it was there:

> the Visual Basic versions of IntelliSense were always more robust and complete than the 5.0 and 6.0 (97 and 98 in the Visual Studio naming sequence) versions of Visual C++

I used VS6 professionally and for private business around 2000-2004, and it was still going strong then. VC++ was great.

One thing though that I still have nightmares about is Visual SourceSafe, Microsoft's idea of a source control system for small teams. It was not only terrible to use (and slow), but we regularly lost data in it due to concurrency issues.

The problem wasn't the IDE, but win32 API documentation was very poorly written back then and lots of programs suffered because of it.

100% agree. Not only was VC++6 a stand-out product overall, but it was easily the better IDE out of the crop of options at the time.

Sadly, the product line got worse before VSCode came out. Things are much better now.

Ah yes, VC++6.0

It had such a long lifetime.

The last time I used it in anger to release commercial software was round about the year 2020, at which point the dev environment for that particular piece of software that customers were still paying annual license fees on was a VM machine. The source code repo it linked to had been unknowingly destroyed years earlier, so the VM image was copied around as needed. One had to find the very latest version of that image, because otherwise any changes one made would of course exclude some other recent changes and customers would receive a Frankenversion.

Starting the VM would reveal a desktop with VC++6 already open, and enough supporting evidence to show how to build the software. Make your changes, build, carefully extract the binary to send to the users, freeze the VM again.

I expect it's still there, still being brought back every year for "one last update."

It feels now like an alternative timeline, one which performance optimisations were first and foremost still. Sometimes I fantasize, thinking how would our current development ecosystem look like, if we never abandoned the "be very vigilant with all resources you use" approach, that includes the whole webdev liftoff, where we ship a few hundred mb chromium engine for a dock app

You make it sound like he's some young'un, but Fabien has been programming since 1983.

https://fabiensanglard.net/40/

Many of those features were already available in MS-DOS and Windows 3.x IDEs from Borland for Turbo Pascal and C++.

Which is why when I got into UNIX development felt like going into the stone age of development tools, thankfully XEmacs was already there.

Which by the way, it was born for Energize C++, in 1993!

https://www.youtube.com/watch?v=pQQTScuApWk

Also here is what NeXTSTEP development environment looked like, used for Quake tooling development, in a 1991 marketing video.

https://www.youtube.com/watch?v=UGhfB-NICzg

Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI, being there at the time, and not being able to use some of these systems, due to the amount of money they required.

> Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI, being there at the time, and not being able to use some of these systems, due to the amount of money they required.

I was not there at the time, but one appeal of CLI (not TUI) is scripting. After a while, you have all your routine packaged in nice alias and commands. And that’s universal across all languages and projects.

>Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI

Elitism

Turbo Pascal had breakpoints, variable inspections in the late 80s. I think it had stack traces too but not 100% sure.

The earlier Microsoft compilers included since 1985 the debugger CodeView, which could do all that and much more.

Around 1990, the development tools offered by Borland and Microsoft for C and C++ were pretty much equivalent and they both were quite good.

While the Borland languages were like "Turbo-X", the Microsoft languages were like "Quick-X".

The greatest difference between the commercial software available at that time and what exists today is that everything was accompanied by a set of high quality manuals that could teach you anything that one would want to know. Nowadays the quality of technical documentation is usually much worse.

That wasn't the banger for vs6 it was the workflow and muscle memory of the thing. The flow is still unmatched IMHO. It was like avid or photoshop for writing windows software.

Default keys in modern IDEs are basically still the vs assignments from the 5/6 era.

It was the closest Microsoft ever came to making their own emacs or vim. vs6 was like 90% of my screen time as a windows dev in the 90s and 2000s

I've been a linux user for 30 years ... I never had the vs6 level of efficiency in linux, still don't. NetBeans was the closest ... yes, NetBeans... (I've given up though, I do things in nvim, tmux and suffer)

Turbo Pascal was amazing for its time. As a young person learning programming it was a step change in functionality. Before that on PCs you were using Basic or assembly It was cheap and incredibly useful.

Yes, Turbo Pascal 5.0 introduced those features in 1988.

https://www.youtube.com/watch?v=UNx4dxXptUg

All the good borland devs were poached by Microsoft. VC5 and 6 were the spiritual successors of the Turbo XXX family of IDEs.

Yes, but if you compare the complexity of (Turbo) Pascal to the complexity of C++... language, environment, libraries and cross-compilation...

(A nice thought-experiment is to ask if Quake could have been coded in TP at all - even if memory hadn't been an issue (I think there was no DOS extender for TP, but I could be wrong).)

Article from February OP

Some more discussion then: https://news.ycombinator.com/item?id=46936274

Man, I love the Visual C++ and Visual J++ interface so much. It was so fast and super clear.

> In June of 1996, having shipped their title but concerned with NeXT stagnation, id Software switched their development stack.

id also decided no more DOS games around that time (well, maybe a year later)

> Speaking of portability, to remove the guesswork that goes on, here are my current opinions on the various platforms:

> the Visual Basic versions of IntelliSense were always more robust and complete than the 5.0 and 6.0 (97 and 98 in the Visual Studio naming sequence) versions of Visual C++

I'm also pretty certain it did, and actually that VC++5 (that I'd used as a student) didn't. I'm less confident about go to definition and stuff, but I think that was all part and parcel of the same thing, so VC++6 had it and VC++5 didn't.

(Just like today, it would sometimes fail to work, for no obvious reason, and it was impossible to figure out why, so perhaps for this article it had got itself into one of those situations...)

If you want to play Quake for free on Windows 11, try this: https://quake-remake.en.uptodown.com/windows/download

I used VS6 professionally and for private business around 2000-2004, and it was still going strong then. VC++ was great.

There is a dozen of existing Quake ports ready to run the moment you feed them the game files, and you recommend a version re-implemented on top of Xash3D, which is a GoldSrc-compatible engine. Why?

We'd have far fewer apps, far fewer features, far more bugs, far more crashes, far less stability and far more memory safety vulnerabilities. Oh, and Linux and Mac would be far less usable.

The age of performance optimizations was the age of computers as little islands that didn't need to communicate with anybody or anything, and definitely not outside of a homogeneous LAN environment. It was the age of people having just one device, running one OS, with no expectation of data synchronization. Sharing files was, at best, done by sending quarterly_report_v14_approved_by_legal_fixed.doc over email. This is no longer the age we live in.

In the timeline I remember, Microsoft and Windows were routinely criticized for producing bloated and buggy systems. Especially from those who previously used an Amiga or Mac. A new version of Windows inevitably meant buying a whole new computer, along with upgrading the memory midway through it's 3-4 year lifespan.

TortoiseCVS all the way down. Nothing else came close. (this was before git and svn, kids. relax!)

Speaking of MS and source control, I have to shout out this incredibly niche channel [1] that recently covered "Microsoft Delta", a precursor and home grown effort that was eventually abandoned in favour of buying in what would become SourceSafe.

[1] https://www.youtube.com/watch?v=8bNLp_oTuNM

> Visual SourceSafe

Ugh, instant flashbacks and not the good kind.

It was my favorite VCS ever at my first workplace where we deployed .war to prod tomcat from eclipse with one click. No tests, no PRs, no tickets. Customer would call me and I could get a change out to them within 5 minutes. Most (and only!) agile workplace I ever experienced in two decades.

> Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI, being there at the time, and not being able to use some of these systems, due to the amount of money they required.

The earlier Microsoft compilers included since 1985 the debugger CodeView, which could do all that and much more.

Around 1990, the development tools offered by Borland and Microsoft for C and C++ were pretty much equivalent and they both were quite good.

While the Borland languages were like "Turbo-X", the Microsoft languages were like "Quick-X".

I think there was a certain irony, that Borland gave up on Turbo BASIC, while Microsoft gave up on Quick Pascal.

>Which is why, I usually assert I cannot understand the nostalgia of CLI and TUI

Elitism

sometimes you wanna do debugging on a device that has no screen or ethernet port too

(Just like today, it would sometimes fail to work, for no obvious reason, and it was impossible to figure out why, so perhaps for this article it had got itself into one of those situations...)

There is a dozen of existing Quake ports ready to run the moment you feed them the game files, and you recommend a version re-implemented on top of Xash3D, which is a GoldSrc-compatible engine. Why?

Ah yes, VC++6.0

It had such a long lifetime.

I expect it's still there, still being brought back every year for "one last update."

[1] https://www.youtube.com/watch?v=8bNLp_oTuNM

We'd have far fewer apps, far fewer features, far more bugs, far more crashes, far less stability and far more memory safety vulnerabilities. Oh, and Linux and Mac would be far less usable.

TortoiseCVS all the way down. Nothing else came close. (this was before git and svn, kids. relax!)

The problem wasn't the IDE, but win32 API documentation was very poorly written back then and lots of programs suffered because of it.

100% agree. Not only was VC++6 a stand-out product overall, but it was easily the better IDE out of the crop of options at the time.

Sadly, the product line got worse before VSCode came out. Things are much better now.

I would guess that the 1998 era Microsoft compiler didn't have nearly as many warnings as modern compilers do.

A friend of mine installed MS-Windows 95 on a 386 and Weird Al Yankovic nailed it:

But my machine, it's obsolete. It takes an hour just to bring up the screen!

The load times of VC6 versus VSCode... yeah. I would bet you can load a VC6 project faster in OP's environment faster than VSCode could load the same project in a current environment.

I think there was a certain irony, that Borland gave up on Turbo BASIC, while Microsoft gave up on Quick Pascal.

sometimes you wanna do debugging on a device that has no screen or ethernet port too

All the good borland devs were poached by Microsoft. VC5 and 6 were the spiritual successors of the Turbo XXX family of IDEs.

Yes, Turbo Pascal 5.0 introduced those features in 1988.

https://www.youtube.com/watch?v=UNx4dxXptUg

Yes, but if you compare the complexity of (Turbo) Pascal to the complexity of C++... language, environment, libraries and cross-compilation...

(A nice thought-experiment is to ask if Quake could have been coded in TP at all - even if memory hadn't been an issue (I think there was no DOS extender for TP, but I could be wrong).)

In the storm of Doom-Quake mania of the mid 90s there was Chasm: The Rift by a small Ukrainian company Action Forms. And if memory serves me right, it was created in Turbo Pascal. It was late in development and came out in 1997 after Quake, so it didn't get much traction. But the engine, though pretty limited, could produce 3D enemies with interesting effects not found even in Quake.

So Turbo Pascal (with a whole bunch of x86 asm inclusions) was totally capable of producing Quake-level games. I myself, in the late 90s, discovered the hidden capacities when I learned x86 assembly from Peter Abel's book. Once I got rid of the primitive TP BGI library and switched to VGA 13h, it was an unbelievable level up in abilities to manipulate pixels on the screen!

I don't see why it couldn't have been written in Pascal. Plus, Quake was written in C/asm, not C++.

That wasn't the banger for vs6 it was the workflow and muscle memory of the thing. The flow is still unmatched IMHO. It was like avid or photoshop for writing windows software.

Default keys in modern IDEs are basically still the vs assignments from the 5/6 era.

It was the closest Microsoft ever came to making their own emacs or vim. vs6 was like 90% of my screen time as a windows dev in the 90s and 2000s

I find vscode with the right plugins better than vs6 was by a long shot. Helix is pretty amazing too.

> Visual SourceSafe

Ugh, instant flashbacks and not the good kind.

A friend of mine installed MS-Windows 95 on a 386 and Weird Al Yankovic nailed it:

But my machine, it's obsolete. It takes an hour just to bring up the screen!

The load times of VC6 versus VSCode... yeah. I would bet you can load a VC6 project faster in OP's environment faster than VSCode could load the same project in a current environment.

I find vscode with the right plugins better than vs6 was by a long shot. Helix is pretty amazing too.

I don't see why it couldn't have been written in Pascal. Plus, Quake was written in C/asm, not C++.

> Chasm: The Rift

I might be misremembering but I thought it was more of a Doom-style engine with 3d models instead of sprites for the entities, rather than a full 3d engine like Quake.

> Chasm: The Rift

I might be misremembering but I thought it was more of a Doom-style engine with 3d models instead of sprites for the entities, rather than a full 3d engine like Quake.

It was definitely something unorthodox - I remember being confused about how it actually worked.

The first time I played, I thought "It is just like Quake". Then you start to notice that the levels are pretty limited - it is all narrow corridors with rare small chambers and open spaces, no steep elevation changes, no rooms above rooms... Kinda like Doom. But then, father's examination shows sloped surfaces, shelves and bridges - stuff the Doom engine can't do.

Maybe, for level geometry, it is closer to portal rendering engines like Build. Still looks pretty claustrophobic even compared to Doom and Duke Nukem 3D. I feel the Chasm level designers could've got more variety from that technology, but again, maybe that was some fundamental limitation. Or maybe it is just like FPS were designed in the mid 90s.

Monsters, items and weapons are fully 3D, though. With dynamic lighting!

It was definitely something unorthodox - I remember being confused about how it actually worked.

Monsters, items and weapons are fully 3D, though. With dynamic lighting!

Feb 5, 2026

Let's compile Quake like it's 1997!

The first batches of Quake executables, quake.exe and vquake.exe were programmed on HP 712-60 running NeXT and cross-compiled with DJGPP running on a DEC Alpha server 2100A. In June of 1996, having shipped their title but concerned with NeXT stagnation, id Software switched their development stack.

We moved to Intergraph hardware running Windows NT right after shipping Quake.

- John Carmack[1]

The next versions of Quake, winquake.exe, glquake.exe, and QuakeWorld (qwcl.exe and qwsv.exe) were all developed and compiled on Windows NT with Visual C++ 4.X.

This article describes the steps to re-create the experience of building the win32 binaries of Quake as it happened in 1997.

The purist's corner

Depending on the level of historical accuracy you want to reach, you can follow the steps with four environments.

Find an Intergraph RealizM Dual P6-200MHz workstation (good luck).
Find a dual Pentium Pro machine (good luck again but finding a W6-LI is doable).
Use a regular late 90's PC like the Quake PC.
Download Oracle's Virtualbox and create a VM.

I tested these steps both on the Quake PC and in Virtualbox, running either Windows 98SE or Windows NT 4.0.

Installing Windows NT 4

Installing Windows NT 4 is pretty easy since the CD is bootable. Installation took 30 minutes.

I love how minimalist Windows NT startup screen is. It proudly displayed how many CPUs are detected (Windows 95/98 only supports one CPU) and how much RAM is there. There is no silly animation.

Adding a second CPU to a system won't be automatically detected by Windows NT. You need to re-install to get the HAL handling SMP systems. The same thing goes with dual CPU motherboard. On a W6-LI, one need not only to add another Pentium Pro but also a regulator!

Windows NT 4 uses the same UI theme as Windows 9X. The first release, Windows NT 3 used the same UI elements as Windows 3.1. It looked awful.

Installing Visual C++ 6

The Win32 version of Quake were coded on Visual C++ 4.X since it was the most recent version of Microsoft IDE available in mid-96. However, by 1999, the project had been migrated to Visual C++ 6. If you don't have the CD handily available, you can likely find it on the Internet Archive or winworldpc.com.

In a time before "always on" Internet, most software had a product ID to fight piracy.

The installation screen also brings up the next "Visual Studio", combining many development environments. It would soon become THE Microsoft IDE to rule them all.

The installation screen looks off. There is a lot of empty space and the progress bar is awkwardly placed. That is because Microsoft did not expect this to run at the crazy high resolution of 1280x1024 (which id developers likely used on their 21" monitors). It only looks as intended in 640x480 or 800x600.

With VC++6 installed, we now need to get the source code. DO NOT get it from github or transfer the files via FTP. This will mess up the workspace .dsw file. Then VC++6 will be unable to parse it. And it won't even give you an error message, it will just open and show no file / project associated. And you will lose 1/2 a day trying to debug the problem.

Instead, you need to get q1source.zip. It used to be available on id Software's FTP server but now you can get it from the awesome Quake Official Archive maintained by Jason Brownless[2].

With a VM you can transfer files via drag/drop. Alternatively you can use Quick ‘n Easy FTP Server which works on both 9X/NT.

To decompress q1source.zip, you will need WinRar. The v2.50 still works well on 9X/NT.

Now launch VC++6. Select "Open Workspace" then pick "WinQuake.dsw".

Modern versions of Visual Studio use .sln (Solution) and .vcxproj but Visual C++ 6 uses .dsp and .dsw. The dsp contains a single project while the dsw is a workspace pointing to dsp projects.

Start the build with "Rebuild All"

The build will fail because VC6++ was unable to assemble all the .s files which contain the hand-optimized assembly by Michael Abrash.

The .s file are built with "mycoolbuild" "Custom Build" step which relies on ml.exe assembler. It comes with VC++6 Processor Pack (vcpp5.exe).

First install Visual Studio 6.0 Service Pack 5 (vc6sp5.exe). Of course, launching setupsp5.exe will fail. This is because you need to install MDAC 2.5 .

Don't lose an hour trying to download MDAC from somewhere. You just need to run mdac_typ.exe which is in the same folder created when vs6spp5.exe decompressed itself.

Go back and run setupsp5.exe. This time it will work. By now it should feel like you are following the solution of Monkey Island. Nothing makes sense. We are definitely deeeep into the 90s.

More awkwardly small progress bar but this is still progress.

Install VC++6 Processor Pack (vcpp5.exe). Now you should see ml.exe next to cl.exe in VC++6 bin folder. Re-open the project with VC++6 and run "Rebuild All " again. This time it should work.

Yup it built! You need to copy PmProXX.dll, WdirXX.dll, and id1 and the game should launch. You can even build/run QuakeWorld and it works with QSpy!

A darn good IDE

VC++6 is remarkably powerful for 1996. It has features such as "Go to definition", breakpoints, stacktrace, and variable inspections (but no Intellisense auto-completion yet). I never used it but it must have felt like a dream at the time.

References

Hacker Times

Hacker Times

Let's compile Quake like it's 1997

Discussion

Discussion