翻訳者から
これはリコ・マリアーニの物語の第二部です。 始まりはこことここでした。
Visual C ++ 2.0（コードネームDolphin、Dolphin）は非常に野心的なプロジェクトでした。 Visual C ++ 1.0をリリースできてうれしかったのですが、私たちに絶対に合わない点がいくつかありました。 それらの1つ-おそらく最も重要なもの-は、ウィンドウの操作が悪夢であるということでした。 Visual C ++ 1.0は、登録ウィンドウ、値追跡ウィンドウ、出力ウィンドウなどを含むすべてのウィンドウに標準のマルチウィンドウMDIインターフェイスを使用しました。 その結果、これらの主要なツールは、エディターとデバッガーによって開かれたウィンドウのストリームに単にdrれています。 それはすべて非常に不快でした。
しかし、私たちがこれと戦う前にまず何が起こったかについて話しましょう。
Basicコンパイラを開発したチームは別の完全なリリースを展開しましたが、Visual Cシェルと統合されていませんでした。 彼の主なタスクは、独立した実行可能ファイルを作成することでした。 一方、Fortran開発チームはFortran Powerstationの最初のバージョンをリリースしました。これは、それ自体が奇跡でした。 この製品は、使い慣れた「DOS拡張」メカニズム、GUIモードでのデバッグを可能にするいくつかのトリック、および改善されたプロジェクトシステムをフルに活用しました。 それはその標準による完全に最新の開発システムでした。 Cobolの開発は、一歩一歩進んでいます。 そして、 MASMとMLと呼ばれるあまり知られていないアセンブラーを忘れないでください。私の意見では、リリースは1つだけでしたが、コストがかかります。 MLはMASM解析ルールを合理化した結果でしたが、1993年の終わりには、別のマクロアセンブラは必要ありませんでした。
1993年について話しているので、その時点までに、革新的なMicrosoft Officeの新しいバージョンであるドッキング可能なツールバーがリリースされたことに言及する価値があります。 Visual CのUIのすべての問題の解決策になると判断しました。ツールバーを追加して、ウィンドウをドッキングできるようにします。 本当に快適です。
「私たちは決定しました」と言いますが、実際には、これの基礎はApp Studioチームによって築かれました。 それらの人のアイデアは彼らの野心でさらに進んだ。
過去には、IDEは統合されたアプリケーションのスイートでしたが、違いを生み出したいと考えていました。 単一シェルのフレームワーク内で、リソースとフォームのエディター、テキストエディター、プロジェクトシステム、デバッガー、およびヘルプが機能することが計画されていました。 さらに、Fortran、Basic、Cobolなどの他の言語をこのシェルに埋め込むことができるように、モジュール化する必要がありました。 後者は、基本的なサービスのセットを提供するだけでなく、メニュー、ツールバーなどのサポートを提供することになっています。 おなじみですね。
しかし、それだけではありません！
とりわけ、Macintosh用の開発ツールが必要でした。 誰もがWLMを覚えていますか？ 私自身、その助けを借りていくつかのプログラムを書きました。 PowerPCおよび680x0用のコンパイラ、リモートデバッグは問題ありません。 そして、はい、MIPSとAlphaのサポートを忘れないでください。
あなたがすでに私たちがクレイジーだと思っているなら、それで無駄です-私はまだ終わっていません。
すべてのことを考えていたときに、Cで記述されたVisual C ++環境コードを事前にC ++に移植する必要がありました。 さらに、通常のアプリケーションからは、新しいシェルで使用できるMFCライブラリに変わるはずでした。 Visual C ++ 2.0はそれ自体をコンパイルおよびデバッグできるはずだったので、一般的に言えば、製品全体が機能するはずです。
また、32ビットへの移植のためにコードを編集する必要があったため、新しいバージョンのライブラリ（MFC 3.0など）をリリースする予定だったことは言うまでもありません。
そして、私はまだ終わっていません。
「編集して実行」、「OLEを簡素化」、「ファイルは別として」という大きな計画がありました。 後者は、開発サイクルを可能な限り単純化および高速化し、OLEメカニズムなどを単純化し、ソースコード内のナビゲーションを容易にすることを意味しました。 ナビゲーションシステムに、今回はC ++のみに関連する多くの新機能を追加しました。 OLE RPCデバッグに関連して多くの興味深いことを行い、「自動ウォッチ」ウィンドウを追加しました。 その瞬間、私はデバッガー開発チームの主要なプログラマーだったので、すべてをはっきりと覚えています。
1つのリリースで十分だと思いますか？ いや
言語自体も開発されており、開発ツールを担当するプログラマーはナシにぶら下がりませんでした。 名前空間は最初の主要な革新でしたが、それらに加えてパターンと例外処理もあり、後者はWindows NT SEHと統合されました。
言語バージョンが異なる場合は、同じバイナリを使用し、リソースファイルごとにローカライズすることを計画しました。 英語版と日本語版は同じでした！ 私の知る限り、その瞬間まで誰もこのようなことをしていませんでした。
そして、この「イノベーションケーキ」の上に桜のように、次のものがありました。 しかし、シカゴなどのオペレーティングシステムがWindows 95という名前でリリースされたことを聞いたことがあるかもしれません。そのため、当社の製品はこのオペレーティングシステムのSDKになりました。 これは、Windows 95とWindows NTの比較が許されないため、大量のエラーを緊急に修正する必要があることを意味していました。
Uff、それはすべて狂ったように見えますが、実際にはもっと多くの仕事をしました。 それ以来、16ビットツールの場合はサービスリリースのみをリリースし、32ビットプラットフォームの場合は完全にクレイジーなデモを行いました。真に統合された開発環境がありました。
その時、私たちは少し休息しました。 32ビットはホットニュースであり、Visual C ++ 1.52はそれ自体でかなり優れていました。開発ツールの他のベンダーはOS / 2サポートに多くの時間を費やしました。 しかし、Delphiデモ-それは何かでした！ しかし、Visual Basicチームもアイドル状態ではなかったため、反対意見がありました。32ビット開発ツールとOCXを使用したこのストーリーです。 結果はクールなエコシステムです。
Visual C ++ 1.0は、私たちがリリースしなければならなかった最も技術的に洗練されたIDEだったと思います。 当時のオペレーティングシステムで動作させるには信じられないようなことをしなければならなかったため、困難でした。 しかし、Visual C ++ 2.0は同様に重要であり、それ以上ではありませんが、重要な媒体でした。技術的にも進歩しました。 開発に多くの時間を費やし、その前にバージョン2.1と2.2をリリースしました。