History of Visual Studio. Part 0.5

There is no and cannot be a single “History of the emergence of Visual Studio”: each person involved in its creation has its own version. If you adapt a famous quote, then "In the Naked City there are many stories ...".

Most likely, the story of Visual Studio began in 1975, when Bill and Paul decided to create BASIC. Perhaps it was possible to start earlier, but I think that 1975 is the farthest year that you can talk about, while still having in mind Visual Studio. That was the time when Microsoft decided to have programs for developers, and not engage in, say, automation of toasters.

Old-timers like me used MS-BASIC on various microcomputers; I personally used Commodore PET(I started on the PET 2001 model, whose name was particularly ironic given how it was unlike 21st century computers ... But I got distracted). MS-BASIC could be used on Apple or TRS-80, and many of us tested our strength on these computers. Immediate feedback and some personal programming experience - all this left a lasting impression on us.

Those who really wanted to know what makes these computers tick (yes, literally) spent countless hours disassembling the programs that controlled them in parts. I can proudly say that Bill Gates taught me assembler for 6502 and thus prepared me for work at Microsoft.

The 80s were an era of incredible diversity in computers, and as a result, in development tools. Many people have created programming languages, but I will not list here any names in order to avoid problems with brand owners. However, I am sure that you will be able to recall several different systems of that time - I immediately remembered about 5 pieces.

If you were developing development tools for a PC that began to dominate in the mid-80s, your life was especially difficult. The x86 instruction set was not particularly beautiful; architecture with 64 KB memory segments already caused a headache by its existence; attempts to squeeze out all possible performance from the then existing processors took the form of fancy constructions in programming languages.

It’s 1988 and I, just from college, got to Microsoft. In zashashnik I had a Pascal compiler (developed jointly with 4 of my friends), and in addition - assembler and linker. But I wasn’t ready for

char _near * far pascal GetString(char far * far * lplpch)

* This source code was highlighted with Source Code Highlighter.

For starters, what the hell pascaldid the keyword do in a C program? The only visual (Visual, see the topic) thing in all this rampant near and far ("near" and "far") was the need for bifocal lenses.

Here you should go back a bit.

The compiler I used at Microsoft in 1988 was Microsoft C 5.1, a nice little language like that; perhaps one of our most successful releases. Until that time, Microsoft was at the zenith of its glory in the field of programming languages, but then a certain company with the name starting with B. encroached on this pie. Good products, good prices - all this greatly contributed to the motivation of people from Buildings 3 and 4 on the Microsoft campus in Redmond .

So, Microsoft C already had 5 big release. BASIC’s compiler, BC6, was just launched, and Quick Basic “QB4” was on its way.

You may already have noticed that I am not even mentioning C ++. We still have to get to it.

Where am I? Oh yes, 1988. The project I was working on was closed after several months of development (and here I am in a good company). It was a project to develop a nice little version of the C language, clearly adapted for incremental compilation. This language was called ... um ... C #. But what is strange: if you look at it through the prism of 2009, it was surprisingly similar to the language that would turn out, try to develop C.NET.

The mainstream project of the time was Microsoft C 6.0. A bunch of innovations, new optimizations, improved debugging. Its main platform was an operating system called OS / 2 - you might have heard about it - but it should have worked under DOS as well. That is still a problem.

I worked on a development environment; more precisely - above the source browser. I did this mainly because I already worked on a similar browser for C #, my colleagues liked it, and many of the ideas have already been applied in Microsoft C 6.0. I think no one will be surprised if I say that among my first tasks was improving the performance of this thing.

Be that as it may, the development environment — probably the very first IDE we released — was called PWB or Programmer's Workbench. Making full use of pseudo-graphics, she used these nishtychnye Character Windows that dominated Microsoft's flagship products of the time. CW, or, as we lovingly called it, COW (cow), was a wonderful environment that provided all kinds of code substitutions (but not data) in order to allow you, working on a PC, to have more than 640 Kb of source code. This system is very similar to the one that was used in real Windows of that time (if my memory serves me right - something around Windows 2.4.x).

The consequence that you had only 640 KB of memory and you wanted to use an IDE was that, generally speaking, you could not have this IDE running at the moment when you either compiled the code, debugged it, or did something something different from editing: corny there was not enough memory. Therefore, this beauty had to use all sorts of tricky things. For example, in order to compile a project, it first determined what steps should be performed, then wrote them to a file, interrupted its work, leaving only a small stub in its memory that controls the entire process, performed these steps, and, finally, restored yourself in the form in which you left it. This created the illusion that the IDE has been resident all this time, while in reality this was far from the case.

For debugging, even more manual dexterity was needed.

I think the CodeView debugger , because of its influence, was one of the most important (if not the most important) application that used DOS Extended Mode. The debugger, you know, is in a very difficult position: it needs to have a lot of data in its memory (to support debugging) and at the same time the debugged program should have been launched. This was a rather difficult task, especially given the known constraint in the amount of RAM, but there was a loophole. Already, say, in 1989, you could use the capabilities of the 386 processor (if you had one) in order to access memory above the 640 Kb mark. Such fraud was called "use DOS Extender"And I think that the CodeView debugger was probably one of the first such Extenders and, I think, it served as the inspiration for writing a similar system in another product that you may be familiar with - in Windows 3.0. But this is a completely different story.

Well, here it is. So, a text debugger using advanced DOS mode and a build system that shuts down this product before doing anything useful. Eliminate all errors and - voila! - The first IDE from Microsoft will appear.
Based on PWB, IDEs were created for many other languages. I know for sure that the source browser supported characters for Basic, Pascal, Fortran, Cobol and C.

That was the spring of 1990 and then there was Microsoft C 6.0. Its IDE has become for several years the base for compiled languages.

Time did not stand still.

C ++ has already begun to conquer the world, and the presence of a high-quality optimizing compiler for C was no longer new to anyone. Fortunately, all this time we were not idle. While some were busy releasing Microsoft C 6.0, others were working on C ++, the frontend for our compilation system. I think almost everyone was sure that the C ++ compiler would be released in a very short time (I say “almost” because there were people who knew more than ours).

And how wrong we were. No, really. We were mistaken incredibly, fantastically; in the style of "yes what are we even thinking about!".

From a translator
I deliberately broke the original “Part I” into two parts: the text is large, it is inconvenient to read. Continuation-end of the first part - here .