Windows 9x ソフトウェアが Windows 7 64 ビットで実行できるのはなぜですか?

Windows 9x ソフトウェアが Windows 7 64 ビットで実行できるのはなぜですか?

私は長年 (Windows XP の導入からかなり経ってから)、古い Windows 9x デスクトップ PC のコレクションを運用していました。基本的に、これらのマシンはハードウェアのスペックが低すぎて XP にアップグレードできず (また、多額の費用がかかったため)、元のソフトウェア (Windows 98SE および Windows ME のさまざまなインストール (すべて 32 ビット バージョンとして実行)) のまま使い続けました。

結局、私は XP を一度も使用しませんでした。Win9x マシンは非常に信頼性が高く、XP や Vista がリリースされてからずっと後も動作していました。しかし、最終的には、ある期間をかけて Windows 7 64 ビットに移行する必要がありました。

私は、なぜそのようなプログラムが Win7 64 ビットで実行されないのかと尋ねるなど、本当に愚かなことをするつもりはありません! :-)

例外なく、32 ビット Windows 98SE で実行していたすべてのソフトウェアは、Win7 の NT 64 ビット アーキテクチャでも (いわば) そのまま動作しました。今日でも、私はさまざまなソフトウェア、特に日常的に使用するワード プロセッサ プログラムや HTML エディタを使用しています。

64 ビット NT で Windows 9x プログラムを実行する際に予想していたような困難を経験したことがないのは、技術的な理由があるのでしょうか? Win7 の「互換性」設定については聞いたことがありますが、「互換モード」でプログラムを実行する必要はありませんでした。

Windows 7 では 32 ビット ソフトウェアと 64 ビット ソフトウェアが別の場所に保存され、別々に処理されることは承知していますが、これは Windows 7 用に作成された 32 ビット プログラムと 64 ビット プログラムに関連しているものだと思っていました。

Windows 98 32 ビット プログラムが Windows XP/Vista/7 32 ビット プログラムと完全に互換性があるように見えることに驚きました。その理由を理解したいと思います。本当に両者に違いはないのでしょうか?

また、古い Windows 9x プログラムの多くはポータブルでした。私は、それらを USB スティックや Windows 7 デスクトップに保存して実行する習慣があります。問題は発生していません。Program Files フォルダーから実行していないにもかかわらずです。もう一度、技術的な観点から、なぜ O/S がこれに反対しないのか理解したいです。

何か危険なことをしているのでしょうか? Windows 7 O/S は非常に安定しているようですが、すべきでないことを要求しているかどうかを知りたいです。

答え1

まったく問題がないのに、不満を言うユーザーはあなたぐらいでしょう。;)

主流メディアは、アプリの互換性の分野で Windows に不当な評価を与えるために多大な努力を払っていますが、実際には、Microsoft は下位互換性に多大な投資を行っており、Windows 98 用に作成されたアプリの大部分は Windows 7 でも使用できます。さらに、Windows 7 は Microsoft がこれまでに開発した中で最も安定したオペレーティング システムです。誤解のないように言っておきますが、Windows 7 と Windows 98 の違いは大きく、しかし、

  • Windows 98は、マイクロソフトがわざわざ書き直さなかった豊富なWindows APIを活用しました。例えば、画面上に四角形を描くウィンドウの作成またはメニューバーを表示する依然として同じです。
  • Windows 7 では、レガシー ソフトウェアの互換性の問題に対処するための対策が実装されています。その 1 つが UAC 仮想化です。Windows 98 アプリは、アプリ データをインストール フォルダーに書き込みました。Windows 7 では、これは許可されなくなりました。ただし、レガシー アプリの場合、UAC 仮想化により、アプリ インストール フォルダー外のデータ書き込み操作が にリダイレクトされます%LOCALAPPDATA%\VirtualStore

Windows 7 で動作しなくなった Windows 98 時代のアプリには、16 ビット アプリ (64 ビット Windows では動作しませんが、32 ビット Windows では動作する場合もあります) や、ハックまたは難解なレガシー OS サービスに依存するアプリが含まれます。

答え2

ここで多くの質問をされていますが、かなり複雑なものもありますが、基本的な答えは「Microsoft は下位互換性の維持に多大な努力を払っています」です。正直なところ、より良い質問は「なぜ動作しないのか」かもしれません。なぜなら、Win9x と NT (Win7 を含む) は両方とも Win32 API と x86 命令セットを使用しているからです (Intel の x86 命令セットに対する AMD の 64 ビット拡張は下位互換性があります。64 ビット モードで動作する「x64」プロセッサは 32 ビット プログラムも実行できます)。

動作しない理由として最も可能性が高いのは、アクセス制御です。Win9x はアクセス制御をまったくサポートしていなかったため、どのプログラムでもやりたいことを何でもできました。悪意を持って使用すると、マルウェアの作成が非常に簡単になります。悪意はないが怠惰に使用すると、多くの開発者がプロ​​グラムをインストール フォルダにデータを書き込むようにプログラムを作成しました。これはさまざまな理由から悪い考えですが、セキュリティもその 1 つです。「実際の」OS では、ファイルがインストールされるデフォルトの場所では、管理者以外のユーザーがファイルに書き込むことはできません。ソフトウェアをインストール/更新する場合以外は、管理者以外のユーザーとして実行する必要があります。

もちろん、この「実行中のディレクトリに書き込む」という行為は簡単(開発者は怠け者だと言ったのですが...) また、ソフトウェアをフラッシュドライブに保存できるという意味で「ポータブル」にもなります (フラッシュドライブは通常、アクセス制御がまったくありません。FAT ファイルシステムのバリアントを使用しており、FAT はファイル権限をサポートしていないためです)。この方法でソフトウェアを実行するアクセス制限された領域にインストールしてそこから実行する(管理者以外のユーザーとして)よりも安全性は低くなりますが、コンピューターを他の人と共有しない限りはおそらく問題ありません。

OSが反対しない理由についてですが、なぜ反対するのでしょうかProgram Files特別フォルダという概念は、慣例上、プログラムをインストールする場所というだけです。(これは実際には非常に愚かな慣例です。なぜなら、パスにスペースがある場所にインストールすると、一部のソフトウェアが機能しなくなるからです。しかし、MSは開発者があまりに不適切ではないことを確認したかったのかもしれません。それ怠け者...) の唯一の特別な点はProgram Files、64 ビット システムでは、32 ビット プロセスが "Program Files" フォルダーを要求すると、実際にフォルダーに誘導されることですProgram Files (x86)。それ以外にも、OS では、ユーザーがアクセスできる場所であればどこからでもプログラムを実行できます。一部のプログラムは、意図的にユーザー プロファイルにインストールされるか、ドライブのルートにある独自のフォルダー (C:\Python27開発者マシンでよく見られるフォルダー) にインストールされます。これらのプログラムは問題なく動作します。

関連情報