Windowsの遺産の両立性の未来へのかいま見

Windows 3.1 Windowsの最も新しい解放の十年古い適用を動かす機能はほとんど道の儀式になった。ほとんどの人々はWindowsのソフトウェア下位互換性が容易に成功のための重要な要因の1つであることを同意する。ソフトウェアの幅そして深さが指数関数的に育つと同時に各解放と、マイクロソフトがサポートのこのピットにより深く、より深いそれ自身を掘るどんなに。そんなにそうある人々は既に持っていなければ予測する結局Windowsを台無しにすることを。

最近出版された特許出願、「天然オペレーティングシステムの遺産の塗布を実行するための環境」あなたのそれらのために家庭で遊ぶことは、マイクロソフトHoiのVOおよびSamer Arafeh (によって2007年の4月にファイルされて動作するかだれがWindowsの穀粒で)ある細部をいかにのそれら明らかにする力 (および重点はパテントが紙切れのちょうど単語であるのでかもしれた) Windowsの未来の解放のソフトウェアの互換性を収容し、劇的に改善しなさい。

パテントに記述されているように、遺産の塗布サポートの問題はバイナリにある(DLLsおよびEXEs)。オペレーティングシステムが更新済であると同時に、システムバイナリは変わる。より古いシステムコール、製品回収および例外は新しいオペレーティングシステムに全然ないかもしれなかったり程度に存在するかもしれなかったりまたは互い違いの応答を発生させるかもしれない。本当らしいこれらのバイナリによって決まる遺産の塗布のhavokを破壊するために。

現在問題へ2つの慣習的な解決がある。それぞれの利点および不利な点とのそれぞれ。

第1 「シム」の使用を用いる。比喩的に話して、それは事が落ちないことを確かめるべき端のまわりに基本的に粘着性があるテープである。厳密には、遺産の塗布が荷を積まれ、遺産の塗布および天然システムバイナリの間に坐るとき大急ぎで加えられるのはcustom-writtenパッチである。伝えられるところによればマイクロソフトは書いたたくさんのWindowsヴィスタのためのシム、あればまだ書く. 上部はシムが実行し比較的易いが全然よく量らない適用によ適用基礎の平均ごとのaでシムを発生させなければならないこと。

第2解決は利点の仮想化の技術を取る。遺産OSの仮想計算機を催すことによって、遺産の塗布はよくするために知らない。仮想化の提供の屈強な性能の費用で完全な適用サポートしかし。ハードウェアサポートはまた例えば3Dグラフィックのような資源を共有することも困難にする原住民である。それはまたユーザーが遺産のオペレーティングシステムの各版を取付けられる要求する。

適用両立性モジュール

提案された解決策はいろいろな方法で両方の最もよいビットを取る。 It works first by detecting if the application was written for the native operating system. If not, it will load the application with its respective legacy system binaries. The accommodate the difference in system calls between the legacy binaries and native kernel, an Application Compatibility Module is placed in between to act as a translator for these calls. In certain cases where a comparative native system calls may not exist at all, the ACM could also be smart enough to provide the same functionality as the missing system call.

Hypothetically speaking, if the system detected an XP application it would load the XP system binaries (ex. system32_xp) and then a XP-to-WinNext compatibility module.

The benefit of this solution is it offers much broader application compatibility with relatively low investment on Microsoft’s behalf on the scale of per-application - they will only have to write a ACM for each legacy system they wish to support. Legacy applications will also be able to take full advantage of the system resources as a native application, because there is no emulation involved.

Notable Windows on Windows - the compatibility system used to provide 16-bit on 32-bit systems support and 32-bit on 64-bit systems support uses a similar concept.

One of the biggest gripes from most Windows enthusiasts has been the bloat legacy compatibility forces into Windows. Whilst this patent doesn’t specifically mention so, I presume such ACMs are modular and can be installed and removed on demand. For example, if you need to run Windows Vista applications in future versions of Windows, you will only download and install the Vista ACM Pack (with Vista binaries) for that operating system. Those who do not require legacy support will then be not required to install any ACMs.

Thinking about it, it could become a business model to sell ACMs separately to Windows - reducing the overall cost of Windows and charging a tiered price for legacy support. A cheaper and less bloated Windows, wouldn’t that be nice.