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 など) の数値を取り出してきて文字列処理するコードを書く人
実際問題があるかどうかはあまり関係無いですよ。 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 など) の数値を取り出してきて文字列処理するコードを書く人
これからのアプリは、上位互換を保障するべき (スコア:5, 参考になる)
ちょっと調べたら、GetVersionExは、既に非推奨になってますね。
で、「互換モード」を設定すると、GetVersionExが偽装される仕組みになってると。
つまり、Win8.1は「Win8.0互換モードが標準」って事です。
逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。
実際問題として、SP等が入ると、GetVersionExは変わらないのに機能がごっそり変更されたりします。
だから、機能を個別に認識して動作するのが本来の姿なんでしょう。
ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
現実に、「
-- Buy It When You Found It --
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 --