Windows 11、30年前にコンパイルされたバイナリも実行

 (twitter.com/mikko)
1 ポイント 投稿者 GN⁺ 2023-08-20 | 1件のコメント | WhatsAppで共有
  • 最新の Windows 11 が、1993年8月18日にコンパイルされたバイナリを実行し、Microsoft の長期的な下位互換性が際立つ事例となった
  • このプログラムは投稿時点で 30年前 に作られたバイナリで、古い Windows ソフトウェアが最新環境でも動作し得ることを示している
  • 事例の核心は、新しいバージョンのOSが過去の実行ファイルをそのまま受け入れる 下位互換性 にある
  • 別途変換、再コンパイル、追加設定が必要だったかどうかは、公開されている内容だけでは確認できない
  • 古いバイナリを実行できる可能性は、企業や個人ユーザーが長期保管されたソフトウェアを扱う際の重要な安定性のシグナルとなる

Windows 11で30年前のバイナリを実行した事例

  • Windows 11 は 1993年8月18日 にコンパイルされたバイナリを実行した
  • この事例は、Microsoft の 下位互換性 が非常に強力だという評価とともに共有された
  • 確認されている情報は、実行可能かどうかとコンパイル日に限られる
    • バイナリ名、開発言語、実行方法、追加設定の有無は含まれていない

関連記事

