Fifty Years of Microsoft Developer Tools

Note this is all pretty much from memory so apologies if I got some of the dates and details wrong. I hope it’s mostly right. I made various references to My History of Visual Studio which you could also read, but it’s from 2009 so it’s dated.

1975: BASIC for Altair 8800

The first programming language created by Microsoft, originally designed for the Altair 8800 microcomputer. This was Microsoft’s entry into software development tools.

This baby was fully configurable to fit in 4K or a luxurious 8K. The beauty of having 4k of memory is that you can be on a first name basis with every byte and that’s something I actually miss. These versions sported integer AND floating point options.

1976–early ’80s — OEM Basics

Microsoft licensed BASIC to lots of companies like Apple, Commodore, and even Tandy. These had many names but usually announced themselves as Microsoft Basic in one way or another. Sometimes sneakily. MBASIC for CP/M and BASICA for the IBM PC became pretty important. But many of us cut our teeth on Apple Basic or Commodore Basic. The sexier GW-BASIC also came in this era. FWIW: I never heard anyone seriously call it Gee Whiz Basic — it was always Greg Whitten Basic. You can make up your own mind.

1983: Microsoft C 1.0

Microsoft originally licensed Lattice C 2.14 and rebranded it as Microsoft C 1.0 in 1983. This compiler was essentially Lattice code with Microsoft branding, plus MS’s own tools bundled in. But we didn’t stay on the Lattice codebase for long.

Around Microsoft C 3.0 (1985), Microsoft rewrote the compiler back end. This effort was called C-Merge — the idea being to merge various internal compiler technologies into a new shared code-generation “back end.” The C-Merge back end later became the core backend for bunches of compilers, including: Microsoft C, C++, QuickC, Fortran, Pascal and maybe even COBOL (I’m not sure about that one). It was the mainstay until the Tuple Compiler became a thing.

1985: Microsoft QuickBASIC

This was still a character oriented system not GUI but it included a sort of GUI-ish UI based on “Character Oriented Windows” affectionately called COW. There was a flavor that included page swapping so that was of course COWS.

“QB” had an integrated environment, including a built-in editor, debugger, and a compiler, all combined in a single product. It also (eventually) supported structured programming and (eventually) object-oriented concepts.

If I recall correctly it was not powered by the same engine that gave us Embedded Basic which also, later, gave us Visual Basic.

QB 4.5 was the pinnacle of this tech, and was very popular. The COW “CUI” was used in all kinds of places.

1985: Codeview Debugger

This was the seed of MS debugging technology and have us the NBxx debugger formats (Norris/Borman). The first versions of Codeview were for DOS of course and it played the usual game of hiding in the high memory to stay out of the way of the running program. This was back when you could imagine doing a full debugger with 10s of K of memory and good swapping to the debug file. It was crucial to be able to debug without actually having all the information resident — a technique that was sadly lost over time. Being starved for memory had a way of making you more awesome. Still, this was one of the first good quality visual debuggers many people would ever experience.

1986–1990 ish Microsoft BASIC Compiler (Professional Development System, or PDS)

This is “BC” the basic compiler a peer to “CL” the C compiler. Also using C Merge. It produced high quality native code for Basic.

Naturally you could debug with Codeview because it barely knew the difference — it’s all a debugable .exe to Codeview.

1991: Visual Basic 1.0 (“Thunder”)

VB changed everything. The ease with which you could make all kinds of forms-based applications. The availablity of every kind of access via extension controls (VBX). Responsive GUI, interactive graphical debugging. Easy modular code management. It was one of the first environments to deliver on rapid application development (RAD) on Windows. The ease with which you could do — whatever was unparelleled.

1990, 1992: Microsoft C6.0 then C/C++ 7.0

