Windows 11は今でもWindows 95のメモリマネージャーを隠しているが、Microsoftは数十年前のコードを保持している

📅 2026-10-19

要約:

Windows 11 はすでに最新のユーザー インターフェイス、高度なセキュリティ メカニズム、強化された人工知能機能を備えていますが、オペレーティング システムの奥深くでは、Microsoft は Windows 95 時代のコードの一部をまだ保持しています。驚くべきことに、これらのコードは過去のレガシー ファイルとしてシステムに残されるだけでなく、特定の条件下で引き続き実行でき、古いメモリ管理動作に依存する一部のアプリケーションに互換性サポートを提供します。

Windows 11 26H2 においても、Microsoft は EmulateHeap と呼ばれるアプリケーション互換性修復メカニズムを保持しています。これにより、特定の古いプログラムが Windows 95 メモリ マネージャーをモデルにしたコードを使用できるようになり、最新の Windows のメモリ管理方法の変更によってこれらのプログラムがクラッシュするのを防ぐことができます。

このメカニズムの歴史は 1990 年代にまで遡ります。そんな時、「シムシティ」という名作ゲームでプログラムエラーが発覚しました。マイクロソフトは単に開発者にゲームの修正を依頼するのではなく、ゲームが引き続き実行できるように Windows 95 の動作を直接変更しました。それ以来、Microsoft はより体系的な互換性メカニズムを使用して、同様の問題を抱えた他の古いソフトウェアが新しいバージョンの Windows で引き続き動作できるようにしてきました。

この歴史は、長い間 Windows の重要な設計原則も明らかにしています。つまり、巨大なソフトウェア エコシステムを備えたオペレーティング システムでは、古いプログラムを正常に実行し続けることの方が、過去のコードを完全にクリーンアップするよりも重要な場合があります。

「シムシティ」のメモリ エラーにより、Microsoft はオペレーティング システムの変更を要求

EmulateHeap が存在する理由を理解するには、まずよくあるプログラミング エラー、つまりメモリを解放した後も読み取りを続けることを理解する必要があります。

アプリケーションの実行中は、データを保存するためにオペレーティング システムからメモリを申請する必要があります。データが不要になった場合、システムが他の用途に再割り当てできるように、プログラムは対応するメモリを解放する必要があります。

プログラムがメモリ ブロックを解放しても、そこからデータを読み続けると、いわゆる「解放後の使用」エラーが発生します。これは典型的なプログラミングの欠陥であり、プログラムが無効なデータを読み取ったり、クラッシュしたり、場合によってはセキュリティ上の問題を引き起こしたりする可能性があります。

初期の Windows 環境の一部のプログラムは、予期せずこの誤った動作に依存していました。

Stack Overflow の共同創設者で元 Microsoft エンジニアの Joel Spolsky が 2000 年に公開した記事によると、初期の Windows バージョンの「SimCity」にも同様の問題がありました。このバージョンの開発者である Jon Ross 氏は、後に誤ってバグを残してしまったことを認めました。つまり、ゲームはメモリを解放した後も、もともとそこに保存されていたデータを読み続けてしまうのです。

この問題がすぐに発覚しなかった理由は、当時の Windows 3.x のメモリ管理方法に関係しています。特定の状況下では、プログラムがメモリを解放した後、関連するデータが他の用途によってすぐには上書きされないため、ゲームが読み取りを続けても、元のコンテンツを取得することができます。

言い換えれば、ゲーム自体にバグがあり、古いオペレーティング システムの動作がたまたま問題を覆い隠しているだけです。

Microsoft が Windows 95 を開発したとき、状況は変わりました。新システムでは異なるメモリ管理機構が採用され、「シムシティ」はWindows 95のベータ版で誤動作が発生し始めた。

マイクロソフトは 2 つの選択肢を迫られました。ゲーム開発者にプログラムの修正を依頼するか、オペレーティング システムにバグを許容し続けるかです。

最終的に、Microsoft は後者を選択しました。

エンジニアは、「シムシティ」専用の互換性コードを Windows 95 に追加しました。システムは、ゲームの実行を検出すると、関連付けられたメモリをすぐには解放しない特別なメモリ割り当てモードに切り替わります。

こうすることで、メモリを解放した後もゲームが元のデータを読み取り続けた場合でも、期待どおりの結果が得られ、クラッシュが回避される可能性が高くなります。

