XWIN II Weblog

ようやく、Xbox 360 導入 その2

PLAYSTATION 3（初期型。60GBモデルを320GBに換装）とXbox 360スタンダード（60GBモデル）の両方を比較して、思うことを列挙してみる。

1. Xbox 360の動作音等が大きいということだったが、Falcon搭載版はPLAYSTATION 3と変わらないばかりか、むしろ小さく感ずる。
2. 起動画面を始めとするUI系画面は、PLAYSTATION 3の方がデザイン的に優れていると感ずる。印象としては、MacとWindowsの違いのようなものか（苦笑）。
3. PLAYSTATION 3のゲームは画面解像度が固定化される（720pを1080pにできない）が、Xbox 360のゲームは有無をいわさず1125pにアップスキャンさせることが可能。どちらがいいのかは、現時点では何とも言えない。
4. PLAYSTATION 3は、ゲームをプレイする以外にも様々なことができるが、Xbox 360では、基本的にはゲームプレイのみしか使いたくない（他アプリケーションのレベルが低い）。
5. PLAYSTATION 3よりもXbox 360の方が安っぽく作られている。
6. コントローラは慣れの問題とは思うが、PLAYSTATION 3の方がしっくり来る。Xbox 360のものは、単3乾電池2本が入っているからか、やや重く感じ重心バランスが悪い。手が小さい私には、アメリカン仕様は合わないのかも。
7. HDD搭載が必須のPLAYSTATION 3とそうでないXbox 360の違いに起因すると思うが、ブロードバンド経由でのムービー再生は、PLAYSTATION 3に軍配が上がる。HD DVDが失われたからか、Xbox 360はゲーム専用機としての色が濃くなった印象。
8. どちらも縦・横どちらにも据え置き可能だが、横置きの場合、上にものを載せることが可能なXbox 360の方がありがたい。私は、Xbox 360の上にPLAYSTATION 3を載せている（逆はできない）。
9. HDDが換装できない、USBインタフェースを持たないXbox 360は、クローズドマシンで使い捨てするような印象。一方、PLAYSTATION 3はマザーボード故障は別にして、HDD換装などが可能であり、末永くハードウェアを使っていけそうな印象。
10. Xbox LiveとPLAYSTATION Networkでは、目指す方向が違うので一概に言えない部分もあるが、PLAYSTATION Networkの方がデザインも含め、見通しがいい。

以上、10項目を思いつくまま挙げてみた。やはり、Xbox 360はFalcon搭載となっても、積極的にPLAYSTATION 3よりもいい印象は持てないが、それでもXbox 360は悪いハードとまでは言えない。特に動作音がPLAYSTATION 3よりも小さい（特に長時間プレイ時）のは、マイクロプロセッサのプロセス縮小が大きく効いていると感ずるものだった。だが、さわってみてアメリカン的な作りはいかんともしがたく、ただゲームをプレイするだけなら、ダッシュボードだのゲーム以外の部分はそれほど気にするまでもないのだが、やはりPLAYSTATION 3をさわった者としては、どうにもダサく見えてしまうのは否めない。実際に、Xbox 360を手にしてからの印象は、手にする前の印象よりもよくなってはいるが、それでもPLAYSTATION 3とは比較にならない。

にもかかわらず、PLAYSTATION 3でプレイできるゲームが少ないのはもちろん、やってみたいと思うゲームがXbox 360よりも圧倒的に少ないため、手を出すつもりがなかったXbox 360を手にしてしまった。PlayStation 2との互換性を持つ60GBモデルを持っている私でさえ、プレイするゲームが少ないと嘆いているくらいなので、今販売されている40GBモデルを購入するユーザは、何をもってPLAYSTATION 3を求めているのだろう。あと2か月もしないうちに発売されて丸2年が経過しようとしているが、将来が見えないPLAYSTATION 3（大作は色々用意されているのだが、2年前の発表時から大きな進展はあっただろうか？）と着々と実績を積んでいるXbox 360。クリスマス商戦前までに、PLAYSTATION 3プラットホームに大きな刺激を注入しないと、ジリ貧になっていくような印象が強い。

とはいえ、WiiというフルHDとは無縁のゲーム機がまだまだ蔓延っているのが現状で、小さいマーケットを食い合うだけでなく、フルHDの魅力を前面に打ち出すだけのパワーを持ったゲームの登場が求められるのは間違いない。本音を言えば、アメリカンでないしっかりしたハードウェアのPLAYSTATION 3に頑張ってほしいが、ここまで体たらくの現状ではXbox 360でもいいと思う今日この頃である。

