本当に生活の一部になると言及されなくなる
ユーザー参加型サービスの力

Windows95と地上の星

Learning Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。

 Shell(デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス)の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。

 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。

「このままだと、95年中にリリースすることはできない」

 深刻な問題である。既に当初の予定より1年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリースして一気に32ビットOSでの主導権を握ろうとしているMicrosoftの戦略上許されることではない。しかし、かといってWindows3.1との互換性をないがしろにすることは、絶対にできない。ユーザーが持っているWindows3.1用のアプリをそのまま走らせることが出来るからこそ、Windows95への移行がスムーズに進むのだ。互換性が維持できなければ、AppleやIBMに付け入るスキを与えてしまう。

 「この状態を打開するために、各部署から人を出してスワットチームを作って欲しい。3ヶ月以内に、市場に出ている売れ筋のWindows3.1用のアプリ全てがWindows95上できちんと走るようにして欲しい。どんな手段を使っても良いからかならずそれを実現するのが君らの役目だ」

 そう言いながらDavid Coleが我々に渡した資料には、ゲーム、教育、ビジネス、などの各ジャンルの売れ筋のソフトのリストが書かれており、Windows95上でちゃんと動作しないものに印がしてある。その数が異常に多い。事態はかなり深刻だ。

 Shellの開発が既に一段落していた私は、すぐにスワットチームに加わる。たまたま、息子たちの幼稚園で使っていたという理由で、Learning Companyの教育ソフトの互換性を担当することにする。Learning Companyは、このジャンルでは常にベストセラーランキングに名を連ねるソフトを何本も持つ、教育ソフトの大手である。その会社のソフトがどれもWindows95で動かないのだ。

 さっそく調査を始める。確かにどのソフトもWindows95上ではちゃんと動かない。調べてみると、Windows3.1用のソフトであるにも関わらず、32ビットのレジスタを使ったインストラクションを使っており、それが32ビットレジスタの上位16ビットが全て0に初期化されていることを前提にしているため、システムが32ビット全てを使うWindows95上で走らせると、暴走してしまうのだ。

 その情報を持って、Kernel(メモリやプログラムを管理する部分)を担当するKevinに話に行く。「16ビットのソフトを起動する前に、全てのレジスタの上位16ビットを0にしてくれれば互換性が高まるはず」というSatoshiの説を訴える。最初はKevinも難色を示すが、結局のところ「それで互換性が高まるのであれば」と納得してもらう。

 変更を加えてもらったKernelでWindowsを立ち上げ、問題のソフトの一つ、Reader Rabbitを走らせてみる。先ほどよりは少し先に進めるが、やはり途中で暴走してしまう。別の問題があるのかも知れない。

 さらに解析を進めると、先ほどと同じような症状だが、今度はシステムコールをした後のレジスタの上位16ビットが0でないことに起因している。再度Kevinに相談に行く。

 「これは完全にアプリ側のバグだよ。システムコールを呼ぶと幾つかのレジスタの内容が破壊されるのはWindowsの仕様だよ。それをちゃんと理解せずに、システムコールの後もレジスタの上位16ビットが0のままであることを前提にしているプログラムを作る方が悪いんだよ」とKevinは言う。

 「しかし、そうは言っても、Windows3.1との互換性のためには出来る限りのことをするのが僕らの仕事ではないのか。」と食い下がるSatoshi。

 結局、Learning Companyのアプリが呼び出しているシステムコールのうち、問題となるものを見つけ出し、そこで破壊されては困るレジスタの値だけを保存するようにシステム側を変更することで合意する。

 しかし、実際にその作業を開始したSatoshiは、すぐにそれが気の遠くなるような作業であることに気が付く。システム側に20箇所ほど変更を加えても、まだReader Rabbit一つ完璧に動かすことができない。こんな場当たり的な方法では効率が悪すぎる。

 時間はどんどんと過ぎて行く。スワットチームのどのメンバーたちも似たような壁にあたっており、「Windows95上で動かないソフトのリスト」は一向に短くならない。

 そんな作業を繰り返しながら、Satoshiは問題を起こすLearning Companyのプログラムにある一定のパターンがあることに気が付く。たぶん、彼らの使っているコンパイラが32-bitのデータを扱う時に生成するコードなのだろう。

 そこで、パターンをアプリ全体から探しだす作業をしてみた。アプリ一つあたり、数箇所から数十箇所に、そのパターンが現れる。アプリがそのコードを実行する前に、レジスタの上位ビットが全てゼロにしてなっていないと暴走するのだ。

 それを検証するために、Satoshiはメモリ上に展開されたReader Rabbitに変更を加えてみることにした。問題となるパターンの部分のコードを効率化してプログラムサイズを少し小さくし、あまったスペースに問題となるレジスタを0にしてしまうインストラクションを挿入したのだ。

 そうやって変更を加えた状態で走らせると、すべてがキチンと動作する。やはり予想通り、このパターンのコードが問題なのだ。

 Windows95上で初めてキチンと走るReader Rabbitを見ているSatoshiの頭に、突然一つのワイルドなアイデアが浮かぶ。急いでKevinのオフィスに走る。

 「Kevin、Kernelがアプリをロードするとき、それがあるソフトの特定のバージョンだっていうことは判別できるものなの?」
 「簡単だよ。モジュール名、日付、コードのチェックサムを見れば、すぐに判定できる。」
 「だったら、ある特定のアプリのコードをメモリーにロードした時に、指定した場所に変更を加えてから実行させるってことも出来る?」
 「もちろん、技術的には可能だよ。でもサードパーティのプログラムを実行時に勝手に変更するっていうのはまずいんじゃない?」
 「David Coleが『どんな手段を使っても』って言ってたじゃないか。やるしかないよ。」

 そこからSatoshiとKevinの共同作業が始まる。Windows3.1用に作られたサードパーティのプログラムをロード時にダイナミックに変更して、Windows95で動くようにしてしまうというウルトラCだ。SatoshiがReader Rabbitに加えるべき変更点をデータ化し、Kevinがそのデータを読み込んでパッチをあてる様にKernelのローダーを変更する。Reader Rabbitが新しいKernelの元で動くようになった時には、既に朝であった。

 その週のスワットチームのミーティングで、SatoshiとKevinはLerning Company製のソフト全てをWindows95上で動かすことに成功したこと、そして、その仕組みはLearning Company製のソフトに限らず、他のメーカーのソフトにも適用可能なことを発表する。

 スワットチームの何人かが、サードパーティのプログラムに勝手にパッチをあてることに懸念を示す。話し合いの結果、互換性問題の具体的な内容をそのアプリのメーカーに開示し、ダイナミックにプログラムに変更を加えることに対して文書で許可をもらえばOK、ということになる。

 スワットチームの他のメンバーもこの仕組みにすぐに飛びつく。この方法を使えば、「アプリ側のバグ」のためにWindows95上で動かなくなってしまったアプリを救うことが出来るのだ。

 翌年7月。予定通りの日付にWindows95をリリースした開発チームにDavid Coleが感謝の言葉を述べ、テーブルの上のシーツを取り除く。ドンペリが50本あらわれる。「優勝した野球チームがビールをかけ合うのであれば、Windowsチームはドンペリだ。」という彼の約束どおりである。皆、一本ずつドンペリを手に持ち、頭から掛け合い、ラッパのみをする。シャンパンまみれになったSatoshiとKevinががっちりと握手をする。

