History of Visual Studio. Part I

From translator
Part 0.5 Continuation

As it turns out, C ++ is a fairly complex language to compile; yes that there - it is difficult even to understand. I remember one conversation about how confusing the pointers to class members can be. The results were amazing 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 more complicated.

At this time, we were busy adding new features to our debugger. As it turned out, the creation of the “Expression Evaluator” for C ++ was also quite a feat. "Calculators" - the animals are quite pleasant. They are used to calculate the values ​​of expressions that would be incorrect in the actual compilation context (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” was supposed to perform all these tasks, being simultaneously similar in spirit to the original language and as responsive as possible.

Did I mention that it could all work slowly?

At that time, I was working on a development environment for the Windows 3.0 platform — another project that was never released — and we had problems with trying to force windows.h compile in any reasonable amount of time.
')
And it was then that a miracle happened with precompiled header files.

I call it a “miracle” because .pch literally 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 header files at the precompilation point was absolutely identical in each compilation unit. This meant that it was possible to divide between modules as information for debugging and navigation, and the internal state of the compiler. The fact that you could get different results in two compilation units after #include header file was a curse to the developers. And the precompiled headers saved us.

Again: I do not name names, but it will suffice to say that I know very well the person who created all this and that it was in the style of “yes it is impossible”, “don’t even try”, “oh yes you did !

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

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


My project was closed. Yes, again. Fortunately, I had a lot of time to be noted.

By the way, Microsoft C 7.0 was, I think, the most difficult (in terms of mass) product ever released by us. I'm not sure that we once tried to roll out so many books.

So we released this bookshelf, and the situation in the meantime has become quite interesting.

We could not release PBW again; we needed a graphical development environment, the basis for which was to be QCW and work was already underway to generalize it and adapt it to our tasks, but there was work there - don't worry about your mother. In addition, in our C ++ implementation there were some important features missing; Microsoft C 7.0 comes with a very limited MFC 1.0 library. We needed to do something about it. And to increase the speed, too, would not hurt.

Each of these tasks was frightening, but I’ll only talk about a few. First, debugging.

Debugging in 16-bit Windows (by the time we finished, it was already Windows 3.1 in the yard) was magic. Win16 was cooperative multitasking and there were no “threads” as such: there was only one thread of execution. Now imagine what it meant: the process could not be stopped in principle. Stop the process - and everything will rise. So if you are trying to make the GUI debugger stop the program being debugged, then it is not worth it. Instead, you had to make everything look as if the program had stopped, but in reality it would continue to work, but it was not the user code that had to execute, but the harmless code provided by the 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 the process windows on the fly and replace WndProc with an implementation that displays a white rectangle instead of full-fledged drawing, storing important messages in the queue for further processing and performing some processing "By default" with the hope that she will not do anything 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 yeah, the development tools ... There was such a thing called Windows NT - you might have heard of it. And we did not want to fence binaries for various environments, so it was necessary to fix the subsystem “DOS extensions” so that you could run console applications of Windows NT in DOS. Impressive. And all this had to be the good old DOS. Twice impressive. But we did it (not without the help of a third party, which I will not name).

And yes, the development tools were slow. We podnuzhilis and stuffed information for CodeView in. Pdb-files in order to facilitate the loss of information, which "provided" cvpack . This is a few other changes - and for the first time in quite a long time, we have the fastest C ++ compiler on the market (at least according to our internal laboratory; your feelings may differ).

While we were doing the compiler, MFC was doing quite well. There appeared a designer, a couple of important craftsmen and the whole farm began to look like VB: drew, clicked, dragged - that's it!

I have to say a few words about VB.

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

The fact that all products wanted to be similar to Visual Basic and changed the name to Visual something-there was a reason. Visual Basic was just very good. Rarely did anyone have an interpreter that provided feedback on the fly, but everyone wanted to recreate key elements of Visual Basic. By the time we finished, Visual Basic was already everywhere, and it deeply influenced design and libraries. We did not have 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 remove our hat to the guys from the application compatibility department: we were not so easy to port), added support for OLE and ODBC. Clients liked it all a lot 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 was was really cool.

While these events were taking place, a part of our team was working on another “really cool” thing: they ported our entire farm to 32-bit Windows NT. It was planned that the release will take place at the time 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 undervalued work.

This is how Visual C ++ 1.1 appeared.

Some not entirely conscious personalities believe that version 1.1 was not a complete product, but was “just a ported product.” These are people who obviously do not understand anything in the development tools. In the system version 1.1 was a completely new, 32-bit, compiler backend. 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 near and far ( far and near ) pointers disappeared. And yes, there, it was all small things, and version 1.1 was just a port.

This was in 1993, the product was called Barracuda. Personally, I hardly noticed there, but the main developers deserve special mention in 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”. Without it, there would be nothing. But just as important was the next release, which I will write about next time. Visual C ++ 2.0 “Dolphin” was the first to integrate development tools into a single software product.