ようやく、Xbox 360 導入 その1

思えば、長かった。
据え置き型ゲームプラットホームとしては、PLAYSTATION 3以来の購入となるが、PlayStationシリーズ以外のものとなると、実にSEGAのDreamcast以来、ほぼ10年ぶりとなる。それだけ、SCEIのゲーム機慣れしてしまっていたのか、と今さらながら驚かされるが、本当ならまだXbox 360には手を出したくなかった。しかし……。

PLAYSTATION 3で、プレイしたいと思うゲームがほとんどなく、一方でPlayStation 2との互換性も現行機種では断たれたまま。そして2009年春頃まで眺めてみても、この状況は変わらない。SCEJはもっと力を入れなければならないだろうに（というか力のいれどころを誤っているとしか思えない）、この体たらくは何なんだ？という想いは、かれこれ半年以上続いている。この間、PLAYSTATION 3が壊れたり、その結果としてコピー禁止データの扱いに強い嫌悪感を覚えたり等、ゲームソフトウェアのリリースに対する不満以外のものも出てきた。まさに、こういう時が浮気の起こるタイミングだとなるだろう（苦笑）。何せ、今のPLAYSTATION 3 40GBモデルは、PlayStation 2との互換性がなくなり、PlayStationプラットホームと呼ぶことはできない。PLAYSTATION 3というよりもBlu-ray STATION、略してBLAYSTATIONと言うべきものだからだ。

そこへ、Xbox 360の値下げがやってきた。ただ、単にそれだけでは食指が動くはずもない。それは、2009年春まで眺めてみれば、明らかにPLAYSTATION 3よりもプレイしたいと思うゲームが多いから、という理由による。他にも、ハードウェアに対する信頼性の低さも気になっていたが、ようやくここに来て多少はまともになったような印象を受ける（消費電力の低減が大きい）。

とまぁ、そんな感じで買ったのが、新たにスタンダードの位置づけとなった60GBモデル。エリートという手もあったが、やはりちょっと心配だったのと、せっかく今回新登場なのだから、ということで決めた。Amazonとかでは転売屋が法外な価格をつけているようだが、ちょっと探してみれば60GBモデルは店頭で買うことができる。私も、特に慌てることなく購入できた。

初のXboxシリーズなので、箱を開けているだけで色々と楽しめた。様々なアイテムがビニール袋に入れられているが、いかにも安っぽく感ずる。比較するのがPLAYSTATION 3では勝負になるはずもないが、PlayStation 2と比べても微妙な印象で、次世代機と呼ぶには安っぽい、いい意味で言えばカジュアルに扱えそうだという感触だ。

つづく。

何とか帰宅（疲）

ただいま、午前7時52分。
今朝になって久しぶりに帰宅し、何日かぶりにVAIO type Zの電源を入れ、これを書いている。一区切りついたわけではないが、土日となれば周りも休みに入ってくれるので、ようやく私も一休みできるというわけである。

色々、書きたいものや書き残しもあるのだが、とりあえず一眠りすることに。寝よう。

帰ってきた まいにちいっしょ。そしてトロ・ステーション

PLAYSTATION 3の死（詳しくは「突然死したPLAYSTATION 3」参照）と共に、一年半以上ため込んだトロ・ステーション関連のデータが消滅してしまい、これはバックアップを取っていてもどうにもならないことを2か月ほど前、このBlogでお伝えした（詳しくは「さらば、まいにちいっしょ。そしてトロ・ステーション」を参照）。これ以来、まいにちいっしょをやる気力が失われ、PLAYSTATION 3プラットホームにも魅力あるゲームが出てこない現状から、浮気までしてしまったのだが（苦笑）、ついに理不尽な仕様から解放されたようである。

インプレスさんの『SCEJ、PS3「まいにちいっしょ」9月度アップデート実施　「トロフィー機能」への対応や「まいいつSTORE」の機能拡張など』によれば、「タイトルユーザーストレージサービス」なるものが開始され、

「プレーヤーの基本情報やニュースの既読数などの基本的な情報を、バックアップデータとしてネットワーク上のストレージに保存するサービス。PS3本体を交換しても、同一アカウントでサインインするだけで基本的なデータを「まいにちいっしょ」に引き継げる。またPS3本体が壊れた場合でも、基本的な要素は復元される」