現代のソフトウェア エンジニアリングの観点から見ると、このアプローチは非常にユニークです。通常、オペレーティング システム開発者は、サードパーティ ソフトウェアのプログラミング エラーを隠すためにシステムの動作を変更することを望んでいません。しかし、当時の Microsoft の目標は、オペレーティング システムをアップグレードするためにユーザーに元のプログラムを放棄させるのではなく、新しいシステムで既存のソフトウェアを確実に実行できるようにすることでした。

この決定は、Windows 互換性の歴史における典型的なケースでもあります。

「シムシティ」から EmulateHeap へ: 互換性メカニズムは徐々に拡大中

シムシティに対する特別な扱いはほんの始まりにすぎません。

Windows が徐々に進化するにつれて、Microsoft は、このゲームだけでなく他のアプリケーションも、古いバージョンの Windows のメモリ管理メカニズムの特殊な動作に依存していることを発見しました。

Microsoft エンジニアの Raymond Chen は、2010 年に発行された Windows テクノロジ コラムでこの問題について説明しました。一部の古いプログラムは、元の値がまだ存在すると仮定して、メモリが解放された後もメモリからデータを読み取り続けます。

これらのプログラムを後続の Windows バージョンで実行すると、メモリ割り当てとリサイクル方法の変更により、他のデータによって上書きされたコンテンツが読み取られ、クラッシュする可能性があります。

Microsoft がこのような問題を抱えたプログラムごとに特別なコードを作成すると、保守コストが高くなるだけでなく、増加する古いソフトウェアに対応することも困難になります。

その結果、Microsoft は EmulateHeap と呼ばれる互換性修正メカニズムを開始しました。

SimCity に固有のコードとは異なり、EmulateHeap はより一般的なアプローチを提供します。メモリ管理関連のインターフェイスへのアプリケーション呼び出しをインターセプトし、これらの呼び出しを Windows 95 の動作をエミュレートする代替実装に転送します。

これには、HeapCreate、LocalLock、GlobalReAlloc など、ヒープ メモリ管理に関連する一連のインターフェイスが含まれます。アプリケーションとその基礎となるメモリ管理メカニズムの間に互換性レイヤーを追加することにより、システムは特定のレガシー プログラムが使い慣れた方法で動作し続けることを可能にします。

さらに驚くべきことは、Microsoft が非常に単純な実装を採用したことです。

Raymond Chen の説明によると、Microsoft のエンジニアは、Windows 95 ヒープ メモリ マネージャーのソース コードを直接コピーし、再コンパイルして、Windows Application Compatibility Framework に追加しました。

これは、非常に重要な Windows 95 メモリ管理コードが、最新の Windows 互換性インフラストラクチャに実際に保持されていることを意味します。

ただし、これは Windows 11 が Windows 95 メモリ マネージャーを実行していることを意味するものではありません。

EmulateHeap は、オンデマンドで有効になる互換性メカニズムです。特定のアプリケーションがこの修正を使用するように構成されている場合にのみ、対応する従来のコードがロードされます。この機能を有効にしない通常のプログラムの場合、この互換性メカニズムにより、Windows は Windows 95 のメモリ管理方法に自動的に切り替わりません。

さらに、EmulateHeap は、Microsoft が「SimCity」専用に作成した互換性コードと同じ機能ではありません。どちらも、古いソフトウェアを正常に実行し続けようとする Microsoft の設計哲学を反映していますが、問題を解決する方法と適用範囲は異なります。

Windows 11 で EmulateHeap を見つける方法は?

Windows の内部互換性メカニズムを理解したいユーザーのために、Microsoft はシステムでサポートされているアプリケーション互換性修正を表示する Compatibility Administrator と呼ばれるツールを提供しています。

このツールは Windows アセスメント & デプロイメント キット (Windows ADK) に含まれており、主にシステム管理者と IT プロフェッショナルを対象としています。 Microsoft が 2026 年 9 月にリリースした関連ツールのバージョンは、Windows 11 26H2 をサポートします。

Windows Most は、作成者が Windows 11 26H2 コンピューター上で EmulateHeap を見つけたと報告しました。具体的な手順は次のとおりです。

まず、Microsoft の公式 Web サイトから Windows ADK をダウンロードし、インストール プログラムを開始します。機能選択画面では、アプリケーション互換性ツールである「アプリケーション互換性ツール」を選択するだけでインストールが完了します。

