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 など) の数値を取り出してきて文字列処理するコードを書く人
問題はJavaの既存コード (スコア:0)
今回の検索結果に上がってるのは全部Javaの既存コードで、JavaのSystem.getProperty("os.name")で取得したもののようだから、Win32 APIのGetVersionExは直接関係ない。まあオープンソース限定で、クローズドソースのは調べようがないし、Javaの実行環境自体がどうやってWindowsのバージョンを取得してるか知らないが。
>また、Windows 10 の Technical Preview 版で、GetVersionEx() API を用いると、6.3.9600 (Windows 8.1 と同じ) という偽装された値が返ってきます。
これは違う。マニフェストファイルに全く記述しなければ6.2(Windows 8)が返ってくる。