とのことである。
この機能の追加は、おそらく私以外にも体験された方が多くあり、同じように悲しい想いをされたことに対するSCEJの回答かと思う。何で最初から実装しなかったんだ！というのは簡単だが、私自身、プログラマであり、SEであり、またプロジェクトマネージャでもあったことから、不具合（Bugではなくユーザレベルからの問題）に対する迅速な回答だと認識している。なので、帰宅できたら再び、まいにちいっしょをインストールしようかと……。に、しても今週中帰宅できるのだろうか（苦笑）。

帰宅できず…

せっかく色々と購入してあるのに、何もできず、さみしくアドエスから更新しております。サブプライムローン問題に端を発した（というかそもそもサブプライムローン自体が…）ここ数日の怒濤の状況に、泊まり込み＋徹夜続きでもうヘロリスト状態。

まずは帰宅したいところだが、今夜も厳しいか（泣笑）。

PlayStation 2 登場当時を振り返る Back to the 2000

さて、敬老の日特集と銘打って、今回は過去を振り返るコーナーです。といっても、そんなに昔のものではなく、今から8年半ほど前に今は亡き「XWIN II Web Page」に書いた内容をもとに振り返ってみようというものです。
まずは、2000年3月1日に書いた内容を抜粋しておくと、

「理由は、『入手する価値はない』と判断したからです。PlayStation2は、はっきりいえばブゥムに過ぎないものでしょう。DVD-Videoを見ることができる？ったって、DVD-Videoのコンテンツはさみしい限りです。いわゆる18禁方面の充実がメディア隆盛の成否を握るといわれていますが、一部専門店を除けばまだまだだし、さらにいえばレンタル市場はお寒い限りです。購入タイミングは、次のモデルチェンジかあるいは価格が下がったタイミングになりそうです。もっとも、それ以前にプレイしてみたいと思うゲェムが出てくればそんなことはいってられませんが、ね。本音を言うなら、0.25ミクロンプロセスから0.18ミクロンプロセスに移行したチップが載ったものが出たなら「買い！」なんだ・け・ど。」

といった感じで、まったく買うつもりがないようなことを書いていました。しかし、私が前言撤回するのは今に始まったものではありません（苦笑）。何だかんだ言って上述した3日後、つまりPlayStation 2の発売日にはこのようなことを書いていた。

────────────────────────
巻頭言 210　「PlayStation2狂想曲」

正直、この話題は取り上げようかどうか迷ったものです。低俗なワイドショウですら取り上げているようなものを取り上げたくないし、単なるフィィバァ状態のものをあれこれいうのもなんだし、専門のニュースメディアも挙って取り上げているのですから。でも、私の書いた記録として、刻む、ということも考えている（位置付けている）巻頭言であるので、やはり取り上げないわけにはいかないなという想いから、本当にサッと火を通すような感覚で取り上げます。

思い起こせば、こういった異常とも思える最初の発売日フィィバァは、ファミコン版『ドラゴンクエスト III』が始めかとなりますか。若かりしあの日（＾＾；私も池袋のビックカメラの行列の一部を担っていたわけですが、あの頃と今とでは「流通形態」が大きく変わっています。詳しくはいいませんが、あの頃のファミコンソフトの流通は任天堂及びその問屋組織である「初心会」が牛耳っており、商品の流通が一部に大きく偏るということも珍しくなかったようです。その結果として、噂やデマゴォグも含めて『ドラゴンクエスト III』の行列騒動が起こったのだと、行列当事者の一人として今は思うところですが、今回のPlayStation2ではそういったことは少なくともないはずです。

というのも、SCEIは販売ルートの多様化を進めており、最たるものはコンビニルートへの参入そしてネット直販であると思いますが、通常小売店ルートでも発注数そのものは来ないにしても、昔のファミコンソフトのようなことはないので、予約販売という形態も含めて入手困難性は大幅に軽減されているでしょう（もちろん、その大前提として製品がそれなりに供給されていなければなりませんが）。にもかかわらず、あの行列は一体何なんだ？ となるのです。

そして、PlayStationやSEGA SATURNといったニューハードが出てきたときももちろん行列はありました。しかし、今回ほどのものではなく、またその取り上げられ方もほとんどは専門メディアのみという事実から、PlayStation2ほどのものではありません。これは、Windows 95フィィバァとの類似性も考慮に入れる必要があるのではと考えます。Windows 95は、秋葉原でおそらく初の大規模深夜販売だったのではないかと思いますが、たかがOSにあれだけ深夜に行列を作る必要があるのか、深夜に買う必要があるのかと今では冷静に見つめることができます。ですが、当時の空気というか雰囲気は、そういった冷静さを失わせるに十分だったと思うのです。私は並びはしませんでしたが、あの日、秋葉原にはいました。発売前日から発売日にかけて。このときの某NIFTY会議室にレポート（＾＾；として、私は次のような報告をしていたのです。