インストールが完了したら、[スタート] メニューで Compatibility Administrator を検索し、32 ビット バージョンを開きます。 Windows 95 時代の古いプログラムの多くは 32 ビット アーキテクチャを使用しているため、このような互換性メカニズムを確認する場合には、32 ビット版を最初に使用する価値のあるツールです。

プログラムを開いた後、[カスタム データベース] 領域で [新しいデータベース] を右クリックし、[新規作成] を選択して、互換モードに入ります。次に、利用可能な互換性修正プログラムのリストで EmulateHeap を探して、この機能を確認します。

Compatibility-Administratir-32-bit-in-Start.jpg

互換モードの新しいデータベースの作成.jpgEmulateHeap-in-Compatibility-Administrators-list-of-compatibility-fixes-on-Windows-11-26H2.jpg

リストにある互換性修正プログラムを見つけたからといって、すべての古いプログラムが正しく動作するようになるわけではないことに注意することが重要です。

Microsoft は以前にも同様の問題に遭遇しました。 Windows 11 22H2 アップデート後、一部のユーザーは、特定の互換性修正を有効にした後、ゲーム「グランド セフト オート: バイス シティ」で音切れの問題が発生し、「ニード フォー スピード: モスト ウォンテッド」がクラッシュしたと報告しました。

これは、互換性修正自体も他のシステム コンポーネントやゲーム コードとの競合を引き起こす可能性があることを意味します。たとえ特定のメカニズムが、ある種の歴史問題を解決できるとしても、それがすべてのプログラムに適していることを意味するわけではありません。

したがって、一般のユーザーは古いゲームを実行するためだけに EmulateHeap を有効にする必要はありません。古いソフトウェアが実行されないという問題が発生した場合は、修正プログラムを適用するかどうかを決定する前に、そのプログラムの具体的な互換性に関する推奨事項を調べることがより賢明です。

なぜ Windows はこの古いコードをクリーンアップしないのでしょうか?

Windows 95 から Windows 11 まで、Microsoft はオペレーティング システムに多くの変更を加えてきました。メモリ管理、グラフィック システム、セキュリティ メカニズム、ドライバーやアプリケーションの実行環境など、現代の Windows は 1990 年代のシステムとは大きく異なります。

しかし、オペレーティング システムは、古いソフトウェアであっても、いつでも破棄して再構築できる製品ではありません。

数十年にわたる開発を通じて、何百万ものアプリケーションが Windows が提供するインターフェイスと動作に依存してきました。これらのプログラムの中には、公式ドキュメントに厳密に従って開発されているものもありますが、知らず知らずのうちにシステムの特定のバージョンの動作に依存しているものもあります。

これらのプログラムがまだ使用されている限り、Microsoft は基盤となるメカニズムの変更による影響を考慮する必要があります。

通常のソフトウェアの場合、オペレーティング システムのアップグレード後の互換性の問題は、特定の不都合を引き起こすだけである可能性があります。しかし、実際のビジネス タスクを依然として実行しているエンタープライズ ソフトウェア、プロフェッショナル ツール、レガシー プログラムの場合、互換性の破壊はさらに大きな損害を引き起こす可能性があります。

その結果、Microsoft は長い間、大規模なアプリケーション互換性フレームワークを維持してきました。その機能は、古いプログラムにそのプログラムが実行されている Windows のバージョンを通知するだけでなく、一部のシステム コールをインターセプトしたり、特定の動作を調整したり、特定のプログラムに基づいて特殊な互換性修正を有効にしたりすることもできます。

これらの措置は通常、ユーザーに対して透過的です。古いプログラムが起動すると、システムは対応する修正をバックグラウンドで適用しますが、ユーザーはオペレーティング システムがプログラムの動作を変更したことに気づかない可能性があります。

EmulateHeap はこのシステムの一例です。

この存在は、Microsoft が Windows 95 のメモリ管理が最新のシステムよりも優れていると考えていることを意味するものではありませんが、一部の古いプログラムが過去の動作に依存していることを意味します。これらのプログラムの破壊を避けるために、Microsoft は、最新のシステムのルールに従ってすべてのソフトウェアを強制的に書き直すのではなく、一連のレガシー実装を互換性フレームワークに保持することを選択しました。

このアプローチには利点とコストの両方があります。古いソフトウェアの耐用年数を延ばし、ユーザーがシステムをアップグレードする際の障害を減らすことができますが、オペレーティング システムのメンテナンスの複雑さも増大し、一部の歴史的なコードが最新のシステムに長期間存在することになります。

