パスワードを忘れた？ アカウント作成
Close
11630911 story
Windows

次期Windowsの名称がWindows 10になった理由は？ 137

ストーリー by headless
新型 部門より
あるAnonymous Coward 曰く、

/.J記事のコメントでも話題になっていたが、次期Windowsの名称が「Windows 9」ではなく「Windows 10」になった理由について憶測が飛び交っている(BusinessNewslineの記事、 Engadget日本版の記事、 本家/.)。

一つは悪評高いWindows 8を継承する数字としての「9」を避けたというもの。一つ飛ばした「10」という数字にすることでWindows 8の良くないイメージを断ち切り、新たなOSであることを打ち出しているというのだ。

もう一つは/.Jでも指摘されていた、OSバージョンをWindows 95/98と誤判定する古いコードがあるという理由だ。Microsoftの開発者を名乗るユーザーによるredditへの投稿では、「if(version.StartsWith("Windows 9"))...」のような形でOSバージョンを判定するサードパーティーソフトウェアが数多くあり、現実的な回避策として「Windows 10」になったと社内で噂されているという。searchcodeで「if(version.StartsWith("Windows 9"))」を検索すると相当数がヒットするので、バージョン判定コードの問題は次期OSの命名に少なからず影響したのではないかと思われる。

この件に関するMicrosoftの回答は「Windows 10は物事を行う上での新しい方法を推進するWindowsを意味します。数字が増えたのではなく、さらに多くのユーザーに力を与える新しいWindowsです。」といった内容で、謎を謎のままにするものだという(Gizmodoの記事)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