(ITProの「本当はすごい『Windowsの互換性維持』」という記事で蘇った記憶に刺激されて書いたエントリー。事実には基づいているが、かなり脚色も入っているし、思いっ切り美化もしているので、その辺りは少し差し引いて読んでいただきたい。)

Comments

中の人

ITMediaぢゃなくてITProですぅ~。

satoshi

すいません~。修正しました。

Andy

「Windows 95なんて技術がない!」という意見をよく聞きましたが、
個人的にはあれだけ互換性を維持してあれだけのメモリサイズで
動かしたということは立派な技術だと思っていました。

今回の記事でそれを再確認した気がします。

Bar

今でもWindows 95はすごいと思ってますが、すごさを再確認させられました。個人的にはNT系より好きです。まさに、こういう裏話が大量に隠されてるっぽいところが。

軽くていいOSなんじゃないかと思うんですけどねー(笑)。そのDNAの一部は、いちおうXPに受け継がれているわけだからがまんして使います。

Dora

こんにちは。読んでて「闘うプログラマー」を思い出しました。私はこれを読んでIT業界に入りました。。

YT

すごい話ですね。私はwindowsの経験がないのですが、

>32ビットレジスタの上位16ビットが全て0に初期化されていることを前提にして
>いるため、システムが32ビット全てを使うWindows95上で走らせると、暴走して
こんなことを見つけるのってかなり大変そうですね。

しかし、そもそも

>システムコールの後もレジスタの上位16ビットが0のままであることを前提にして>いるプログラム

っていう状況がよくわかりませんでした。結局、アプリケーションの問題ではなく、コンパイラの問題だったのでしょうか。普通、アプリケーションはレジスタの値を直接見ませんよね。

shu

