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 など) の数値を取り出してきて文字列処理するコードを書く人
これからのアプリは、上位互換を保障するべき (スコア:5, 参考になる)
ちょっと調べたら、GetVersionExは、既に非推奨になってますね。
で、「互換モード」を設定すると、GetVersionExが偽装される仕組みになってると。
つまり、Win8.1は「Win8.0互換モードが標準」って事です。
逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。
実際問題として、SP等が入ると、GetVersionExは変わらないのに機能がごっそり変更されたりします。
だから、機能を個別に認識して動作するのが本来の姿なんでしょう。
ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
現実に、「
-- Buy It When You Found It --
Re:これからのアプリは、上位互換を保障するべき (スコア:0)
> だから、機能を個別に認識して動作するのが本来の姿なんでしょう。
ところがDLLインジェクション脆弱性のせいで、機能検出は推奨されていない。
Re:これからのアプリは、上位互換を保障するべき (スコア:3, 参考になる)
http://msdn.microsoft.com/ja-jp/library/cc429835.aspx [microsoft.com]
>オペレーティングシステムの特定の機能が存在するかどうかを判断することを目的としている場合、現在(開発時点で最新)のオペレーティングシステムのバージョン番号だけを指定する方法は、通常は最善とは言えません。再配布可能な DLL という形で、新しい機能が追加されている可能性もあるからです。このようなことを目的としている場合、GetVersionEx 関数を使ってオペレーティングシステムのプラットフォームまたはバージョン番号を判断する代わりに、その機能が存在するかどうかをテストしてください
ここ見る限り機能検出を推奨してるように見えるが
Re: (スコア:0)
これ、古くはブラウザのjavascriptで、IEとNetscapeを文字列で判断して分岐してた時から変わってないね。
もし IE なら document.all~
って書くからIEが新しくなってハマるんだから、
もし documento.all があるなら document.all~
って書けばいいのに。
(本当は document.all 使わなければいいのに)