1件のコメント

 
GN⁺ 2023-08-20
Hacker Newsのコメント

  • 参考までに、Joel Spolskyの記事もある: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    SimCityの開発者の一人によると、DOSでは偶然うまく動いていたものの、Windowsでは壊れる致命的なバグがあったという。解放済みメモリを再利用するバグで、Windowsチームのテスターが人気アプリを動かしていたところ、SimCityが何度も落ちることに気づいた。Windowsの開発者たちはSimCityを逆アセンブルし、デバッガで追跡してバグを見つけたうえで、SimCityが実行されているかどうかを確認し、その場合に限って、解放後もメモリを使い続けられる特殊モードでメモリアロケータを動かすコードを入れたそうだ

    • 反例として、Soldier of Fortuneは現代のWindowsで誤って適用された互換性ハックのせいで壊れる。実行ファイル名を変えると問題なく動く
      こういう後方互換性の実装は不透明で場当たり的なので、あまりよくない。同様の道具は競合他社のアプリを壊すためにも使われてきた。たいていは、どの古いWindowsバージョンとして実行するかを一つずつ試すことになる。Linuxも安定したABIがないので、より良いわけではないし、Macは優れたRosettaと、理由のないアプリ破壊が混在している状態だ。FreeBSDのほうがうまくやっていたのか？ VMSのような、消えていった「成熟した」OSのほうがよかったのかもしれない
    • 最近のGPUドライバ更新も、おおむねこんな感じだ。開発者がゲームを直す代わりに、NvidiaはゲームのバグをGPUドライバのレベルで直して配布するほうが自分たちに利益がある、と計算しているわけだ
    • これはむしろ、後方互換性は壊すべきだという優れた根拠に見える。こうした馬鹿げたハックは誰かの保守とデバッグの負担になり、OS全体に税金のように上乗せされる。実際、その痕跡はかなり表に出ていると思う
    • Raymond Chenの「The Old New Thing」のボーナス章を探すと、人気アプリを一つずつ確認し、新しいOSで動くようにするためにWindowsをハックする専任チームがあった事例がたくさん出てくる
    • 一方でAsahi LinuxのGPUドライバは、プロセス名の最初の文字がXかどうかを確認し、そうなら単に拒否する
      なぜ今でもXorgを動かしているのか？ もうWaylandへ移行しているべきだ、という感じだ
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chenはこの話題について、何十年にもわたって内部からの視点を提供してきた: https://devblogs.microsoft.com/oldnewthing/

  • Windows API全体の安定性のおかげで、Win32/DXがWine/Protonの膨大な作業を通じて、Linuxや他のOS上で非常に安定して信頼できる「汎用」APIになっているのは面白い。ゲームがLinuxネイティブ版のリリースをやめ、単にProton向けとして出すケースをよく見る

    • Protonを前提にしたリリース版のほうが、Linuxネイティブ版より設定が簡単で、よりよく動くことが多い
    • その通り。去年、誰かがこのテーマで記事を書いていて、ここでもかなり議論されていた
      https://sporks.space/2022/02/27/win32-is-the-stable-linux-us...

  • これは狂っているのではなく、道具に対して当然期待する水準だ。私のハンマーは、30年前に買った釘にも今なお完璧に機能する
    後方互換性を壊し続ける不安定な土台の上には、何かを築くことはできない。結局、作る時間より保守する時間のほうが長くなる。そしてその後で車輪を再発明することになるが、ユーザーの立場では、ピカピカの新しい車輪が必ずしもより良いとは限らない。私が使っているソフトウェアの大半は10年以上前のもので、一部はまだ更新されているが、一部はそうでなかったりクラウドへ行ってしまったりして、私は幸せに取り残されている

    • Milwaukeeは、すでにかなり時代遅れになった自社工具用のNiCADバッテリーを今でも製造している
    • 逆に、こうした愚かな制限に永久に縛られることもある: https://news.ycombinator.com/item?id=14286383

  • 以前はそう信じていたが、今は違う
    Games for Windows – Liveサービスを使っていたSteamゲームのうち、2014年のサービス終了後に更新されていないものは、Windows 10以降では実行できない。そのサービスDLLが削除されたためだ。しばらくは、人々がサードパーティサイトからDLLをダウンロードして解決していたが、今ではそれもできない

    • DRMやネットワークサービスのない古いゲームでも、グラフィック互換性のために動かないことがある。ただしcnc-ddrawがその多くを救っている: https://github.com/FunkyFr3sh/cnc-ddraw
    • それでも、それらのゲームの海賊版はまだ動きそうだ ;)

  • もっと「狂った」例もある
    z/OS（OS360、MVSとも呼ばれる）は1960年代のプログラムまでサポートしており、IBMのあるDEは、Apollo 11ミッションのころにコンパイルされたプログラムを今でも使っていると言っていた

    • メインフレームの世界ではよくあることだ。Unisys（旧Univac）は、1962年に登場したUnivac 1100とバイナリ互換のDoradoメインフレームを今でも持っている
    • DEって何？ それと、そのプログラムが何をするものかも教えてくれた？
      30年以上前のバイナリを実行したり自動変換したりする他のシステムもある。POWER上のIBM i（i5/AS400）はSystem/38（1980）時代のプログラムを実行できそうだし、X86-64上のHPE NonStop（Tandem Guardianとも呼ばれる）は、1970年代後半の元の独自TNSシステムと1991年のMIPSシステムのバイナリを実行または変換できる

  • Windows が下位互換性に執着しているのは有名だが、DOS CLI アプリは DOS サブシステムが事実上固まっているので、それほど大きな挑戦ではない感じがする。もっと要件の多い DOS 風プログラムや初期の Win16 アプリを動かしたらどうなるのか気になる。たとえば 1986 年の Zortech C++ と Phar Lap DOS extender、あるいは Windows 3.1 の Minesweeper のようなものは動くだろうか？

    • それは DOS アプリではなく Win32 コンソールアプリだ。DOS アプリ（16 ビットでも 32 ビットでも）や Win16 アプリはネイティブには実行されない
    • Zortech C++ はしばらく自分が使っていた環境で、いい思い出がある。Phar Lap は深く入り込みすぎていて現在の Windows で動かすのは難しいと思うが、試してみる価値はある。おそらく拡張メモリ／エクステンデッドメモリ関連の機能は、今ではほとんど動かない気がする

  • これはまったくすごいことだと思われるべきではない。日常的で当然のことと見るべきで、できないなら非常に恥ずかしく、受け入れがたい失敗と見るべきだ
    2023 年の混乱ぶりを基準にしてすごくないという意味ではない。私たちが目指すべき規範がそうだという意味だ

    • 同意する。ほとんどの静的コンパイル済みバイナリが動作しなくなる理由はまったくない

  • Linux もそうだと言う人もいるだろうし、技術的には正しいが、実際にはかなり難しい
    カーネル ABIは安定しているが、それ以外はほとんど純粋な混沌に近く、これは Linux でアプリケーションが通常パッケージングされる方法によるものだ。アプリ自体はロードできるとしても（a.out 形式でなければ）、ほとんどのライブラリ読み込みで失敗する可能性が高い。結局、基準となる Linux ディストリビューション全体の chroot や別のランタイムが必要になり、30 年前のディストリビューションのアーカイブを見つけられるかも確信しにくい。さらに、カーネル ABI が本当に 1 ビットも変わっておらず、/proc や /sys のような他のインターフェースも変わっていないと仮定しなければならない。/sys は 30 年前にはなかったように思う。Xorg アプリなら、プロトコルレベルの互換性に昼食代を賭ける気にはならない

    • Linux でも Windows と同じ仕組みで動く。必要な動的ライブラリと設定がなければ動かない
      なぜこれが Linux では減点要因で、Windows ではそうではないのか理解しにくい

  • 古い Mac ソフトウェアがそのまま動かないのは、いつも残念に思っていた。Apple が新しいアーキテクチャへ移行するのは仕方なかったのかもしれない。だが数年後にエミュレーターが壊れるところが問題だ
    Microsoft が顧客に示す献身が、これほど驚くべきことであってはならない。すべての会社がそう振る舞うべきだ

    • Apple にもかつては、初代 iMac（300MHz？）にも最新の Mac OS X を入れられるようにしていた時代があった。RAM を最大まで増設する必要はあったかもしれないが、それで十分だったし、実際かなり使えた