今回は、久しぶりに旧XWIN II Web Pageに掲載していた記事を復活させるコーナーです（苦笑）。詳細は忘れてしまいましたが、約9年運営していてトップページに次いで最もアクセスが多かったのが、今回復活させる「Windowsのシステムリソース解説」でした（まるまる盗用され、それを通報いただいたりしたこともいい思い出です）。もちろん、Windowsと言ってもここではWindows VistaでもXPでも2000でも、その前のNTのことではありません。今は亡き、いわゆるWindows 9xのことを指します。最初に書いてから、既に9年以上が経過しておりますが、PCの温故知新の歴史を確認する意味でも…。と能書きはここまでにして始めましょう。
───────────────────
なぜメモリ不足が起こるのか？
Windows（以下、ここでの議論ではWindows NT/2000/XP系を含みません）を使用していると、一度はお目にかかる「メモリ不足」。
- 「メモリを256MBも搭載してあるのに、まだ足りないのか？」
- 「Windowsアプリケーションを一つしか使っていないのになぜ？」
- 「WindowsのBugだ～！」
と、色々な思いが錯綜することでしょう。ですが、Windows 95の前バージョンであるWindows 3.1やWindows 3.0の頃に比べれば、「メモリ不足」に悩まされることははるかに減少しています。
しかし、現在のトラブルに昔話を持ち出されたところで何の慰めにもならないし、古いバージョンのWindowsのことなんか関係がないと思われるかもしれません。ですが、ちょっと待っていただきたい。Windows 95や98、Meでは、PCに搭載されているメモリ（RAM）よりも大きなメモリを扱うことができるのです。これは、仮想メモリという概念で、HDDをメモリのように見せかけることで、実際に搭載されているRAMと同等に扱うようにするテクニックです。HDDに空き容量が少ない（100MB程度を切る）というならともかく、そうでなかったとしたらメモリ不足に陥るなど通常では考えられません。さらにいえば、この仮想メモリという概念は、Windows 95で初めて採用されたのではなく、Windows 3.0の頃から採用されていました（ただし、RAMの４倍までという上限があった）。つまり、「メモリ不足」の根本的原因は、実際上のメモリ（RAM、そしてHDD）が足りないのではなく、Windows 3.0や3.1との互換性のためにあると考えることができるわけです。
Windows 3.0、そして3.1が活躍していた頃（1990年代前半）のPCは、現在と違ってRAMやHDDの容量は潤沢にあったとはいえませんでした（もちろん、それは現在との比較であって、当時はさらに昔と比べれば不足していたとはいえなかった）。PCに搭載されているRAMは、一般的には4MB程度で多くても 16MB程度、HDDも、100MB程度が当たり前だったのです。
このように、現在から見て非常に少ないRAMやHDDでしたが、いわゆるメモリそのものが足りなくなることはまれで、実際には別の理由で「メモリ不足」に陥っていました。それは、いわゆるシステムリソース不足と呼ばれるものです。これが不足することが、「メモリ不足」に直結していたわけなのです。
では、システムリソースとはいったい何のことなのでしょうか。
Windowsのシステムリソースとは
Windowsのシステムリソースという言葉は、Windows 95や98、Meのエクスプローラーのバージョン情報（ヘルプ→バージョン情報）に見ることができます。何％が使用可能かという形で情報が表示されていますが、まず、このシステムリソースとは何かを解説します。
システムリソースという言葉が、Windowsに登場したのは、Windows 3.0で新たに登場したプログラムマネージャのバージョン情報（ヘルプ→バージョン情報）の中に現れました。プログラムマネージャは、Windows 95に搭載のエクスプローラーにとって代わるまで、Windows標準のアプリケーションラウンチャとして活躍していたのですが、現在ではほとんど見ることがありません。なので、過去の遺物かと思われていますが、実は現在のWindows Meでも残されています。Windowsフォルダの中にPROGMAN.EXEというものを見つけることができますが、これがプログラムマネージャです。スタートメニューのファイル名を指定して実行で、PROGMANと入力して実行すれば、プログラムマネージャを起動できます（ただし、あくまでプログラムマネージャは過去との互換性を維持するために残されているもので、正式サポートの対象からは外れています）。
これは、Windows 3.1まで採用されていたということから想像がつくとおり、16-bit Windowsアプリケーション（以下、Win16アプリケーションという）です。面白いことに、古いWin16アプリケーションであるはずのプログラムマネージャで調べたシステムリソース使用可能％と、32-bit Windowsアプリケーション（以下、Win32アプリケーションという）であるエクスプローラで調べたシステムリソース使用可能％が同じ（実行タイミングによっては若干のずれが生ずることはある）ことが確認できるでしょう。なぜ、古いWin16アプリケーションと新しいWin32アプリケーションが同じ結果を返すのかは、この後でじっくりと解説していきますが、まずはシステムリソースという言葉が、このプログラムマネージャのバージョン情報内に初めて登場したということを覚えておいて下さい。
（ただし、Windows NT/2000/XPのプログラムマネージャは、Win32アプリケーションである。よって、システムリソース使用可能情報は、このバージョンでは用意されていない。Windows NTの最初のバージョン3.1では、ユーザインタフェースがWindows 3.1を模していたので、そういったアプリケーションプログラムも基本的にWin32アプリケーションとして用意されていた。）
プログラムマネージャやエクスプローラのバージョン情報に登場するシステムリソースは、Windowsにどのような影響を及ぼすものなのでしょう。そしてそれは、何を意味するものなのでしょうか。ここで、一つの実験を行ってみます。Windowsが起動した直後、システムリソース使用可能％を調べ、その後、ExcelやWordといった Windowsアプリケーション（Win16アプリケーション、Win32アプリケーションを問わず）をいくつか実行した状態で、もう一度システムリソース使用可能％を調べてみます。すると、最初に調べたものよりも少なくなっていることが分かります。続いて、Windowsが起動した直後に実行した Windowsアプリケーションをすべて終了させ、もう一度システムリソース使用可能％を調べてみると、一番最初よりは少なくなっているかもしれませんが、Windowsアプリケーションを実行しているときのものよりは増えていることが確認できます。
このことから、システムリソースとは、具体的にはっきりはしませんが、少なくともWindowsアプリケーションが使用することで減っていくものだということがいえるでしょう。そして、システムリソース使用可能％が限りなく０に近づくまで、Windowsアプリケーションを実行し続けていくと、あるところで「メモリ不足」が起こります。
そうです。これがWindowsにおける「メモリ不足」の正体で、システムリソースの不足が直結していると、先にふれたことにつながるわけです。
（この他にも、本当の意味でのメモリ不足に陥ったりすることもあれば、間抜けなメモリ管理方法によるプロセッサの重要なリソースであるディスクリプタテーブルのセレクタ不足というものもある。ただし、システムリソース不足と比較すればその可能性は限りなくゼロに近い）。
プログラムマネージャのバージョン情報内に示されるシステムリソース使用可能％は、結局のところ、ユーザに対して「メモリ不足」の事前警告的な意味合いを持つものだと言っていいものです。では、システムリソースとは、どのようなものでどういった制限があり、どの程度の容量があるのか。これらについて、続けてみていきましょう。
USERとGDI
ここでは、ある程度Windowsのシステムアーキテクチャについての理解を前提知識として必要としますので、ごくごく簡単ではありますが、Windowsのシステムアーキテクチャについてふれていきます。
Windowsは、Windows 3.0からWindows Meまでに大変多くの機能が追加になっていますが、伝統的にWindowsのコアシステムコンポーネントは大きく分けて３つのモジュールに分けることができます。その３つとは、KERNEL、USER、GDIといい、それぞれの役割はおおよそ以下のようなものとなっています。
- KERNEL Windowsアプリケーションをメモリにロードし、実行する。また、Windowsアプリケーションのメモリ管理を行う。
- USER キーボード、マウス、タイマ等のメッセージ入出力を管理し、すべてのウィンドウの管理も行う。
- GDI フォント、グラフィックス及びプリント処理を行う。GDI = Graphics Device Interface。
さらに簡単に比喩的にいってしまえば、KERNELは、縁の下の力持ちでユーザの目に触れることはほとんどないもの。USERは、ユーザの入出力の面倒を全面的にサポートし、ユーザインタフェースという目に見える形で現れるもの。GDIは、グラフィックス（文字も含む）処理全般を扱い、これもユーザの目に触れるものといえます。Windowsでは、これら目に見えるもの、目に見えないものも含めて、すべてリソース（オブジェクト）という形で管理するようになっています。USER が管理するリソースをUSERリソース（ウィンドウやメニュー等）といい、同じくGDIが管理するリソースをGDIリソース（フォントやビットマップ等）といいます。これらリソースは、USERやGDIが管理するといいましたが、どのようにして管理するのかといえば、その基本情報（リソース構造体）を USERまたはGDI固有の記憶領域に確保することで実現しています。
このことから、数多くのウィンドウを作成したり、あるいは数多くのグラフィックスを作成することで、固有の記憶領域を使用していくことがお分かりになるでしょう。このUSER、そしてGDI固有の記憶領域が、実はシステムリソースに密接に関係しているのです。
ここで、もう一度、プログラムマネージャのバージョン情報に立ち戻ってみましょう。このバージョン情報内に登場するシステムリソースは、どこから求められているのかといえば、最初のWindows 3.0時代には、実はMicrosoft社からは公開されていませんでした。しかし、その後になってGetHeapSpacesという非公開 API（Application Programming Interface。要は、Windowsプログラムで使用する関数のようなもの）を使って実現されていることが明らかにされました。非公開云々についてはここでは立ち入りませんが、このGetHeapSpacesという非公開APIを用いて、きちんと入口と出口を問題なくプログラムを記述・作成すれば、どのWindowsプログラムからもUSER固有の記憶領域（これをUSERローカルヒープという）の未使用量並びに、GDI固有の記憶領域（これを GDIローカルヒープという）の未使用量を得ることができるようになるのです。
ですが、GetHeapSpacesではシステムリソースを直接得るようにはなっていないことにお気付きでしょう。実は、プログラムマネージャのプログラム内部でシステムリソースは定義されているのです。プログラムマネージャは、GetHeapSpacesで得られたUSERローカルヒープ未使用量を、 Windows全体のUSERローカルヒープで割り返すと、USERローカルヒープ未使用率が算出されます。同様にGDIローカルヒープ未使用率を算出した後に、双方を比較して少ない方をシステムリソース使用可能％としているのです。つまり、システムリソース使用可能％とは、USERローカルヒープまたはGDIローカルヒープのうち、少ない方の全体に占める比率をいい、これはWindows 3.0登場時にプログラムマネージャによって規定されたものだったのです。
Windows 3.0におけるシステムリソース
Windowsのシステムリソースとは、Windows 3.0におけるプログラムマネージャが規定したUSERまたはGDIローカルヒープに由来するものだということは分かりました。では、肝心のUSER及び GDIのローカルヒープはどのくらいあったのかを見ていきましょう。と、その前に、なぜローカルヒープという言葉を用いているのかをふれておく必要があります。なぜなら、この後の議論でローカルという意味を知るか知らぬかで理解度が変わってくるからで、Intel 16-bitプロセッサのアーキテクチャをご存じない方には、何をいっているのかさっぱり分からないというかもしれませんがご容赦ください。
まず、ヒープ（Heap）の方は、英和辞書をひくといくつかの邦訳が載っていますが、ここでは「塊」という程度の意味でいいでしょう。ヒープと略していますがその実体はヒープメモリであるので、いわばメモリの塊、メモリブロックということを意味します。そしてローカル（Local）の方は、それに対する言葉にグローバル（Global）というものがあります。Intel社の16-bit CPUは、8-bit CPUとのプログラム互換性のため、特異なセグメントアーキテクチャを採用しています。これは、64KBのメモリブロックを一つのセグメントとすることで、8-bit時代に書かれたプログラムの移植性を向上させるというアプローチだったのですが、反面、これは64KB以上のメモリブロックを扱う（セグメント境界をまたぐ）際に大変大きな足かせを生むこととなっていたのです（複雑さと互換性のトレードオフで、互換性をとったということです）。それは、セグメントを越えたメモリアクセスは、コストの高い（要は処理に時間がかかるということ）ものということを意味しました。
このセグメントアーキテクチャによって、コストの小さい（単純で処理時間の短い）メモリアクセスは必然的にセグメント内に収まるもの、つまり64KB以内の処理になり、これをローカルアロケートといい、そうでないコストの高いものをグローバルアロケートといいます。
以上のことから、ローカルヒープとは、64KB以内（裏を返せば最大64KB）のメモリブロックという意味になります。これは、いわゆるリアルモードと呼ぶ8086プロセッサで実現されていたモードはもちろんのこと、続く80286プロセッサで採用された最初のプロテクトモードでも64KBのセグメントは存在しており、拡張メモリ仕様のひとつXMSメモリの確保もセグメント単位で行わなければならない（無論、リアルモードとの相互互換のためにも必須ではあるのですが）ことが、プロテクトモード下においても64KBという制限を生んでいました。この制限は、32-bitプロセッサ80386からサポートされた32-bitプロテクトモード（これに対し、80286のプロテクトモードを16-bitプロテクトモードと呼ぶこともある）によってようやくなくなりましたが、完全に64KBの呪縛から解き放たれるには、80386登場から数年を経たWindows NT 3.1でやっと実現し、すべてのWindowsとしてはWindows XPによってWindows 95/98/Meユーザに対し、アップグレードを行うことで初めて実現できるという時間がとてつもなくかかるものです。普及したソフトウェア環境を更新するということがどれほど困難なことなのかを窺い知るには十分でしょう。
さて、ローカルヒープの容量に戻りますが、以上のことから察しがつくようにローカルヒープは最大でも64KBしか確保できず、実際、一単位のローカルヒープの容量は64KBになっています。Windows 3.0では、USERローカルヒープを１つ（64KB）、GDIローカルヒープを１つ（64KB）持っています。よって、容量的には合計で128KBでしかありません。このことは、どんなにあふれんばかりのメモリがあったとしても、システムリソースの容量はわずかに128KBしかないといえるわけです。ですが、128KBすべてをいわゆるシステムリソースに使えるのかといえば、それは誤りです。というのは、それぞれのローカルヒープにはどういったリソース構造体が記憶されるのかが決まっていて、たいていの場合は、等しくローカルヒープが使用されることはなく、USERローカルヒープのうちの一方が最大 64KBという上限に達してしまい、ここで「メモリ不足」となってしまうのです。よって、システムリソースの上限を128KBというくらいなら、まだ 64KBが上限といった方が妥当だとなるわけです。
しかもひどいことに、Windows 3.0では致命的な問題として、プログラムマネージャに登録されているアプリケーションすべて（実行していないばかりか、アイコンを表示すらしていないものまで含む）のプログラムアイコンにウィンドウ（アイコンもWindowsレベルでいえばウィンドウの一種）を割り当てていたことで、無駄にUSERローカルヒープが食い尽くされるという事態が発生していました。最初は4-bitカラー（16色）くらいが標準だった環境（VGA以前のEGA等も対象だったのですから）も、Windowsの躍進によって8-bitカラー（256色）や16-bitカラー（65,536色）といった多色環境が増えてくることで、それに伴いアイコンのデータ量が爆発的に増えてしまったからです。32ドット角のアイコンを例にとれば、4-bitカラーでは32 x 32 x 4 = 4096bits = 0.5KBほどなのに、8-bitカラーでは２倍の1KB、16-bitカラーでは４倍の2KBとなってしまうのですから、16-bitカラー環境で32 個のアイコンを登録したらそれだけで64KBとなり、パンクしてしまうわけです（実際は、他にも使用しているのでその前にパンクしてしまう）。
こういった状態では、すぐにシステムリソースがパンクしてしまうことは明らかで、実際、Windows 3.0は「メモリ不足」に大いに悩まされることとなっていました。このため、次バージョンのWindows 3.1ではシステムリソース、中でもUSERローカルヒープの拡大や、不用なリソースをシステムリソース領域から追い出すというものが最優先課題となったのです。
Windows 3.1におけるシステムリソース
Windows 3.0は、米国市場に広く受け入れられましたが、その結果、Windowsの脆弱さが数多く指摘されました（システムの脆弱性とパフォーマンスは基本的にトレードオフであって、パフォーマンスを高めるために脆弱性を来たす＝処理を端折ることは、マシンパフォーマンスが低い頃はよくあることだった）。その中でも、システムリソースの拡大は最優先事項の一つとなり、Windows 3.1では3.0と比べれば大幅なシステムリソースの拡大を実現しました。中でも、USERローカルヒープのうち、もっとも容量を食っていたメニュー構造体とその中のメニュー項目が、新たなローカルヒープとしてそれぞれ独立し、容量でいえば64KBから128KBと倍増しました。GDIローカルヒープは64KBと変わらなかったものの、管理方法を変えるなどして不用なリソースをシステムリソース領域から追い出したことで、結果として広くなったと言えます。この結果、システムリソース全体ではWindows 3.0と比べて1.5倍以上になったのです。
ですが、ローカルヒープそのものの制限である64KBは、80286プロセッサのサポートを残すため、及び互換性の面から相変わらず残されていました。この制限を撤廃するには、ローカルヒープでなくグローバルヒープを利用するしかありません。しかし、グローバルヒープは先にも述べたように大変に高価な処理で、システムパフォーマンスに悪影響を及ぼしてしまいます。Windows 3.1の設計目標の大きな一つには、Windows 3.0よりも高速にするということも含まれていたので、それでは本末転倒となってしまうことから、ローカルヒープをグローバルヒープに移行することは行われませんでした。
いずれにしても、Windows 3.1はWindows 3.0に比べればシステムリソースはほぼ倍増したので、以前に比べれば「メモリ不足」にはなりにくかったのは事実です。しかし、かなりの頻度で「メモリ不足」が起こっているのは事実であり、これはローカルヒープを使用している限りは避けられないものだったのです。なお、システムリソース使用可能％を表示するのに利用するAPIを非公開であるGetHeapSpacesから、 GetFreeSystemResourceという新たな公開されたAPIに変更されました。このAPIはTOOLHELP.DLLで実装されており、このDLLをWindows 3.0にコピーして使用すれば、Windows 3.1と同様にシステムリソース使用可能％を表すことができます。また、Windows 3.1でも非公開APIのGetHeapSpacesを利用することができますが、GetHeapSpacesはWindows 3.1で拡張されたローカルヒープについては調べることができないため、若干不正確な値となってしまう場合があるので、このAPIを用いるには十分な注意が必要です。
Windows 95におけるシステムリソース
システムリソースの制限は、セグメントアーキテクチャによるローカルヒープの上限が64KBということが絶対的な理由です。これを解消するには、セグメントアーキテクチャからの脱出、Intelプロセッサの16-bitアーキテクチャを捨て去らなければなりません。そこで、新たにIntelプロセッサの32-bitアーキテクチャを採用した新しい32-bit WindowsをWindows 3.1の後継として作ることとなりました。これがコードネームChicagoと呼ばれたWindows 95です。ところが、Windows 95はこれまでの16-bit Windowsとの互換性を維持しつつ、新しい32-bit Windowsを併存させるという非常に難しいアプローチで設計・製造されたため、大変に複雑なシステムとなってしまいました。この複雑さはどこに起因しているかといえば、16-bitと32-bitが混在するハイブリッドなシステムということです。この複雑さはシステムリソースにも当てはまります。
（こういう経緯に至ったのは、既にリリースされていたWindows NT 3.1が米国をはじめとしてまったく売上不振だったことがあげられます。売上不振だったのは、PCへのハードウェア要求が高かったからで、完全32- bit化してしまうと互換性の維持に加えて、プロセッサやRAM、HDDへの要求が高くなり、Windows 3.1からのリプレースを含めた普及に大きくブレーキがかかると想定されたためです。）
Windows 95では、これまでのローカルヒープに加えて、新たに32-bitヒープがシステムリソースに加わりました。32-bitヒープとは、セグメントアーキテクチャにまったくしばられないため、ローカル、グローバルといった区別のないフラットな上限4GBのメモリブロックです。ただ、上限が理論上は4GBというだけで、Windows 95のUSERそしてGDIの32-bitヒープ容量は2MBとなっています。実際の容量は、USER 32-bitヒープが２つ、GDI 32-bitヒープが１つ、トータル6MBが新たにシステムリソースとして加わったのです。これは、上限という面から見ると64KBから2MBと従来の 32倍になったわけで、いくらなんでもリソース不足に陥ることはないだろうと思われました。
上図がWindows 95におけるシステムリソースの全貌です。確保される最大値（つまり、実際はこれより少ないことがほとんどということ）は、16-bitハンドル値を変換するための仕掛け（図中ではPointer Exchange Table）が64KBずつ加わるため、トータルでは6528KB（6.375MB）となります。また、個々のリソースの上限も下記のように拡張されました（ただし、32-bitヒープの上限までという制限はある）。
ところが、Windows 95になっても「メモリ不足」から逃れることはできませんでした。もちろん、これまでと比べてシステムリソースは多大に使用していますが、さすがに32倍には増えていません。この理由は、Windows 95が完全な32-bitシステムではなく、16-bitシステムも混在したハイブリッドシステムであるということによります。例えば、新しく加わった32-bitヒープはWindows 3.1時代までのWin16アプリケーションでは使うことができません。なぜなら、Windows 3.1で提供されていたローカルヒープを使う前提に立っているものが少なからずあるため、互換性の面から使用することは大変に危険だからです。システムで使用するウィンドウが32-bitヒープに移動したことで、Windows 3.1の頃と比べれば、ローカルヒープには余裕はありますが、所詮上限は64KB止まりです。これがあふれてしまえば、いくら32-bitヒープが空いていようと「メモリ不足」になってしまうのは、Windows 3.1と変わることがないのです。
そして、どどめとしては、エクスプローラーがシステムリソースを表示する際に利用するAPIが、Windows 3.1と同じGetFreeSystemResourceという事実です。これは、いわゆるWin16 APIで変更を加えられていないことから、新しい32-bitヒープについては何ら考慮に入っていません（仮に入っていたとしても、分母が64KBと 2MBでは最小値がどちらになるかは自明だろう）。つまり、エクスプローラのバージョン情報に示されるシステムリソースとは、結果的にWindows 95が持つシステムリソースのごく一部であるWindows 3.1までと互換性のあるローカルヒープだけが対象となっているのです。とはいえ、「メモリ不足」の元凶となるシステムリソース不足は、32-bitヒープよりもローカルヒープの方が先になくなるのだから、ユーザにとっての「メモリ不足」の判断指標になる意義は損なわれていないといえるでしょう。
なお、Windows 95になってシステムリソース残量がWindows 3.1に比べて明らかに増えたように見えた現象は、GetFreeSystemResourceがベースとする分母が変わったためです。Windows 3.1（及び派生バージョン）までは、そのまま64KBという値が使用されていたのですが、Windows 95からは64KBではなく、それよりも少ない数値に変更されました。それはエクスプローラが最初に実行される（エクスプローラはShellなので、いわゆるファイラとしてだけの役割ではない。エクスプローラウィンドウが一つも開いていなくても必ず１プロセスは実行されている）時に、その時点での16- bitヒープメモリ残量を計算し、これを分母としてグローバル変数として設定しているのです。したがって、最初のエクスプローラ実行後にほとんど自動実行プログラムがなかったならば、限りなく100％に近いシステムリソース残量となり、見かけだけはWindows 3.1よりもシステムリソースが増えたように見えるという小手先のインチキのようなものと映るわけです。
こうした水増しのようなものはあるものの、思い出していただきたいのは、最初の方でふれた「古いバージョンのWindowsの話が関係ある」ということです。先進的な32-bit OSとMicrosoft社が喧伝したWindows 95、システムリソース不足が起こらないと吹聴されたWindows 95の実像は、16-bitの制限を引きずったままのものだったのです。しかし、エンドユーザにはこのようなことを言っていましたが、開発者向けの資料ではこのことはきちんと説明されていました（ただし、ほとんどの開発者が見向きもしないWindows 95 DDK＝デバイスドライバ作成者向け資料でしたが…）。
Windows 98におけるシステムリソース
では、Windows 95に続くバージョン、Windows 98及びWindows 98 2nd Editionではどうなっているかというと、Windows 95とほとんど変わっていません。システムリソースとしていくつか新しいものが追加されましたが、本質的な変更はありません。32-bitヒープと16- bitのローカルヒープの混在もそのままです。エクスプローラーのバージョン情報におけるシステムリソースも、 GetFreeSystemResourceをそのまま使用しています（ただし、計算ベースとなる分母算出方法は変わっています）。
ただ、Windows 95が登場した頃に比べると、Win16アプリケーションは減ってきています。このことで、「メモリ不足」になりにくくなってきていますが、まだまだ多くのWin16アプリケーションは健在です。中でも、マルチメディア系のアプリケーションは、プログラムそのものはWin32アプリケーションであっても、呼び出すDLLがWin16だったりするものも多く、その上、使用するシステムリソース量がハンパでないことから、簡単に「メモリ不足」になってしまうものも見受けられます。このあたりは一般ユーザには分からないので、具体策をユーザ側がとりえないことが問題だといえます。
Windows Meにおけるシステムリソース
最後のWindowsとなるWindows Me。起動時間だけが早く、他に取り柄もないといわれた最悪のWindows Meですが、もともとWindows 98からWindows 2000に移行予定だったものを行えなかったための窮余のバージョンとして唐突に作られたものなので仕方がありません。ただ、DOSを完全に排除したことによるリアルモード撤廃の恩恵は、結果的に多くの面で互換性を喪失させた割には、メリットが起動時間短縮だけではあまりに情けないものです。 Windows Meが目指した安定性というものも、Windows NT/2000と比べれば、比べること自体が罪のようなものであるし、不安定な上での安定性追求は逆にBugの温床とスピードという限りなく不安定さを許容した上でのメリットすらつぶしてしまいました。こんなバージョンですから、システムリソースの改良など行うわけもなく、基本的にWindows 95以降と何ら変わってはいないといっていいでしょう。
メモリ不足解消のために
最悪のWindows Meを挟んだことで有終の美を飾ることのできなかったWindows。いよいよ、本命のNTカーネルを持つWindows XPに移行するという道を開き、バージョンアップならぬOS変更になります。これをもって、Windows誕生以来、ずっとつきまとってきたシステムリソース不足というものは、ほぼ完全に解消されます（たとえWindows XPでも、ウィンドウを16,000個くらい開けばリソース不足やメモリ不足には陥る）。しかし、マイクロソフトがそうはいってもすぐに皆がWindows XPに移行するわけではありません。Windows Me以前の従来のWindowsだって、しばらくの間は現役です。それまでの間は解消されることのない「メモリ不足」。これを解消するにはどうしたらいいのでしょうか。
絶対的な答えはただ一つ、「Windowsを再起動する」ことです。もともと、Windowsは安定したシステムではありませんでした。それを安定させる努力もまったくなかったとはいえませんが、それ以上に新しい機能を追加してきたものがWindowsなのです。現実に即したOS、それがWindowsなのですから、そもそも安定性を求めることが間違っています。Windowsと一口にいっても、ドライバやアプリケーション等々、Microsoft社以外の数百以上に及ぶデヴェロッパのプログラムコードがひしめき合っているのだから、うまく動く方が奇跡です。
実際、多くの「メモリ不足」は、本当の意味でメモリをフルに使ってしまっているのではなく、プログラムのBug等によって、リソースリークが起こった結果、「メモリ不足」に陥ってしまっています。こんなものに対して、まともに向き合っていては疲れてしまいます。なので、潔く「Windowsを再起動する」ということが手っ取り早いメモリ不足解消の方法なのですね。
───────────────────
いわゆる16-bit時代の負の遺産を引き継いだ、Windows 9x。まだ当時はセキュリティなどよりも、いかにパフォーマンスを上げるかが最重要事項だったし、先進的なWindows NTもリソース食いの低パフォーマンスとこき下ろされたものだった。そして、現在。32-bitから64-bitへの移行が言われつつ足踏みは続き、Windows Vistaへの移行もままならない。次バージョンWindows 7ではパフォーマンスを上げる方向とも聞く。見た目は変われど、その本質は何一つ変わっていない。そんなことを思う、今日この頃…。
最近のコメント