C6 included tons of work on the CMerge back end, really pushing its optimization features to the limit. By late in the C6 cycle work was already underway to support C++ natively and this was supposed to take only a few months. There was even an effort to rewrite all of the C compiler interally supposedly just with 1 or 2 people which was never going to go anywhere. What did happen was two versions with the programmers workbench (the zenith of the CUI IDE’s) and Codeview redone on that same technology. Codeview learned more “how to hide in high memory” tricks in this time. Tons of amazing work to make builds look like they were integrated even thoug the IDE had actually exited (it had to, for the memory).

C7 was the first C++ compiler produced by Microsoft, and was the foundation of the C++ language for the future. Though we did consider rebooting it at least once and probably other times. The project to reconsider the rebooting with the EDG front end. The proposals were “Phoenix” where the new compiler rises from the ashes of the old (which has nothing to do with the Phoenix back end project that came later but had the same name, this is a front end change) and “Eel” the “electric shock” of adapting the EDG front end but giving it features like precompiled headers and all the others things unique to the MS Front end. “Phoenix” won out and AFAIK it’s still the MS front end. Except not in Intellisense, that’s powered by EDG!

MFC 1.0 shipped with C7 — a huge milestone in and of itself!

1991: Quick C for Windows

The first GUI IDE for Windows, it’s barely remembered. It’s core, debugger, editor, all of it, is what became Visual C++ 1.0. It was supposed to be very easy to do this but it turned into quite a death march because generalizing applicaiton development to creating full Windows binaries in an IDE that was itself running on Windows was no mean feat. Just capturing build results in general was a small miracle. But it all started here. It was focused. It was lean. It did it’s job well. It inspired what all the Visual C family…

1993: Visual C++ “Caviar”

Visual C++ was the first Microsoft development environment to fully support the development of native Windows applications using C/C++. It included an integrated development environment (IDE) and powerful tools for GUI and API integration, a major step forward for Windows application development.

I’ve written elsewhere about the miracle that is soft-mode debugging in Windows 3.x (where there are no threads and therefore nothing can truly stop) so I won’t do it again.

This version included App Studio, for resource creation and behind the scenes a slick build system was doing the job. At least there was enough memory — we could run in protected mode. But everything was super challenging.

1995: Visual Basic 4.0

Visual Basic 4.0 introduced support for 32-bit applications and provided the first real support for Windows 95. It also added the ability to create ActiveX controls, enhancing software modularity and reusability.

1995: Visual C++ 2.0 “Dolphin”

The first version of Visual C that supported 32 bit development was actually VC 1.1 for NT “Barracuda” or just “Cuda”. Dolphin built on this adding tons of new GUI. A reusable shell. An extension model. Docking windows. It was a fully integrated environment with one tool able to do everything you needed from debugging to resource creation and more MCF wizards than ever. Dolphin would be the basis of the VC toolchain until VC6 — the last before the .NET series. There were Dolphin plugins for Fortran, Basic, and more… Dolphin included the new “Tuple Compiler” back end which became the basis of all future back ends (alas the Phoenix back end never quick made it to mainstream).

1998: Visual Basic 6.0 and Visual C++ 6.0

This was the zenith of these technologies. VB6 was beloved by developers and it was in a way so good that nobody wanted to move off of it. Likewise VC6 with its ridiculously simple install and astonishing feature like Edit and Continue for native code (!!) was the zenith of this toolchain.

2002: .NET Framework and Visual Studio.NET

The .NET Framework introduced a new approach to application development on Windows. It brought a unified programming model for developing both web and desktop applications. Visual Studio 2002 served as the IDE for the .NET platform and included tools for C#, VB.NET, and ASP.NET.

The introduction of C# as a part of the .NET platform marked a major innovation in modern software development. C# was designed to be a modern, object-oriented, and type-safe language, combining features of C++ and Java while being tightly integrated into the .NET Framework.