こんばんは。いつも読んでます。
物語中の:)Mr.Satoshiが行った行為は、reverse engineeringと思われます。
中島先生はどう思われますか?
#約20年前のアルバイトで、国民的ワープロを別OSにポーティングするお手伝いをしたことを思い出しました。(ICE使って)

satoshi

>結局、アプリケーションの問題ではなく、コンパイラの問題だったのでしょうか。普通、アプリケーションはレジスタの値を直接見ませんよね。

 はい、Learning Companyの使っていたコンパイラのバグでした。Windows3.1用のコンパイラにも関わらず必要に応じて32bitレジスタを使うインストラクションを生成する様にできていたのですが、何を勘違いしたのかすべてのレジスタの上位16ビットは常に0であることを前提にしたコードを生成するため、こんな事態になってしまいました。

>物語中の:)Mr.Satoshiが行った行為は、reverse engineeringと思われます。中島先生はどう思われますか?

 これをリバース・エンジニアリングと呼ぶのかどうかは微妙なところですね。普通、リバース・エンジニアリングとは通常「ソフトがどうやって動いているのかを解析する」ことを指しますが、このケースでは「どうやって動いているか」には興味がなく、「なぜWindows3.1の上では動くのにWindows95の上では動かないのか」を調べただけなので、少し違いますね。

Naotake

"ソフトウェアはサービス"であるならば、どこまでお客様を裏切らないでいられるかという事の集約されたエントリだと思いました。酔っ払い客の狼藉を警察沙汰にするような店よりも、受け入れてくれるような店にこそ通い詰めたいモノですよね。

Maki

Satoshiさん、「Windows95と地上の星」を読みながら、ソフトウェア開発と映画制作は共通点が多い気が致しました。投資家に、ビル・ゲイツ氏。プロデューサーに、David Cole氏。監督・兼・主演に、Mr.Satoshi。まず、最初にテーマがあり、コンセプトを作り、どれくらいのリソースを投入し、いつ、誰に、どのような価値を提供するのか、また、ビジネス・リターンは何か、など。今日、映画制作では、タレント以上に、作り手である「監督」「プロデューサー」「演出家」の名前が注目されています。もしかすると、ひとは、『Goodness』を追究するもとで「モチベーション」「組織との一体感」を実感し、同時に、その改善プロセスを通じて、「スキル」や「解決能力」など獲得できる可能性がある・・・。人は、経験・体験を通して大きく成長する・・・。仮に、ソフトウェアがサービスであるならば、近い将来、ソフトウェア産業において、われわれは新たなビジネス・シーン(作り手がブランドへ)を目の当たりにする日がくるかもしれませんね。『おもてなし』のこころは、人とひとを結びつける不思議なチカラを持っている気がする・・・。

三田皓司

XPを使い始めたWin PC初心者です。

マックは、ダイナマックからキューブまでさわっておりました。その頃の経験で言うと、OSが変わっても、今まで使っていたソフト(やゲーム)が走るのは当たり前だったのですがね?

最近は、PCやマックが【進化?】すると、ソフトが使えなくなる・・・のが当たり前になってきたようで、困っております。

浦野収司

ちはー、中島君お久しぶりです。
コンパイラのバグのしわ寄せまで面倒見るって大変そう。
MacOSのほうはリビジョン一つ違っただけでソフト動かなくなってましたが、あれに対してユーザーは文句も言わ無かったのが不思議でした。

satoshi

>コンパイラのバグのしわ寄せまで面倒見るって大変そう。

 ユーザーにとって、コンパイラのバグかどうかは分かりませんからね。彼らにとってみれば、Windows 3.1で動いていたソフトがWindows 95で動くか動かないかが重要で、動かないとなれば原因が何であれ「Windows 95マシンには買い換えない」という行動に出たりするわけです。

Ted

そんなsatoshiから、当時数々のUnauthorized Windows/ Undocumented DOS を書いたAndrew Schulmanは、どう見えていたのでしょうか?
よろしければ教えてください。

yoyoyokohama

ジョエル・スポルスキーさん(VBAの前身であるExcel Basicを作った方)が、後方互換性についてのビジネス的な意味について考察してます。こちらも非常に興味深いです。

http://japanese.joelonsoftware.com/Articles/StrategyLetterII.html

Maxtutakusouda

windows95の生々しい互換性の話、大変面白く読ませていただきました。確かに当時はIBMやappleの力が強く、油断できない状況だったように思います。アプリのコードを書き換えてしまうというウルトラCはさすが天才のお仕事だと思いました。日本の会社でも成功したらドンペリくらい開けるようになれば、ソフトウエア技術者ももっと増えるのにな、と思います。

The comments to this entry are closed.