「あんなところに行くわけないよと思ってはみたけれど、人に誘われ、22日午後6時頃には、すでに秋葉原に来ていた。さすがに午前0時まで、あと6時間もあるせいか、週末の秋葉原とそう変わらない感じを受けた。しかし、ショップをみれば、Win95前夜祭といった感じで、デコレーションの準備に追われているところも多かった。朝日新聞情報によれば、ザ・コン館は、午前0時オープン時には、Win95しか売らないとあったので、Plus!やOffice95も目的だった私は、他ショップに確認を取ったところ、全部揃うことを確認し、ほっと一息ということで飲み屋に入った。連れと何だ神田のばか話で盛り上がった後、午後11時頃に店を出て、酔い冷ましも兼ね、秋葉原を徘徊した。天気は雨が降ったりやんだりという状況だったが、私たちは運がよかったのか、外に出ているときはほとんどふられなかった。」

「午前0時に近づいてくると、秋葉原に戦雲が漂ってきた！バス3台を連ねてやってきたNEC販促ビラまき部隊を始め、東芝の筐体娘軍団、コンパックのバスタオル巻き、アップルのMac部隊(＋Macサポータ？)、富士通FMV隊(あまり特徴がなかったような...)......が、道行く人に無差別絨毯ビラまき攻撃を開始する。ショップも次々開店し、整理券を配る店や、先行予約販売を開始する店、Win95プリインストールをうたうNECなどの新機種を並べはじめる店、コロッケやおでんやコーヒーやうどんなどもWin95にちなんで販売する店など、午前0時に向け、盛り上がりを見せていた。こういった光景を見ながら、中央通りを歩いていると、たかがOSの新バージョンの発表にこれだけの人が集まるとは...という感慨が胸に去来した。長年、この世界に関わってきた人は少なからず、こういった思いがあると思う。」

