Vistaでのゲーム開発で続発したトラブルの「笑えない原因」

あるAnonymous Coward 曰く、

GAME Watchの記事より。
Vistaでのゲーム開発においてIME関連のトラブルが頻発していたようだが、その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」ということだったらしい。
サンプルコードを作成してレビューしたマイクロソフト、知らずに使い回した開発者ともにミスがあったわけだが、とくに開発者の立場では、わかってはいても見逃しがちなミスではないかと思う。

笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

# タレコミ人です

本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にある

動いていても信用ならない
バグはコピペで広がる
何かあるとOSのせいになる

というのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。

また、本文には

これまでのIMM32は、このフラグを親切にも無視し続けていた

とありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。

Re:笑うしかない人と、笑うに笑えない人と

[kei100 (5854)]

類似の内容として、RegOpenKeyEx [microsoft.com]のsamDesiredを0に指定してたらWin9xでは動くのにNT系で動かないってのがありましたね。

# ちゃんと引数が何を意味しているかや何を設定すべきか見直しましょうという事かっ

Re:笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

セキュリティの重鎮、高木先生がPHPの教本のサンプルからセキュリティホールが広がる可能性を示したエントリを書かれたことがあります。

プログラミング解説書籍の脆弱性をどうするか
http://takagi-hiromitsu.jp/diary/20051227.html

サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。

サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[fcp (32783)]

最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。

サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていたのではないでしょうか。

例えば、 C 言語の入門書を最近手に取ったことがないのですが、 15 年ほど前の本では、最初の方に C 言語のプログラムの例として例えばこんなコードが書かれていることも珍しくなかったように思います (C 言語のプログラムの形に慣れてもらうとか、コンパイル・実行の仕方を説明するとか、入出力の方法を説明するなどの目的で)。

#include <stdio.h>
int main()
{
    char name[50];
    printf("あなたの名前は何ですか? ");
    gets(name);
    printf("こんにちは、%sさん!\n", name);
    return 0;
}

後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、初めて「じつは第 1 章に書いてあったプログラム 1.3 には問題があったのです」などと説明されるわけです。全部一度に説明しても理解できないので、これは悪くない方法だと思います。

言語の入門書ではなくてライブラリーのドキュメントでも、サンプルコードでは目的が大事だというのは変わりません。 API 関数の呼び出し方の説明なら、その説明に特化して他の要素を無視した方が説明したい部分がわかりやすくなるというのはよくあることです。そのため、エラーチェックをしないコードが載ったり、そのまま使ったらセキュリティー的に大問題なコードが載ったりしますが、それが悪いことかどうかは状況によります。 (もちろん、目的がよくわからないサンプルコードというのも世の中にはたくさんありますが……。)

Game Watch の記事にある DirectX SDK のサンプルコードの話は、記事によれば、コードを書いた側も正しく書いてあるつもりの部分がじつは間違っていたということのようで、「サンプルコードだからそのまま使えないのは仕方ない」という類のものではなさそうですが。

Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[Anonymous Coward]

>後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、
>初めて「じつは第 1 章に書いてあったプログラム 1.3 には
>問題があったのです」などと説明されるわけです。
>全部一度に説明しても理解できないので、
>これは悪くない方法だと思います。
いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。
他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。
ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？

良い説明を書くには、穴がないように細心の注意を払います。
せめて教科書くらいは、そうあってほしいものです。

多分手にとった本がおなじかもしれないけど

[Anonymous Coward]

悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

その章では、まずは大雑把にＣを理解しようとかだったかな？

##その本は、Ｃ言語とＣ＋＋言語を熟知している人が
書いたものだと感じた。

Re:多分手にとった本がおなじかもしれないけど

[fcp (32783)]

悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

書いてあったかもしれません。憶えていません。

このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。

Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[fcp (32783)]

いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。

「べき」かどうかはスタンスの違いの問題です。僕は、入門書にもいろいろな種類があって良いと考えています。もちろん、どこで読むのをやめても間違った知識を持つことがないような入門書があっても良いですが、通読することを前提として、途中で読むのをやめたら間違った知識を持ってしまうかもしれないような入門書があっても良いと考えています。

他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。

