History of Visual Studio. Part II

From translator
This is the second part of the Rico Mariani story. The beginning was here and here .

Visual C ++ 2.0 (codename Dolphin, Dolphin) was a very ambitious project. We were happy to release Visual C ++ 1.0, but there were a few moments that absolutely did not suit us. One of them — perhaps the most important — was that working with windows was a nightmare. Visual C ++ 1.0 used a standard multi-window MDI interface for all windows, including such things as the register window, value tracking window, output window, etc. As a result, these key tools simply drowned in the flow of windows opened by the editor and debugger. It was all very unpleasant.

Let us, however, first talk about what happened before we began to fight it.

The team that developed the Basic compiler rolled out another full release, but it was not integrated with the Visual C shell; his main task was to create standalone executable files. On the other hand, the Fortran development team released the first version of Fortran Powerstation, which was a miracle in its attitude. This product fully utilized the familiar “DOS Extension” mechanism, some tricks that allowed debugging in GUI mode, as well as an improved project system. It was quite modern by the standards of the development system. The development of Cobol progressed with its measured step. And let's not forget about MASM and the little-known assembler called ML, which, in my opinion, had only one release, which cost, however, a lot. ML was the result of the rationalization of the MASM parsing rules, but at the end of 1993 we didn’t really need another macro assembler.

Since we are talking about 1993, it is worth mentioning that by that time new versions of Microsoft Office came out with a cool new feature: docked toolbars. We decided that they would solve all our UI problems in Visual C: just add toolbars and allow docking windows. Really comfortable.
')
I say “we decided”, but in fact the basis for this was laid by the App Studio team. The ideas of those guys went even further in their ambition.

In the past, our IDE was a set of integrated applications, but we wanted to make a difference. It was planned that a resource and form editor, a text editor, a project system, a debugger, and help would work within a single shell. And to top it all, it had to be modular so that other languages, such as Fortran, Basic or Cobol, could be built into this shell. The latter was supposed to provide a set of basic services, as well as provide support for menus, toolbars and other things. Sounds familiar, doesn't it?

But that's not all!

Among other things, we wanted to have development tools for Macintosh. Does anyone remember WLM? I myself wrote several programs with its help. Compilers for PowerPC and 680x0, remote debugging is not a problem. And yes, do not forget about the support of MIPS and Alpha.

If you already think that we are crazy, then in vain - I have not finished.

While we were thinking about everything, the code of the Visual C ++ environment written in C had to be pre-ported to C ++, which was done - and we fixed a bunch of errors in the process. In addition, from a normal application, it had to be turned into an MFC library, which could be used in a new shell. And the whole product, generally speaking, had to work with it, because Visual C ++ 2.0 should have been able to compile and debug itself.

And it goes without saying that we planned to release new versions of libraries (MFC 3.0, for example), since we still had to edit their code for porting to 32 bits.

And I still haven't finished.

We had big plans for “Edit and Go”, “OLE simplifications” and “files aside!”. The latter implied that we planned to simplify and accelerate the development cycle as much as possible, simplify the OLE mechanism and all that, and facilitate navigation through the source code. I added many new features — this time exclusively related to C ++ — to the navigation system; we did a lot of interesting things in connection with debugging via OLE RPC channels, added an “Automatic Watch” window. At that moment I was a lead programmer in the debugger development team, and therefore I remember everything so clearly.

Think enough for one release? Not.

The language itself was also developing, and the programmers responsible for the development tools did not rattle around the pears. Namespaces were the first major innovation, but in addition to them, there were also patterns and exception handling, the latter being integrated with Windows NT SEH .

For different language versions, we planned to have the same binary, and localize the resource files. English and Japanese versions were identical! As far as I know, no one has done anything like that before.

And, like the cherry on top of this “innovation cake”, there was the following. You may have heard about such an operating system as Chicago, released, however, under the name Windows 95. So our product was destined to become an SDK for this operating system. This meant that it was necessary to urgently fix a bunch of errors, since Windows 95 was much more unforgivable compared to Windows NT.

Whew, it all looks like madness, but in fact we did a lot more work. For 16-bit tools, we have since released only service releases, and for 32-bit platforms, we have done quite a freak demonstration: we also had a truly integrated development environment!

At that time, we had a little respite. 32 bits was hot news, Visual C ++ 1.52 was good enough in itself, that other software vendor spent a lot of time supporting OS / 2, which we thought was an operating system that was losing its strategic advantage. But Delphi demonstrations - it was something! But we had something to oppose, because the Visual Basic team also did not sit idle: 32-bit development tools and the whole story with OCX . The result was a cool ecosystem.

I think Visual C ++ 1.0 was the most technically complex IDE we had to release. It was difficult because we had to do incredible things to make it work on the operating systems of that time. But Visual C ++ 2.0 was just as, if not more, an important medium — so much we have advanced technologically. We spent a lot of development time, and we were waiting for versions 2.1 and 2.2.