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は変わらないのに機能がごっそり変更されたりします。
だから、機能を個別に認識して動作するのが本来の姿なんでしょう。
ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
現実に、「アプリが未サポートだから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 のテクニカルプレビューを試用したことがある人ならば、このような意見が机上の空論であることがわかるはず。