History of Visual Studio. Part I

From the translator
Continuation of Part 0.5

As it turns out, C ++ is a rather complicated language to compile; what’s there - it’s difficult even to understand. I remember one conversation about how confusing pointers to class members can be. The results were awesome and boiled down to the fact that pointers can point to members defined in a virtual base class. This is all C ++: individual things seem simple, but as soon as you start combining them with others, things get complicated right away.

At this time, we were busy adding new features to our debugger. As it turned out, the creation of the “Expression Calculator” for C ++ was also quite a feat. "Calculators" - the animals are pretty nice. They are used to calculate the values ​​of expressions that in the actual compilation context would be incorrect expressions (for example, calculating the value of a static variable outside the current scope, or calculating the value of a global variable from another module). The “calculator” had to perform all these tasks, simultaneously being similar in spirit to the source language and as responsive as possible.

Did I mention that this could all work slowly?

At that time, I was working on a development environment for the Windows 3.0 platform - another project that was not yet released - and we had problems with trying to force windows.hcompilation at any acceptable length of time.

And just then, a miracle happened with precompiled header files.

I call it a “miracle” because.pchliterally revolutionized our approaches to software development. Other systems in the past used a similar approach, but ours was smarter. For example, due to the fact that our system was based on images of compiled header files, it ensured that the overall effect of the header files at the precompilation point was absolutely identical in each compilation unit. This meant that it was possible to separate between the modules information for debugging and navigation, as well as the internal state of the compiler. The fact that after including ( #include) the header file in two compilation units you could get different results was the curse of the developers. And the precompiled headers saved us.

Again: I don’t give names, but it’s enough to say that I know very well the person who created all this and that it was in the style of “yes it’s impossible”, “don’t even try”, “oh, you did it ! "

At the same time, another team was working on a product called Quick C for Windows, which later turned out to be incredibly important. A lot of work has been put into this product; he had the first real IDE for Windows and real debugging. However, all this was incomplete, and a little later I will say why bringing all this to mind was not an easy task.

While the trial and the case, that other company also did not stand still, but released cool C ++ compilers. Until 1992, we had nothing to answer: we released Microsoft C 7.0 based on PBW and, literally at that moment, Quick C for Windows (QCW).


My project was closed. Yes, again. Fortunately, I managed to check in a lot.

By the way, Microsoft C 7.0 was, I think, the heaviest (from the point of view of mass) product we have ever released. I'm not sure that we once tried to roll out so many books.

So we released this bookshelf, and the atmosphere in the meantime became quite interesting.

We couldn’t release PBW again; we needed a graphical development environment, the basis for which was to become QCW and work was already underway to generalize it and adapt it to our tasks, but there was work there - don't worry. In addition, our C ++ implementation lacked some important features; Microsoft C 7.0 delivered a very limited MFC 1.0 library. We had to do something about it. And to increase the speed would also not hurt.

Each of these tasks was intimidating, but I will only talk about a few. The first is debugging.

Debugging on 16-bit Windows (by the time we finished, Windows 3.1 was already in the yard) was magic. Win16 had cooperative multitaskingand there were no "threads" as such: there was a single thread of execution. Now imagine what that meant: the process could not be stopped in principle. Stop the process and everything will get up. So if you are trying to get the GUI debugger to stop the program being debugged, then this was not worth it. Instead, you had to make it look like the program stopped, but in reality it would continue to work, but it should not execute user code, but harmless code provided by a debugger that would continue to process window messages.

Part of this magic was that when the process being debugged “stopped”, it was necessary to “subclass” all process windows and replaceWndProcto an implementation that displays a white rectangle instead of a full rendering, saves important messages in a queue for further processing and generally performs some kind of “default” processing with the hope that it will do nothing wrong. The focus became even more interesting when the application tried to send DDE or OLE messages. This was the “miracle” of Soft Mode debugging.

Oh yes, development tools ... There was such a thing called Windows NT - you may have heard of it. And we did not want to make binaries for different environments, so we had to fix the “DOS extension” subsystem so that we could run Windows NT console applications in DOS. Impressive And all this should have been a good old DOS. Twice impressive. But we did it (not without the help of a third party, which I will not call).

And yes, development tools were slow. We pulled ourselves up and stuffed the information for CodeView into .pdb-files in order to facilitate the loss of information that "provided"cvpack. This, several other changes, and for the first time in quite a while, we have the fastest C ++ compiler on the market (at least according to our internal laboratory; your feelings may vary).

While we were doing the compiler, MFC was doing pretty well. A designer appeared there, a couple of important masters and the whole farm began to look like VB: he drew, clicked, dragged - done!

I must say a few words about VB.

The code name Visual Basic 1.0 was Thunder. When I first heard him, it seemed to me somewhat arrogant. I thought their behavior in the style of “Feel the power of thunder!” it was just the arrogant boast of boys. And I was wrong.

There was a reason for the fact that all products wanted to be similar to Visual Basic and changed their name to Visual something-there. Visual Basic was just very good. Rarely did anyone have an interpreter that provided feedback on the fly, but everyone sought to recreate the key elements of Visual Basic. By the time we finished, Visual Basic was already everywhere, and it deeply influenced design and libraries. We didn’t get Visual Basic, but something Visual: it was Visual C ++ (if you still follow: Microsoft C 8.0 and MFC 2.0).

This was followed by a rather interesting release, in which we made our 16-bit tools work under Windows NT in 16-bit mode (we take our hat off to the guys from the application compatibility department: it was not so easy to port us), we added support for OLE and ODBC. Clients liked this all very much and for the first time since working at Microsoft, I clearly felt that we had an advantage over competitors in the field of development tools for C / C ++. The language was not yet complete, but what it was was really cool.

While these events were taking place, part of our team was working on another “really cool” thing: they ported our entire economy to 32-bit Windows NT. It was planned that the release will take place at the time of release of Windows NT 3.5. This, the release of a localized version for Japan, as well as, in principle, support for internationalization, was an important but completely underestimated work.

This is how Visual C ++ 1.1 came about.

Some not-so-conscious individuals believe that version 1.1 was not a full-fledged product, but was "just a ported product." These are people who obviously do not understand anything in the development tools. The version 1.1 system had a completely new, 32-bit, backend compiler. We all know how portable these backends are. And yes, there was a completely new debugger with a completely different mechanism of operation: in Windows NT there were real threads that could be stopped. And again: the memory model for the entire program was different, since the near and far ( farand near) pointers disappeared . And so yes, cho there, it was all small things, and version 1.1 was just a port.

It was in 1993, the product was called Barracuda. Personally, I hardly noticed there, but the main developers deserve a separate mention in the History.

The situation promised to be very interesting; The most important release of the C ++ toolkit in my memory was Visual C ++ 1.0 “Caviar”. If it weren’t, there would be nothing. But just as important was the next release, which I will write about next time. Visual C ++ 2.0 “Dolphin” for the first time and actually integrated development tools into one software product.