リリースでBAARDが削除されないのはなぜですか？
Windows 3.1のベータ版では、 隠された暗号化されたコードがあり、DR-DOSで起動すると、理解できないエラーメッセージが生成されました。
リリースでは、彼らはそのようなトリックを処理しないことに決めましたが、検証コードとメッセージ自体は削除されませんでした：
内に残り、AARDコードが各開始で再び実行されるように1バイトを変更するだけで十分です。
なぜ彼を離れたのですか？ マイクロソフトは、将来、これらの疑わしいチェックのロックを解除することを本当に望んでいましたか？
もちろん違います。 リリースのメッセージでさえ「Windows 3.1ベータサポートに連絡してください」と変わりませんでした。メッセージが本当に表示されることを意図していた場合、ベータテスト後に更新されます。
では、なぜ実行しないリリースに意味のないコードを残すのでしょうか？
ラリーオスターマンの説明：
BAARDは、Windows 3.1のベータ版の唯一の興味深い機能ではありませんでした。
Windowsは初めてCtrl-Alt-Delを押すことを傍受し、「フリーズしたプログラムを閉じるのを手伝ってください」という独自の画面を表示しました。 Windows 3.xを使用している人は、この画面が青であることを覚えています。 ベータ版では、彼は鈍い黒でした。
ハングしたアプリケーションが閉じていることをユーザーが確認したが、Windowsがそれを完了できなかった場合（たとえば、システムにハングしたアプリケーションがまったくなかった場合）、Windowsが提供できるのは再起動だけでした。
Windows 3.1リリースでは、この奇妙な点が修正されました。現在、ハングしているアプリケーションがない場合、Windowsはすべてをそのままにすることをお勧めします。
私はレイモンド・チェンから別の同様の物語を読んだようです。 現在ソースを見つけることができませんでした。 そこでChenは、Windowsの古代のビルドの1つで、未使用の変数を発見したと言いました。 削除しました-コード内のまったく異なる場所で、関数が機能しなくなりました。 彼らは変数を返しました-バグはなくなりました。
今回は、チップが整然としていました。プログラマーには本当に問題がありました。 壊れた関数では、使用前にすべての場合で初期化されなかった変数がありました。 初期化されていない変数の値は、誤って割り当てられたスタックセル内にあるガベージでした。 この場所では常にゼロであることが判明しました。 ゼロはその変数の適切な値であり、プログラムは引き続き実行されました。
未使用の変数が削除されると、プログラム内の他のすべての変数がスタックに沿って「移動」し、初期化されていない変数用に予約された場所に、他の値が現れました。 これでプログラムがクラッシュしました。
Chenの同僚の驚いたことに、この機能は何ヶ月も前に書かれており、以前のWindowsのリリースになってしまいました！ 状況がうまく組み合わされているため、バグにもかかわらず常に正常に機能しているため、バグが長い間気付かれていませんでした。
チェンは、Windows 3.0以来誰も触れていないWindows XPのコードスニペットがある理由の説明としてこの話を引用しました。 目に見えないバグの数は誰にもわかりません。 しかし、誰もが確実に知っています。 このコードは機能します。
リリースでは、彼らはそのようなトリックを処理しないことに決めましたが、検証コードとメッセージ自体は削除されませんでした：
WIN.COM
内に残り、AARDコードが各開始で再び実行されるように1バイトを変更するだけで十分です。
なぜ彼を離れたのですか？ マイクロソフトは、将来、これらの疑わしいチェックのロックを解除することを本当に望んでいましたか？
もちろん違います。 リリースのメッセージでさえ「Windows 3.1ベータサポートに連絡してください」と変わりませんでした。メッセージが本当に表示されることを意図していた場合、ベータテスト後に更新されます。
では、なぜ実行しないリリースに意味のないコードを残すのでしょうか？
ラリーオスターマンの説明：
JMP
コマンドを挿入してコードの実行をバイパスすることは非常に安全です。 それを削除すると、残りのコードで関数オフセットが変更されます-つまり テストされていない新しいコードになります。 ベータテストは既に完了しているため、開発者はテスト済みのコードをテストなしのコードに置き換えないようにしました。
しかし、一体どうしてこのようなコードの小さな変更が何かに影響するのでしょうか？ クリス・プラトリーが例を挙げます：
再コンパイルのようにではなく、コードをリンクしても、予期しないバグが発生する可能性があります。 数年前、アジア言語のWord97のリリースに取り組んでおり、コード全体の準備がすでに整っていると考えていたときに、最終的な最適化を開始しました。 個々の機能のパフォーマンスに関する統計を収集し、それらを最適な方法でファイルに並べ替えるツールがあります。 機能コードは変更されません。 最適化後、最終テスト用のコードを提供しました-そして両方！ -バグがありました。 テスターがプログラムの特定の機能を使用すると、一部のマシンで最適化されたコードがクラッシュしました。 同じマシンで、最適化の前に同じ機能が正常に機能しました。
デバッグしました。 ただし、最適化されたバージョンにデバッグ情報を追加しても、クラッシュすることはありません。 追加情報なしでデバッグしようとしました。 ただし、デバッガーで実行しただけでも、クラッシュすることはありません。 転倒の原因を突き止めようとしても、プログラムは転倒しませんでした。 しかし、私たちが彼女を放ったとき、彼女は絶対にいつも倒れました。
パターンに気付いたときに、ICE（ハードウェアデバッガー）を使用しようとしていました。プログラムは、周波数が150 MHz以下のPentiumプロセッサでのみクラッシュしましたが、まったくクラッシュしませんでした。 すでにリードでした。 インテルのWebサイトにアクセスして、「不正確なリスト」（バグと呼ばれる）を確認しました。 ビンゴ！ Pentiumプロセッサには「不正確」があり、特定の条件では障害につながります。 非常に特定の条件：JMP
後に33バイトの後に条件ジャンプがあり、JMP
自体がメモリページの境界にある場合。 この「不正確さ」は、Pentium 150MHzのリリース以降に修正されました。
実際、よく知られているのはごくわずかですが、チップにはバグが非常に多くあります。 最終的に、人々は神ではなくマイクロコードチップを書きます。 通常、チップメーカーはバグを見つけるとすぐに、コンパイラメーカーに伝えます。 そのため、コンパイラは検出されたバグをバイパスしてコードを生成し、これらのバグを抱える通常のプログラマがスタックすることはなくなります。 この特定のバグをまだ知らなかったわずかに時代遅れのコンパイラがあったことが判明しました。
Intelの担当者が、この非常にバグが原因でプログラムの不思議なクラッシュが発生する可能性があることを確認すると、最適化されたコードを調べ、コマンドの有罪なシーケンスを見つけ、2つのジャンプ間の距離が34バイトになるように3バイトを手動で再配置しました。 滝は止まりました。
今、誰かが彼の訂正が「絶対に安全」であると私に保証するとき、私はいつもこの話をします。 コードの変更は絶対に安全ではありません。
私自身も同様のバグに遭遇しました。Exchange5.5で作業しているときに、次のビルドが1台のテストマシンでクラッシュしました-常に同じマシンで。 数日間、私たちは理由を見つけようとしましたが、役に立ちませんでした。バグはわずかなコード変更から消えました。 しかし、デバッグを停止すると、必ず表示されます。 最終的に、クリスと同様に、「不正確なリスト」を見つけました。 そして実際、私たちのコードはそれらの1つに苦しんでいました。 特定のビルドの修正に満足せず、バグが不可能なコンパイルオプションのセットを見つけました。
したがって、Windows開発者がリリースにAARDコードを残したのは驚くことではありません。彼らは、このコードを使用してWindowsを数か月間ではなくとも数週間テストしており、このコードが適切に配置されたときにWindowsが機能することを知っていました 。 Windowsがそれなしで動作するかどうか、彼らは-リリース前に-見つけることを敢えてしなかった。
BAARDは、Windows 3.1のベータ版の唯一の興味深い機能ではありませんでした。
Windowsは初めてCtrl-Alt-Delを押すことを傍受し、「フリーズしたプログラムを閉じるのを手伝ってください」という独自の画面を表示しました。 Windows 3.xを使用している人は、この画面が青であることを覚えています。 ベータ版では、彼は鈍い黒でした。
ハングしたアプリケーションが閉じていることをユーザーが確認したが、Windowsがそれを完了できなかった場合（たとえば、システムにハングしたアプリケーションがまったくなかった場合）、Windowsが提供できるのは再起動だけでした。
Windows 3.1リリースでは、この奇妙な点が修正されました。現在、ハングしているアプリケーションがない場合、Windowsはすべてをそのままにすることをお勧めします。
私はレイモンド・チェンから別の同様の物語を読んだようです。 現在ソースを見つけることができませんでした。 そこでChenは、Windowsの古代のビルドの1つで、未使用の変数を発見したと言いました。 削除しました-コード内のまったく異なる場所で、関数が機能しなくなりました。 彼らは変数を返しました-バグはなくなりました。
今回は、チップが整然としていました。プログラマーには本当に問題がありました。 壊れた関数では、使用前にすべての場合で初期化されなかった変数がありました。 初期化されていない変数の値は、誤って割り当てられたスタックセル内にあるガベージでした。 この場所では常にゼロであることが判明しました。 ゼロはその変数の適切な値であり、プログラムは引き続き実行されました。
未使用の変数が削除されると、プログラム内の他のすべての変数がスタックに沿って「移動」し、初期化されていない変数用に予約された場所に、他の値が現れました。 これでプログラムがクラッシュしました。
Chenの同僚の驚いたことに、この機能は何ヶ月も前に書かれており、以前のWindowsのリリースになってしまいました！ 状況がうまく組み合わされているため、バグにもかかわらず常に正常に機能しているため、バグが長い間気付かれていませんでした。
チェンは、Windows 3.0以来誰も触れていないWindows XPのコードスニペットがある理由の説明としてこの話を引用しました。 目に見えないバグの数は誰にもわかりません。 しかし、誰もが確実に知っています。 このコードは機能します。
All Articles