特集
|
 |
1987年――Windows 2.0（リアル モードとの悪戦苦闘）
Windowsは、グラフィカルなユーザー インターフェイスを備えたOSとして、1985年に最初のバージョンが発表された。当初のバージョン（1.x）は、タイリング ウィンドウ方式を採用していたので、見映えや操作性が現在のものとはかなり違っていたが、それ以上に機能制約が多かったので、実用性はほとんどなかったといえる。その後、1987年に発表されたWindows 2.0で現在のようなオーバーラップ ウィンドウ方式が採用され（GUIは、当時同時に開発が進められていたOS/2の影響を受けている）、また、アプリケーションもいくつか発表されるなど、実用性が向上した。
Windows 2.0の必要システム構成は、1台のハードディスクまたは2台の両面フロッピー ディスク ドライブ、最低320Kbytesのメモリ（640Kbytesあれば申し分ない）、640×200ドット以上のグラフィックス表示能力というものであった。驚くべきことに、ハードディスクのない、フロッピー ドライブのみのコンピュータでもかろうじて使うことができたわけだ。しかし現在ほど高機能でなかったとはいえ、このような環境でグラフィカルなマルチウィンドウ システムを実行するのは、言ってみればゴーカートのサーキットでF1カーを走らせようとするようなものだ（Windowsは、まだリアル モードで動作するプログラムの1つにすぎなかった）。
事実、この当時のWindowsは、自分自身をメモリに割り当てるだけでも精一杯で、とてもアプリケーションをいくつも同時実行できる余裕はなかった。このためEMSを使って、利用可能なメモリ領域を増やし、アプリケーションやデータを頻繁にロードしたり、破棄したりして、メモリをやりくりしていた。
1987年末――Windows/386（仮想8086モードでマルチタスクMS-DOSを実現）
Windows 2.0は、リアル モードのMS-DOS上において、リアル モードのコードで記述されたWindowsシステムを実行するための環境であるので（当然、アプリケーションもリアル モードで記述されている）、80286や386が備えるプロテクト モードの機能はまったく使っていない。そこで、80386の仮想8086モードを使って、MS-DOSプロンプト（通称「DOS窓」）を同時に複数動作させるという技術が開発され、それがWindows/386という製品として出荷されることになった（同時に、Windows 2.xはWindows/286と改名された）。Windows 2.0では、MS-DOSプログラムを起動するときは、他のWindowsアプリケーションがすべて停止していたが、このWindows/386環境下では、DOS窓を同時にマルチタスクで実行することができた。これが後にWindows 3.0の「386拡張モード」へと進化する。
1990年――Windows 3.0（80286／386のプロテクト モードへの対応で、やっと実用的に）
Windowsに大きな転機が訪れたのは、80286や386のプロテクト モードを活用した、Windows 3.0が発表されたときである。このWindowsには、3つの動作モードが用意されていた。
「リアル モード」は、従来のWindows 2.0と同じモードである。リアル モードで動作するプロセッサと、メイン メモリとEMS／HMA／UMBメモリだけを使ってアプリケーションを実行している。Windows 3.0では機能がいろいろと拡張されているので、ペイントブラシを数個も起動すれば、もうメモリが足りなくなってしまうという、あまり実用性がないモードである。従来との互換性のために存在していた。
「スタンダード モード」は、80286の16bitプロテクト モードを使った動作モードである。最大16Mbytesまでのメモリを管理することができるので、より実用的なアプリケーション実行環境を実現することができる。
「386拡張モード」は80386以上のプロセッサでのみ動作するモードであるが、スタンダード モードでの動作に加えて、仮想8086モードを使ってMS-DOSプログラムを同時に実行することもできるし（スタンダード モードでは、MS-DOSプログラムの実行中は、Windowsアプリケーションはすべて停止する）、80386のページングを利用した仮想記憶機構により、さらに多くのメモリを効率よく使用することができる。
 |