This version of Visual Studio introduced enhancements for .NET development, but that would be a major understatement. It was a foundational release, with new COM based extensibility and the “everything is an extension” model. This was the first time all the languages were in the same unified environment and although the first release was not loved as much as the standalone versions had been its successors defined the Visual Studio Family. Books could be (and have been) written about this my own “My History of Visual Studio” was half a novel in length…

In the interest of brevity, I’ll only say that VS2005 and VS2008 continued on this path but they were each multi-year releases with mountains of work behind them. But in some sense, they were incremental releases compared with VS2002 and then VS2010.

[in the original version of this entry I mixed up my notes on 2005 and 2002 and ascribed things to the wrong ones, I’ve cleaned that up in the above]

2010: Visual Studio 2010

After Visual Studio 2008, it became clear that we needed to do a “remodel” — we picked 4 pillars

• Scalable/Frugal: Visual Studio should scale from small to large projects, offering performance and responsiveness at all project sizes.
• Modern: Built with new technologies that had a future, especially GUI
• Extensible: The IDE should allow developers to extend and customize it to fit their needs.
• Connected: Visual Studio should integrate with cloud services, collaboration tools, and modern distributed development workflows.

Specifically, the remodel called for a new extensible editor, a replacement for the shell written in WPF, a unified model for language services, full support for managed extensions, support for multi-targeting, including using designers for different versions of the .NET framework at the same time, and out of process extensions for any use especially designing for Office. I could go on for hours.

VS2010 was supposed to create a baseline we could use for at least a decade and I’m happy to say that it did that. But not without challenges. Memory was always tight and the pressure to go to 64 bits was there from the beginning — but that was a monumental effort that would need over a decade to reach fruition.

There were bi-yearly releases of this flavor of Visual Studio in 2015, 2017, 2019… with more designers and more platforms supported. I don’t want to trivialize things like Azure support but this article is already getting long.

2015: Visual Studio Code

I might call this a quiet initial release but VS Code roars now. This is a complete re-imagining of how to build an IDE using Electron. The degree of extensibility is massive. The ease with which new extensions can be created is unparalled. I’ve gone on record as saying that I believe this is ultimately the future of Visual Studio as it increasingly inhabits the space that is most needed and most popular and it’s ridiculously easy to adopt unique workflows. I mean even Meta uses VS Code, can anyone imagine them switching to Visual Studio and solution based development for their monorepo? VSCode can literally anywhere and be whatever you need it to be. Async everything. Multiprocess everything. Remote access everything. I love it and I was once Chief Architect of Visual Studio so…

2021: Visual Studio 2022

12 Years later, Visual Studio 2022 was the first 64-bit version of the IDE, allowing it to handle larger codebases and workloads more efficiently. It also introduced AI-powered capabilities, improved GitHub workflows, and support for .NET 6 and .NET MAUI for cross-platform development. The effort required to port all those extensions to 64 bits and then get the extension ecosystem rebooted cannot be overstated.

2022: GitHub Copilot (GHCP)

I have to end on this note. I never in a million years would have guessed that in my lifetime I could type prompts and get code. I like GHCP’s ability to auto-guess intent but that’s actually not the killer productivity feature. The ability to ask questions and have it find issues like “where did I forget to check for a return code” and then even move those flows into CICD… those things don’t save minutes, they save days or even weeks. Quick prototypes or things you wouldn’t bother coding because it’s too much of a pain but they become trivial with a prompt change the way you think about coding — here’s one just last week: “Write a python program that shows a log normal distribution with 1000 data points and also show what experiments drawn from that same distribution might look like with 20 samples in each. Show the observed mean, standard distribution, and P75 and P90. Plot everything on a log scale.”

30 seconds later I had python that ran and i got my screen shots for my slides.

OK it’s not a device driver, but this changes everything.

Man… I’m so lucky I got to see this stuff. I was only 11 years old still learning basic math in 1975 but 5 years later I was coding in Commodore Basic and disassembling ROMs written by Bill and Paul to learn how to code in assembly.

What a ride.

Happy 50th Microsoft!