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 など) の数値を取り出してきて文字列処理するコードを書く人
Re: (スコア:1)
糞なのは名前と比較していることではなくて、前方一致で比較していることですよ。
本当に動作検証した環境だけサポートしたいのであれば、完全一致で比較するべきです。
ところでGetVersionExが正しいバージョンを返さない仕様は、私もかなり疑問です。
depricated扱いにされちゃっているので、「今回はマニュフェストがあれば通してるけど、次はもっと頑張っても正しいバージョンは得られなくするかもよ。」というMSの意図を感じます…
Re:Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア:1, 参考になる)
そろそろ我慢できなくなってきたから言うけど、MSはドキュメントでVerifyVersionInfo(またはそのラッパーマクロ)を使えと明言しているのに、わざわざ怪しげな方法 [livedoor.jp]を探し出してくるお前らみたいなバカのせい。
ちなみにMSがVerifyVersionInfoを推奨するのはこういうバカ [srad.jp]でも「バージョンx.y以降」を正しく判定できるから。
Re:Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア:2, おもしろおかしい)
GetVersionExはNT3.5・95以降で使用可能。
VerifyVersionInfoは2000以降で使用可能。
移行期はVerifyVersionInfoを確実に使うにはGetVersionExで2000以降なのを確認した上で、GetProcAdressでVerifyVersionInfoのアドレスを取得しなきゃいけないのが余計な手間がかかるから嫌がられたんでしょうな。
あとは「先人の知恵」を拝借する習慣の繰り返し。
どうして一次資料を見ないのか？ (スコア:2, 参考になる)
先頭に、別のAPI使えって書いてあるし、
ちゃんとサンプルコードの例示もあるのになー
http://msdn.microsoft.com/ja-jp/library/cc429835.aspx [microsoft.com]
http://msdn.microsoft.com/ja-jp/library/windows/desktop/ms724451(v=vs.... [microsoft.com]
野良情報を読むなとは言わないが、合わせて1次情報を必ず参照するのは基本中の基本だよね。
ググって野良情報を鵜呑みにするとか最低。
それならググらない方がまだマシ。