それも、「明示すべき」かどうかはスタンスの違いです。そのような状況で脚注等を付けない著者がいても、悪いとは僕は思いません。

ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？

仮にそうなってしまったら不幸なことですね。でも、入門書を途中まで読んだだけでプログラミング言語を理解できたと考えるような人には、その入門書は向いていなかったというだけのことです。そういう人もいるからというだけの理由で、すべての入門書はこうあるべきなどと規定するのは、つまらないと思います。

Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[tos3 (34423)]

>いえ、悪い方法だとおもいます。
>このような説明では「どこで読むのをやめてもＯＫ」なものを
>示すべきです。

賛成です

その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
数百ページのネットワークプログラミングの本だったと記憶しています。

締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。

詳しくは書けないのだが・・・

[Anonymous Coward]

> 「APIのバグを直したら、そのバグに依存して異常動作を免れていた

Ｖｉｓｔａ で とあるマイナーなＡＰＩ関数（複数の引数で呼び出す）が改訂されまして、
これまで「Reserved なんで ゼロを指定しておくように」とされてた
４つめの引数に意味が追加されました。

その引数に設定するのは、とある Define値 ２種のどちらかと規定され直しています。

ところが！ その引数にゼロが指定されてると、
「不正な引数が設定されるのでエラー」
となってしまうのです。

誰だよ、 Ｖｉｓｔａは ＸＰと互換性があるって言ってたの。

＃ セキュリティとか ユーザー権限とかとはまったく無関係なＡＰＩなんだよ

Re:笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

ありがちだろうか。
事態はもっと奇怪だよね。

この部分、実はVista以前のずっと昔から間違ったまま放置されてきていたのだが、NyaRuRu氏によると「これまでのIMM32は、このフラグを親切にも無視し続けていた」ということだ。

　つまり、従来の環境ではプログラムが誤っているのにもかかわらず正常に動作してしまい、誰もバグに気がつかなかった。

・バグは昔からあった
・でもバグが露呈しないバグがあった
・バグが露呈しないバグを直したら、最初のバグが出て来た
こうじゃないのか。２重のバグと言うべき。
利用したプログラマがこれ→http://www.watch.impress.co.jp/game/docs/20070927/wv05.htm [impress.co.jp]を自嘲的に笑うところか怒るところかは議論があるだろうが。

詰まるところ

[mitil (29556)]

えーと、だからプログラマーはマシン語を理解しておくべき？ [srad.jp]とかいう話が出てきて（略

# と話を蒸し返してみる。

それはともかくとして、コンパイラーやフレームワークのバグに悩まされた私は、
これからはライブラリーの中身にも悩まないといけないんですねorz

Re:笑うしかない人と、笑うに笑えない人と

[soltiox (25610)]

＞何かあるとOSのせいになる
これは、非常に納得できるような。
「msが……」とか「winが……」という話ではなくて、
トラブルの原因を、自分たち以外の何かに求める傾向というのは、あるような気がします。

初めから、「自分の作ったコードにエラーが無い」と確信している人は居ないと思います。
ですが、隅々まで把握できている（つもりの）自分のコードが、
問題となっている現象を発生させない、という確信を持ってしまったら、
「osのせい」とか「hwのせい」とか「隣のセクションが担当しているモジュールのせい」とか、
自分以外の悪者をでっちあげてしまう事はよくあります。
osって、そういう時に憎しみの対称にするには、手頃で便利なアイテムのような。
悪口や罵詈雑言を言っても、聞こえる範囲に関係者は居ないし。
「俺様はosにケチを付けられる程のスキル持ちなんだぜぇ」みたいな、自己拡大感も味わえるし。

// そして「何をツボってるのさ？」と聞いてきた、通りがかりの同僚に、
// 単純なスペルミスを指摘されてしまう罠。

Re:笑うしかない人と、笑うに笑えない人と

[Yak! (32970)]

＞何かあるとOSのせいになる

ちょっとオフトピ気味ですが、Microsoft 自身もこれは分かっているようで、下位互換性を維持するための涙ぐましい対処が Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング! (大型本) [amazon.co.jp] (THE OLD NEW THING - PRACTICAL DEVELOPMENT THROUGHOUT THE EVOLUTION OF WINDOWS の和訳。和訳タイトルは不適切だと思います) に載っています。そんなことまでやってるのかと思った一例を挙げておきます。

