最も可能性が高いのは、 ビルとポールがBASICを作成することを決めた1975年にVisual Studioの話が始まったときです。 おそらくそれより早く始めることは可能だったかもしれませんが、1975年は、Visual Studioを念頭に置いて話し合うことができる最も遠い年だと思います。 それは、Microsoftが開発者向けのプログラムを用意し、トースターの自動化などに従事しないことを決定したときでした。
私のような昔からの人は、さまざまなマイクロコンピューターでMS-BASICを使用していました。 個人的にCommodore PETを使用しました（2001年のPETモデルで始めましたが、21世紀のコンピューターとは異なり、その名前は特に皮肉でした...しかし、気が散りました）。 MS-BASICはAppleまたはTRS-80で使用でき、多くの人がこれらのコンピューターで強度をテストしました。 即座のフィードバックと個人的なプログラミングの経験-これらすべてが私たちに永続的な印象を残しました。
これらのコンピューターを動かしている要因（はい、文字通り）を本当に知りたいと思っていた人たちは、それらを部分的に制御するプログラムを分解するために無数の時間を費やしました。 Bill Gatesが6502のアセンブラーを教えてくれたので、Microsoftで働く準備ができたと誇らしく言えます。
80年代は、コンピューター、そしてその結果としての開発ツールの驚くべき多様性の時代でした。 多くの人がプログラミング言語を作成しましたが、ブランド所有者との問題を避けるために、ここでは名前をリストしません。 ただし、当時のさまざまなシステムを思い出すことができると確信しています。私自身もすぐに5個ほどを思い出しました。
80年代半ばに支配的になり始めたPC開発ツールを開発していた場合、あなたの人生は特に困難でした。 x86命令セットは特に美しくありませんでした。 64 KBのメモリセグメントを備えたアーキテクチャは、すでに存在することの頭痛の種でした。 その時点で既存のプロセッサから可能なすべてのパフォーマンスを絞り出そうとする試みは、プログラミング言語での奇妙な構造の形を取りました。
それは1988年で、私は大学からちょうどマイクロソフトに着きました。 zashashnikには、Pascalコンパイラー（私の友人4人と共同開発）と、さらにアセンブラーとリンカーがありました。 しかし、私は準備ができていませんでした
char _near * far pascal GetString( char far * far * lplpch)
* This source code was highlighted with Source Code Highlighter .
まず第一に、
pascal
キーワード
pascal
Cプログラムで何をしましたか？ このramp延する近距離および遠距離（「近」および「遠」）で唯一の視覚的なもの（視覚、トピックを参照）は、二重焦点レンズの必要性でした。
ここで少し戻ります。
私が1988年にマイクロソフトで使用したコンパイラは、Microsoft C 5.1であり、そのような言語としては素晴らしいものです。 おそらく最も成功したリリースの1つです。 それまで、マイクロソフトはプログラミング言語の分野で栄光の頂点にありましたが、その後、B。で始まる名前を持つ特定の企業がこのパイに侵入しました。 。
そのため、Microsoft Cにはすでに5つの大きなリリースがありました。 BASICのコンパイラBC6が発売されたばかりで、Quick Basicの「QB4」が登場しました。
すでにお気付きかもしれませんが、私はC ++についても言及していません。 私たちはまだそれに到達する必要があります。
私はどこ？ そうそう、1988年。 私が取り組んでいたプロジェクトは、数ヶ月の開発の後、閉鎖されました（そして、ここで私は良い会社にいます）。 これは、インクリメンタルコンパイルに明らかに適合した、C言語の素敵な小さなバージョンを開発するプロジェクトでした。 この言語は... um ... C＃と呼ばれていました。 しかし、奇妙なことです。2009年のプリズムを通して見ると、C.NETを開発しようとする言語に驚くほど似ていました。
当時の主流プロジェクトはMicrosoft C 6.0でした。 多数の革新、新しい最適化、改善されたデバッグ。 その主なプラットフォームはOS / 2と呼ばれるオペレーティングシステムでした-あなたはそれについて聞いたことがあるかもしれません-しかしそれはDOSの下でも動作するはずでした。 それはまだ問題です。
開発環境で作業しました。 より正確に-ソースブラウザの上。 私がこれを行ったのは、主にC＃の同様のブラウザーで作業しており、同僚がそれを気に入っており、多くのアイデアが既にMicrosoft C 6.0に適用されているためです。 私の最初の仕事の中で、このことのパフォーマンスを改善したと言っても誰も驚かないと思います。
それはともかく、開発環境（おそらく私たちがリリースした最初のIDE）は、PWBまたはProgrammer's Workbenchと呼ばれていました。 疑似グラフィックをフルに活用して、彼女は当時のMicrosoftの主力製品を支配していたこれらのnishtychnye Character Windowsを使用しました。 CW、または私たちが愛情を込めて呼んでいるCOW（cow）は、PCで作業して640 Kbを超えるソースコードを使用できるようにするために、あらゆる種類のコード変更（データではなく）を提供する素晴らしい環境でした。 このシステムは、当時の実際のWindowsで使用されていたシステムと非常によく似ています（私の記憶がうまく機能している場合-Windows 2.4.x周辺の何か）。
メモリが640 KBしかなく、IDEを使用したいという結果は、一般的に言って、コードのコンパイル、デバッグ、または何かを行ったときに、このIDEを実行できないことでした。編集とは異なるもの：十分なメモリがありませんでした。 したがって、この美しさはあらゆる種類のトリッキーなものを使用する必要がありました。 たとえば、プロジェクトをコンパイルするために、最初に実行する手順を決定し、ファイルに書き込み、作業を中断し、プロセス全体を制御する小さなスタブのみをメモリに残して、これらの手順を実行し、最終的に復元しましたあなたがそれを残した形で自分自身。 これはIDEがずっと常駐しているという幻想を作り出しましたが、実際にはこれは事実からは程遠いものでした。
デバッグには、さらに手作業が必要でした。
CodeViewデバッガーは、その影響により、DOS拡張モードを使用した最も重要な（最も重要でないとしても）アプリケーションの1つであったと思います。 ご存知のように、デバッガーは非常に難しい位置にあります。メモリー内に大量のデータを保持する必要があり（デバッグをサポートするため）、同時にデバッグされたプログラムを起動する必要があります。 これは、特にRAMの量の既知の制約を考えると、かなり難しいタスクでしたが、抜け穴がありました。 たとえば、1989年には、386プロセッサ（搭載している場合）の機能を使用して、640 Kbマークを超えるメモリにアクセスできます。 このような詐欺は「 DOSエクステンダーを使用 」と呼ばれ、CodeViewデバッガーはおそらく最初のエクステンダーの1つであり、よく知られている別の製品で同様のシステムを作成するためのインスピレーションだったと思います。 Windows 3.0で。 しかし、これはまったく異なる話です。
さて、ここにあります。 これは、高度なDOSモードを使用するテキストデバッガーと、何かを実行する前にこの製品をシャットダウンするビルドシステムを意味します。 すべてのエラーを排除して-出来上がり！ -Microsoftの最初のIDEが表示されます。
PWBに基づいて、IDEは他の多くの言語用に作成されました。 ソースブラウザがBasic、Pascal、Fortran、Cobol、Cの文字をサポートしていることは確かです。
それが1990年の春で、Microsoft C 6.0がありました。 そのIDEは、数年前からコンパイル言語のベースになっています。
時間は止まりませんでした。
C ++はすでに世界を征服し始めており、C向けの高品質な最適化コンパイラが利用可能になったのは誰にとっても新しいことではありません。 幸いなことに、この間ずっと私たちは遊んでいませんでした。 Microsoft C 6.0のリリースで忙しい人もいれば、コンパイルシステムのフロントエンドであるC ++で作業している人もいました。 ほとんどすべての人が、C ++コンパイラが非常に短い時間でリリースされると確信していたと思います（私たちよりも多くのことを知っている人がいたので、「ほぼ」と言います）。
そして、私たちがどれほど間違っていたのか。 いいえ、本当に。 信じられないほど、幻想的に誤解されました。 「はい、私たちは何を考えているのでしょう！」というスタイルで。
翻訳者から
私は意図的に元の「パートI」を2つの部分に分割しました。テキストは大きく、読むのは不便です。 最初の部分の継続終了- ここに 。