大富豪家2.0の日記
2006年05月02日
10:18
Windows95の互換性譚
http://
satosh
i.blog
s.com/
life/2
006/04
/windo
ws95.h
tml
http://
b.hate
na.ne.
jp/ent
ry/htt
p://sa
toshi.
blogs.
com/li
fe/200
6/04/w
indows
95.htm
l
無茶な解決法に驚くのはいいのだが、すごい技術だとか感動するのはマズいだろう。
コメント
2006年05月02日
10:27
shinji
アプリケーションごとにOSの機能を変えるのは、3.1 から95に移行した際に導入されたものだったと思う。Mac OS みたいにどんどん動かなくなっちゃうのも困るけど。
2006年05月02日
10:31
９８○
すばらしい、ＭＳＤＯＳらしい解決方法だと思います;-)
2006年05月02日
10:44
もと
素直に感動しちゃいます ^_^; 技術にではなくて、成し遂げる、という行為について、ですけど。
2006年05月02日
11:01
おごちゃん
見事な技術でありトリックでしょう。私の目には、かなりエレガントにも見えます。
これが「マズい」というのは、アカデミズムに毒され過ぎです。
2006年05月02日
11:02
ひろのぶ
> それが32ビットレジスタの上位16ビットが全て０に初期化されていることを前提にしているため、
おー、20年ぐらい前にNTTの交換機用CPUエミュレータを作ったときに、同じような境遇に出くわしたことがあるぞ。
交換機のCPU(D10という特殊なCPUだ）インストラクションマニュアル通りに完璧に作ったにもかかわらず、交換機上で実際に動いている実行コードを処理するとバグる。
交換機が新しくなると、その上で動いている莫大な数のプログラムの検証をしなくてはいけない。ハードウェア側の実機が出来る前に、並列してソフトウェア側の検証作業をすると開発期間が劇的に短くなる。そのためのCPUエミュレータだ。これがこんなレベルでバグっていては話にならない。
むかしの交換機の実行コードなんて職人芸でバイナリーパッチを当てているから16進ダンプで読むしかない。直接的な問題は簡単に見つかった。メモリから32ビットレジスタに転送したとき上位8ビットがマスクされた状態を前提として処理しているからだ。これは最初の日にわかった。8ビットをマスクしている処理部分を16進でダンプされたプリントアウトから探すのだが、ない。CPUの仕様書にもそんな記述はない。一週間ずっと机の上にある厚さ３センチにもなるプリントアウトされた16進ダンプとマニュアルとの睨めっこが続いた。何故だかわからないが、１ついえることは自分の書いたコードに間違いはない。
関係者が集まった会議でそれを切り出す。すると「あ、それ内部バスが24ビットバスだから転送時に自動的に上位8ビットがクリアになるのですよ」交換機の実機仕様などもらっておらず、CPU仕様を頼りに作っている。なぜならCPUエミュレータを作ったんだから。いずれにしろ自分は正しかった。実際に動いているコードよりも自分を信じていて、しかも、それが正しかった自分を褒めてやった。
ちなみにその交換機で動いていた潜在的バグがある実行コードは、次の世代の交換機では使われなかったはずである。なぜならば、CPUが下位互換であっても内部バス仕様なんかはガラリと変わっていたから。
そんなことを事前に見つけ出すためのCPUエミュレータだったので、開発途中とはいえ役目は果たしていたのだ。自分的にはGJである。
2006年05月02日
11:13
i16(愛一郎)@一陽來復
「すごい労力だ」とか「人民解放軍みたいだ」のような感動なら確かにある。殺しても殺しても山の向こうから素手に丸腰の大軍団が湧いて出るので米軍は朝鮮戦争で大変だったんだよというような脱力感で。
ローラー作戦で営業を掛けて技術的劣勢を跳ね飛ばしてしまうような種類の経営であっても営利企業であれば損失が出るより利益が上がるほうがエライ。非営利団体や政府機関でなく営利企業であるから当然顧客や一般社会などではなくて株主を向いており、株主の利益のために顧客サービスが必要であれば「顧客サービスさえも厭わない」、というような。
しかしもちっとエレガントにイカンのかねー。過去の全ＯＳのライセンスが自分持ちなんだから「全部入れちゃう」みたいなIBMのVMみたいなほうがすっきりしそうだけどそうもいかんのかなー。
ＰＣ９８Ｖｍとかのむかしのフロッピーコピーツールってこんな感じでアプリごとにパッチ当ててたんじゃないかな。自前のハードウェアでは書けない変則フォーマットのフロッピーで市販されたソフトをバックアップフロッピーで動かしたかったらチェック部分にパッチ当てちゃわないと動かない。
てことは当時既に使い古された「技術」？
自分トコのＯＳの動作仕様を必ずしも把握してないから「古いバージョンのＯＳのフリ」が出来ないんですねえ。しかしこうやってどんどん仕様が肥大していったらますます把握できない。
ＯＳが保存してたレジスタを保存しなくなったら「それって仕様変更だろう」と思うんだけど、そう認める気配が全くないのがまず一番スゴイですね。
2006年05月02日
11:14
みなっち
とりあえずドンペリのシャンパンファイトうらやましい。
確かに手段は選ばず、ですね。
2006年05月02日
11:29
まえG
元ネタのIT Proの記事へのコメント
http://
itpro.
nikkei
bp.co.
jp/mem
bers/p
arts/p
utfeed
back.j
sp?_PA
RTS_ID
=FB01&
REF=/a
rticle
/OPINI
ON/200
60427/
236520
/
（無料登録必要）
でも、「どこがすごいんじゃと小一時間．．．」というコメントが多数(笑)
2006年05月02日
11:36
shinji
「１ついえることは自分の書いたコードに間違いはない」って、その16進が自分で書いたコードだってことと読んでしまった...
「動かなくなったうちのプログラム用のパッチをWindowsに入れてください」「1500万円いただきます」ってな感じなのかな? 確かにアカデミックではないなぁ。
2006年05月02日
11:42
ひろのぶ
「恥ずかしいけど、ま、とりあえずアリだよね」というならわかるけど、こんなのを褒めたり、すごいとかいう方が本当の意味でのプロとしてどうにかしている。
この後先考えないマイクロソフトの開発文化が脆弱性を山ほど抱えたシステムを作る土台になっているのですがねぇ。エレガントですか。はぁ。
2006年05月02日
12:11
ふくち
えー、これは Microsoft が恥ずかしがるべきことなんですか?
そりゃまぁ、シェアを低下させないためにはなりふり構わなかったことは多少は恥かちー、という気にはなるかもしれませんが、その目的にはこうしたトリックは不可避ですよねぇ。Joel on Software では SimCity に対応させるための特殊メモリアロケーションモードなんて話もありましたが、裏側でいくら泥臭いことをやっていようが、これまで使っていたアプリケーションが新しい OS でも使えるってのは、基本的なサービスでしょう。もちろん、「落ちないOS」「セキュアなOS」も基本的サービスですが、当時は後方互換性の維持の優先順位が高いと彼等は判断した。で、市場もそれを支持した。
これがネットの発達した現在なら、パッチやアップデータを用意しまくるとか、あるいは各ソフトハウスに「アップデートの手引き」を配布して独自対応してもらう、という選択もあったでしょうが。
2006年05月02日
12:23
ひろのぶ
マーケティングの連中ならいざ知らず、エンジニアとして、それはかなり恥ずかしいですよ。そもそも互換性の問題なんていうのは５０年代のコンピュータが出現した頃から延々と繰り返されてきた問題で、別にマイクロソフトが発見した問題じゃない。知らなかっただけでしょ。クリスマス商戦に間に合わせるためにねぇ、まあいいけどね。
最近、マイクロソフトも大反省して、ちゃんと作るようにしています。出荷スケジュールも大幅に遅らせて。少しはまともになったようです。
2006年05月02日
12:54
ふくち
でもこの話って、Win3.1 を作った連中が後のことを考えなかったから Win95 で動かなくなった、という話じゃなくて、サードパーティの連中が外道なことしたからこのままじゃ面倒見れない、という話ですよね。
Win16登場時から、Win32前方互換性を保証していたんでしたっけ?
2006年05月02日
13:32
おごちゃん
恥ずかしいのは、動かないアプリを作っていた方でしょう。
古いOSでは「動いてしまっていた」だけだったものを、こういった方法で何とかしたってのは賞讃されてもいい。確かにMSの企業文化が場当たり的というのはわかりますが、ここに書かれている範囲のことにはそれはスジ違いの批判かと。
件の文章を最後まで読む前は、もっと泥臭いことかと思いました。アプリケーションに対応した、それぞれ用のシステムコールがあるみたいな。
2006年05月02日
13:45
shinji
Win 3.1 のAPIの規定が甘くて、色んな会社がみんな勝手に想像して実装していたんだね。ところが、Win95 になって、preemptive な実装に変わったせいで、その勝手に想像していた実装が「同時に動く」ってことになってしまった。OS側に残る状態の想定がまちまちだったんでしょう。なので単純にアプリ作成側が悪いってわけでもないです。
今みたいに、ネットでパッチ配布ってわけじゃないし、テストでそれが発覚した時に、もちろん、ちゃんとしたAPI定義は行われたわけなんだけど、「じゃぁ、既存のソフトはどうする?」ってな話になったんでしょう。
そこで、アプリ作成側に妥協するのが、Microsoft らしい。
そして、その対応機能テーブルが、Windows NTになっても引き継がれたってことなわけだな。さすがに、ほとんど機能してないとは思うんだけど、確かに、悪用されたりすると嫌だよね。
2006年05月02日
14:19
まえG
「仕様と実装の分離」ってIBMのシステム360以降あたりまえになった概念だと思うんですけど、実際にはドキュメントが曖昧で、実装に依存するコードが世にあふれちゃうケースってまだまだありますよね。
ある程度しかたない話だと思うんだけど、MSの解決法が「すごい」というのは抵抗あるなあ。
昔Win3.1でプログラム書いたとき、EnumWindows() （表示されてるトップレベルWindowを列挙するAPI）が、列挙中に他のプロセスがWindow開いたり閉じたりしたらどうなるのか、それともアトミックに列挙できるのか何も書いてなくて困った覚えが。確か当時試した限りはアトミックに列挙できたんだと思うんですけど、それに依存してよいものかどうか。
2006年05月03日
08:54
hachi
ずっと以前、「MSはかつて、ライバルのLotus 1-2-3だけがうまく動かなくなるように意図的にOSに細工したことがある」という文章をどこかで読んだような記憶があるのですが(遠藤諭さんの著書だったような覚えあり)、今ぐぐってみてもどうもそれらしい記述を見つけられないので、もしかすると記憶違いかまったくのガセだったかもしれません。すみません。
2006年05月03日
12:30
shinji
http://
msdn.m
icroso
ft.com
/libra
ry/def
ault.a
sp?url
=/libr
ary/en
-us/dn
apiove
r/html
/api-o
vervie
w.asp
たぶん、これでしょう。自社だけが知っている隠しAPIを用意して使っていたわけ。これでアンチMSにならずにいられるってのは、なかなか難しい。まぁ、悔い改めて公開ということになったわけだけど。
2006年05月03日
13:10
i16(愛一郎)@一陽來復
特定パターンのプログラムにパッチを当てちゃうというアドホックな挙動も仕様と言ってしまえば仕様なわけだから独禁法に掛かっちゃうようなサイズの会社が主製品でそんなことをやってるとそれも公開しなさいになっちゃってどんどん膨大なことになって破綻するんでないかなあ。
2006年05月03日
13:38
ふくち
そういや Vista では XP プログラムのサポートはどうなるんでしょう。