「13.2 プログラムがドキュメントに載っていない構造に進入するとき」より
[エクスプローラ] ウィンドウの振る舞いをシェル拡張から変更したいと考えたベンダーがいた。(中略)彼らはドキュメントに載っていないウィンドウメッセージを使用して、シェル拡張からエクスプローラの内部構造の１つへのポインタを取得した。(中略)
ベンダーが認識したものと探していたものは、偶然にも多重継承クラスの基本クラスだった。複数の基本クラスを持つクラスがある場合、コンパイラがそれらの基本クラスをメモリに割り当てる順序は保証されない。たまたま、このベンダーがテストしたすべてのバージョンの Windows では、それらは X、Y、Zの順序で割り当てられていた。
Windows 2000 を除けば。
Windows 2000 のコンパイラは、X、Z、Yがその順序であると判断した。(中略)しばらくして、システムはクラッシュした。
プログラムが (Yをつかむために) X を探しにいったら、最初に偽の X が見つかるように、「偽のX、Y」を作成しなければならなかった。
その方法を考え出すために週の大半がつぶれた。

Re:笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

むしろ、その互換性こそがWindowsのシェア=資金の源な気がします。
だからこそ、色々互換性を保つための仕組みを組み込むという。
過去の遺産が全部動きません、流用できませんってなったら全て新規開発しなおし。
それなら別のOS、例えばLinuxとかでイイヤってなるでしょ？

プログラマの質ってここまで低下してたんだ

[Anonymous Coward]

サンプルコードってのは説明のために冗長な書き方してたりして、ふつー、そのままじゃ使い物にならん。
MSのサンプルだろうが、そのへんの技術サイトのだろうが、このへんは変わらん。
だから実用コードにするにはひと手間入れるし、それでサンプルのバグだって気づく。

コピペじゃスキルは上がらんよ。

Re:プログラマの質ってここまで低下してたんだ

[Anonymous Coward]

いや、ゲーム業界のプログラマは、もはや全体的な質を把握できる人間がいないほど分業化されていて
ハードのリッチ化に伴って構造が巨大化してるにも関わらず、リリース速度を落とすことが出来ない
だから質が低下「した」のではなく、もともと低い、というか、そもそもプログラムで一生食べよう
なんて思っていないバイトだから価値観が違うわけで、そういう人間しかいない万年デスマーチ体質になれば、
「コピペしていたらスキルがつかない」とか、もっともな教訓のでる幕はないでしょうよ、と。

Re:プログラマの質ってここまで低下してたんだ

[Anonymous Coward]

質問サイトで応答してみるとよく分かりますよ。
おまえ・・・これ、業務用のプログラムそのものじゃないか？って思えるものから、時には会社名入っているコードまで貼り付けて教えて下さいとか・・・
んで、「ここが違う」「ここを理解していないから勉強しなさい」って書くとキレられるんですよね。
さらには、「親切なつもりのバカ」が現れてソースを貼り付けることも。

こうして、プログラム＝タダ、という意識とプログラマのスキルの低下が進むのよね。
「親切なつもりのバカ」は、何も考えないで貼り付けてるんだろうけど。

Re:プログラマの質ってここまで低下してたんだ

[Anonymous Coward]

>質が下がっているというか、絶対数が増えているので質の低いのも増えているということではないかと。
激しく納得。
前のレスにつなげると、質問するとコード貼り付けてくれるからプログラムなんて簡単だ、って思い込む人が多いのかも。
>言葉尻を捕らえてあげつらったりキレたりするような人は、いずれ誰にも相手にされなくなるだけです。
普通はそう思うんだけど、世間にはいくらでも「親切なつもりのバカ」がいるんだよね。
質問する側も、そこらへんはわきまえていて、自分のハンドルに悪い印象がついたと思ったらさっさと別のハンドルを取得して「親切なつもりのバカ」が釣れるまではっていたりします。
（マルチポストは当たり前ですよ。）

