Vistaでのゲーム開発で続発したトラブルの「笑えない原因」 114
ストーリー by GetSet
判ってみれば何でもないが、非常にありがち 部門より
判ってみれば何でもないが、非常にありがち 部門より
あるAnonymous Coward 曰く、
GAME Watchの記事より。
Vistaでのゲーム開発においてIME関連のトラブルが頻発していたようだが、その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」ということだったらしい。
サンプルコードを作成してレビューしたマイクロソフト、知らずに使い回した開発者ともにミスがあったわけだが、とくに開発者の立場では、わかってはいても見逃しがちなミスではないかと思う。
笑うしかない人と、笑うに笑えない人と (スコア:4, 参考になる)
本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にあるというのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。
また、本文にはとありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。
Re:笑うしかない人と、笑うに笑えない人と (スコア:2, 参考になる)
# ちゃんと引数が何を意味しているかや何を設定すべきか見直しましょうという事かっ
Re:笑うしかない人と、笑うに笑えない人と (スコア:2, すばらしい洞察)
プログラミング解説書籍の脆弱性をどうするか
http://takagi-hiromitsu.jp/diary/20051227.html
サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:5, すばらしい洞察)
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていたのではないでしょうか。
例えば、 C 言語の入門書を最近手に取ったことがないのですが、 15 年ほど前の本では、最初の方に C 言語のプログラムの例として例えばこんなコードが書かれていることも珍しくなかったように思います (C 言語のプログラムの形に慣れてもらうとか、コンパイル・実行の仕方を説明するとか、入出力の方法を説明するなどの目的で)。
後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、初めて「じつは第 1 章に書いてあったプログラム 1.3 には問題があったのです」などと説明されるわけです。全部一度に説明しても理解できないので、これは悪くない方法だと思います。
言語の入門書ではなくてライブラリーのドキュメントでも、サンプルコードでは目的が大事だというのは変わりません。 API 関数の呼び出し方の説明なら、その説明に特化して他の要素を無視した方が説明したい部分がわかりやすくなるというのはよくあることです。そのため、エラーチェックをしないコードが載ったり、そのまま使ったらセキュリティー的に大問題なコードが載ったりしますが、それが悪いことかどうかは状況によります。 (もちろん、目的がよくわからないサンプルコードというのも世の中にはたくさんありますが……。)
Game Watch の記事にある DirectX SDK のサンプルコードの話は、記事によれば、コードを書いた側も正しく書いてあるつもりの部分がじつは間違っていたということのようで、「サンプルコードだからそのまま使えないのは仕方ない」という類のものではなさそうですが。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1, 参考になる)
>初めて「じつは第 1 章に書いてあったプログラム 1.3 には
>問題があったのです」などと説明されるわけです。
>全部一度に説明しても理解できないので、
>これは悪くない方法だと思います。
いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。
他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。
ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？
良い説明を書くには、穴がないように細心の注意を払います。
せめて教科書くらいは、そうあってほしいものです。
多分手にとった本がおなじかもしれないけど (スコア:1, 参考になる)
その章では、まずは大雑把にＣを理解しようとかだったかな？
##その本は、Ｃ言語とＣ＋＋言語を熟知している人が
書いたものだと感じた。
Re:多分手にとった本がおなじかもしれないけど (スコア:1)
書いてあったかもしれません。憶えていません。
このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
「べき」かどうかはスタンスの違いの問題です。僕は、入門書にもいろいろな種類があって良いと考えています。もちろん、どこで読むのをやめても間違った知識を持つことがないような入門書があっても良いですが、通読することを前提として、途中で読むのをやめたら間違った知識を持ってしまうかもしれないような入門書があっても良いと考えています。
それも、「明示すべき」かどうかはスタンスの違いです。そのような状況で脚注等を付けない著者がいても、悪いとは僕は思いません。
仮にそうなってしまったら不幸なことですね。でも、入門書を途中まで読んだだけでプログラミング言語を理解できたと考えるような人には、その入門書は向いていなかったというだけのことです。そういう人もいるからというだけの理由で、すべての入門書はこうあるべきなどと規定するのは、つまらないと思います。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
>このような説明では「どこで読むのをやめてもＯＫ」なものを
>示すべきです。
賛成です
その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
数百ページのネットワークプログラミングの本だったと記憶しています。
締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。
詳しくは書けないのだが・・・ (スコア:2, 興味深い)
Ｖｉｓｔａ で とあるマイナーなＡＰＩ関数（複数の引数で呼び出す）が改訂されまして、
これまで「Reserved なんで ゼロを指定しておくように」とされてた
４つめの引数に意味が追加されました。
その引数に設定するのは、とある Define値 ２種のどちらかと規定され直しています。
ところが！ その引数にゼロが指定されてると、
「不正な引数が設定されるのでエラー」
となってしまうのです。
誰だよ、 Ｖｉｓｔａは ＸＰと互換性があるって言ってたの。
＃ セキュリティとか ユーザー権限とかとはまったく無関係なＡＰＩなんだよ
Re:笑うしかない人と、笑うに笑えない人と (スコア:1, すばらしい洞察)
事態はもっと奇怪だよね。
・バグは昔からあった
・でもバグが露呈しないバグがあった
・バグが露呈しないバグを直したら、最初のバグが出て来た
こうじゃないのか。２重のバグと言うべき。
利用したプログラマがこれ→http://www.watch.impress.co.jp/game/docs/20070927/wv05.htm [impress.co.jp]を自嘲的に笑うところか怒るところかは議論があるだろうが。
詰まるところ (スコア:1)
# と話を蒸し返してみる。
それはともかくとして、コンパイラーやフレームワークのバグに悩まされた私は、
これからはライブラリーの中身にも悩まないといけないんですねorz
Re:笑うしかない人と、笑うに笑えない人と (スコア:1)
これは、非常に納得できるような。
「msが……」とか「winが……」という話ではなくて、
トラブルの原因を、自分たち以外の何かに求める傾向というのは、あるような気がします。
初めから、「自分の作ったコードにエラーが無い」と確信している人は居ないと思います。
ですが、隅々まで把握できている（つもりの）自分のコードが、
問題となっている現象を発生させない、という確信を持ってしまったら、
「osのせい」とか「hwのせい」とか「隣のセクションが担当しているモジュールのせい」とか、
自分以外の悪者をでっちあげてしまう事はよくあります。
osって、そういう時に憎しみの対称にするには、手頃で便利なアイテムのような。
悪口や罵詈雑言を言っても、聞こえる範囲に関係者は居ないし。
「俺様はosにケチを付けられる程のスキル持ちなんだぜぇ」みたいな、自己拡大感も味わえるし。
// そして「何をツボってるのさ？」と聞いてきた、通りがかりの同僚に、
// 単純なスペルミスを指摘されてしまう罠。
Re:笑うしかない人と、笑うに笑えない人と (スコア:3, 興味深い)
ちょっとオフトピ気味ですが、Microsoft 自身もこれは分かっているようで、下位互換性を維持するための涙ぐましい対処が Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング! (大型本) [amazon.co.jp] (THE OLD NEW THING - PRACTICAL DEVELOPMENT THROUGHOUT THE EVOLUTION OF WINDOWS の和訳。和訳タイトルは不適切だと思います) に載っています。そんなことまでやってるのかと思った一例を挙げておきます。
Re:笑うしかない人と、笑うに笑えない人と (スコア:2, 興味深い)
だからこそ、色々互換性を保つための仕組みを組み込むという。
過去の遺産が全部動きません、流用できませんってなったら全て新規開発しなおし。
それなら別のOS、例えばLinuxとかでイイヤってなるでしょ？
プログラマの質ってここまで低下してたんだ (スコア:4, すばらしい洞察)
MSのサンプルだろうが、そのへんの技術サイトのだろうが、このへんは変わらん。
だから実用コードにするにはひと手間入れるし、それでサンプルのバグだって気づく。
コピペじゃスキルは上がらんよ。
Re:プログラマの質ってここまで低下してたんだ (スコア:2, すばらしい洞察)
ハードのリッチ化に伴って構造が巨大化してるにも関わらず、リリース速度を落とすことが出来ない
だから質が低下「した」のではなく、もともと低い、というか、そもそもプログラムで一生食べよう
なんて思っていないバイトだから価値観が違うわけで、そういう人間しかいない万年デスマーチ体質になれば、
「コピペしていたらスキルがつかない」とか、もっともな教訓のでる幕はないでしょうよ、と。
Re:プログラマの質ってここまで低下してたんだ (スコア:2, 興味深い)
おまえ・・・これ、業務用のプログラムそのものじゃないか？って思えるものから、時には会社名入っているコードまで貼り付けて教えて下さいとか・・・
んで、「ここが違う」「ここを理解していないから勉強しなさい」って書くとキレられるんですよね。
さらには、「親切なつもりのバカ」が現れてソースを貼り付けることも。
こうして、プログラム＝タダ、という意識とプログラマのスキルの低下が進むのよね。
「親切なつもりのバカ」は、何も考えないで貼り付けてるんだろうけど。
Re:プログラマの質ってここまで低下してたんだ (スコア:1, 興味深い)
激しく納得。
前のレスにつなげると、質問するとコード貼り付けてくれるからプログラムなんて簡単だ、って思い込む人が多いのかも。
>言葉尻を捕らえてあげつらったりキレたりするような人は、いずれ誰にも相手にされなくなるだけです。
普通はそう思うんだけど、世間にはいくらでも「親切なつもりのバカ」がいるんだよね。
質問する側も、そこらへんはわきまえていて、自分のハンドルに悪い印象がついたと思ったらさっさと別のハンドルを取得して「親切なつもりのバカ」が釣れるまではっていたりします。
（マルチポストは当たり前ですよ。）
本当に問題を理解している人って、「どういう風にすれば理解できるか？」の視点でレスするんだよね。
ここは、まず基本であるアレを見ろだとか、その考え方は違うだとか。
それに対して中途半端に理解した人とかって、すぐコードを貼り付けたがる。
質問した人にとって、なんだかんだ言われるよりはコード貼り付けてあった方が有難いわな。
だから「親切なつもりのバカ」の方が評価が高くなるし、そういう人の方が増える。
ふと思いついたんだが、OKwebだかなんだかの質問者が回答者に対して評価する形式ってどうよ？
質問する側って、分からないからこそ質問するんだろ？
分からないのに評価なんてできるのか？
逆に、質問する側こそ評価されてしかるべきだと思う。
# mixi見れませんがな（´・ω・`）
Re:プログラマの質ってここまで低下してたんだ (スコア:1)
理解してやりかた覚えて～とかのノウハウがアップデートのたびにマッサラにされたりするんで、コピペしたくなる気持ちがも分かるっていうか。
ブラックボックスになっちゃってますねぇ (スコア:1)
この問題の本質は「サンプルコードがブラックボックス的に組み込まれている」点ではないでしょうか.
サンプルコードの本質は、ある特定の処理方法の「やり方」を提示することであり、
プログラマは本来、そこにある手順、ロジック、変数等の意味を理解しないといけません.
理想は理解した上でコードを自作して動作を検証することですが、急ぎ仕事でコピペする場合でも
上記理解は必須だと思います.
それを、わからない変数やフラグをそのままでコピペするから今回のような問題が起こる.
そういう意味では、プログラマの質の低下は結構深刻なのかもしれません.
# テストで漏れてるのも問題っちゃ問題ですが、それはまた別の話.
Re:プログラマの質ってここまで低下してたんだ (スコア:1)
実に喜ばしいことだ！ (スコア:3, おもしろおかしい)
MacOS X にもゲーム一杯出てｸﾚﾖﾝ....orz
Re:実に喜ばしいことだ！ (スコア:3, おもしろおかしい)
ともに進む仲間たち
1. Xcode
2. Cocoa
3. AppleScript
# 俺達はまだこの長い MacOS X ゲーム坂を登りはじめたばかりだぜ！
他のMSのサンプルコード(?)で私が影響があったもの。 (スコア:3, 参考になる)
ATL使って2バイト文字パス使うと環境によって不具合が出る [microsoft.com]
なんかがありました。
# Setup1.exeはその他のOffice Developer版とかも同じバグ持ちだった気がする。
MSのサンプルコード (スコア:3, 参考になる)
昔、趣味でMacOSのプログラミングをやってました。InsideMacやプログラミング本を参考にいろいろやっていましたが、InsideMacなんてそのままじゃ絶対に動かない。「概念の」コードとか、前後にいろいろ付加してはじめて動くコードとか。
Win32もつまみ食いしましたが、そっちは一発で動く。やっぱりシェアが広いと需要もそれだけあり、書籍・サンプル類が充実するんだな、うらやましいな、と思った記憶があります。正直びっくりです。
-- gonta --
"May Macintosh be with you"
Re:MSのサンプルコード (スコア:1)
# 新し目のInsideMacintoshではC/C++のサンプルもありましたが...。&言語変換している点ですでにコピぺじゃないけど。
もともとMac≒XLib, Windows≒XToolKitくらいのプログラムしやすさの差がありましたしね。Windowsの方が随分プログラマにとっての環境は良いと思いますよ。
Best regards, でぃーすけ
Re:MSのサンプルコード (スコア:1)
あとはCJKで使われる多バイト文字とかIME周りは向こうじゃ常用してる人の母数が少ないので問題が潰されにくいのかも。
日本語のリファレンス周りも不完全とはいえ他環境と比較したら充実してますし、開発という点で見たらWindows環境は便利だと思いますよ。
# ただし、日本語情報は稀に記号類が欠落したり古いとかあるので英語版も念の為に見た方が安心。
# それでもゼロから英文で読まないといけないとかソースを読み解かないといけないわけではないので大分楽。
## もちろん、トラブル時はその限りじゃありませんし、MS側がミスる時もありますが。
何をいまさら、 (スコア:1, すばらしい洞察)
そもそも、動作する以前にコンパイルすら通らないコードだったりするんだから、
なぜ、サンプルコードを動かすだけにたっぷりと時間をかけなければならないのか
不思議でしょうがないです。
しかも、なんでそんなに時間がかかるんだ！、と怒られた日にゃぁ、
同様の体験をしている人は多数いるはず、
Re:何をいまさら、 (スコア:3, すばらしい洞察)
処理を省いていることが普通。したがってサンプルコードをそのまま
適用すると、特定の条件化で不具合を起こすのは別段に珍しいことじゃない。
まともな開発者ならサンプルコードをそのまま利用するようなことはしない。
ましてIME関係の処理なんて、本家MSHQの人間にはまったく関係ないのだから、
サンプルにバグが無いことのほうが不思議（ぉ
Re:何をいまさら、 (スコア:3, 興味深い)
ライブラリを使うことは避けられない上に、最近は～クックブックとか
逆引き～というまさにコピペで使うためのコード集が当たり前で、コピペを
推奨するような流れでさえあります。
サンプルコードと言えども、コピペされることを意識して、ある程度のチェックは
しておく必要のある時代になってしまったのかもしれません。
Re:何をいまさら、 (スコア:2, すばらしい洞察)
サンプルコードと実用コードの「差が少なく」なるような言語が、
「より高級な」言語だと言えるのだろうね。
たとえば配列の境界チェックとか、チェックを違反したら例外を挙げてくれるとか、
そういう性質が有る言語なら、最初に作った文字列のサイズが最悪足りなくても、後から何とかできるし、発覚もしやすい。
Cはねー。想定外の事態になったとき、それを誰も(処理系が)教えてくれるわけではない、ってのが(Javaとかに比べれば)しんどいのだよね。
＃Cでエラーリカバリーを書いてったら、コードの70%以上がリカバリーになっちゃったので、こりゃヤバイと思ったAC。
Re:何をいまさら、 (スコア:1)
ハンドリングじゃなくてリカバリ？
Re:何をいまさら、 (スコア:3, 興味深い)
とか思う。Win32 DDKのベータとか3rdパーティの作ったソースがそのままで
「何でこんな機能が必須なんだ？誰も使わないのに～実装が面倒だぜ」とか愚痴入ってておもしろかったもんだ。
＃ベータ取れたDDKでは同じソースはあったけどコメントが消えてた
ちなみにAppleのDDKだと茶目っ気たっぷりに「ここにエラー処理が必要だよね？」とか書いてあって思いっきり脱力した経験あり。それを知りたいからサンプル見てるんだろがー。とか思った。
Re:何をいまさら、 (スコア:2, すばらしい洞察)
コンパイルすら通らないんだったら当てにならないことは明らかだからかえって問題ないでしょう。
という点こそがまさに問題になったわけで。
もっともこの件はNyaRuRu氏のブログでかなり前から明らかにされていた [hatena.ne.jp]ので、サンプルをそのまま鵜呑みにしない程度にアンテナを張ってる人だったらとっくに知っていたでしょう。したがって「何をいまさら」という結論だけは同意します。
Re:何をいまさら、 (スコア:1)
でも、アクションを起こす基準が違うので単純に比較できない。
オープンソース：
興味を持つ必要がある部分なら迅速に進む
ＭＳ：
顧客に（営業的に）影響がある部分なら迅速に進む
オープンソースもフィードバックに対する全てのアクションが
迅速ではないですからね。良くも悪くも開発者への信頼がベース。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:何をいまさら、 (スコア:1, 興味深い)
まれにリソースをリークしてくれたりするサンプルがあったなー
発見されたバグはどんどん直っていくはずだから、
歴代のサンプルのdiffを取ってみると面白いのかもしれないね。
もしかして (スコア:1, 興味深い)
＞その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」と
Apple製品のロックが外れないバグ？
UnitTestを公開しやがれ！ (スコア:1, すばらしい洞察)
でも公開されてないコードのUnitTestは、こっちが自力で書くのは大抵無茶。特に今回のように微妙に変な引数があったとき、「これで正しい」と言い切れるUnitTestを外部の者が書くのはほぼ無理。
それでだ。
昔はともかく最近はNUnit…じゃなく同等競合製品(苦笑)のMS謹製のUnitTestツールも有るんだったよね。
じゃあそれで書いたUnitTestのソースを公開しやがれ＞MS
もともとUnitTestって、「このメソッドをちゃんと動かせるサンプル、をメソッドごとに添付する」という(Smalltalkの)文化を、もう一歩押し進めたものだったそうだ。
UnitTestはサンプルだと見なせる。
そして、UnitTestということは「ちゃんと動くか、それともハマルか」どちらなのかがハッキリ言い切れる状態なコードだということであり、サンプルとしての「使える度」も向上しているということ。
全部は無理にしても、可能な限り公開して欲しいな。
本体の(おそらく長大すぎるのであろう)ソース公開より、Testの公開のほうが、おそらく技術的には有用だ。
MSがおそらく最後の砦と考えてるであろうソース全公開までは課されずに済むので、これはMSにとっても悪い話ではないはず。
いっぽうで「ブラックボックスだから駄目じゃん。「だから」ソース公開しろ」と言ってる人々も、Testが公開されればブラックボックスではなくなるという意味で、状況が前進するのだし。
(Stallman系は満足させられないが、それはまた別の話。)
UnitTestが実は無い、なんてこと言ったら笑い転げてあげますよ？＞MS
Re:UnitTestを公開しやがれ！ (スコア:2, すばらしい洞察)
だとすると、本体のソース以上に公開を嫌がるような気がします。
Re:UnitTestを公開しやがれ！ (スコア:1)
Re:使い回した開発者のミス？ (スコア:3, すばらしい洞察)
WM_IME_SETCONTEXTのヘルプ [microsoft.com]には、とあります。
例示されたサンプルはなにもせずにreturnしているので、明らかにウィンドウメッセージのヘルプと矛盾しているんですよね。
ただ、WM_IME_???系の処理を行ったことがない方だと、気付けないのもやむなしかもしれませんが……。
Re:使い回した開発者のミス？ (スコア:1)
本当は、このメソッドを呼び出した呼び出し元WindowProcの
lParamを書き換えて、呼び出し元のWindowProcに制御を返したいわけです。
呼び出し元がWM_IME_*に対して何か処理をしている可能性もありますので。
return falseはおそらく、デフォルトの処理を行うことをあらわしています。
このサンプルを書いた人は、lParamを書き換えておけば
return後に呼び出されるDefWindowProc相当関数のパラメータも
変更されて呼び出されると(無意識のうちに)考えてしまったのでしょう。
とはいえ、DefWindowProcを呼び出すようなコードは、
後で修正がしにくくなるでしょう。
DefWindowProcを呼びだしてデフォルトの処理を避ける(return true)のは、
あくまでも次善の策です。
Re:使い回した開発者のミス？ (スコア:1, すばらしい洞察)
サンプルコードとはそういうもの、常考。
Re:使い回した開発者のミス？ (スコア:2, おもしろおかしい)
そして、原文（英語）のドキュメントを頑張って読んでみるけど、日本語訳が間違いとは思えない。しかしそれ以上に自分の語学力にも自信がない。
「オレはC言語と英語ではC言語のほうが得意だ」ということで、自分が英語のドキュメントも正確に読めなかったと思ってしまう。
そして「このサンプルは正しいはずだ」と思ってしまう…
…オレだけか。
Re:使い回した開発者のミス？ (スコア:1, すばらしい洞察)
それなら話は早いです。
コードを検証しましょう!!
#たいていの場合、プログラムは書いてあるとおりに動きます
Re:使い回した開発者のミス？ (スコア:1, すばらしい洞察)
ソースが(自分から見て)公開されてるわけでもないライブラリが介在すると、
この発想は破綻します。
どうしてもブラックボックスの振る舞いを「推測」せざるを得なくなってしまう。
読めば判るという大原則が機能しない。
…だからこそ優秀な人々は、オープンソース(誰にでも公開)だの、アジャイル(チームメートには公開)だの、といった開かれた開発形態が必要だと理解している。
引用と同じような台詞を例えば「matz氏が」言うのには意味も価値も十分有る。
MSの中の人が言ったら笑い話になってしまう。
(でも数年前にゲイツが来日し某大学で講演したとき、「他人のソース嫁。それがタメになる」と言ったんだよね。そう言うんだったらMSのソースも確認させてほしいもんだが…)
Re:使い回した開発者のミス？ (スコア:1)
たいていの場合と書いてありますが？
そしてたいていの場合以外というのは、おっしゃるとおりライブラリやOSのバグだったりもするんですが、ハードウェアのバグなどもあったりします。
中の方をどんどん追っていっても、いずれはブラックボックスに突き当たるので(ICの中の実装まで追う人は少数派でしょ)、振る舞いを推測することはとても重要です。
いずれはどこかでブラックボックスに突き当たるのであれば、これを基にオープンソースの重要性を説くのはちと苦しいですね。
Re:使い回した開発者のミス？ (スコア:1, すばらしい洞察)
ライブラリの話は関係ないでしょう。
コードが見えてるんですから、おかしい事は気付きますよ。
Re:使い回した開発者のミス？ (スコア:1, 参考になる)
それはですね。Microsoft 提供の windowsx.h に
#define GetFirstChild(hwnd) GetTopWindow(hwnd)
ってのがあるため、VCL の GetFirstChild が勝手に置き換わってしまう問題を回避するための苦肉の策なのですよ。
幸い、VCL / PASCAL 言語は大文字小文字を同じとみなしますからね。
Microsoft も反省したのか、その後のヘッダーファイルでは
#define IAccessibleWinSAT_get_accChildCount(This,pcountChildren)
こんな感じに、簡単には衝突しないように配慮しているようです。