x64は実は5.2なので、2003と同じ扱いである事が分かります。PC-9800シリーズ向けの実装が存在しました。いえば、NTの頃はMIPSやらAlphaやらもサポートされました(一時はSPARCの噂までありました)。以前私はWDKを使って、Windows向けのストレージ系ツールを設計・開発していました。このブログのWDKのカテゴリでいくつか記事を書いているのは、その時得られた知見に基づいたものです。このツールは、Windowsのカーネルモードドライバ(フィルタードライバ)を含んでいて、ディスクI/Oを監視して色々操作するものでした。テストの為に、ユーザーモードのアプリケーションで非常に高負荷なI/Oを発生させ、ntfs.sys・フィルタードライバ・物理ドライバ間のパフォーマンス測定を行っていました。5系列の各スタックは、全体的にパフォーマンスが高いなと思ったのです。6(つまりVista以降)と5の間には、「乗り越える事が出来ない」程のパフォーマンス差がありました。5系列の方が良いと思われます。その位の差がありました。VistaではSSE2への最適化も謳われていましたが、「そんなものは無かった」程の違いです。結局「Vista重い」というのは、エンドユーザーの正直な感想で大体合っていたなーと思います。この例はシンセティックなベンチマークのようなものです。現実的なパフォーマンスの測定には、他のあらゆる要素が関係してきます。システムの利便性は、ベンチマーク結果だけで測る事は出来ません。ベンチマーク速度の話が出て来る度に、「あぁ、5のスタックだけ使えたらなぁ」という、不毛な妄想をしたものです。XP以上は、今の所HYPER-Vのゲスト拡張機能は問題なく動作するようです。2000については、リリースビルドは問題ありませんが、デバッグビルド(デバイスドライバデバッグ用の、アサーションが大量に挿入されたWindows)は動作しませんでした。XPの当初の印象は良くない物でした。Updateが出来ないという、最悪の状態でしたが、最後には修正されてほっとしました。現在、主に.NETの世界の住人として気になる事は、CLRとのバージョンの関係でしょう。2.0~3.5)のバージョンの扱いと重なります。2.0も終焉と考えても良いかなと言う点です。4.0)という状況です。Studioを使わなければならないため、古いバージョンでの開発は互換性問題を解決するよりも、問題を引き起こす方が大きいという、想像もしなかった状況になってきています。NuGetのパッケージを使い、そのパッケージに脆弱性が見つかった場合、殆どのプロジェクトは最新版に対して修正を行うと思われます(そもそもNuGetにはバージョン分岐の概念が無い)。すると、脆弱性対策を行うには、パッケージを最新に更新すれば良い(=最新に更新しなければならない)、という事を意味します。ASP.NETのプロジェクトは、思いっきりNuGetに依存しているので、これを回避するのはかなり辛いです。今後の開発は、同じプラットフォームバージョンが維持されることを前提に開発するのはほとんど不可能で、常に最新に追従し続けなければならない、事を意味します。これは既にスマートフォンベースの開発(iOS及びAndroid)では当たり前になってきており、好むと好まざるとにかかわらず、Windowsもその位の、素早く、変化に追従できる開発が求められる、という事です。マイクロソフト周辺での事情の変化も大きい、IT全体での変化もとても大きなものでした。5を見送りたいと思います。API」の話を持ち出しましたが、このAPIは非推奨です。functions」を使って下さい。WordPress%d人のブロガーが「いいね」をつけました。