本当に問題を理解している人って、「どういう風にすれば理解できるか？」の視点でレスするんだよね。
ここは、まず基本であるアレを見ろだとか、その考え方は違うだとか。
それに対して中途半端に理解した人とかって、すぐコードを貼り付けたがる。
質問した人にとって、なんだかんだ言われるよりはコード貼り付けてあった方が有難いわな。
だから「親切なつもりのバカ」の方が評価が高くなるし、そういう人の方が増える。

ふと思いついたんだが、OKwebだかなんだかの質問者が回答者に対して評価する形式ってどうよ？
質問する側って、分からないからこそ質問するんだろ？
分からないのに評価なんてできるのか？
逆に、質問する側こそ評価されてしかるべきだと思う。

# mixi見れませんがな（´・ω・`）

Re:プログラマの質ってここまで低下してたんだ

[zozbug (9256)]

そりゃまーそうですが、DirectXって2か月に一回アップデートがでて、そのたびに仕様が変わったり、新しい方法でやった方がよくなったりするんですよね。新機能なので詳細なドキュメントはアリマセンとか。

理解してやりかた覚えて～とかのノウハウがアップデートのたびにマッサラにされたりするんで、コピペしたくなる気持ちがも分かるっていうか。

ブラックボックスになっちゃってますねぇ

[Tatenon (20311)]

いくらコピペでもさすがに入力と出力でテストくらいはしてると思うのですが、
この問題の本質は「サンプルコードがブラックボックス的に組み込まれている」点ではないでしょうか.

サンプルコードの本質は、ある特定の処理方法の「やり方」を提示することであり、
プログラマは本来、そこにある手順、ロジック、変数等の意味を理解しないといけません.
理想は理解した上でコードを自作して動作を検証することですが、急ぎ仕事でコピペする場合でも
上記理解は必須だと思います.

それを、わからない変数やフラグをそのままでコピペするから今回のような問題が起こる.
そういう意味では、プログラマの質の低下は結構深刻なのかもしれません.

# テストで漏れてるのも問題っちゃ問題ですが、それはまた別の話.

Re:プログラマの質ってここまで低下してたんだ

[NightWalker (21969)]

しかし、NyaRuRu氏ですらおそらくコピペ [hatena.ne.jp]と言及されてますし・・

実に喜ばしいことだ！

[Anonymous Coward]

何にしてもVistaのバッドニュースはマカーにとっては実に喜ばしいことだ！がはははは！



MacOS X にもゲーム一杯出てｸﾚﾖﾝ....orz

Re:実に喜ばしいことだ！

[argon (3541)]

MacOS X というのは、豊かなゲームをもたらす勇者になる RPG でしたか。

ともに進む仲間たち
1. Xcode
2. Cocoa
3. AppleScript

# 俺達はまだこの長い MacOS X ゲーム坂を登りはじめたばかりだぜ！

他のMSのサンプルコード(?)で私が影響があったもの。

[kei100 (5854)]

VB付属のセットアップ用プログラムがバグってて2バイト文字絡みの不具合が出る [microsoft.com]
ATL使って2バイト文字パス使うと環境によって不具合が出る [microsoft.com]
なんかがありました。

# Setup1.exeはその他のOffice Developer版とかも同じバグ持ちだった気がする。

MSのサンプルコード

[gonta (11642)]

MSのサンプルコードなんて、そんなもんすよ！という意見が多く見られますが本当ですか？

昔、趣味でMacOSのプログラミングをやってました。InsideMacやプログラミング本を参考にいろいろやっていましたが、InsideMacなんてそのままじゃ絶対に動かない。「概念の」コードとか、前後にいろいろ付加してはじめて動くコードとか。

Win32もつまみ食いしましたが、そっちは一発で動く。やっぱりシェアが広いと需要もそれだけあり、書籍・サンプル類が充実するんだな、うらやましいな、と思った記憶があります。正直びっくりです。

--
-- gonta --
"May Macintosh be with you"

Re:MSのサンプルコード

[Deasuke (34806)]

そうですね。おまけにPascalでクロージャ使ってるのとかはそのままC/C++に持っていけないし...。
# 新し目のInsideMacintoshではC/C++のサンプルもありましたが...。&言語変換している点ですでにコピぺじゃないけど。
もともとMac≒XLib, Windows≒XToolKitくらいのプログラムしやすさの差がありましたしね。Windowsの方が随分プログラマにとっての環境は良いと思いますよ。

