"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.
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.
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 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.
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
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."
Before the .Net era, there were millions of programmers who were experts in VB. In fact, VB6 was the defacto tool to build desktop apps.
Then Microsoft decided to compete with the new-age rivals: Java and CORBA. So it expanded COM into DCOM and then further into COM+, and eventually released the .Net platform.
Suddenly, those millions of programmers and their built desktop apps were obsolete, as they had to race to understand .Net and learn how to use it to build new apps and replacements for the old VB6 apps.
And somewhere along the way, many of them decided it wasn't worth the struggle (because .Net was a nightmare to install as client apps on Windows machines; even the deployment scripts had becom3 too complex), and they migrated to other tools (Java, Python, Perl, Ruby on Rails, PHP, etc.) or to non-programming jobs (usually management).
Thus, within a few years, Microsoft had veritably killed the programming industry it took decades to build and nurture (and yes, Microsoft's decision to turn a blind eye - as its Windows OSes, MS Office and Visual Studio (VB & VC++) tools were pirated across the world, churning out millions of programmers and users familiar with its products as they used the pirated versions at school, college. home and office - that was also a deliberate decision by Microsoft during this halycon era).
But I feel .Net became too big of a beast even for mighty Microsoft to handle. As concerns grew over the performance aspects and innumerable dependencies of the .Net platform and related tools (Azure, SSIS, SSRS, etc.), the world started to shift away from Microsoft's tools, and that's perhaps why Microsoft finally knuckled under and embraced the open-source ecosystem it had openly hated for decades. VSCode, etc., are Microsoft's last-ditch attempts to have some relevancy in the programming industry.
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]
> 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.
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).
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.
> 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)
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?
"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.
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 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.
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.
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
Didn't Smalltalk environments have those features ages ago already?
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."
Could be worse. It’s finally gone now but I believe that my employer used VS6 as late as 2025.
VC++6 was the first IDE I ever used: as a kid, I was gifted a CD that had a version of it included. What a great tool to have for the time.
I would go on to use Bloodshed Dev-C++ next. Which was also quite great for the time.
Before the .Net era, there were millions of programmers who were experts in VB. In fact, VB6 was the defacto tool to build desktop apps.
Then Microsoft decided to compete with the new-age rivals: Java and CORBA. So it expanded COM into DCOM and then further into COM+, and eventually released the .Net platform.
Suddenly, those millions of programmers and their built desktop apps were obsolete, as they had to race to understand .Net and learn how to use it to build new apps and replacements for the old VB6 apps.
And somewhere along the way, many of them decided it wasn't worth the struggle (because .Net was a nightmare to install as client apps on Windows machines; even the deployment scripts had becom3 too complex), and they migrated to other tools (Java, Python, Perl, Ruby on Rails, PHP, etc.) or to non-programming jobs (usually management).
Thus, within a few years, Microsoft had veritably killed the programming industry it took decades to build and nurture (and yes, Microsoft's decision to turn a blind eye - as its Windows OSes, MS Office and Visual Studio (VB & VC++) tools were pirated across the world, churning out millions of programmers and users familiar with its products as they used the pirated versions at school, college. home and office - that was also a deliberate decision by Microsoft during this halycon era).
But I feel .Net became too big of a beast even for mighty Microsoft to handle. As concerns grew over the performance aspects and innumerable dependencies of the .Net platform and related tools (Azure, SSIS, SSRS, etc.), the world started to shift away from Microsoft's tools, and that's perhaps why Microsoft finally knuckled under and embraced the open-source ecosystem it had openly hated for decades. VSCode, etc., are Microsoft's last-ditch attempts to have some relevancy in the programming industry.
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.
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).
I would guess that the 1998 era Microsoft compiler didn't have nearly as many warnings as modern compilers do.
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.
Man, I love the Visual C++ and Visual J++ interface so much. It was so fast and super clear.
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.
Article from February OP
Some more discussion then: https://news.ycombinator.com/item?id=46936274
> 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)
If you want to play Quake for free on Windows 11, try this: https://quake-remake.en.uptodown.com/windows/download
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?