さようなら、Windows 5。

とうとう近づいてきた

win20032
最近、良く目につくようになった、「Windows Server 2003移行」の文字。GoogleやBingで検索すると、技術情報よりも延命措置の有償サービスが上位に表示されます。私の業務環境では既にレガシーWindowsを扱っていない事もあり、現実的な問題がどんなものかは想像するしかない状態です。

公式がどこかいまいち良く判らないので、リンクを張っておきます:Windowsライフサイクルのファクトシート

Windows XPが2014年4月にサポート切れとなり、もうすぐWindows Server 2003のサポートも切れます(2015年7月15日)。つまり、Windowsとしてサポートが存在するバージョンはVista以降、という事になります。

Windows XPはともかくとして、Windows Server 2003は個人的にとても良い印象のWindowsでした。Windows XPと大体において同じカーネルを持ち、Windows XPのように色々ゴテゴテと付いていないOSと見た時、2003の扱いやすさが光るのです。

# ええと、Vistaや7が嫌いと言う訳ではなく、むしろ「見た目」で入る製品も好きなのですが、手の内でほぼコントロール出来る感も、それはそれで良いと思ってます。

また、Windows 5系列は、初めてx64のサポートが追加されたバージョンでもあります。初物だけあって、Windows XP x64 Editionは色々な制約があって、ユーザーサイドで必ずしも良いOSとは言えませんでしたが、Iteniumと違ってx86にやさしい(互換性が高い)事が良く、後続のWindows x64の基礎を作りました。また、同じx64カーネルを持つWindows Server 2003 x64はサーバー向けという事もあって、より良く改良されていました。

# Windows Server 2003 x64はWindows XP x64よりも、全ての面で安定性が高かった。
# デバイスドライバについて言えば、サードパーティはWindows XP x64を半ば無視ししていたのに対し、2003 x64での開発に注力していたことも大きいです。


カーネルモードの5

win20031Windows XPやWindows Server 2003は、Win32プログラミングを行う方なら知っているかもしれませんが、GetVersionEx APIで得られる「メジャーバージョン番号」番号は「5」です。この記事のタイトルはそこから来ている訳ですが、このバージョン5はWindows 2000からWindows Server 2003 R2までの系譜です。分かりつらいですね。Windows 5の一覧を載せましょう:

 

  • Version 5.0 – Windows 2000 x86 (Windows 2000 Professional/Server/Advanced server)
  • Version 5.1 – Windows XP x86 (Professional/Home/Starter)
  • Version 5.2 – Windows Server 2003 x86/x64/Itenium (無印/R2) / Windows XP Professional x64/Itenium

Windows XP x64は実は5.2なので、2003と同じ扱いである事が分かります。既にどうでもいいトリビアですが、Windows 2000、つまり5.0は、唯一のNEC PC-9800シリーズ向けの実装が存在しました。

# そういえば、NTの頃はMIPSやらAlphaやらもサポートされました(一時はSPARCの噂までありました)。

以前私はWDKを使って、Windows向けのストレージ系ツールを設計・開発していました。このブログのWDKのカテゴリでいくつか記事を書いているのは、その時得られた知見に基づいたものです。このツールは、Windowsのカーネルモードドライバ(フィルタードライバ)を含んでいて、ディスクI/Oを監視して色々操作するものでした。

テストの為に、ユーザーモードのアプリケーションで非常に高負荷なI/Oを発生させ、ntfs.sys・フィルタードライバ・物理ドライバ間のパフォーマンス測定を行っていました。その時に、Windows 5系列の各スタックは、全体的にパフォーマンスが高いなと思ったのです。

Windows 6(つまりVista以降)と5の間には、「乗り越える事が出来ない」程のパフォーマンス差がありました。残念ながら開発はWindows 7・2008R2までであったため、最新のWindows 8でどの程度改善されたのかは分かりませんが、それでもWindows 5系列の方が良いと思われます。その位の差がありました。

# VistaではSSE2への最適化も謳われていましたが、「そんなものは無かった」程の違いです。結局「Vista重い」というのは、エンドユーザーの正直な感想で大体合っていたなーと思います。

勿論、この例はシンセティックなベンチマークのようなものです。現実的なパフォーマンスの測定には、他のあらゆる要素が関係してきます。また、システムの利便性は、ベンチマーク結果だけで測る事は出来ません。ですが、ベンチマーク速度の話が出て来る度に、「あぁ、5のスタックだけ使えたらなぁ」という、不毛な妄想をしたものです。

実行環境について:Windows XP以上は、今の所HYPER-Vのゲスト拡張機能は問題なく動作するようです。Windows 2000については、リリースビルドは問題ありませんが、デバッグビルド(デバイスドライバデバッグ用の、アサーションが大量に挿入されたWindows)は動作しませんでした。


終焉

Windows XPの当初の印象は良くない物でした。また、Windows XPの終盤では、IE6の不具合と思しき症状も放置されたためにWindows Updateが出来ないという、最悪の状態でしたが、最後には修正されてほっとしました。

さて、現在、主に.NETの世界の住人として気になる事は、CLRとのバージョンの関係でしょう。Windows 5の系列は、大ざっぱにはCLR 2.0(.NET 2.0~3.5)のバージョンの扱いと重なります。つまりは、Windows 5が終焉するのに合わせて、CLR 2.0も終焉と考えても良いかなと言う点です。

Microsoft .NET Frameworkサポートライフサイクルポリシーを見ると、何だかややこしい事になっていますが、開発者の目線で見ると、もはやNuGetのサポートは避けられず、Visual StudioがWPFベースで実装されている事もあり、Visual Studio 2012での開発が最低レベル(少なくともCLR 4.0)という状況です。

NuGetは2010向けもありますが、パッケージの方が2010で検証していないものもあり、結局NuGetを使うなら、ほぼ最新のVisual Studioを使わなければならないため、古いバージョンでの開発は互換性問題を解決するよりも、問題を引き起こす方が大きいという、想像もしなかった状況になってきています。

また、NuGetのパッケージを使い、そのパッケージに脆弱性が見つかった場合、殆どのプロジェクトは最新版に対して修正を行うと思われます(そもそもNuGetにはバージョン分岐の概念が無い)。すると、脆弱性対策を行うには、パッケージを最新に更新すれば良い(=最新に更新しなければならない)、という事を意味します。

# 既にASP.NETのプロジェクトは、思いっきりNuGetに依存しているので、これを回避するのはかなり辛いです。

つまり、今後の開発は、同じプラットフォームバージョンが維持されることを前提に開発するのはほとんど不可能で、常に最新に追従し続けなければならない、事を意味します。これは既にスマートフォンベースの開発(iOS及びAndroid)では当たり前になってきており、好むと好まざるとにかかわらず、Windowsもその位の、素早く、変化に追従できる開発が求められる、という事です。

マイクロソフト周辺での事情の変化も大きい、IT全体での変化もとても大きなものでした。

そんな今日の状況を感じつつ、Windows 5を見送りたいと思います。

RIP Windows 5 versions.

win20033


※なお、文中で「GetVersionEx API」の話を持ち出しましたが、このAPIは非推奨です。「Version Helper functions」を使って下さい。