--
Best regards, でぃーすけ

Re:MSのサンプルコード

[kei100 (5854)]

元々の母数が多いのでトチってる絶対数も多いっていうオチな気もします。
あとはCJKで使われる多バイト文字とかIME周りは向こうじゃ常用してる人の母数が少ないので問題が潰されにくいのかも。

日本語のリファレンス周りも不完全とはいえ他環境と比較したら充実してますし、開発という点で見たらWindows環境は便利だと思いますよ。
# ただし、日本語情報は稀に記号類が欠落したり古いとかあるので英語版も念の為に見た方が安心。
# それでもゼロから英文で読まないといけないとかソースを読み解かないといけないわけではないので大分楽。
## もちろん、トラブル時はその限りじゃありませんし、MS側がミスる時もありますが。

何をいまさら、

[Anonymous Coward]

MS のサンプルコードなどまったく当てにならない。
そもそも、動作する以前にコンパイルすら通らないコードだったりするんだから、

なぜ、サンプルコードを動かすだけにたっぷりと時間をかけなければならないのか
不思議でしょうがないです。
しかも、なんでそんなに時間がかかるんだ！、と怒られた日にゃぁ、

同様の体験をしている人は多数いるはず、

Re:何をいまさら、

[narunaru (30931)]

サンプルコードではエラー処理や、例外的な状況に対応するための
処理を省いていることが普通。したがってサンプルコードをそのまま
適用すると、特定の条件化で不具合を起こすのは別段に珍しいことじゃない。

まともな開発者ならサンプルコードをそのまま利用するようなことはしない。

ましてIME関係の処理なんて、本家MSHQの人間にはまったく関係ないのだから、
サンプルにバグが無いことのほうが不思議（ぉ

Re:何をいまさら、

[Anonymous Coward]

実際、何もかも自分で作るようなコーディングでもしない限り、理解の浅い
ライブラリを使うことは避けられない上に、最近は～クックブックとか
逆引き～というまさにコピペで使うためのコード集が当たり前で、コピペを
推奨するような流れでさえあります。

サンプルコードと言えども、コピペされることを意識して、ある程度のチェックは
しておく必要のある時代になってしまったのかもしれません。

Re:何をいまさら、

[Anonymous Coward]

そう言われて気付いたんだけども、
サンプルコードと実用コードの「差が少なく」なるような言語が、
「より高級な」言語だと言えるのだろうね。

たとえば配列の境界チェックとか、チェックを違反したら例外を挙げてくれるとか、
そういう性質が有る言語なら、最初に作った文字列のサイズが最悪足りなくても、後から何とかできるし、発覚もしやすい。

Cはねー。想定外の事態になったとき、それを誰も(処理系が)教えてくれるわけではない、ってのが(Javaとかに比べれば)しんどいのだよね。

＃Cでエラーリカバリーを書いてったら、コードの70%以上がリカバリーになっちゃったので、こりゃヤバイと思ったAC。

Re:何をいまさら、

[CowardDuck (25674)]

> Cでエラーリカバリー

ハンドリングじゃなくてリカバリ？

Re:何をいまさら、

[Anonymous Coward]

サンプルってことでMSは元々のコメントを消すべきじゃなかったんだ。
とか思う。Win32 DDKのベータとか3rdパーティの作ったソースがそのままで
「何でこんな機能が必須なんだ？誰も使わないのに～実装が面倒だぜ」とか愚痴入ってておもしろかったもんだ。
＃ベータ取れたDDKでは同じソースはあったけどコメントが消えてた
ちなみにAppleのDDKだと茶目っ気たっぷりに「ここにエラー処理が必要だよね？」とか書いてあって思いっきり脱力した経験あり。それを知りたいからサンプル見てるんだろがー。とか思った。

Re:何をいまさら、

[Anonymous Coward]

動作する以前にコンパイルすら通らないコードだったりするんだから、

コンパイルすら通らないんだったら当てにならないことは明らかだからかえって問題ないでしょう。

動いていても信用ならない

という点こそがまさに問題になったわけで。