| Windows 3.xの構成 |
| Windows自体は、MS-DOSから起動される1つのアプリケーションである。この上にWindowsのデバイス ドライバやカーネルなどが構築され、そこから各種のDLLやアプリケーション プログラムのコード／データ セグメントをメモリにロードしながら実行している。ファイルI/Oなどは、最終的にはリアル モードのMS-DOSシステムを呼び出して処理している。そのため、システム コール呼び出し時にオーバーヘッドの大きなモード切り替えが発生する。当時は、ほとんどのデバイスが、まずMS-DOSレベルで利用できるように設計されていたため（たとえばディスクやネットワーク デバイスなど）、それらの機能をWindowsアプリケーションから呼び出したとき、最終的にリアルモードのMS-DOSへのモード切り替えが起こるのは、避けられないことであった。なおグラフィックス ビデオ カードなどのように、MS-DOS側のサポートがないものについては、プロテクト モードで動作するデバイス ドライバで処理されている。 |
Windows 3.xでは、80286／386が提供するプロテクト モードに対応し、Windowsのシステム モジュールや、Windowsアプリケーションをプロテクト モード メモリ領域に割り当てるようになった。ただしWindows 3.xにおいても、MS-DOSを土台としている点は従来と変わらず、ハードウェアを制御するデバイス ドライバはリアル モードで動作しており、またファイルI/Oには、リアル モードのMS-DOSのシステム コールを使用するようになっていた。つまり、アプリケーションやMS-DOSプログラムから発行される各種のシステム コールは、最終的にはMS-DOSやBIOSを介して、実際のハードウェアなどにアクセスするようになっている。なお386拡張モードでは、この最終的なハードウェアへのアクセスを、80386 CPUの持つ機能を使ってトラップし、MS-DOS環境を実現する仮想マシンへのアクセスに振り替えている。そのため、複数のMS-DOS環境を生成して、同時に実行することが可能になっている。
ところで、このようにWindows 3.0では、80286／386プロセッサが提供するプロテクト モードに対応し、自身のシステム モジュールや、実行されたアプリケーションを、プロテクト モードでのみアクセス可能なプロテクト モード メモリ領域にロードしている。しかし当時のWindows 3.0システムは、DLL（Dynamic Link Library）としてメモリ上に存在していただけで、現在のWindows 9xのように強制力をもってシステムやアプリケーションを完全に掌握していたわけではない。この当時のマルチタスク方式は、同時実行されている各アプリケーションが自発的に制御を他のプロセスに明け渡すことを前提とした、ノンプリエンプティブな（協調的な）マルチタスク方式であった（つまり、誰かが無限ループに陥ると、システム全体がハングアップしてしまう）。またWindows 3.0になっても、MS-DOSをベースとするオペレーティング環境であることはVer.2.x当時と変わらず、ファイルI/Oなど一部の処理では、MS-DOSのサービス ルーチンをそのまま利用するようになっていた。このためファイルI/Oが発生すると、プロテクト モード←→リアル モードというオーバーヘッドの大きなモードの推移を実行時に繰り返さなければならず、結果的に性能の低下を招いていた。当時は、ほとんどのデバイスが、まずMS-DOSレベルで利用できるように設計されていたため（たとえばディスクやネットワーク デバイスなど）、それらの機能をWindowsアプリケーションから呼び出したとき、最終的にリアルモードのMS-DOSへのモード切り替えが起こるのは、避けられないことであった。なおグラフィックス ビデオ カードなどのように、MS-DOS側のサポートがないものについては、プロテクト モードで動作するデバイス ドライバで処理されている。
1992年――Windows普及の立役者、Windows 3.1
Windows 3.1は、Windowsが広く普及する契機となったバージョンである。基本的にはWindows 3.0とそう大きく変わっていないが、性能の向上やユーザーインターフェイスの改良、TrueTypeサポート、音源サポートなどのマルチメディア機能が追加されている。
1995年――晴れてOSに昇格したWindows 95。しかしその実態は……
1995年に登場したWindows 95では、カーネルが32bit対応になり、ユーザー インターフェイスが一新されると同時に、MS-DOSが不要とされ、胸を張ってオペレーティング システムと呼べるようになった（とはいえ、実際にはカーネルの基本的な部分は、Windows for Workgroups 3.11（WFW 3.11）の時点ですでにかなり完成されていた）。カーネルの32bit化に伴って、Windows 95では、それまでプログラマやユーザーを悩ませてきたさまざまな制限が緩和された。Windows 95に対応した32bitプロテクト モードのアプリケーションは、Win32アプリケーションと呼ばれ、これに対し従来の16bitアプリケーションはWin16アプリケーションと呼ばれるようになった（Win32は、Windows NTの開発過程において、Win16アプリケーションを32bit環境に移行するために開発されたAPIである）。しかし、16bit時代の呪縛が完全に解けたかというとそうではない。過去のソフトウェア資産との互換性を維持する必要があるため、巧妙に制限を緩和しながらも、問題の抜本的な解決はなされなかった（正確には、したくてもできなかった、というのが本当のところであろう。過去のMS-DOSやWin16のプログラムがまったく動かないようなWindowsなど、とても受け入れられない。このため、Windows 9xのカーネル内部には、いまだにWindows 2.x／3.xのアーキテクチャに基づくデータ構造が数多く残っており、各所に64Kbytesの制限がある）。この問題の抜本的な解消は、当初からフル32bit対応のオペレーティング システムとして、まったく新規に開発が進められたWindows NT（現在のWindows 2000）に託されることとなる（NTは、逆に、Win32アプリケーションが動くことがメインであり、Win16やMS-DOS環境などについては、できるだけ互換性を維持する、という方針で開発されている。NT登場当初のデバイス サポートは、Windows 3.xに比べると、非常に限定的であった）。ユーザー インターフェイスやデスクトップの見た目はWindows 2000と変わらず、基本的なアプリケーション インターフェイスも32bit化されてはいるものの、Windows 9xには、今なおWindows 2.xや3.xの時代の名残が影を落としているのである。
 |
 |
 |
特集 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる （2017/7/27）
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する （2017/7/24）
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 （2017/7/21）
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる （2017/7/20）
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた！ まずはWordPressをインストールしてみる
 |
|
|
|
|
注目のテーマ
Windows Server Insider 記事ランキング
転職／派遣情報を探す
