History of Visual Studio. Part 0.5

There is not and cannot be a single “History of the appearance of Visual Studio”: every person involved in its creation has its own version. If we adapt the well-known quotation, then “There are a lot of stories in the Nude City ...”.

Most likely, the history 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 furthest thing to talk about, while still referring to Visual Studio. That was the time when Microsoft decided to have programs for developers, and not to 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 especially ironic, considering how different it was from 21st century computers ... But I digress). 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 an indelible impression on us.

Those who really wanted to find out what makes them “tick” (yes, literally) these computers spent countless hours sorting out the programs that controlled them. I can proudly say that Bill Gates taught me assembler for 6502 and prepared me to work at Microsoft.
')
The 80s were the era of incredible diversity in computers, and, as a result, in development tools. Many people created programming languages, but I will not list here any names or names in order to avoid problems with brand owners. However, I am sure that you will be able to recall several different systems of the time - I myself immediately recalled about 5 pieces.

If you were involved in creating PC development tools 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 with its existence; Attempts to squeeze out all possible performance from the then existing processors took the form of fancy constructions in programming languages.

In the yard in 1988 and I, just from college, got into Microsoft. In store I had a Pascal compiler (developed together with 4 of my friends), and in addition, an assembler and linker. But I was by no means ready for

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

* This source code was highlighted with Source Code Highlighter .

For starters, what the devil did the pascal keyword pascal in a C program? The only visual (Visual, see topic) thing in all this rapport near and far (“near” and “far”) was the need for bifocal lenses.

Here you should go back a bit.

The compiler that I used at Microsoft in 1988 was Microsoft C 5.1 - a nice little such language; perhaps one of our most successful releases. Until that time, Microsoft was at the height of glory in the field of programming languages, but then a certain company with a name starting with B made an attempt 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 releases. The BASIC compiler, BC6, was just released to the market, and Quick Basic “QB4” was already on the way.

You might already notice that I don't even mention C ++. We still have to reach it.

Where, I mean, me? And, yes, 1988 year. 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 small, pretty version of the C language, obviously 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 have turned out, would you 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 primary platform was an operating system called OS / 2 — you could hear about it — but it had to work under DOS. That is also a problem.

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

However, the development environment — probably the very first IDE we released — was called PWB or Programmer's Workbench. Entirely and fully using pseudographics, she used these nishtyachnye Character Windows, which prevailed in the flagship Microsoft products of the time. CW, or, as we called it, COW (cow), was a wonderful environment that provided all sorts of code changes (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 used in the real Windows of that time (if memory serves me - something in the Windows 2.4.x area).

The fact that you only had 640 KB of memory and you wanted to use the IDE was that, generally speaking, you could not have this IDE running when you either compiled the code, debugged it, or did something This is 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, she first determined which steps to perform, then wrote them into a file, interrupted her work, leaving only a small cap that controls the whole process, performed these steps and, eventually, restored yourself exactly as you left it. This created the illusion that the IDE had been resident all this time, whereas in reality this was far from being the case.

For debugging, more dexterity was needed.

I think that the CodeView debugger , due to its influence, was one of the most important (if not the most important) applications that used DOS Extended Mode. The debugger, you know, is in a very difficult situation: it needs to have a lot of data in its memory (to support debugging), and at the same time a program being debugged had to be started. It was quite a 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 gain access to the memory above the 640 KB mark. Such frauds were called “use DOS Extender ” and I think that in the CodeView debugger there was probably one of the first such Extenders and, I think, it served as an inspiration for writing such a system in another product with which you may be familiar - in Windows 3.0. But that's another story.

Well, here. This means a text debugger that uses advanced DOS mode and a build system that quits this product before doing anything useful. Eliminate all errors and - voila! - The first IDE from Microsoft will appear.
PWB-based IDEs have been created for many other languages. I know for sure that the source browser supported the symbols for Basic, Pascal, Fortran, Cobol and C.

It was the spring of 1990 and then was Microsoft C 6.0. His IDE has become the base for compiled languages ​​for several years.

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 a novelty for anyone. Fortunately, all this time we have not been idle. While some were busy releasing Microsoft C 6.0, others were working on C ++, a front-end 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 of ours).

And how wrong we were. No, actually. We were wrong incredibly, fantastic; in the style of "yes, what did we even think about!".

From translator
I deliberately broke the original “Part I” into two parts: the text is large, inconvenient to read. The continuation-ending of the first part is here .