Ver. 5.0 … Windows 2000
Ver. 5.1 … Windows XP (32bit)
Ver. 5.2 … Windows Server 2003、Windows XP (64bit)
Ver. 6.0 … Windows Vista
Ver. 6.1 … Windows 7
Ver. 6.2 (6.2.9200) … Windows 8
Ver. 6.3 (6.3.9600) … Windows 8.1
V er.6.4 (6.4.9841) … Windows 10 (Technical Preview)
そのため、わざわざブランドバージョン (Windows 7, Windows 8, Windows 8.1 など) の数値を取り出してきて文字列処理するコードを書く人
Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア:5, 参考になる)
プログラム開発者にとって、Windows の内部バージョンは下記のように合理的な管理となっていることから、一見使いやすいように思えます。
Ver. 5.0 … Windows 2000
Ver. 5.1 … Windows XP (32bit)
Ver. 5.2 … Windows Server 2003、Windows XP (64bit)
Ver. 6.0 … Windows Vista
Ver. 6.1 … Windows 7
Ver. 6.2 (6.2.9200) … Windows 8
Ver. 6.3 (6.3.9600) … Windows 8.1
V er.6.4 (6.4.9841) … Windows 10 (Technical Preview)
そのため、わざわざブランドバージョン (Windows 7, Windows 8, Windows 8.1 など) の数値を取り出してきて文字列処理するコードを書く人
Windows8.1はWindows8SP1 (スコア:1)
GetVersionExで同じ値が帰るなら、「内部バージョンは変更されていない」と解釈するのが本筋でしょう。
つまり、商業上の理由で8.1と言っているが、実はSP1って事です。
XPでも、SP2等で「GetVersionExで同一バージョンが帰るが内部的には別物」となった実績(?)がありますし。
SP1だと解釈すれば、「バージョン番号の偽装」では無いですよね。
実際、今後のWindows8の方針として、8.1だけがサポートとなり、8.1へのアップデートが必須となる様ですし。
XPのSPでは、「アプリ側での対応が当然」と看做されていた様に思います。
で、実際の所としては、「COMを使った機能の確認」や「DLLのバージョンを判定しての処理」がM$の推奨手順で、GetVersionExでの代用は出来ない旨の記述がMSDNに明記されてます。
元々、GetVersionEx自体がWindowsAPIだから、他のWindowsAPIで機能を明示してその動作を認識する実装が「正当な方式」なんです。
「ブランドバージョンを取得して文字列比較する」実装も、結局はダーティハックであり、DLLのバージョン変更(WindowsUpdateで常用される)に対応出来ない欠陥があります。
実の所、Windowsは「単一バージョンの判定処理」だけでは対応出来ない面倒なシステムとなってます。
「使用する機能を明示して、その機能のバージョンを取得する」実装が正当と言うのも、その事に由来してます。
アプリケーションマニフェストも、(非常に記述が面倒だが)機能を個別に指定する仕組みが入ってます。
バージョン番号で全体の動作を切り替えるのでは無く、機能個別でバージョン毎に動作を最適化する実装が必要なんですよ。
その点を端折って責任問題が云々ってのは、開発側の手抜きかと。
(無論、個別での動作変更は凄く処理が面倒だから、そのコストを何処かに転化する必要は在りますが)
-- Buy It When You Found It --