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 が内部バージョンを偽装するのが諸悪の根源 なのです。
例えば、Windows 8.1 で、GetVersionEx() API を用いると、6.2.9200 (Windows 8 と同じ) という偽装された値が返ってきます。
何故、Microsoft がこういうことをするかというと、「Windows 8 を Windows 8.1 に変更したら、今まで動いていたアプリが動かなくなった」というクレームを受けたくないからでしょう。
しかし、プログラマーとしては、Windows 8.1 での動作確認が済むまでは「あなたがご利用のOSは、このソフトウェアではサポートしていません。」とエラーを出して強制終了する動作にしたかったりするわけです。動作を確認していない OS で動かしたことにより不具合が発生して、重大な経済的損失が発生することもあるのですから。
だからこそ、GetVersionEx() などの API を使わずに、ブランドバージョンを取得して文字列比較するといったコードを書いたりするのです。このような Microsoft の対応は、ウイルスバスターの連続誤検出問題で話題となった「いじくるつくーる」の作者さん [inasoft.org]なども疑問視しています。
もちろん、他の API を使う [livedoor.jp] だとか、マニフェストの宣言によって API による内部バージョン偽装を阻止する [inasoft.org] といった方法もあります。後者については、Windows 8.1 で起動させないようにするために、Windows 8.1 に対応しているというマニフェストを書かないといけないのが不合理に感じます。
実際問題があるかどうかはあまり関係無いですよ。 Windows 8.0対応のプログラムを開発しているときには、8.1でも全て正常に動作するなんてことは保証出来る訳ないんですから、万一を考え このスレッドの大元のコメントにあるような
しかし、プログラマーとしては、Windows 8.1 での動作確認が済むまでは「あなたがご利用のOSは、このソフトウェアではサポートしていません。」とエラーを出して強制終了する動作にしたかったりするわけです。動作を確認していない OS で動かしたことにより不具合が発生して、重大な経済的損失が発生することもあるのですから。
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 など) の数値を取り出してきて文字列処理するコードを書く人を糞プログラマー扱いする人が居ますが、Microsoft が内部バージョンを偽装するのが諸悪の根源 なのです。
例えば、Windows 8.1 で、GetVersionEx() API を用いると、6.2.9200 (Windows 8 と同じ) という偽装された値が返ってきます。
また、Windows 10 の Technical Preview 版で、GetVersionEx() API を用いると、6.3.9600 (Windows 8.1 と同じ) という偽装された値が返ってきます。
何故、Microsoft がこういうことをするかというと、「Windows 8 を Windows 8.1 に変更したら、今まで動いていたアプリが動かなくなった」というクレームを受けたくないからでしょう。
しかし、プログラマーとしては、Windows 8.1 での動作確認が済むまでは「あなたがご利用のOSは、このソフトウェアではサポートしていません。」とエラーを出して強制終了する動作にしたかったりするわけです。動作を確認していない OS で動かしたことにより不具合が発生して、重大な経済的損失が発生することもあるのですから。
だからこそ、GetVersionEx() などの API を使わずに、ブランドバージョンを取得して文字列比較するといったコードを書いたりするのです。このような Microsoft の対応は、ウイルスバスターの連続誤検出問題で話題となった「いじくるつくーる」の作者さん [inasoft.org]なども疑問視しています。
もちろん、他の API を使う [livedoor.jp] だとか、マニフェストの宣言によって API による内部バージョン偽装を阻止する [inasoft.org] といった方法もあります。後者については、Windows 8.1 で起動させないようにするために、Windows 8.1 に対応しているというマニフェストを書かないといけないのが不合理に感じます。
これからのアプリは、上位互換を保障するべき (スコア:5, 参考になる)
ちょっと調べたら、GetVersionExは、既に非推奨になってますね。
で、「互換モード」を設定すると、GetVersionExが偽装される仕組みになってると。
つまり、Win8.1は「Win8.0互換モードが標準」って事です。
逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。
実際問題として、SP等が入ると、GetVersionExは変わらないのに機能がごっそり変更されたりします。
だから、機能を個別に認識して動作するのが本来の姿なんでしょう。
ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
現実に、「アプリが未サポートだからXPから移行出来ない」って問題がありました（多分まだ在る）。
最近の攻撃状況から見ると、古いOSの脆弱性に起因するセキュリティ問題は、使用者だけでは無く、他者も巻き込む重大懸念事項です。
だから、動作未確認の環境でも「一応動作する」様に作りこむべきだし、リリース後は至急サポート対象にするのが、今後のソフト屋に望まれる姿勢かと。
「そんな費用何処から出すんだ？」って問題は、「サポートを売りつける」モデルを採用すれば解決出来ます。
もう、売りっぱなしじゃ済まない時代になってるんじゃないでしょうか。
-- Buy It When You Found It --
検証していない環境をサポートするのは不可能 (スコア:3, すばらしい洞察)
笑っちゃうほどおかしな話ですね。
どれだけコストを掛けても、未知のAPI変更に対応することなんて不可能です。
動くかどうか判らないものをサポートするには、お金がかかるかからない以前の問題です。
「20年後も、このテレビが映るようにしてくれ」ということと同じですよ。
放送の方式が変わるかもしれないし、補修部品を作成していた会社がなくなるかもしれない。
テレビ等は方式が公開されていて多数の会社が製作できますが、Windowsはたかだか一企業が作成しているOSです。
コストをかければプレリリース版等で早くから情報を掴んで、新しい対応バージョンを前もって用意することはできるでしょうし、
問題が起きたらすぐに直すように待機部隊を用意したりすることも当然できるでしょう。
ただそれは、本来サポートできるか、新しいOSに対応できるかどうかとはまた別の話です。
未知の変更に必ず対応できるという保証は誰にもできません。
Re: (スコア:0)
> どれだけコストを掛けても、未知のAPI変更に対応することなんて不可能です。
APIの仕様変更はあり得るが、マニュアルに記載された範囲で使っている限り、普通、そういうケースは稀。
そういう地雷を踏むプログラムを書いているプログラムは、何か変なことをしている場合が多い。
Re: (スコア:0)
自分で正しい答えを出しているのに変なの。
「稀」は絶対に無いわけじゃないし「多い」も同様。
”どれだけコストを掛けても、未知のAPI変更に対応することなんて不可能です。”
は正しいじゃん。
Re: (スコア:0)
なぜ、好き好んで変なことをしようとするのか
変態なの？
Re: (スコア:0)
国語辞典の利用を推奨します。
Re:これからのアプリは、上位互換を保障するべき (スコア:2)
> 逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。
これでお客さんが納得してくれるなら良いんですけどね。
「だったら非対応って書けや！」とか「確認くらいしろよ！」、「おたくはろくに確認もせずに『対応』と言い張るんですか？」と文句がくるのは確実で、すぐに信用問題に発展しますよ。
お客さんが企業ユーザーでもエンドユーザーでも。
Re:これからのアプリは、上位互換を保障するべき (スコア:1)
実際問題として、GetVersionEx()を使ったハックで、「Win8.0で動くのにWin8.1じゃ動かない」って例があるんですかね？
そもそも、GetVersionEx()は非推奨APIなんだから、これでバージョン判定するアプリは、「本当はWindows8非対応だけどなんとなく動いてる」状態だと考えるべきかと。
（MSDNの記述通りに、キチンと各機能の有無を個別に判定すれば、GetVersionEx()の偽装は問題にならない）
-- Buy It When You Found It --
Re:これからのアプリは、上位互換を保障するべき (スコア:2)
実際問題があるかどうかはあまり関係無いですよ。
Windows 8.0対応のプログラムを開発しているときには、8.1でも全て正常に動作するなんてことは保証出来る訳ないんですから、万一を考え
このスレッドの大元のコメントにあるような
しかし、プログラマーとしては、Windows 8.1 での動作確認が済むまでは「あなたがご利用のOSは、このソフトウェアではサポートしていません。」とエラーを出して強制終了する動作にしたかったりするわけです。動作を確認していない OS で動かしたことにより不具合が発生して、重大な経済的損失が発生することもあるのですから。
という話になる訳です。決して技術的な話じゃないですよ。ソフトウェア開発元が責任やリスクをどう考えるかの問題です。
Re:これからのアプリは、上位互換を保障するべき (スコア:3)
逆に、「Win8を8.1にアップデート（半ば自動で行われる）したらアプリが起動しなくなった」リスクも存在する訳です。
で、そのような状況への対応には「GetVersionEx()を使ったハックを使うべきでは無い」のです。
何しろ、MSDNで使用が非推奨なのだから、非互換に起因する責任は、ソフトウェア開発元が負う事になります。
そして、厳密に「Win8.0でだけ動作」させるなら、マニフェストに明記するべきです。
半端に「8.0以上8.1未満(多分)に対応」と指定するから、GetVersionEx()を使ったハックが必要になる訳なので。
-- Buy It When You Found It --
Re: (スコア:0)
＞（MSDNの記述通りに、キチンと各機能の有無を個別に判定すれば、GetVersionEx()の偽装は問題にならない）
それは理想なんだけど、アプリがOSの機能の有無を必ずしも取得できるようになってなくて、一度試行してエラーなり例外が出て、その内容を見て初めてその機能がないことが分かる場合もある。そういうコストをかけるより、OSのバージョンを見て有無が判別できるなら、そちらを選ぶ開発者の方が多いと思う。
Re:これからのアプリは、上位互換を保障するべき (スコア:2)
＞そういうコストをかけるより、OSのバージョンを見て有無が判別できるなら、そちらを選ぶ開発者の方が多いと思う。
うん、私も多分そうする^^;。
でも、これは、将来のリスクと現在の開発コストとの折り合いの問題。
すぐに対応出来る体制なら「手抜き実装も有り」だし、将来メンテ不能になることが分かっていて、且つ、キチンと対応しないと自身の信用問題になるなら、「コストは掛かっても手抜きは厳禁」とするべき。
ま、「どうせ切り捨てられるから、真面目に実装なんてしてられない」って人が多いのが実情で、同時にソフトの信頼性を低下させてる原因だと思うが。
-- Buy It When You Found It --
Re:これからのアプリは、上位互換を保障するべき (スコア:1)
未確認なのにどうやって?
なるべくレガシーな機能や特殊な機能を使わない等ある程度は考慮するにしても、
突然のOSの仕様変更にあらかじめ対処するのは無理ってものだろう。
Re: (スコア:0)
> Win8.1は「Win8.0互換モードが標準」って事です。
ところがWindows 8.1にはオプトインのWindows 8.0互換モードもあるんだな。
Re: (スコア:0)
SetDllDirectory を使え。
http://msdn.microsoft.com/ja-jp/library/windows/desktop/ms686203(v=vs.... [microsoft.com]
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 使わなければいいのに)
Re: (スコア:0)
過去のソフトは未来のOSをケアできないんだから、バージョン取得関数が過去のOSを偽装するのはしかたない、
とみると、新しいOSが出るたびに新しいバージョン取得関数を新規で用意すればいいのだ。
つまり新しいOSだと意識しているプログラムだけが新しい関数で正しいバージョンを取得でき、OSの新旧を判別できる、と。
Re: (スコア:0)
だから、それがまさに、8.1でMSがとった対応でしょ。
Manifest FileのSupporedOSにWindows8.1のGUIDを追加しておけば、（＝新しいOSだと意識しているプログラム）
GetVersionExも正しい値をかえす訳で。（なければ、Windows8だと返す）
Re: (スコア:0)
＞「そんな費用何処から出すんだ？」って問題は、「サポートを売りつける」モデルを採用すれば解決出来ます。
無理でしょ
サポートできる状態を維持するコストが永続的にペイできるわけがない
OS変わってもいつまでもサポートされると考える方がおかしい
Re:これからのアプリは、上位互換を保障するべき (スコア:1, 荒らし)
＞サポートできる状態を維持するコストが永続的にペイできるわけがない
当然です。
だから、年額方式の様なサポート体制にしろって言っているのです。
顧客のシステムも永続する訳ではないのだから、帳尻は合います。
-- Buy It When You Found It --
Re: (スコア:0)
そんなことやってたら帳尻合わないからサポート外にするんだよ
よほどの大手でないかぎりサポート維持コストに見合う年額なんて設定したら誰もサポートに金払わない
「帳尻は合います。」なんて妄想を言ってるだけのアホにはわからんか
Re: (スコア:0)
そもそも業務システムの場合、OSバージョンアップに対する改修ってそれに見合う金額で普通にやるよね。
それを保守費用の範囲でやるか、別に予算を立てるかはケースバイケースだけど。
わざわざ年額サポートにする必要が無い。
Re: (スコア:0)
横レス失礼
いろいろと鼻で笑っている方々がいますけど
何のためにPreview版があるのかと小一時間
私は開発者じゃなくユーザー側ですが
PreviewでればVMに入れて
現行のソフトの起動確認して
開発へフィードバックくらいはしてますよ
本リリース後に確認しますってぬるい姿勢こそ
笑われるあり方かなと思ったり
# ちょっとなげかわしいな
Re:これからのアプリは、上位互換を保障するべき (スコア:1)
何のためにPreview版があるのかと小一時間
Windows 8 のテクニカルプレビューを試用したことがある人ならば、このような意見が机上の空論であることがわかるはず。
Re:Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア:2)
「あなたがご利用のブラウザは、このWebサイトではサポートしていません。」とエラーを出して使わせてくれないWebサイトも大目に見てあげよう。;-)
Re:Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア:1)
言わんとすることは理解できるけど、このストーリーの主題である、startwithで比較するような糞コードはどんな理由でも擁護できないですね
Re:Microsoft が内部バージョンの偽装をするのが諸悪の根源 (スコア: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次情報を必ず参照するのは基本中の基本だよね。
ググって野良情報を鵜呑みにするとか最低。
それならググらない方がまだマシ。
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 --
Re: (スコア:0)
そんなレヴェルの高い話じゃなくて、Windows XP以降を判定するつもりで「if (majorVersion >= 5 && minorVersion >= 1)」とか書く底なしのバカのせい。
Re: (スコア:0)
OS の名前を見てバージョンチェックするコードの方が遙か昔からあって、
GetVersionEx が偽装するようになったのは最近の話じゃないの?
時系列を無視してまで Microsoft を叩きたいの?
Re: (スコア:0)
Windows 95でバージョンを3.95と偽装した [msdn.com]ほうが明らかにこれより前だが、上のコメントで書いたとおり「底なしのバカ」のせいだろ。
Re: (スコア:0)
GetVersionExだと言ってるのに、なぜGetVersionを出してくるのか。
Re: (スコア:0)
それを言ったらそもそもGetVersionExはOSの名前を返さないんだから時系列以前の問題だろ。
Re: (スコア:0)
時系列で言ったらMSがOSのリリースプランやOS判定方法、API互換性に関する方針を予め
出さなかった事が問題なのでは？
アプリ屋はAPIの互換性で痛い目にあった結果、各自保守的な方針を取ったように見えます。
Re: (スコア:0)
2000よりあとに出た
4.9のMEも忘れないであげて
# MS自体が消したがってる黒歴史
問題は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）が返ってくる。
Re: (スコア:0)
MSがメジャーバージョンをいじらなくなったのは、Vistaを6.0にしたときに、メジャーバージョンが５じゃないから死ぬというアプリが続出し、それがあたかもVistaが悪いかの様に扱われたためです。
そのあたりの説明は、もう読めなくなってますね。
http://windowsvistablog.com/blogs/windowsvista/archive/2008/10/14/why-7.aspx [windowsvistablog.com]
Re: (スコア:0)
>OSとしてはほとんど変わらず
ここが保証されない。というか現実としてころころ変わってるわけで。