29 年を経て、マイクロソフトのベテラン エンジニアは「MS-DOS はグラフィックスを実行できた」と認めたが、同社は…
最近の更新
2月19日午後12時11分（東部標準時）：見出しを修正し、追記しました。Windows 95のセットアップは実際には完全にテキストベースではありませんでしたが、理論的にはMS-DOSのみでグラフィック機能を使って構築することもできました。元の記事は以下です。
2025年8月24日、MicrosoftのWindows 95オペレーティングシステムは30周年を迎えます。もう歳を取ったと感じていますか？Windows Centralはこのオペレーティングシステムの大ファンで、その誕生、革新的なタスクバーへの象徴的なスタートメニューの導入、Windows 95の機能としてのスタートメニューの開発秘話など、懐かしい話題を頻繁に取り上げています。
Windows 10のサポート終了が迫り、Microsoftがユーザーへのアップグレードを促すためにWindows 11へのキャンペーンを強化する中、Windows 10が依然としてWindows 95の多くの機能を搭載しているのは興味深い。しかし、つい最近まで一つの疑問が未解決のまま残っていた。Windows 95のセットアップチームは、MS-DOSでグラフィックス処理ができることを忘れていたのだろうか？
30 年以上にわたって Windows オペレーティング システムの開発に携わってきた Microsoft のベテラン エンジニア Raymond Chen 氏が、同社が Windows 95 のセットアップをグラフィックスではなくテキストベースにすることにした理由を明らかにしました。
Microsoft の Windows 95 セットアップがテキストベースだったのはなぜですか?
Windows 95は、その後継となるMicrosoftのオペレーティングシステムと比べて、群を抜いています。これは、インストールプロセス中に豊富なグラフィック要素を備えた後継オペレーティングシステムと比較して、Windows 95のユーザーインターフェースが平凡で、テキストも平凡なため、非常に顕著です。
マイクロソフトのエンジニア、レイモンド・チェンは、「MS-DOS（Microsoft Disk Operating System）はグラフィックスに対応していた」と明かしました。なぜマイクロソフトはテキストベースのWindows 95を選択したのでしょうか？グラフィックスをサポートできるにもかかわらず、チェンはオペレーティングシステムのグラフィックスサポートが原始的で、時間の制約があったと述べています。
「はい、MS-DOSはグラフィックス処理が可能でした。つまり、グラフィックス処理を積極的に妨げるわけではないということです。しかし、それでもすべては自分で行う必要がありました。1ピクセルを描画するためのBIOSコール以外に、グラフィックスプリミティブはありませんでした。それ以外のすべては自分で行う必要があり、そもそもBIOSコールを使ってピクセルを描画するのは遅いので、使いたくありませんでした。少しでもパフォーマンスを上げたいなら、フレームバッファに直接アクセスする必要がありました。」
マイクロソフトのエンジニアは、Windows 95のセットアップにグラフィックス機能を追加するのは、そのプリミティブが1ピクセルを描画するためのBIOS呼び出しに限られていたため、非常に困難だっただろうと明かした。チェン氏はさらに、この方法でセットアップにグラフィックス機能を導入するのは、処理速度が遅いため、あまり良い考えではなかったと付け加えた。パフォーマンスのボトルネックを回避する唯一の方法は、フレームバッファに直接アクセスすることだった。
Windows と Xbox の熱狂的なファンのための最新ニュース、レビュー、ガイド。
しかし、これは氷山の一角に過ぎませんでした。プロセスははるかに複雑で、単一ピクセルよりも複雑なものを描画するためのグラフィックライブラリの作成も必要でした。幸いなことに、Windows 95にはVGAビデオカードの最小システム要件が備わっていたため、CGAやEGAの懸念は軽減されました。しかし、それでもプレーナーモードを調整する必要があり、これは容易なことではありませんでした。
平面モードとは、平面導波路を伝搬する電磁モードです。平面モードは光の閉じ込めと伝搬制御を可能にします。「幸いなことに、廊下の向こう側にはVGA平面モードの専門家チームがいて、Windowsビデオドライバの開発に携わっていますので、お手伝いいただけます」とチェン氏は付け加えました。
ピクセル表示に加え、セットアッププログラムにはダイアログボックスも必要になります。そのため、標準的なGUIダイアログインターフェース内でグラフィックライブラリを補完するウィンドウマネージャを作成する必要があります。また、要素間のタブ移動やホットキーの割り当てにはキーボードのサポートも必要になります。
このプロセスには、日本語のような非アルファベット言語の文字入力サポートの追加も含まれていました。幸いなことに、東京で日本語入力を担当するWindowsのエキスパートチームに頼ることはできましたが、時差は作業の進捗に悪影響を及ぼす可能性があります。これは、UIチームが開発した新しいコントロールにも適用され、同様のプロトコルに従う予定です。
システムのハードウェアタイマーに基づいてイベントをトリガーするスケジューラを必要とするアニメーションも忘れてはいけません。Windows 95のセットアッププロセスにさえ含まれていないコードを記述する必要があります。さらに懸念されるのは、これだけの労力を費やした後でも、すべてをわずか640KBのストレージに詰め込むのは至難の業だったということです。プロテクトモードマネージャを作成し、プロテクトモード用に割り当てられた追加のストレージスペースを活用することで、この問題を回避できます。
マイクロソフトは既に同様の製品、 Windows 3.1ランタイムをリリースしており、この取り組みは逆効果に思える。同製品は「ビデオドライバ、グラフィックライブラリ、ダイアログマネージャ、スケジューラ、プロテクトモードマネージャ、入力メソッドを備え、完全にデバッグ済み」だった。
ケビン・オケムワは、ケニアのナイロビを拠点とするベテランのテクノロジージャーナリストです。Windows Centralで業界の最新トレンドや動向を幅広く取材し、豊富な経験を有しています。イノベーションへの情熱と細部への鋭い洞察力を持つ彼は、OnMSFT、MakeUseOf、Windows Reportといった主要メディアに寄稿し、Microsoftエコシステムを取り巻くあらゆるトピックについて、洞察力に富んだ分析と最新ニュースを提供しています。常に変化するテクノロジーのトレンドを追っている暇な時は、世界を旅したり、音楽を聴いたりしています。