MicrosoftのRaymond Chen氏はこのほど、「Were there any Windows 3.1 programs that were so incompatible with Windows 95 that there was no point trying to patch them? - The Old New Thing」において、Windows 3.1向けに開発された一部ソフトウェアがWindows 95で動作しなかった背景を解説した。

同氏の解説から、Windows 3.1とWindows 95の間に単なる不具合修正では対応できない深刻な互換性問題が存在していたことがわかる。

  • Windows 3.1時代のソフトは、OS内部構造への依存によりWindows 95で動作しないケースがあった 出典：Microsoft

    Windows 3.1時代のソフトは、OS内部構造への依存によりWindows 95で動作しないケースがあった 出典：Microsoft

なぜ互換性の問題が発生したのか？内部構造への依存が原因

Windows 95で互換性問題が発生した最大の理由は、OS内部に直接アクセスする設計が通用しなくなったためだ。

1995年に登場したWindows 95は、その元になったWindows 3.1からGUIの面で飛躍的な進歩を遂げた。しかしこのアップデートの過程で、一部のソフトウェアで修正困難な互換性の問題が発生した。Chen氏の記事ではその背景を説明している。

問題（1）OS内部へ直接アクセスする設計

特に問題となったのは、アプリケーションがOS内部の構造へ直接アクセスする設計である。Windows 3.1時代の一部ソフトウェアは、APIに頼ることなく、システムハンドルを独自にポインターへ変換し、内部データへ直接アクセスする手法を採用していたという。

しかしWindows 3.1は16ビットOSだったのに対して、Windows 95では内部のメモリ管理方式が変更され、32ビット環境へ移行した。その結果、ハンドルをポインターに変換する手法そのものが成立しなくなり、意図したとおりに動作しないソフトウェアが出てきたという。

問題（2）APIではなく内部実装に依存したコード

また、本来はAPIから取得できる情報であっても、内部実装へ依存するコードが使われていた例も指摘されている。このような設計はOSの進化に弱く、結果として移行時の障害を拡大させた。

OSのバージョン判定処理を実装したソフトウェアもあったが、その判定処理そのものに誤りがあり、想定外の環境で誤作動を引き起こす事例も確認されたという。

そのほか、APIの挙動を変更する独自フックなど、個別の要因による不具合も存在した。それらの多くは、内部構造への深い依存が最も大きな要因だったとされている。

パーツの自前開発がバージョンアップの障害になった理由

Windows 3.1や95の時代は、低レイヤーのパーツを自前で実装しているソフトウェアが現在に比べてはるかに多かった。これはプログラマーがOS内部の仕組みを深く理解していたということでもあるが、皮肉なことにそれがバージョンアップに対する柔軟性を損なう結果になったわけだ。

現在のソフトウェア開発にも通じる教訓

Chen氏の記事は、公開された仕様に基づいてソフトウェアを開発する重要性をあらためて思い起こさせてくれる。

この問題は現在のソフトウェア開発にも通じる。OSの内部仕様に依存する設計は、将来の互換性リスクを高めるため、公開APIの利用が重要とされている。