次期Windowsの名称がWindows 10になった理由は？ More

  • プログラム開発者にとって、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 に対応しているというマニフェストを書かないといけないのが不合理に感じます。

    • ちょっと調べたら、GetVersionExは、既に非推奨になってますね。
      で、「互換モード」を設定すると、GetVersionExが偽装される仕組みになってると。

      つまり、Win8.1は「Win8.0互換モードが標準」って事です。
      逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。

      実際問題として、SP等が入ると、GetVersionExは変わらないのに機能がごっそり変更されたりします。
      だから、機能を個別に認識して動作するのが本来の姿なんでしょう。

      ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
      現実に、「アプリが未サポートだからXPから移行出来ない」って問題がありました（多分まだ在る）。

      最近の攻撃状況から見ると、古いOSの脆弱性に起因するセキュリティ問題は、使用者だけでは無く、他者も巻き込む重大懸念事項です。
      だから、動作未確認の環境でも「一応動作する」様に作りこむべきだし、リリース後は至急サポート対象にするのが、今後のソフト屋に望まれる姿勢かと。

      「そんな費用何処から出すんだ？」って問題は、「サポートを売りつける」モデルを採用すれば解決出来ます。
      もう、売りっぱなしじゃ済まない時代になってるんじゃないでしょうか。

      --
      -- Buy It When You Found It --
      シェア
      親コメント

      • 検証していない環境をサポートするのは不可能 (スコア:3, すばらしい洞察)

        by Anonymous Coward on 2014年10月05日 22時19分 (#2688744)

        ついでに言えば、「動作未確認だからサポート外」ってのは、ソフト屋の甘えだと思います。
        現実に、「アプリが未サポートだからXPから移行出来ない」って問題がありました（多分まだ在る）。

        笑っちゃうほどおかしな話ですね。
        どれだけコストを掛けても、未知のAPI変更に対応することなんて不可能です。
        動くかどうか判らないものをサポートするには、お金がかかるかからない以前の問題です。

        「20年後も、このテレビが映るようにしてくれ」ということと同じですよ。
        放送の方式が変わるかもしれないし、補修部品を作成していた会社がなくなるかもしれない。
        テレビ等は方式が公開されていて多数の会社が製作できますが、Windowsはたかだか一企業が作成しているOSです。

        コストをかければプレリリース版等で早くから情報を掴んで、新しい対応バージョンを前もって用意することはできるでしょうし、
        問題が起きたらすぐに直すように待機部隊を用意したりすることも当然できるでしょう。
        ただそれは、本来サポートできるか、新しいOSに対応できるかどうかとはまた別の話です。
        未知の変更に必ず対応できるという保証は誰にもできません。

        シェア
        親コメント

      • > 逆に言えば、「Win8.0で動くのにWin8.1じゃ動かない」なら「M$が悪い」って言い切れば良い訳です。

        これでお客さんが納得してくれるなら良いんですけどね。
        「だったら非対応って書けや！」とか「確認くらいしろよ！」、「おたくはろくに確認もせずに『対応』と言い張るんですか？」と文句がくるのは確実で、すぐに信用問題に発展しますよ。
        お客さんが企業ユーザーでもエンドユーザーでも。

        シェア
        親コメント

        • 実際問題として、GetVersionEx()を使ったハックで、「Win8.0で動くのにWin8.1じゃ動かない」って例があるんですかね？

          そもそも、GetVersionEx()は非推奨APIなんだから、これでバージョン判定するアプリは、「本当はWindows8非対応だけどなんとなく動いてる」状態だと考えるべきかと。
          （MSDNの記述通りに、キチンと各機能の有無を個別に判定すれば、GetVersionEx()の偽装は問題にならない）

          --
          -- Buy It When You Found It --
          シェア
          親コメント

          • 実際問題があるかどうかはあまり関係無いですよ。
            Windows 8.0対応のプログラムを開発しているときには、8.1でも全て正常に動作するなんてことは保証出来る訳ないんですから、万一を考え
            このスレッドの大元のコメントにあるような

            しかし、プログラマーとしては、Windows 8.1 での動作確認が済むまでは「あなたがご利用のOSは、このソフトウェアではサポートしていません。」とエラーを出して強制終了する動作にしたかったりするわけです。動作を確認していない OS で動かしたことにより不具合が発生して、重大な経済的損失が発生することもあるのですから。

            という話になる訳です。決して技術的な話じゃないですよ。ソフトウェア開発元が責任やリスクをどう考えるかの問題です。

            シェア
            親コメント

            • 逆に、「Win8を8.1にアップデート（半ば自動で行われる）したらアプリが起動しなくなった」リスクも存在する訳です。

              で、そのような状況への対応には「GetVersionEx()を使ったハックを使うべきでは無い」のです。
              何しろ、MSDNで使用が非推奨なのだから、非互換に起因する責任は、ソフトウェア開発元が負う事になります。

              そして、厳密に「Win8.0でだけ動作」させるなら、マニフェストに明記するべきです。
              半端に「8.0以上8.1未満(多分)に対応」と指定するから、GetVersionEx()を使ったハックが必要になる訳なので。

              --
              -- Buy It When You Found It --
              シェア
              親コメント

      • Re:これからのアプリは、上位互換を保障するべき (スコア:1)

        by Anonymous Coward on 2014年10月05日 20時58分 (#2688699)
        >> 動作未確認の環境でも「一応動作する」様に作りこむべきだし
        未確認なのにどうやって?
        なるべくレガシーな機能や特殊な機能を使わない等ある程度は考慮するにしても、
        突然のOSの仕様変更にあらかじめ対処するのは無理ってものだろう。
        シェア
        親コメント

    • 「あなたがご利用のブラウザは、このWebサイトではサポートしていません。」とエラーを出して使わせてくれないWebサイトも大目に見てあげよう。;-)

      シェア
      親コメント

    • 言わんとすることは理解できるけど、このストーリーの主題である、startwithで比較するような糞コードはどんな理由でも擁護できないですね

      シェア
      親コメント

    • 糞なのは名前と比較していることではなくて、前方一致で比較していることですよ。
      本当に動作検証した環境だけサポートしたいのであれば、完全一致で比較するべきです。

      ところでGetVersionExが正しいバージョンを返さない仕様は、私もかなり疑問です。
      depricated扱いにされちゃっているので、「今回はマニュフェストがあれば通してるけど、次はもっと頑張っても正しいバージョンは得られなくするかもよ。」というMSの意図を感じます…

      シェア
      親コメント

    • Windows8.1はWindows8SP1 (スコア:1)

      by BIWYFI (11941) on 2014年10月06日 13時33分 (#2688977) 日記

      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 --
      シェア
      親コメント

  • 検索 (スコア:5, 興味深い)

    by Anonymous Coward on 2014年10月05日 19時34分 (#2688654)

    > OSバージョンをWindows 95/98と誤判定する古いコードがあるという理由だ

    プログラムの検索もそうですが、
    GoogleやYahoo!の検索、ヘルプなどの検索でも

    Windows 9の情報が欲しいのに、Windows 95/98の情報が出てきてしまうのでは？

    って話は7が出たころから言われていました。

  • 問題にするべきはそこじゃない (スコア:2, 参考になる)

    by Anonymous Coward on 2014年10月05日 18時20分 (#2688606)


    if(osName.startsWith("Windows 9")|| osName.equals("Windows ME")) {
            ...

    これがWindowsバージョンを調べる、ほぼ慣用句と化したコードだという点。
    正にJava厨は無能という説を体現したようなコードだ。

    # Javaは脆弱性の塊だと思ってきたが、まさかJavaプログラマー自体もそうだったとは・・・・。
    # osName.startsWith("Windows 9")でググってコードがわんさか出てくる時点で、もはやJavaプログラマー(笑)。

  • Oneにそろえたかった (スコア:1)

    by Anonymous Coward on 2014年10月05日 18時57分 (#2688627)

    http://www.gizmodo.jp/2014/10/9windows_10.html [gizmodo.jp]

  • Windows X (スコア:0)

    by Anonymous Coward on 2014年10月05日 17時54分 (#2688589)

    Windows X になるのを期待してた人はこちらへどうぞ。

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー