My History of Visual Studio (Part 2)
[All the other Parts: History of Visual Studio]
Visual C++ 2.0, “Dolphin” was a very ambitious release. We were really happy with VC1 but there were quite a few things that were entirely unsatisfactory. One of them, maybe the most important, was the fact that window management in the thing was just a nightmare. VC1 used the standard MDI interface for all the windows, including the tool windows like registers, watch, output, and so forth – that was just not adequate because you found key display windows were swimming in a sea of documents many of which had been opened by the debugger and so forth. It was quite bad.
But let’s talk about some of the other things that had been going on before we get into that.
The BASIC compiler team (the non-visual basic?) delivered another solid release, but that didn’t integrate with the VC shell. It was for making standalone executables ala the other command line tools. On the other hand the FORTRAN team delivered the first Fortran Powerstation release – a little miracle in its own right. It used a lot of Dos Extension technique and some slick remote debugging tricks to debug in it from the GUI and tweaked the visual project system and yowsa you get a modern looking (at that time) Fortran release. Pretty impressive stuff. COBOL was still humming along at a regular cadence and let’s not forget MASM, the ultimate (literally) release I think and the little known other assembler ML that I think had only one release – but it was quite a feat in and of itself. Try rationalizing all the ad hoc parsing rules for MASM and ML is what comes out. But maybe we didn’t really need another macro assembler very badly by then; it’s late 1993 now remember.
Speaking of 1993, there were new versions of Office out there and they had a slick feature – docking toolbars. We decided that was the answer to the windowing problems we had in VC – go one up on docking toolbars and allow docking windows. Now you could dock your window to the side, bottom, top… really slick.
I say “we decided” but I should probably say that the foundation of this ambitious effort didn’t actually come directly from the VC team, it was the App Studio team that suggested it and built the initial scaffolding. And the ambition was even bigger.
Previously our IDE was a suite of integrated applications but we wanted to change that. The shell’s plans were to allow us to host all our features in one application that included resource editing (forms too), plus text, project, debug, build, and help all in one application. And – wait for it – it had to be modular so that other languages like Fortran, Basic, and COBOL could plug in. This shell provided a core set of services those packages could use, like menus, toolbars, toolwindows, and so forth. Does this sound at all familiar VS Extenders? More on that later.
But wait, that’s not all!
We also wanted to deliver tools for the Macintosh, anybody remember WLM? I wrote some Mac apps with it myself! PowerPC, 680x0 compilers and debuggers, no problem. Remote debugging to the rescue! Oh and let’s not forget support for the MIPS and Alpha as well.
Do you think we’re nuts yet? Because we aren’t done.
While we’re at it, the Visual C++ codebase, which was written in C (remember the C++ compiler wasn’t yet done when it started and it began life as Quick C for Windows), had to be first ported to C++ (which helpfully found lots of bugs) and then turned from a regular windows application into an MFC library that could be used by the new shell. And the whole product had to basically keep working while this was going on because VC2 had to be able to build and debug itself.
Oh and naturally we’re delivering new libraries, and a new MFC (MFC 3.0) plus since we’re going to touch all that code anyway may as well port it all to 32 bits (we had Barracuda to start with but many of the other pieces that were merging in were only 16 bit).
I’m still not done yet.
We also had some big themes around “edit and go”, “simplifying OLE”, and “beyond files” – meaning we wanted the build cycle to be tight and easy, and fast, we wanted to make all those new OLE features like embedding and whatnot simpler, and we wanted you to be able to navigate your codebase as much as possible without worrying about what files you had put it in. I added more browsing features, many C++ oriented ones at that time; we did some cool debugging across OLE RPC channels, and more. I remember a lot of debugging features because I was close to them. Things like data tips, and autoexpand, and the automatic watch window – I was the lead debugger developer during this time.
Think that’s enough for one release? We’re still not done!
More language features hit the tools, just in case you think those guys are slacking off – namespaces was the first I think but this version also lands the major language features -- Templates and Exception Handling. Hugely valuable and EH was fully integrated into the Windows NT SEH model which was no mean feat!
We’re going to have one worldwide binary, the same bits ship in Japan, Europe and the US except for localized resources – the J version and the English version are the same! That had never been done before to my knowledge.
And, the cherry on top, there was a little operating system release coming out that you may have heard of, we called it “Chicago”, but it hit the market as Windows 95. We had to be the main SDK for that operating system, which meant fixing all kinds of bugs because Chicago was much less forgiving than Windows NT.
Wow, that seems totally nuts but we did that, and more. We did only minor things to the 16 bit tools from that point forward, servicing VC 1.52 (1.52a, b, and c) but we did wicked demos for the 32 bit suite, so many platforms, and a truly unified IDE, all the tools in one place.
We caught some breaks in the industry at that time as well, 32 bit was hot, 1.52 was good enough, that other tool vendor was spending a lot of time thinking about (ironically) OS/2, which, being who we were, we thought was a losing strategy. But wow, the Delphi demos! Amazing stuff! It’s a good thing the VB team was getting busy too – 32 bit tools, and OCX story to compliment their VBX story, a great ecosystem.
I think Visual C++ 1.0 may have been the most technically challenging IDE we ever delivered because of the amazingly weird things we had to do to make it work on that operating system. But I think Visual C++ 2.0 was just as important, if not more so, because of how much we moved our own technology forward and the sheer massive volume of deliverables. Both were a lot of long hours; and there were subscription releases 2.1 and 2.2 yet to come.
[See The Documentary on Channel 9!
Comments
Anonymous
October 06, 2009
The comment has been removedAnonymous
October 07, 2009
[quote]It’s a good thing the VB team was getting busy too – 32 bit tools, and OCX story to compliment their VBX story, a great ecosystem.[/quote] I think you got too ironic in that sentence.Anonymous
October 07, 2009
How clumsy of me, I didn't mean to be ironic, I meant it as a genuine compliment.Anonymous
October 15, 2009
Having lost track of how many s/w projects I've worked on (i.e. I'm really old), VC2 remains as one of my favorites. We had such an experienced team across the board that we were able to do all you write about <strong>without a spec!</strong> It was to great to put another nail in Phillipe's coffin.