もっともこの件はNyaRuRu氏のブログでかなり前から明らかにされていた [hatena.ne.jp]ので、サンプルをそのまま鵜呑みにしない程度にアンテナを張ってる人だったらとっくに知っていたでしょう。したがって「何をいまさら」という結論だけは同意します。

Re:何をいまさら、

[onoyan (135)]

そりゃ窓口くらいあるんじゃないでしょうか。
でも、アクションを起こす基準が違うので単純に比較できない。

オープンソース：
　興味を持つ必要がある部分なら迅速に進む

ＭＳ：
　顧客に（営業的に）影響がある部分なら迅速に進む

オープンソースもフィードバックに対する全てのアクションが
迅速ではないですからね。良くも悪くも開発者への信頼がベース。

--

--- （´-`）｡oO(平和な日常は私を鈍くする) ---

Re:何をいまさら、

[Anonymous Coward]

コンパイルが通らないはなかったけど、

まれにリソースをリークしてくれたりするサンプルがあったなー

発見されたバグはどんどん直っていくはずだから、
歴代のサンプルのdiffを取ってみると面白いのかもしれないね。

もしかして

[Anonymous Coward]

＞Vistaでのゲーム開発においてIME関連のトラブルが頻発していたようだが、
＞その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」と

Apple製品のロックが外れないバグ？

UnitTestを公開しやがれ！

[Anonymous Coward]

本来そのためのUnitTestだよなー。

でも公開されてないコードのUnitTestは、こっちが自力で書くのは大抵無茶。特に今回のように微妙に変な引数があったとき、「これで正しい」と言い切れるUnitTestを外部の者が書くのはほぼ無理。

それでだ。
昔はともかく最近はNUnit…じゃなく同等競合製品(苦笑)のMS謹製のUnitTestツールも有るんだったよね。

じゃあそれで書いたUnitTestのソースを公開しやがれ＞MS

もともとUnitTestって、「このメソッドをちゃんと動かせるサンプル、をメソッドごとに添付する」という(Smalltalkの)文化を、もう一歩押し進めたものだったそうだ。
UnitTestはサンプルだと見なせる。
そして、UnitTestということは「ちゃんと動くか、それともハマルか」どちらなのかがハッキリ言い切れる状態なコードだということであり、サンプルとしての「使える度」も向上しているということ。

全部は無理にしても、可能な限り公開して欲しいな。
本体の(おそらく長大すぎるのであろう)ソース公開より、Testの公開のほうが、おそらく技術的には有用だ。

MSがおそらく最後の砦と考えてるであろうソース全公開までは課されずに済むので、これはMSにとっても悪い話ではないはず。

いっぽうで「ブラックボックスだから駄目じゃん。「だから」ソース公開しろ」と言ってる人々も、Testが公開されればブラックボックスではなくなるという意味で、状況が前進するのだし。
(Stallman系は満足させられないが、それはまた別の話。)

UnitTestが実は無い、なんてこと言ったら笑い転げてあげますよ？＞MS

Re:UnitTestを公開しやがれ！

[Anonymous Coward]

もし仮に完全なUnitTestのソースがあったとして、それを公開してしまうと、クローンの検証ツールとしても使えてしまうのでは？
だとすると、本体のソース以上に公開を嫌がるような気がします。

Re:UnitTestを公開しやがれ！

[Tsann (15931)]

ウィンドウプロシージャのUnitTest…考えたくないなぁ。

Re:使い回した開発者のミス？

[T.Sawamoto (4142)]

んー。でもこのコード、かなり「あからさまな間違い」の部類にはいると思いますよ。
WM_IME_SETCONTEXTのヘルプ [microsoft.com]には、

If the application has created an IME window, it should call ImmIsUIMessage. Otherwise, it should pass this message to DefWindowProc.

とあります。
例示されたサンプルはなにもせずにreturnしているので、明らかにウィンドウメッセージのヘルプと矛盾しているんですよね。
ただ、WM_IME_???系の処理を行ったことがない方だと、気付けないのもやむなしかもしれませんが……。

Re:使い回した開発者のミス？

[qquick (26652)]

サンプル自身は読んでいませんが、このコード断片から判断できることとして。

本当は、このメソッドを呼び出した呼び出し元WindowProcの
lParamを書き換えて、呼び出し元のWindowProcに制御を返したいわけです。
呼び出し元がWM_IME_*に対して何か処理をしている可能性もありますので。

return falseはおそらく、デフォルトの処理を行うことをあらわしています。
このサンプルを書いた人は、lParamを書き換えておけば
return後に呼び出されるDefWindowProc相当関数のパラメータも
変更されて呼び出されると(無意識のうちに)考えてしまったのでしょう。

とはいえ、DefWindowProcを呼び出すようなコードは、
後で修正がしにくくなるでしょう。
DefWindowProcを呼びだしてデフォルトの処理を避ける(return true)のは、
あくまでも次善の策です。

Re:使い回した開発者のミス？

[Anonymous Coward]

何かおかしい動作をしたら、元にしたコードが間違ってるんだと思うだろ、普通。
サンプルコードとはそういうもの、常考。

Re:使い回した開発者のミス？

[Anonymous Coward]

サンプルコードがドキュメント通りに動かなかったとしたら、かつドキュメントが日本語だったら、「このドキュメントが間違っているのではないか？」と思ってしまう。
そして、原文（英語）のドキュメントを頑張って読んでみるけど、日本語訳が間違いとは思えない。しかしそれ以上に自分の語学力にも自信がない。
「オレはC言語と英語ではC言語のほうが得意だ」ということで、自分が英語のドキュメントも正確に読めなかったと思ってしまう。
そして「このサンプルは正しいはずだ」と思ってしまう…

…オレだけか。

Re:使い回した開発者のミス？

[Anonymous Coward]

> 「オレはC言語と英語ではC言語のほうが得意だ」ということで、

それなら話は早いです。
コードを検証しましょう!!

#たいていの場合、プログラムは書いてあるとおりに動きます

Re:使い回した開発者のミス？

[Anonymous Coward]

>プログラムは書いてあるとおりに動きます

ソースが(自分から見て)公開されてるわけでもないライブラリが介在すると、
この発想は破綻します。
どうしてもブラックボックスの振る舞いを「推測」せざるを得なくなってしまう。
読めば判るという大原則が機能しない。

…だからこそ優秀な人々は、オープンソース(誰にでも公開)だの、アジャイル(チームメートには公開)だの、といった開かれた開発形態が必要だと理解している。
引用と同じような台詞を例えば「matz氏が」言うのには意味も価値も十分有る。
MSの中の人が言ったら笑い話になってしまう。

(でも数年前にゲイツが来日し某大学で講演したとき、「他人のソース嫁。それがタメになる」と言ったんだよね。そう言うんだったらMSのソースも確認させてほしいもんだが…)

Re:使い回した開発者のミス？

[quililila (23086)]

> #たいていの場合、プログラムは書いてあるとおりに動きます

たいていの場合と書いてありますが？
そしてたいていの場合以外というのは、おっしゃるとおりライブラリやOSのバグだったりもするんですが、ハードウェアのバグなどもあったりします。
中の方をどんどん追っていっても、いずれはブラックボックスに突き当たるので(ICの中の実装まで追う人は少数派でしょ)、振る舞いを推測することはとても重要です。

いずれはどこかでブラックボックスに突き当たるのであれば、これを基にオープンソースの重要性を説くのはちと苦しいですね。

Re:使い回した開発者のミス？

[Anonymous Coward]

ここで話題になってるのは「サンプルコード」のバグです。
ライブラリの話は関係ないでしょう。
コードが見えてるんですから、おかしい事は気付きますよ。

Re:使い回した開発者のミス？

[Anonymous Coward]

>　旧BorlandのVCLヘッダにタイプミスがあり、ツリービューの「Get～Child」が「get～Child」のまま仕様になり

それはですね。Microsoft 提供の windowsx.h に

#define GetFirstChild(hwnd) GetTopWindow(hwnd)

ってのがあるため、VCL の GetFirstChild が勝手に置き換わってしまう問題を回避するための苦肉の策なのですよ。
幸い、VCL / PASCAL 言語は大文字小文字を同じとみなしますからね。
Microsoft も反省したのか、その後のヘッダーファイルでは

#define IAccessibleWinSAT_get_accChildCount(This,pcountChildren)

こんな感じに、簡単には衝突しないように配慮しているようです。