2009-03-22 - 未来のいつか/hyoshiokの日記
私もVisual Studio使う場合、場当たり的なprintfデバッグはやらないです。だってprintfデバッグよりもVisual Studioのほうが高機能なんだもん。printfデバッグに類する技を使うのは開発環境でどうしようもなくサポートされていなくて、APIの挙動を確かめるときのサンプルというか、テストというか、そういうプログラム作る時かな。
完成品でデバッグするといえば、かつてのMS-DOSの時代、先輩たちはパッチエリアと呼ばれるコード領域をとっていました。バグ見つかるとソースコードから直すんじゃなくて、無条件ジャンプ使ってバグの出る場所の前でパッチエリアに埋め込んだ新コードへ飛ばしてしまうと。ソースコードの修正が許されるのはパッチ用のエリアを使いつくしたときだけだったそうです。MASMなどを使っていた時代の話です。
そんな人たちばかりだったので、私が入社してすぐにWindows 3.1向けにCとWindows SDKを使った開発が始まって、「なぜコンパイルされた結果のバイナリ比較(fc /b)がこんなに違うんだ」と上司から問い詰められて、説得するのに苦労したものです。
ログといえば、変数なんかの状態を見るとき、もう「出しすぎ」と思うくらいログ書いたほうがいいです。大きくなるとか、遅くなるとか考えずに。ログ出力するためのAPI側で抑止するフラグとか実装すればいいのです。ログに関してはいまだに後悔することしきりです。
内部を見るといえば、Windowsのcheck版(デバッグコードなどがいっぱい入ったやつ。MSDNでダウンロードできます。ただし英語版のみ)はいっぱい内部情報出してくれます。Windows NTではシリアルでNTマシン同士をつながないとカーネルデバッグできなかったから、NTが動くスペックのマシン用意するの辛かった。あとは下手なドライバ(たいていビデオだった)のせいで割り込みが上がってこなくてシリアルからのデータがぼろぼろ抜けてデバッグできなかったので、大昔ドライバの人たちは基本VGA使ってデバッグしてたり。
ちなみにcheck版に対して、普通一般に使われるWindowsはfree版と呼ばれます。ところどころバージョン表記などでfreeとか出ているのはここからきています。
printfデバッグ
