Shellの開発が既に一段落していた私は、すぐにスワットチームに加わる。Companyの教育ソフトの互換性を担当することにする。Companyは、このジャンルでは常にベストセラーランキングに名を連ねるソフトを何本も持つ、教育ソフトの大手である。その会社のソフトがどれもWindows95で動かないのだ。確かにどのソフトもWindows95上ではちゃんと動かない。調べてみると、Windows3.1用のソフトであるにも関わらず、32ビットのレジスタを使ったインストラクションを使っており、それが32ビットレジスタの上位16ビットが全て0に初期化されていることを前提にしているため、システムが32ビット全てを使うWindows95上で走らせると、暴走してしまうのだ。その情報を持って、Kernel(メモリやプログラムを管理する部分)を担当するKevinに話に行く。「16ビットのソフトを起動する前に、全てのレジスタの上位16ビットを0にしてくれれば互換性が高まるはず」というSatoshiの説を訴える。最初はKevinも難色を示すが、結局のところ「それで互換性が高まるのであれば」と納得してもらう。Rabbitを走らせてみる。先ほどよりは少し先に進めるが、やはり途中で暴走してしまう。別の問題があるのかも知れない。解析を進めると、先ほどと同じような症状だが、今度はシステムコールをした後のレジスタの上位16ビットが0でないことに起因している。再度Kevinに相談に行く。「これは完全にアプリ側のバグだよ。システムコールを呼ぶと幾つかのレジスタの内容が破壊されるのはWindowsの仕様だよ。それをちゃんと理解せずに、システムコールの後もレジスタの上位16ビットが0のままであることを前提にしているプログラムを作る方が悪いんだよ」とKevinは言う。「しかし、そうは言っても、Windows3.1との互換性のためには出来る限りのことをするのが僕らの仕事ではないのか。」と食い下がるSatoshi。Companyのアプリが呼び出しているシステムコールのうち、問題となるものを見つけ出し、そこで破壊されては困るレジスタの値だけを保存するようにシステム側を変更することで合意する。実際にその作業を開始したSatoshiは、すぐにそれが気の遠くなるような作業であることに気が付く。Rabbit一つ完璧に動かすことができない。こんな場当たり的な方法では効率が悪すぎる。時間はどんどんと過ぎて行く。スワットチームのどのメンバーたちも似たような壁にあたっており、「Windows95上で動かないソフトのリスト」は一向に短くならない。Companyのプログラムにある一定のパターンがあることに気が付く。彼らの使っているコンパイラが32-bitのデータを扱う時に生成するコードなのだろう。そこで、パターンをアプリ全体から探しだす作業をしてみた。アプリ一つあたり、数箇所から数十箇所に、そのパターンが現れる。アプリがそのコードを実行する前に、レジスタの上位ビットが全てゼロにしてなっていないと暴走するのだ。Rabbitに変更を加えてみることにした。問題となるパターンの部分のコードを効率化してプログラムサイズを少し小さくし、あまったスペースに問題となるレジスタを0にしてしまうインストラクションを挿入したのだ。やって変更を加えた状態で走らせると、すべてがキチンと動作する。予想通り、このパターンのコードが問題なのだ。Rabbitを見ているSatoshiの頭に、突然一つのワイルドなアイデアが浮かぶ。急いでKevinのオフィスに走る。モジュール名、日付、コードのチェックサムを見れば、すぐに判定できる。「もちろん、技術的には可能だよ。Coleが『どんな手段を使っても』って言ってたじゃないか。」そこからSatoshiとKevinの共同作業が始まる。Windows3.1用に作られたサードパーティのプログラムをロード時にダイナミックに変更して、Windows95で動くようにしてしまうというウルトラCだ。Rabbitに加えるべき変更点をデータ化し、Kevinがそのデータを読み込んでパッチをあてる様にKernelのローダーを変更する。Rabbitが新しいKernelの元で動くようになった時には、既に朝であった。Company製のソフトに限らず、他のメーカーのソフトにも適用可能なことを発表する。スワットチームの何人かが、サードパーティのプログラムに勝手にパッチをあてることに懸念を示す。話し合いの結果、互換性問題の具体的な内容をそのアプリのメーカーに開示し、ダイナミックにプログラムに変更を加えることに対して文書で許可をもらえばOK、ということになる。スワットチームの他のメンバーもこの仕組みにすぐに飛びつく。この方法を使えば、「アプリ側のバグ」のためにWindows95上で動かなくなってしまったアプリを救うことが出来るのだ。Coleが感謝の言葉を述べ、テーブルの上のシーツを取り除く。ドンペリが50本あらわれる。「優勝した野球チームがビールをかけ合うのであれば、Windowsチームはドンペリだ。」という彼の約束どおりである。皆、一本ずつドンペリを手に持ち、頭から掛け合い、ラッパのみをする。シャンパンまみれになったSatoshiとKevinががっちりと握手をする。(ITProの「本当はすごい『Windowsの互換性維持』」という記事で蘇った記憶に刺激されて書いたエントリー。事実には基づいているが、かなり脚色も入っているし、思いっ切り美化もしているので、その辺りは少し差し引いて読んでいただきたい。|CommentsITMediaぢゃなくてITProですぅ~。21:26すいません~。個人的にはあれだけ互換性を維持してあれだけのメモリサイズで動かしたということは立派な技術だと思っていました。今回の記事でそれを再確認した気がします。95はすごいと思ってますが、すごさを再確認させられました。個人的にはNT系より好きです。いう裏話が大量に隠されてるっぽいところが。軽くていいOSなんじゃないかと思うんですけどねー(笑)。そのDNAの一部は、いちおうXPに受け継がれているわけだからがまんして使います。23:24こんにちは。読んでて「闘うプログラマー」を思い出しました。私はこれを読んでIT業界に入りました。07:50すごい話ですね。私はwindowsの経験がないのですが、>32ビットレジスタの上位16ビットが全て0に初期化されていることを前提にして>いるため、システムが32ビット全てを使うWindows95上で走らせると、暴走してこんなことを見つけるのってかなり大変そうですね。そもそも>システムコールの後もレジスタの上位16ビットが0のままであることを前提にして>いるプログラムっていう状況がよくわかりませんでした。結局、アプリケーションの問題ではなく、コンパイラの問題だったのでしょうか。普通、アプリケーションはレジスタの値を直接見ませんよね。06:02こんばんは。engineeringと思われます。中島先生はどう思われますか?#約20年前のアルバイトで、国民的ワープロを別OSにポーティングするお手伝いをしたことを思い出しました。06:16>結局、アプリケーションの問題ではなく、コンパイラの問題だったのでしょうか。普通、アプリケーションはレジスタの値を直接見ませんよね。Companyの使っていたコンパイラのバグでした。Windows3.1用のコンパイラにも関わらず必要に応じて32bitレジスタを使うインストラクションを生成する様にできていたのですが、何を勘違いしたのかすべてのレジスタの上位16ビットは常に0であることを前提にしたコードを生成するため、こんな事態になってしまいました。engineeringと思われます。中島先生はどう思われますか?これをリバース・エンジニアリングと呼ぶのかどうかは微妙なところですね。普通、リバース・エンジニアリングとは通常「ソフトがどうやって動いているのかを解析する」ことを指しますが、このケースでは「どうやって動いているか」には興味がなく、「なぜWindows3.1の上では動くのにWindows95の上では動かないのか」を調べただけなので、少し違いますね。09:33"ソフトウェアはサービス"であるならば、どこまでお客様を裏切らないでいられるかという事の集約されたエントリだと思いました。酔っ払い客の狼藉を警察沙汰にするような店よりも、受け入れてくれるような店にこそ通い詰めたいモノですよね。11:54Satoshiさん、「Windows95と地上の星」を読みながら、ソフトウェア開発と映画制作は共通点が多い気が致しました。投資家に、ビル・ゲイツ氏。Mr.Satoshi。最初にテーマがあり、コンセプトを作り、どれくらいのリソースを投入し、いつ、誰に、どのような価値を提供するのか、また、ビジネス・リターンは何か、など。今日、映画制作では、タレント以上に、作り手である「監督」「プロデューサー」「演出家」の名前が注目されています。すると、ひとは、『Goodness』を追究するもとで「モチベーション」「組織との一体感」を実感し、同時に、その改善プロセスを通じて、「スキル」や「解決能力」など獲得できる可能性がある・・・。人は、経験・体験を通して大きく成長する・・・。仮に、ソフトウェアがサービスであるならば、近い将来、ソフトウェア産業において、われわれは新たなビジネス・シーン(作り手がブランドへ)を目の当たりにする日がくるかもしれませんね。『おもてなし』のこころは、人とひとを結びつける不思議なチカラを持っている気がする・・・。マックは、ダイナマックからキューブまでさわっておりました。その頃の経験で言うと、OSが変わっても、今まで使っていたソフト(やゲーム)が走るのは当たり前だったのですがね?最近は、PCやマックが【進化?】すると、ソフトが使えなくなる・・・のが当たり前になってきたようで、困っております。22:48ちはー、中島君お久しぶりです。コンパイラのバグのしわ寄せまで面倒見るって大変そう。MacOSのほうはリビジョン一つ違っただけでソフト動かなくなってましたが、あれに対してユーザーは文句も言わ無かったのが不思議でした。16:14>コンパイラのバグのしわ寄せまで面倒見るって大変そう。ユーザーにとって、コンパイラのバグかどうかは分かりませんからね。95マシンには買い換えない」という行動に出たりするわけです。Schulmanは、どう見えていたのでしょうか?よろしければ教えてください。Basicを作った方)が、後方互換性についてのビジネス的な意味について考察してます。こちらも非常に興味深いです。07:24windows95の生々しい互換性の話、大変面白く読ませていただきました。確かに当時はIBMやappleの力が強く、油断できない状況だったように思います。アプリのコードを書き換えてしまうというウルトラCはさすが天才のお仕事だと思いました。日本の会社でも成功したらドンペリくらい開けるようになれば、ソフトウエア技術者ももっと増えるのにな、と思います。TypepadTop。