9 月。
『異世界おじさん』7 話。 異世界で勇者を捜す思い出。 魔物のハリネズミ。 メガドライブ。
異世界でなく現実の話。 この前書いた MEDIA CHECK 改造デバイスドライバーは作れるか? を検討した。 残念ながらデバイスドライバーの最初の INIT コールの際にはまだリンクがされていないため、リストをたどることが不可能だ。 ただしデバイスドライバーの先頭のリンクポインターは使われるらしいことがわかった。 オフセット分足して同じセグメントでまた INIT を呼び出してくれるらしい。 そのため 2 つのデバイスドライバーをひとつのファイルに埋め込めば、2 番目のデバイスドライバーは 1 番目のデバイスドライバーのリンクポインターを読むことができる。
デバイスドライバーの組み込みをキャンセルできるかどうか。 キャラクターデバイスについては方法はひとつしかない。 Break address にわざととても大きなセグメントアドレスを設定してしまうこと。 そうするとリンクはされないがエラーメッセージが出る。 ブロックデバイスについてはそれ以外にドライブ数を 0 と返す手がある。 おそらくデバイスが接続されていなかった場合が想定されているのだろう。 これはエラーメッセージは出ない。 ただしメモリーを巻き戻す処理がある。 なぜか Break address のオフセットアドレスを 0 とみなして次の処理を始めるようになっている。 シンプルにデバイスドライバーのセグメントのままでオフセットアドレスだけを設定しているデバイスドライバーなら、これでなかったことになるが、セグメントアドレスを進めてしまっている場合は、そのセグメントアドレスの手前までは残るってことだ。 そんな仕様なのか? はよくわからないが、一応これらを元に考えていたものは作れそうな気がする。
で、調べてみると GET_IN_VARS という内部用のシステムコールがあって、それが返すデータの中にデバイスドライバーのリンクの先頭アドレスもあるようだ。
しかしこれ、バージョンによって構造が全然違うみたいで、例えば PC DOS 3.20 でもずいぶん後ろのほうになっていた。
なのでこれはちょっと使いにくいかなと思う。
他に記憶になかった話、CONFIG.SYS には AVAILDEV という設定があり、デフォルト TRUE だが、これを FALSE にすると、デバイスファイルに /dev/ (\dev\) 形式でしかアクセスできなくなるんだそうな。
つまりデバイスファイルと同じ名前のファイルが作れる。
これがあるから \DEV\CON ってキーワードが出てくるんだ。
FALSE をデフォルトに変えていたなら後の Windows 95 の concon bug はなかったかも知れないのになぁw
あと微妙に思うところがあるのは、ファイルオープンのたびに、デバイスファイルかどうかを調べるために線形探索で文字列比較をするので、8088 みたいな遅いプロセッサでたくさんデバイスドライバーを組み込んでいると、FALSE のほうがファイルオープンにかかる時間が速くなっていただろうと思った。
ただし COPY CON や NUL へのリダイレクトは当たり前のように使われていたため、普及しなかったのかも知れない。
SWITCHAR はなんかあったような記憶もあるが誰も使わなかったというか...
他に記憶になかったのは COUNTRY かな。 PC DOS 2.11 にはなかったが、PC DOS 3.20 や JX の DOS にはあったようだ。 0 がアメリカ、1 がヨーロッパ、2 が日本だ。 日付の並び順などが変わる。
雨。 涼しい日。 湿度が高かったためエアコンは使った。
テレビでやってた映画『るろうに剣心 京都大火編』。 2014 年の邦画。 映画館で見た映画。 第 1 作の『るろうに剣心』には今話題の香川照之が出演しているが、第 2 作以降には出演していないためか普通に放送される。 なお執行猶予期間の伊勢谷友介は今作には出演しており普通に放送もされている。
詳しい皆様のコメントにより INT 2EH ってのがあった話を知る。 いや、昔は知っていたかも知れないが、使った記憶はない...
それとデバイスドライバーとして組み込むこともできるしコマンドラインで実行することもできるプログラム、あったなぁー。 JX/PCjr だとそういうのでなくなぜか拡張子が .COM になっている (けどコマンドラインで実行はできない) デバイスドライバーもあったが、あれ謎だったな。 MS-DOS 2.0 のソースコードでわかるが、next ポインターはリストにリンクされる時に読み取られるので、.COM 形式で先頭に JMP 命令を置いておき、デバイスドライバーで最初に呼び出される INIT の処理の間に -1 に書き換えてしまえば、どちらでも組み込めるプログラムが作れる。
PCJRMEM.COM っていうデバイスドライバーがあったが、これは何者だったのか、ちょっぴり分析してみると、ビデオ BIOS をフックして何かやっているようだ。 Google 検索で情報が見つかるが、ああー。
そうそう、PCjr はなぜか VRAM 共用メモリーが低位アドレス (0) から始まっていたんだった。 0 からは割り込みベクターがあるので実質は先頭ページは使えない。 テキスト VRAM は容量が小さいので、ページで後ろのほうを選択すれば上位のアドレスになる。 が、飛び地になってしまうんだな。 DOS がそれを扱えないので、このデバイスドライバーがまとめて予約済みにしてしまおうってことみたいだ。 割り込みフックが何をしているのかはよくわからんけど。 この辺は JX の (日本語モードの) ほうがメモリー配置を変えて VRAM 共用が上位アドレスになっているのでまともだが (ハードウェア的にはどちらのメモリーマップも扱えるように一種のメモリー管理ユニットのようなものが付いている)、それでも画面モードによっては上位アドレスを破壊するんだよな? DOS から見たら面倒な存在だろうな。
んで PCJRMEM.COM ってオプションがあったらしくて、/E って指定すればより大きく予約済みにするってことなのかな、これ。 たぶん本当はこれを指定して使わなきゃいけなかったんだろうな。 ただし BASIC と互換性がない (笑) から BASIC を使うなら組み込んじゃだめ。
昼以降は晴れていた気がする。
夜コストコ行ってみたらこんでいた... 日曜日の夜のほうが空いているだろうか。 それとも夏休みが終わったから...
CO2 モニター、きのう久しぶりにつけてみたら 1000 近い数字で少し高すぎる気がしたので、トイレの窓を少し開けて窓のところに置いて補正をした。 100〜200 ぐらい高い数字が出ていた感じかな。
ソースコードに出てくる IBMJAPVER や IBMJAPAN の由来、もしかして IBM マルチステーション 5550 なのでは?
1983 年前半に発売され、「日本語 DOS」を採用したパソコン。
日本語 MS-DOS としては実はパソピア 16 が先だったとの Wikipedia 情報もあるが、5550 は IBM のビジネス機であり IBM から Microsoft に日本語対応を依頼していても何の不思議もない。
実際のところ MS-DOS の KANJI 対応というのはあまりたいしたことはしていなくて、文字コードが決まってしまえばあとは 2 バイト文字をちゃんと扱えるようにしようというレベルの話のよう。
2 バイト目に \ があってもディレクトリ区切りにしない、とか、コマンドライン行編集で 2 バイト文字が 1 バイトずつ削除されないようにする、とか。
んで 5550 は当時としては珍しい 24 ドットフォント採用の高解像度パソコンだが、なんと初期のモデルには漢字 ROM を搭載せずソフトウェア描画を行っていたそうなので、1982 年に文字コードが決まってからの開発が十分間に合ったんじゃないのかな。 想像だけど。 Wikipedia 情報によれば、5550 のワードプロセッサは DOS ベースでなく、文字コードも EBCDIC を使っていたらしい...
パソピア 16 は 1982 年発売なのかよーマジか。 いや、発表か。 1983 年の 2 月に出荷開始か。
公開されている MS-DOS のソースコードから日付を検索すると、v1.25 のほうの最終は 1982 年の 3 月っぽい。 ASM.ASM だけ 1983 年があるが、これは "Seattle Computer Products 8086 Assembler" って書いてあるからたぶんあんまり MS-DOS との関係はないだろう。 v2.0 のほうは 1982 年に多数のリビジョン更新のあとがあり、IBM PC 用の DOS が出たのもこの年か。 1983 年の日付も見られるが、特に 2.11 のコードが少し含まれるようなので、その関係でなのかな。 "International DOS" ってのが 1983 年 2 月 17 日で MSHEAD.ASM に書いてあるのだが、パソピア 16 関係のアップデートがきちんと反映された的なものだろうか。
とにかくこの 1983 年前後にめまぐるしく変化している感じがあって、いけいけどんどんで開発されていたのかなと思う。 1993 年前後になると Windows が熱々なわけだ。 ここ 10 年で言えば virtual machine とか container とか machine learning とかそういうのみたいに、あるいはオペレーティングシステムで言えば 10 年前頃の Android かな、そういう熱さを感じる。
んで、MS-DOS のソースコードにあった ANSI.txt (ANSI.DOC) を見ていたら、キーコード入れ替え的な話がある。
ESC [ 0 ; 6 8 ; " d i r " ; 1 3 p という例が載っていて、これで F10 キーで dir コマンドを実行するようにできるんだよと。
へぇ、そういえばそんな機能もあったような...
そうすると、Unix 的に、カーソルキーを ESC [ A みたいな入力にするのもできるんじゃないの?
つまり例えば ESC [ 0 ; 72 ; 27 ; " [ A " ; p とだな... って試したら本当にできた。
へぇ。
そうだったんだ。
PC-98 はどうだったか? カーソルキーのキーコードはどうやら ^H ^J ^K ^L に割り当てられていた。 vi かよw そういえばこのおかげでローグクローンをカーソルキーでプレイできたんだっけな。 この方式の欠点は左カーソルキーとバックスペースの区別が付かないところだ。 上の p を使うエスケープシーケンスは標準じゃないので ANSI.SYS 以外では使えなかったんじゃないかな。
DOS 汎用アプリケーションでも日本では IBM 方式の NUL 文字を使用するカーソルキー表現に対応しているものは少なかったような気がする。
Unix では ESC [ A みたいなのが当たり前になっているから DOS もみんなそうしていたら良かったんだよね。
でも DOS には ESC 入力で行削除的な機能もあったから、難しかったのかもなぁ。
晴れ。 のんびり。
MS-DOS のソースコードの中から DEBUG.COM のビルドは先月やったが、他のプログラムもビルドしてみようと思った。 が、とにかくコマンドを手で入れるのは面倒くさい。 MAKE コマンドがあればいいんだが...
で、手抜きの簡易 MAKE 的なものを作った。 MAKEFILE を読むのではなくて、引数に出力ファイルとソースファイル群を並べて、アセンブル、リンクと、必要に応じて EXE2BIN をやるってわけ。 これがなかなか面倒くさい。 MASM で書くからなんだがw DOS の Exec システムコールって EXE ファイルからならメモリーサイズの縮小の必要はないのかと思っていたけど、いざ書いてみたらだめだったので必要らしいw それに Exec システムコールの後はスタックポインターすら保持されないってどういうことやねんw スタックポインターをグローバル変数に保存してから実行するしかないのかw デバッグにも手こずった。 まぁちゃちなデバッガーである DEBUG.COM でもあるとないとでは大違いだけどね!
あと、INCLUDE まで考慮していないので、これだけではだめパターンが結構ある。 うーん、何時間も掛けて作った割にはいまいちか?
作っている時に発覚したのが、当時の MASM (バージョン 1.10), なんと、エラーになっても ERRORLEVEL 0 で終了しやがるw しかもエラーでも出力ファイルが中途半端に作られているw これじゃあエラーになっても止められないじゃないか、なんて実装なんだw
んで DOSBox で試していたんだけど、いざいろいろ試してみると MASM が *Out Of Memory* エラーを出すケースが出てきた。
その独自 MAKE ツールが COMSPEC (COMMAND.COM) 経由で子プロセスを起動するせいでメモリーが足りないのか?
厳しいな!
と思ってソースコードの一部を分割してエラーが出なくなったことを確認したが、何やらいろいろ面倒で...
CHKDSK.COM をビルドするのに、DOSSYM.ASM には必要な定義が含まれておらず、DOSSYM_v211.ASM を使う必要がある。
んで、じゃあ DOSSYM.ASM を置き換えればいいかなと思ったら、今度は DEBUG.COM のビルドに失敗する...
ウーン...
ふと、FreeDOS でやったらどうなるんだろうと思って試してみた。 FreeDOS のフロッピーディスクのイメージをダウンロードしてきて、QEMU で一枚目で起動して言語選択、Y/N のところを N にしたらプロンプトに落ちる。 ここで FDISK, FORMAT 等のコマンドは使えるので仮想 HDD にシステムを転送、それから mtools で仮想 HDD にファイルをまとめてぶち込んで、起動して実験してみたところ、MASM のエラーは出なかった。 フーン。
何より QEMU なら Linux KVM が使えるのでめちゃくちゃ速い。 DOSBox はスピード調整ができるけど、基本遅いプロセッサのエミュレーションなので遅いんだな。 ただし仮想 HDD になるのでファイルの編集なんかが面倒くさい。 お手軽 DOS 互換環境としては、昔は dosemu っていうのも使っていたんだけど、これは Debian 公式パッケージがなくなっちゃったんだよな。
午前中ちょっとお腹が緩かったので、お昼を自炊にした。 幸いお昼以降は特に問題なかった。 お昼も特にお腹に優しい食事にしたわけではない。
きのうの F1 はオランダ GP か。 観客がだいぶアレw 発煙筒を投げ込むんじゃない! フェラーリはいつも通りのやらかしっぷり。 何というかライコネンがいた時以上にひどくなっているような... やっぱりライコネンはフェラーリチャンピオンってのがスタッフの意識にも響いていたのかなw メルセデス勢の追い上げが見物だったが、角田が止まってバーチャルセーフティカー、さらにはボッタスがメインストレートで止まってしまってのセーフティカーは本当にタイミングが悪かった。 まぁーセーフティカー無くてもフェルスタッペンが鬼の追い上げを見せて優勝していただろうとは思うが、その鬼の追い上げすら見られなくなったのは本当に残念だった。 というか、ペレスはピットイン後にセーフティカーになっちゃったんだっけな? 運が悪ければフェルスタッペンもそういうタイミングになっていた可能性もあるんだよな。
QEMU 上の FreeDOS でもっといろいろアセンブルしてみようと思っていろいろやってみていたんだが、MASM が internal error を吐いたり、ハングしたりする... やっぱりメモリー不足か? FreeDOS の拡張メモリー系を組み込み空きメモリーをたっぷりにして試してもだめだった。 んんー!
CHKDSK はビルドできたが DOS 2.x 上じゃないと動かないようにチェックがあるみたいで動作確認ができていない。 DISKCOPY はビルドできたがコピーの確認はしていない。 EDLIN もビルドできたがファイルを開いてみてはいない。 EXE2BIN はビルドできて使えていそうな感じがする。
MASM がうまくいかないファイルもそんなに大きい感じには見えないんだけど、マクロを多用しているかも知れない。 まぁ、マクロかシンボルか、だよな、おそらくメモリー上にいろいろ積みすぎてあふれてしまっているんだろう。 たぶん新しいバージョンの MASM ならうまくいくんだろうけど、ここはこの 1.10 で何とか通るようにしてみたいよなぁ。 MASM は自分で作るにはだいぶやっかいな高級アセンブラーなので、なるべくそのまま使えたらうれしい。
朝ちょっと雨降ったっけ? 少し生ぬるい強めの風が吹いていた。
先月ぽろりすの 2000 年問題対策みたいなことを書いたが、なぁんと、作者様が昨年対応済みとの情報を頂いた。
PC98版の☆ぽろりす☆のY2K問題対応版をリリースしました(Version 1.57) | KTKR雑記
当時の環境を捨ててしまっていると再コンパイルは苦労するだろうなぁ。 だからといって機械語で直接パッチを当てるのも限界ってもんがあるんだが...
MASM のエラー、internal error が出たり、変なぐしゃぐしゃが表示されて終了したり、仮想 8086 メモリードライバーが例外検知のメッセージを出したり、ハングしたりと、明らかに挙動がおかしいパターンについて調べていくと、IFIDN または IFDIF が使われているとそうなることがわかった。
これは文字列比較のディレクティブらしくてマクロに渡された引数を識別している部分だが、ディレクティブそのものがエラーになるのではなく、異常動作をするというのは MASM Version 1.10 にそういうバグがあったのかな。
対策として、このディレクティブを使うのをやめて、文字列連結 (& でマクロの引数とつなげることができた) でシンボル参照して IFDEF と IF による比較に変更したところ、その異常動作はなくなった。
で、メモリー不足はかなり発生しやすく、単純にアセンブルしていくのは難しい。
何が問題か?
Out of memory で終了後 QEMU の pmemsave コマンドを使ってメモリーの内容をファイルに書き出して、中身を眺めてみたところ、ソースコードのキーワードが出てくるような領域は 64KiB ぐらいしかない。
後ろにメモリーは余っているが、別セグメントまで使う実装はまだ MASM Version 1.10 には入っていなかったのかも知れない。
メモリーを見るとインクルードされている DOSSYM に含まれる各シンボル名が異様に長く、これがメモリーを圧迫している気配だ。
明らかにカーネルでしか使わないであろうシステムコール絡みの構造体の定義などもあり、40 年前の実装にしてはアセンブル環境に求められるリソースがなかなか富豪的である。
これの対策は不必要な部分を除外できるように書き換えることかなと思っているが、それで十分かは怪しい気もする。
どうしても通せないようであれば、インクルード (INCLUDE) を展開の上で、エクスポート (PUBLIC) しないシンボル類を短いシンボルに置き換えたり、不必要なシンボル定義を削除したり、簡単な EQU 定義は先に展開してしまったりするプリプロセッサが必要かも知れない。
昼はまだ晴れていたが蒸し暑かった。 夜は雨になったっぽい。
座骨神経痛は今でも出ることがあるが、ごまかしがうまくいっているのでこれはもう大丈夫そうかな。 腰付近をもんだりさすったりする感じで。 頸椎のほうもたまに調子悪いけど、肩の位置を意識するごまかしはうまくいっている。 肩こりがひどいときは葛根湯を飲む時もあるけど、痛み止めは飲んでいない。
メモリーの中身をもう一度見直すと、STRUC (構造体) のメンバーがずいぶん容量を食っている感じがする。
メンバーひとつで 40 バイトぐらいの勢いだ。
EQU も数が多いし名前が長いのでアレだが、メモリー上では詰まっているところも結構ある。
手としては手作業か自動のプリプロセッサか。
手作業では不必要な STRUC 定義を排除するというのがひとつ、EQU も頻繁に使われるものとそうでないものがあるのは確かなので、うまく IF で分けてそれでアセンブルが通るならうれしい。
プリプロセッサとする場合は、INCLUDE を展開した上でシンボル名を短いものに振り替えるというのがひとつ、さらに EQU の分は完全に独自で置換してしまう手もある。
数が数百個あって多いので EQU の大部分がなくなるだけでもききそうではあるが、STRUC があれだけメモリーを食っていたことを考えるとな...
MS-DOS のファイルの更新日時を読み取るシステムコールは %cx と %dx のふたつのレジスターに日時を返す仕組み。 これは FAT の書式をそのまま持ってきている模様で、年は 1980 を引いて 7 ビット、月が 4 ビットで日が 5 ビットだ。 それに時が 5 ビット、分が 6 ビット、秒は 1/2 して 5 ビットという形。
それに対して現在の日時のアクセスは日付と時刻が別々のシステムコールになっており、8 ビットあるいは 16 ビットのレジスターを使ってシンプルに返してくれる。 1980 年以降の縛りもない。 返そうと思えば閏秒さえ返せてしまえそうな、ある意味現代的なインターフェイスになっている。 ただし、日付と時刻が別々というのは、日付の変わり目に取得したらどっちだよってことになり面倒である。 某 C のランタイムライブラリはどうやら日付の取得を 2 回呼び出すようだ。 詳しくは見ていないが、標準 C ライブラリの日時管理は 1970 年 1 月 1 日からの秒数なので、アプリケーションが日付を求めるかどうかにかかわらず、日付と時刻を取得して秒数に変換するしかないわけで、それが 1 日ズレたら致命的だから、対策をしてあるんだろう。
それ以外に CLOCK デバイスファイルも存在するが、こっちは 6 バイトで日付と時刻を表す。
それが、1980 年 1 月 1 日からの日数 (16 ビット), 分 (8 ビット), 時 (8 ビット), 1/100 秒 (8 ビット), 秒 (8 ビット) の 6 バイトとなっていて、どうしてここは日数にしたんだろうか。
まぁ日数でも 16 ビットあるので、Unix 時間が秒で 32 ビットだったのに比べればずいぶん未来まで表現できはするんだけど、PC/AT 互換機の RTC って年月日の BCD 仕様になっているから変換が必要だし、システムコールではこれをまた年月日に分解すると思うとちょっと微妙なインターフェイスである。
雨ちょっと降った? 涼しい日。
スマートフォン Android One S6 なんだけど、開発者オプションでタップ位置を表示にしていてわかったことがあって、スリープ状態から電源ボタンなり指紋認証なりで画面を表示させた後、一発目のタップ位置がめちゃくちゃな位置になっているみたいだ。 前からそうだったかわからないけど、今はそうなっている。 あと Android 12 になってから ZXing の QR コードスキャナーアプリでなぜかオートフォーカスが働かない。 あと画面の左上が変色していて、落っことした時か何かに液晶にダメージが入ったのかも知れないけど、変色部位が広がっていく様子はない。 ソフトウェアアップデートはもう来ないんだろうしー、と思ってチェックしたら 5.230BE が来ていた。 あれ?? そろそろ最後かな? いや、発売から 3 年はまだ経っていないからもう少しあるのか。
ZXing のオートフォーカス問題は、追従フォーカスしないという設定を外したらなおった。 オートフォーカスの設定は別にあってそっちは有効にしてあったんだけど。 いつの間にかこの設定がオンになっていたのか、それとも、以前のバージョンではオンのままでも問題なかったのか。 わからん。
bcc っていう C コンパイラー、Debian パッケージもあって DOS 用の C ライブラリ elks-libc もあり、.COM 形式のプログラムは簡単に作れる。 MASM のプリプロセッサを試しに作ってみるならこれがいいか。
この前の F2 オランダ戦を見たら、Feature Race で岩佐が 3 位! はともかく、セーフティカー開けにひどい多重クラッシュが発生していた。 加速を遅らせると後方が混乱するの、去年 F1 でもあったな... あそこまでひどい速度差があったわけではなかったが、別々の場所で 2 台が追突していたように見えた。
それで知ったけど今の F2 はセーフティカー中のタイヤ交換はタイヤ交換義務を消化した扱いにはならないらしい。 ハードタイヤスタートが不利だよな、それって... いや、ソフトタイヤスタートでもそろそろピットインって頃にセーフティカー入られるとつらいか。 セーフティカー中のピットインの扱いは本当にどのやり方も一長一短で難しいよなぁ。 バーチャルセーフティカーやフルコースイエローのやり方のほうが不公平さは少ない感じがするんだけど、スピードを何分の一に落とす的な制限のかけ方の場合は結局ストレートのスピードはそこそこ速いので、この前の F1 オランダ GP みたいにメインストレートで止まったマシンがあるとまず使えないし。
晴れ!
ニトリでこの前買った携帯扇風機 HF3103、扇風機そのものはいいんだけど、バッテリーからの出力を切ることができない仕様で、減りが早い気がする。 電源マークのボタンが付いているけど、押すと残量が光るのみ。 押しても扇風機を止めることはできないし、押さなくても扇風機が起動できるということは... そもそもは最初フル充電にして少し試した後何もつながずに放っておいたら 1 週間ちょっとぐらいでスッカラカンになっていたというところ。 再度充電して何度か扇風機で使っているが、やっぱり使っていない間に残量が減っているような気がする。 常時 5V をかけているんだとしたら、そりゃ減るよな... eneloop モバイルバッテリー KBC-L2A が全然減らないのとは対照的。
テレビでやってた映画『るろうに剣心 伝説の最期編』。 2014 年の邦画。 映画館で見た映画。 奥義を使って志々雄を... というところ、去年テレビアニメ版を見たこともあって、あまりの違いに驚きもある。 テレビアニメ版は 15 分のたたかいを何話もかけてやるのでその点は映画のほうが引き延ばしがなくすっきりしている。 あとテレビアニメ版では漫画っぽいあまりにも非現実的な技表現がそのまま持ち込まれていたが、実写映画はうまいこと普通の剣術のように見せているのは良い。 高く飛び上がったり刀が燃えたりといった漫画っぽさをちょこちょこ取り入れつつ、技名を叫んで画面がチカチカして決着とか目に見えぬ速さで移動とかみたいなテレビアニメ的表現は避けている感じでバランスがいいよね。 技名だけじゃなくて、全体的に説明調でないのもいいところかも知れない。
bcc でプリプロセッサを書いてみた。
STRUC と EQU のシンボルに関して、前者は 5 文字以上、後者は 8 文字以上に関して、4 文字のシンボルに置換するというもの。
何度かデバッグの後、bcc が struct の値渡しをうまく扱えないようだというバグっぽいのにも遭遇しつつも、動くようになったので MSDOS.ASM を食わせたら、やっぱり MASM は out of memory だと。
そもそもシンボル多すぎなんだろうなぁこれ。
EQU の展開までやるしかないかなぁ。
でも一部 EQU は微妙に IF の影響があってトリッキーだ。
STRUC も不要なものは削るようにすべきか。