「そして、カウントダウンが終わり、販売開始！　しかし、私たちは万世橋脇の公衆トイレにいたため、ジャスト午前0時のイベントや販売開始の瞬間を見ることができなかった(ビールの飲みすぎ...(^^;;;)。さて、販売開始されたし、どこで買おうか？　ここで私たちには二つの選択肢があった。どこでもいいからすばやく購入し、終電に間に合うように帰宅するか、あるいはできるかぎり安いところを見つけて、初電で帰宅するかというものだったが、結局、後者の選択をした。すでにT・ZONE時計は0時15分を回っていたからである。」

「いろいろ徘徊したり、また、ビラまき・プラカード持ち店員の情報を得る(この間、いろいろインタビューを受ける)などして出した結論は、Office95 はショップ間の差はほとんどない。Win95が8,980円、Plus!が5,600円という価格で、アイツーで販売されていることが分かり、急遽、アイツー3号店前の列に並ぶ。しばらくして、ようやく順番が回ってきて無事に目的の3種の神器を確保することができたのである。時は、T・ZONE時計によれば0時55分を回っていた。」

「さて、もう終電はない。初電は4時30分過ぎとのこと。3時間半もいったい何をしていればよいのだ、と思案に暮れていたが、東芝のショウルームが開いているのを確認した私たちは、サービスでもらったホットコーヒーを左手にし、ショウルームでしばしの休息を取った。が、ショウルーム内は、東芝の新デスクトップのCMが繰り返し流されており、なんだか刷り込まれたような印象を受け、閉店の午前4時近くまで、東芝のショウルームの世話になった(途中、再び、中央通りまで出たが、たいていのショップは午前3時頃までに閉店したようであった)。そして寒空の中、秋葉原駅前で似たような連中と30分ほど駅前で震えた後(一見、浮浪者風の人が布団を敷いて寝ていたが、一番駅前で暖かそうにみえた)、初電に乗って帰宅の途についた............。」

これは、4年以上前の1995年11月23日に書いたものですが、Microsoft Office 95も同時発売だったとはすっかり忘れていました。人の記憶なんて、ホントあてにならないものです。三種の神器（Windows 95、Windows Plus!、Office 95）を喜んで買っているようにしか読めないレポートを書いておきながら、何が冷静になって見つめることができますだってね………と、脱線気味なので戻しましょう。というわけで、これを境に深夜販売と行列というのは、一種お祭りのようなものという認識に変わったのかなと思うわけです（PlayStation2 は深夜販売は行わないとしているが、実質深夜に整理券配布や行列指定をすることで同義だろう）。これに加え、Windows 95の時もPlayStation2と同様に、わけわかマスコミが面白半分で取り上げていることで一般への認知度も高く、「何だか知らないけどすごい」、「これを知らないと遅れる」というような強迫観念で突き動かされているという印象を大変強く受けるのです。

とどのつまり、このPlayStation2狂想曲を意味もなく拡大しているのは、Windows 95時と同様に、わけわかマスコミが興味本位で取り上げたことによる増幅結果にほかならないでしょう。ただ、そのコアの要素としては「従来よりも優れている」という下地は無視できません。PlayStation2が仮にDreamcast程度のハードウェアだったなら、いくらSONYとはいえ、あそこまで盛り上げることは難しかったと思えます（興味本位での盛り上がりは同程度までいくかもしれないが）。テクノロジ部分を純粋に評価したいとするのは例外なのはもちろんとしても、本来のゲェムではなく（もっともSCEIはゲェムマシンとは言っていない）、DVD-Videoなどどうでもいいことが真っ先に上がっているというのは『何だかなぁ～』と思うわけです。でも、Windows 95の時もWindows 95がOSであるということを知らないばかりか、PCのものであるということも知らない人もいたくらいだから、それはそれでしようがないのでしょうけどね。

ホント、バカみたい。（2000/3/4）
────────────────────────

これは、PlayStation 2発売直前のフィーバーぶりを呆れつつ、昔は自分もWindows 95登場時や、さらにそれよりさかのぼるドラゴンクエストIII（もちろん最初のファミコン版）の発売フィーバーの渦中にいたのだという自省の念を思い出して書いたものだった。発売3日前には買わないと言い、発売日当日の早朝にはフィーバーぶりを呆れていたにもかかわらず、その日の夜にはこんなことを書いていたのです。

────────────────────────
巻頭言 211　「PlayStation 2、結局二台購入」

この画面写真をご覧いただくまでもないですね。何だかんだと言いながら、PlayStation 2を二台購入してしまいました。ソフトウェアはナムコさんの「リッジレーサーV」とアートディンクさんの「A列車で行こう6」の二本を購入。数日前の巻頭言を読み返してみると、「なんて嘘つきなんだ！」としか思えない行動ですが、状況変化によってということでご容赦を（＾＾；

で、さっそくさわってみた感触ですが、なかなかいいです。特に、XRGB-2を通して見るゲェム画面はもう、PCでのそれを凌駕しているようにも見えます（VGAサイズでなら凌駕している）。DVD-Videoも再生したところ、大きな不満はありません。印象としては、PCにかなり近づいてきたと思います。PlayStation 2は大容量メモリカードと本体側に搭載されている32MBのDirect Rambus DRAMを生かす形で、ROMのみにシステムを焼きこむのではなく、メモリカードからシステムメモリにロードしてファームウェア（の一部）として機能するからです。これにより、ハードウェアレベルでの致命的Bugがあったとしても、ソフトウェアの書き換えで対応できる可能性が飛躍的に高まったとなるでしょう。もちろん、Bug対応だけでなく、システムとしてのアップデートも容易かと思います。

大容量メモリカードは、これまでのメモリカードと違ってブロック単位で扱うのではなく、PC同様Bytes単位で扱えることから、メモリカードも8MB固定でなくそれ以上のものも容易になるはずです（これまでのメモリカードでもサードパーティから大容量のものはあったが、15ブロック単位でのページングを行うことが必須であったので、15ブロックという限界は変わらなかった）。これも、これまでのゲェムマシンというよりは、PC寄りの発想のものだといえます。ちなみに、大容量メモリカードには次の3つのファイル（ファイルという言い方が自然だよなぁ）が格納されます。

• あなたのシステム設定ファイル（3KB）
• システムドライバー（42KB、2000/02/02 1:01:19）
• DVDプレーヤー（634KB、2000/02/02 1:01:14）

よって、空き容量は7300KBとなっています。こういった管理方法もPCならでは、でしょう。このことから察しがつくように、DVDプレーヤーが格納されているメモリカードをメモリカードスロットに用意しておかなければ、DVD-Videoを鑑賞することができなくなります。PCを扱っている人ならどうということはないのですが、ファイルという概念がわかっていないと、なかなかこのあたりを理解するのは難しいかと思えます。メモリカードが増えてきて、いちいちDVD-Videoが入ったメモリカードを探すのは面倒なので、使用法としてはシステム関連ファイルのみを格納するメモリカードと、ゲェムのセーブデータを格納するメモリカードとわけて運用した方がいいように感じました。ですが、肝心のメモリカードは単体発売されていないようです。私は真っ先にメモリカードが品切れになると予測し、入手の算段を考えていたのですが、出荷されていないのでは手の打ちようがありません。とにかく、大容量メモリカード。PS2専用ゲェムを行うなら入手しておいて損はないかと思います。

さて、今のところ、の感触ですが、目的のPlayStation用のゲェムが問題なく動作するのなら、文句なし買い！ですね。やっぱり、CD-ROM（DVD-ROM）ドライブが速いとよくなりますよ。こんなんで喜んでいる私は、大バカ者ですね。（2000/3/4）

────────────────────────
というわけで、結局2台購入してしまうのだから、自分自身に呆れてしまいます。しかし思い出すのは、けっしてPlayStation 2も順風満帆な船出ではなく、メモリカード周りのトラブルを始め、多くのトラブルが発生していたこと。発売と同時に出た多くのゲームもほとんど面白くなく、引き続きPlayStationのゲームをプレイしていたことです。にもかかわらず、これを逆転していったのは何だったのか？　トレンドは変わってもこういう部分は早々変わるものではないと思うのですが…。

と敬老の日ということで、昔のことを思い出してみた。

── 買った…

取り急ぎこれだけです。

ようこそ、WELCOME、等、多言語対応だが、反面安っぽい印象（苦笑）。

３連勝だが、心配なタイガース

大阪出張の際、大阪地方はタイガース盛り上がっているなぁと感じていたが、昨日もサヨナラ勝ちで3日連続というのは、過去5度しかない珍しい記録だという。しかし、このヤクルト3連戦のスコアを眺めて見ると、不安は募るばかりだ（苦笑）。

ヤクルト　０ ０ ０ ０ ２ ０ ０ ０ ０　２
阪　　神　２ ０ ０ ０ ０ ０ ０ ０ １　３

ヤクルト　０ ０ １ ０ １ ０ １ ０ ０　３
阪　　神　３ ０ ０ ０ ０ ０ ０ ０ １　４

ヤクルト　２ ０ ０ ０ ０ １ １ ０ ０　４
阪　　神　２ ０ ０ ０ ０ ０ ０ ０ ３　５

サヨナラ勝ちと言えば、見ている方もハラハラものだが、やっている方はもっと大変だろう。しかも、得点が初回と最終回しか入っていないのだ（汗）。昨日は今岡昇格後、即活躍という巡りも悪いものではない。いい兆候ではある。だが、手放しで喜べない。マジック17だが、もう一山もふた山も…あるだろう…なぁ……。

お米の純米ルーロ

大阪に出張に行くと、決まって家人に頼まれるものがある。それは「お土産」である。以前、大阪に一緒に行った際、梅田の阪急百貨店地下1階で家人曰く「オーラを感じた」という、「五感」という店のロールケーキを買った。お米の純米ルーロという面白い名前のものである。

店頭の説明によれば、ルーロは誤植などではなくフランス語でロールケーキのことを言うらしい。で、買ってきた翌日が賞味期限だったので、早速今日いただくことにした。

箱を開けてみると、ここにも解説が書かれていたり…。「最高のロールケーキをお作りする為にぎりぎりの焼き加減に致しております」という台詞が熱い（苦笑）。と、それはともかく大変やわらかいので、ちょっとでも力を入れるとつぶれてしまうので、切るのになかなか難しかったりする（不器用な私なので、そうでない人にとってはどうってことはないだろう）。

焼き色もしっかりしており、いただいてみると素朴な味がする。ごってごてのロールケーキや、高いだけの自由が丘方面にあるパッと出の高いだけのものとは大違い。とはいえ、大阪方面では有名らしいが、東京方面に進出しても成功しないような気がする（オーナーが堅実であれば進出しないとは思うが…）。味覚が関東と関西とでは違うことはもちろんだが、田舎者の集合体である東京地方ではどちらかといえば、派手な味が好まれるからだ。

とまぁ、そんなことはどうでもいい。家人に喜ばれたので、それだけでいいのだ。

Windowsのシステムリソース解説 Back to the 1999

今回は、久しぶりに旧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ではパフォーマンスを上げる方向とも聞く。見た目は変われど、その本質は何一つ変わっていない。そんなことを思う、今日この頃…。