すべてのクラシック ソフトウェアが平等に扱われるわけではありません

Microsoft は一部の古いプログラムに対して特別な互換性コードを保持する意向ですが、すべての従来のソフトウェアが最新の Windows で引き続き実行できることを意味するわけではありません。

代表的な例は、かつて Windows に組み込まれていた 3D ピンボール ゲームである 3D Pinball です。このゲームが 64 ビット バージョンの Windows で利用できなくなった理由の 1 つは、追加作業を必要とする 64 ビット互換性の問題があり、Microsoft が問題を完全に修正するためにリソースを投入しなかったことです。

これは、EmulateHeap の状況とは対照的です。

広く使用されているソフトウェア、重要な商業的価値があるソフトウェア、または比較的限定的な変更を加えれば継続して実行できるソフトウェアの場合、Microsoft は互換性の維持にリソースを投資する意向がある場合があります。他のプログラムについては、修理費用が高すぎる場合、またはユーザーの需要が大幅に減少した場合、Microsoft はサポートを提供しないことを選択する場合があります。

したがって、Windows との互換性は際限なく約束されるものではありません。メンテナンスコスト、ユーザーのニーズ、セキュリティリスク、技術的な複雑さの間で常にトレードオフを行う必要があります。

Microsoft が近年 Windows インターフェイスの最新化を続けていることは注目に値します。たとえば、同社は、Windows 95 時代から残っているプロパティ ダイアログ ボックスの一部を、WinUI 3 ベースの新しいインターフェイスに徐々に置き換えています。

ただし、インターフェイスの最新化と基本的な互換性のメンテナンスは同時に実行できます。ユーザーに表示されるウィンドウには新しい設計テクノロジが採用されている可能性がありますが、インターフェイスやシステム アーキテクチャの更新によって過去のアプリケーションの互換性が失われないように、一部の古いコードがシステム内にまだ保持されています。

これは、Windows と多くの比較的新しいソフトウェア プラットフォームとの重要な違いの 1 つでもあります。Windows は最新のアプリケーションをサポートする必要があるだけでなく、数十年にわたって形成されてきた巨大なソフトウェア エコシステムに可能な限り対応する必要もあります。

Windows 95 から Windows 11 まで続く互換性の伝統

EmulateHeap の話は、古いゲームとメモリ マネージャーに関する単なる技術的な逸話のように見えるかもしれませんが、実際には Windows の長年にわたる中核戦略を反映しています。

「シムシティ」の Windows 95 ベータ版に問題があったとき、Microsoft はゲームのバグを許容するためにオペレーティング システムを変更することを選択しました。それ以来、より多くの古いプログラムが過去のシステム動作に依存していることが明らかになってきたため、Microsoft はより完全な互換性修復メカニズムを徐々に確立してきました。

現在、Windows 11 には Windows 95 のメモリ管理動作をシミュレートできるコードがまだ保持されており、ユーザーは Microsoft が提供する管理ツールを通じてそのコードを見つけることができます。

これは、最新の Windows が依然として Windows 95 のコア アーキテクチャに依存しているという意味ではなく、また、通常のコンピュータがバックグラウンドで古いオペレーティング システムを実行しているという意味でもありません。実際に引き継がれているのは、互換性コードの一部と、古いソフトウェアをできるだけ壊さないようにするための Microsoft の設計アイデアです。

数十年前のオペレーティング システムにとって、このアプローチは技術的な負担であると同時に、競争上の利点でもあります。ユーザーが Windows の新しいバージョンにアップグレードするとき、多くの場合、購入したソフトウェア、使い慣れたツール、長年にわたって蓄積してきたワークフローを引き続き使用したいと考えます。古いコードの一部を保持することで、Microsoft はオペレーティング システムのアップグレードによって生じる互換性のリスクを軽減しました。

この観点から見ると、Windows 11 に隠された Windows 95 メモリ マネージャーは単なる歴史的遺物ではなく、ソフトウェア互換性に対する Microsoft の長期的な取り組みを具体的に示したものであると言えます。オペレーティング システムのインターフェイスが変更され続け、ハードウェア プラットフォームがアップグレードされ続けている場合でも、古いゲームやプログラムが今日のコンピューターで引き続き実行できるという理由だけで、数十年前のコードが機能し続ける可能性があります。

関連タグ

関連記事

コメント

0/500
Captcha (click to refresh)
コメントなし