1匹の犬とWindows 3.1グラフィックスタックの対決

 (wuffs.org)
2 ポイント 投稿者 GN⁺ 2025-01-06 | 1件のコメント | WhatsAppで共有
  • 2008年製の Asus Eee PC 1000H で Windows 3.11 を 1024x600 画面に合わせて使おうとしたところ、標準 VGA と Microsoft 256色 Super VGA ドライバーの限界が明らかになった
  • Windows 3.x の Super VGA 対応は共通標準ではなく、カードごとの独自拡張に合わせた仕組みであり、Eee PC の Intel GMA 950 は対応対象ではなかった
  • SVGAPatch は Microsoft の svga256.drv を VBE 呼び出しベースに書き換えて高解像度 256色出力を可能にするが、DOS 画面切り替え後に GUI が壊れる問題が残っていた
  • 逆アセンブルの結果、初期モード設定は VBE に置き換わっていたが、画面切り替え時の再設定経路は依然として Tseng ET4000 用のモード 30h と text mode 状態での VBE scan line 設定を呼んでいた
  • 追加パッチによりフルスクリーン DOS セッションから GUI に戻る際の破損は減ったが、bank switching の状態までは完全に解決されず、実機の Eee PC では GUI とウィンドウモードの復帰が可能な水準にとどまった

Eee PCでWindows 3.11のグラフィックスを復活させる

  • 対象機器は 2008 年に購入した Asus Eee PC 1000H で、x86_64 非対応のため最新の Linux ディストリビューションの多くも動かしにくい状態だった
  • 目標はこのネットブックで Windows 3.11 for Workgroups をより良いビデオ出力で動かすことだった
  • 標準出力は VGA 640x480 16色 なので、1024x600 画面では見栄えが悪くアスペクト比も合わない
  • Windows 3.11 のセットアップには古いビデオアダプター向けドライバーが含まれているが、Eee PC の Intel GMA 950 には対応していない
  • 同梱の Super VGA ドライバーは最大 1024x768 256色対応のように見えるが、この環境ではエラーになって Windows が起動しない

VGA、SVGA、VBEの違い

  • VGA は 1980 年代に IBM が設計した特定のビデオコントローラーであり、単に青いアナログコネクターや 640x480 解像度を意味するものではない
  • SVGA は標準というより「基本 VGA より進んだもの」をまとめて呼ぶ用語に近く、ソフトウェア側が各カードの独自拡張を直接サポートする必要があった
  • Microsoft の 256色 SVGA ドライバーの対応一覧には次の系列が含まれている
    • ATI VGA series
    • Cirrus Logic VGA
    • Oak Technology VGA
    • Paradise VGA
    • Trident VGA
    • Tseng VGA
    • Video Seven VGA
    • Western Digital VGA
  • VBE(VESA BIOS Extensions) は VGA 以外の機能を共通インターフェースで扱えるようにするが、Windows 3.x には直接的な VBE ドライバーが含まれていなかった
  • BearWindows の VBE9x と VBEMP はそれぞれ Windows 9x と NT で VBE を使えるようにするが、Windows 3.x 版は存在しない

SVGAPatchが解決したことと残したこと

  • SVGAPatch は Microsoft の 256色 Super VGA ドライバーにパッチを当てて VBE を使えるようにする
  • パッチ済みドライバーは 1024x600 のような画面を正しく表示できるが、DOS 互換性では衝突が発生する
  • Windows 3.1 Enhanced Mode ではグラフィカルな Windows アプリと DOS アプリケーションを同時に実行でき、DOS プロンプトもウィンドウまたはフルスクリーンで開ける
  • SVGAPatch 適用後、次の問題が再現した
    • フルスクリーン DOS モードに入ってから Windows GUI に戻ると画面が壊れる
    • 場合によってはウィンドウモードの DOS プロンプトを開くだけでも画面が壊れる
    • DOSBox、86Box、実機の Eee PC のいずれでも再現するが、壊れ方は少しずつ異なる
  • 別の新規ドライバー PluMGMK/vbesvga.drv はトゥルーカラーモードまで対応するが、ここでは Microsoft のコードと SVGAPatch を修正する方向で解析が進められた

Windows 3.xグラフィックスタックの構造

  • Windows 3.x Enhanced Mode は 32 ビット保護モードの Virtual Machine Manager が複数の VM を作り、その最初の VM 内で Standard mode Windows が実行される構造になっている
  • Windows Setup でビデオアダプターを選ぶと、単一ドライバーではなく複数の構成要素が一緒にインストールされる
    • Grabber: ウィンドウモード DOS アプリの描画を担当するとみられる
    • Display Driver: 主 Windows VM 内でハードウェア初期化と GUI 描画を担当し、Windows 3.x では GDI のかなりの部分も自前実装している
    • Virtual Display Device(VDD): Virtual Machine Manager の一部として動作し、DOS アプリと実際の VGA ハードウェアの間を多重化する
  • 256色 SVGA 項目は同じドライバーを使い、SYSTEM.INI の解像度と DPI 設定で区別される
  • SVGAPatch は Display Driver だけを修正し、SVGA VDD には手を付けない
  • 結局、Display Driver、VDD、SVGAPatch が作った非公開変更を合わせて理解する必要があり、そこで初めて画面破損の原因を絞り込めた

逆解析に使った資料とツール

  • 参考資料として Windows 3.x VDDVGA と Windows 3.1 DDK を使用した
  • Windows 3.1 DDK には次のソースが含まれている
    • VGA、IBM 8514、Video 7、16色 SVGA の Display Driver ソース
    • VGA、IBM 8514、Video 7、16色 SVGA の VDD ソース
    • ほぼすべての Grabber ソース
    • ごく少ないドキュメント
  • しかし必要だった 256色 SVGA Display Driver と関連 VDD のソースは含まれていなかった
  • svga256.drv と vddsvga.386 の解析には IDA と Ghidra を使った
  • Ghidra は .drv は読めたが、VDD は VxD なので別途 LX loader が必要で、32 ビットコードと 16 ビットコードが混在するファイルを扱うには制約があった

svga256.drv 内部解析

  • svga256.drv には GETCHARWIDTH, STRETCHBLT, VIDEOINIT_ATI などの export 関数があり、DDK ソースと照合できた
  • 一部の関数は VGA ドライバーのソースとほぼ同じだったが、GETCHARWIDTH のように bold font 幅補正機能が抜けている差異もあった
  • REALIZEOBJECT では VGA ドライバーと Video 7 ドライバーのコードが混ざっているような違いが見られ、色処理ロジックも異なっていた
  • GDI 関数だけではビデオアダプターとの相互作用を説明しきれず、初期化経路である physical_enable の解析へ進むことになった

physical_enableとMicrosoft SVGAドライバーの方式

  • Windows Setup で “Super VGA (800x600, 256 colours, small fonts)” を選ぶと SYSTEM.INI に次の値が入る
    • dpi=96
    • resolution=2
  • パッチ済みドライバーは起動後にさらに次の値を書き込む
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable はビデオモードを設定し、対応モード一覧を走査して動作するチップセット別モードを探す中核の初期化関数である
  • Microsoft の元のロジックは解像度ごとの対応モードテーブルを持ち、SetAndValidateMode で各モードを試す
  • 成功するとチップセット別初期化関数や bank 設定関数などを探して呼び出し、パレット設定、フレームバッファ初期化、VDD アドレス設定まで進む

SVGAPatchの実際の変更

  • SVGAPatch は 3 つの解像度一覧で先頭のチップセット項目の関数 ID を 2000 に変え、SetAndValidateMode と一部のチップセット別関数を上書きする
  • 主要な変更点は次のとおり
    • SetAndValidateMode: 従来の VGA BIOS ベースのモード設定の代わりに VBE 4F02h で拡張ビデオモードを要求する
    • SETBANK_TRIDENT: Trident 専用レジスター書き込みの代わりに VBE 4F05h でビデオメモリウィンドウを切り替える
    • VIDEOINIT_TRIDENT: VGA CRTC Offset Register への書き込みの代わりに VBE 4F06h で scan line 長を設定する
  • パッチ後は対応モード一覧の先頭項目が成功し、関数 ID 2000 に結び付けられた書き換え関数群が使われる
  • SYSTEM.INI に Tseng ET4000 値が書かれるのは、値自体は実際には使われなくても一覧先頭項目の名前がそのまま保存されるためである

VDDとDspDrvr_Addresses

  • VDD は DOS プログラムが実ハードウェアを専有していると期待する状況を仮想化で処理する
  • 各 VM は VDD_CB_Struc 構造体インスタンスを持ち、この構造体にはフラグ、VGA コントローラー状態のミラー、VM ごとのビデオメモリ割り当て情報が入っている
  • VDD には特定の VGA アダプターを検出し、特定レジスターの保存・復元・シミュレーション方法を変えるベンダー別コードが存在する
  • DspDrvr_Addresses は Display Driver が VDD にアドレス情報を渡すサービスで、コメント上では DX は予約フィールドなので 0 であるべきだが、実際の VGA VDD コードには DX が 0 でない場合の特別動作がある
  • SVGA VDD には DX == 2 のときの新しい経路があり、SVGA256.DRV はこの関数を次の値で呼び出す
    • BX = 0xFFFF
    • DX = 2
    • DS:SI は shadow memory status バイトを指す

DOSBox-Xで原因を絞り込む

  • DOSBox-X の Video debug overlay とデバッガーを使い、フルスクリーン DOS プロンプト切り替え前後の VGA 状態を比較した
  • 正常 GUI、正常 DOS、壊れた GUI、壊れた DOS の各状態で表示されるモード注釈とレジスター状態が異なっていた
  • vendor-specific VDD フラグが誤って有効になるか確認するため DOSBox-X を改造して物理メモリをダンプしたが、DOSBox ではそのフラグは立っていなかった
  • VGA レジスターを比較すると、DOSBox 内部の scan_len 値が正常状態と破損状態で異なっていた
    • 正常 DOS では 40
    • 壊れた DOS では 296
    • 正常 GUI では 128
    • 壊れた GUI では 256
  • DOSBox の VESA Scan Line API 実装は現在のビデオモード判定に応じて scan_len を異なる形で計算しており、この点が主要な疑いの対象として絞り込まれた

決定的な手がかり: text modeでのVBE scan line設定

  • DOSBox-X に VESA scan line 設定ログを追加すると、次の呼び出しが捕捉された
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • 現在のモードは M_TEXT
  • Display Driver は VBE 4F06h で scan line 長を 1024 バイトに設定するが、DOSBox は現在を text mode と見なしているため内部状態の計算が誤ってしまう
  • Windows 起動時には 800x600 SVGA と M_LIN8 状態で scan line 設定が正常に行われる
  • フルスクリーン DOS プロンプトを開き、Alt+Enter で GUI に戻ると次の流れになる
    • あるコードがモード 30h、すなわち 10 進 48 への切り替えを要求する
    • patched display driver が text mode 状態で scan line 長を設定する
    • DOSBox 内部状態と VGA レジスター由来の状態が食い違う
  • モード 30h は SVGAPatch が hijack した Tseng ET4000 の 800x600 用モード値だった

見落とされていた画面切り替え経路

  • Windows 3.1 Display Driver は INT 2Fh を hook して画面切り替え命令を受け取る
  • VGA ドライバーは次の 4 命令を扱うが、SVGA256 ドライバーは SCREEN_SWITCH_OUT と SCREEN_SWITCH_IN しかサポートしていない
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • 問題の関数は Windows GUI に戻る際に呼ばれる dev_to_foreground だった
  • SVGA256 の dev_to_foreground は次の流れで動作する
    • farsetmode を呼ぶ
    • farsetmode がモード 48 を設定する
    • チップセット別 VideoInit を呼ぶ
    • enabled_flag を 0xFF に設定する
    • Windows API SetPalette を呼ぶ
  • SVGAPatch は初期化時のモード設定経路を VBE に変えたが、画面切り替え時に再びモード設定を行う経路は変更していなかった

追加パッチによるGUI復旧の改善

  • 元の setmode コードは wGraphicsMode を ax に入れて INT 10h を呼び、その後 ptr_videoinit を呼ぶだけの短い構造だった
  • SVGAPatch が短くした SetAndValidateMode の後ろに余っていた空間へ新しいコードを挿入した
    • CurrentHeight から 1 を引いた値を cx に入れる
    • SetAndValidateMode を呼ぶ
    • ptr_videoinit を呼ぶ
  • setmode の最初の命令を新コードへジャンプするように変え、画面切り替え時にも VBE ベースのモード設定経路を通るようにした
  • この修正後はフルスクリーン DOS セッションに入ってから GUI に戻っても、画面はもはや壊れなくなった
  • ただしウィンドウモードからフルスクリーンへ移る際に点が再び現れる問題は残った

残るbank switchingの問題

  • DOSBox デバッガーで B8000 VGA メモリを見ると、テキスト内容は存在するのに画面には表示されていなかった
  • 疑わしい箇所は、ドライバーがより多くのビデオメモリにアクセスするために使う bank switching だった
  • DOSBox-X に SVGA bank 状態を出力するコマンドを追加すると、フルスクリーンに戻るとき VGA アダプターが誤った bank に留まっていることが確認できた
  • dev_to_background で bank を 0 に戻そうとする新しいルーチンを入れたが、問題は直らなかった
  • DOSBox の VBE 4F05h 実装は VGA CRTC レジスター 0x6A に書き込む方式で、dev_to_background が呼ばれる時点では既に VDD が書き込みを trap している状態なので遅すぎた

元ドライバーとパッチドライバーの実験結果

  • 86Box で Microsoft 元版の SVGA 256色ドライバーを複数のエミュレートカードで試した結果、対応一覧内でも結果は一様ではなかった
    • Cirrus Logic GD5420 (ISA): 動作する
    • Tseng Labs ET4000AX: 動作する
    • Oak OTI-077: 初回のウィンドウモード DOS プロンプト起動時に画面破損、フルスクリーンでは縦線が出る
    • Trident TVGA 8900D: フルスクリーン DOS プロンプトで画面破損、ウィンドウモードは正常
    • ATI VGA Wonder XL、Paradise PVGA1A、Video 7 VGA 1024i の一部解像度では Windows 起動に失敗
  • 86Box はまったく同じカードを提供しているわけではなく、エミュレーション精度も確実とは言えないという留保がある
  • 修正した SVGAPatch ベースのドライバーをより新しいカードで試した結果もカードごとに異なっていた
    • Matrox Millennium II: 非常に遅く、ウィンドウモード DOS は動くがフルスクリーンは壊れる
    • 3dfx Voodoo Banshee: ウィンドウモード DOS を開くと GUI が壊れるが、フルスクリーン切り替えは動作する
    • S3 Trio3D/2X: Windows 起動時に壊れた画面が出るが、DOS プロンプト後にフルスクリーンを抜けると 1024x768 が正常表示される
    • 3dfx Voodoo3 3500 SI: Banshee に似ているが、フルスクリーンは 1 回しか動作しない

Eee PCでの最終状態

  • 実機の Eee PC では GUI は正常に動作する
  • フルスクリーン DOS プロンプト切り替えは依然として壊れるが、DOSBox とは異なる形で現れる
  • DOSBox では壊れた文字の多い text mode が現れ、Eee PC では一部の色が失われた壊れた GUI が表示された
  • ウィンドウモードに戻せば復旧可能である
  • 元の SVGAPatch はウィンドウモードのプロンプトを開いただけでも GUI 全体が壊れて OS の再起動が必要だったが、修正したドライバーはそれより大きく改善された
  • より良い解決策としては、活発に開発が続いている PluMGMK/vbesvga.drv を今後も追いかけることにした

関連記事

1件のコメント

 
GN⁺ 2025-01-06
Hacker News のコメント

  • SVGA 対応はさておき、最新規格に対応した PC に Windows 3.x を入れると標準 VGA がすぐ動くのに、現代の Linux/BSD では適切なドライバーと手動の設定ファイルなしには、Xorg/Wayland で基本的なソフトウェアアクセラレーションの VGA フレームバッファすら簡単には使えないのが、いつも驚き
    すでに終わった XFree86 プロジェクトが、こうした「そのまま動く」に最も近い試みだったが、まだ道半ばで、そのアプローチは Xorg のフォークには保存されなかったように思う

    • XFree86 もここでは Xorg と違うことはしていなかった
      最新 PC で CSM から起動すると、推奨はできないが、Xorg が x86emu でビデオ BIOS を実行して VBE バックエンドで立ち上がるはずで、EFI で起動すると、ファームウェアとブートローダーが残したモード上で efifb ベースの modesetting が立ち上がるはず
      ただし、これは 16 ビットや 32 ビットの OS のほうが簡単な作業。VESA のモード設定にはリアルモードの 16 ビット呼び出しが必要で、標準の後期には 32 ビットのエントリーポイントが名目上はあったものの、きちんと実装したところはほとんどない。64 ビットモードに入ると vm86 が使えず、ユーザー空間から 16 ビットコードを呼び出せない。そのため、ビデオ BIOS コードを読んで x86 エミュレーター上で実行する x86emu が必要になるが、常に完璧というわけではない
    • Linux には vgafb/vesafb があるので、ディストリビューションが適切に設定されていれば可能
      ただし通常は性能も品質も低い体験になり、ユーザーは原因が分からないかもしれないので、一部または大半のディストリビューションはデフォルトで有効にしていないようだ。今ではほぼすべての GPU がネイティブにサポートされているため、「アクセラレーションなしの VGA/VESA を使っているので直してください」というポップアップを作る動機もなかったのだろう
    • ずいぶん昔の話だが、X には「そのまま動く」汎用 VGA ドライバーがあったと記憶している。今はそれがないという意味？
    • X11 にはかなり昔から VESA ドライバーがあったが、処理するピクセル数が解像度とともに急速に増えるため、性能面でのスケーリングが悪い
      仕事で使う起動可能な Linux ディストリビューション、主に GRML と Clonezilla は、KMS 対応によって起動中の画面や仮想 KVM のネイティブ解像度に自動で合わせられ、かなりよく動く。Anaconda、つまり RedHat 系のインストーラーや Debian インストーラーも、起動時にネイティブ解像度へ調整される
      GUI インストーラーは X11 上で VESA を直接使う
      Xorg のフォークも、かなり前から「設定ファイルなしの起動」をサポートしている。もうずいぶん前から設定ファイルを管理しておらず、そのほうがずっと満足度が高い。https://www.xkcd.com/963/ 参照
    • Xorg は、ビルドシステムを整理した XFree86 に近いと思う

  • 昔の Windows 3.1 GUI は、今のものよりずっと直感的で効率的で、使いやすそうに見える
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    本文のような低解像度の画面で Win11 はいったいどう見えるのだろう？ Win11 のスタートメニューは、キーワードを入力してから回路に祈ること以外にはほとんど使いものにならない
    素朴な仮説としては、Windows NT と 2000 が最適点で、その後はプロダクトマネージャーたちが魔法をかけ続けてきたのだと思う。KDE と Gnome はあまり変わっていないが、時間がたつほど魅力的に見える :)

    • 最後の「良い」バージョンは Windows 7 だと思う。NT/2000 に似ているが、グラフィックハードウェアの向上のおかげでより見栄えがよく、その前の XP も同様だった。Vista も UI 自体は悪くなく、欠陥は別のところにあった
      Windows 8 がすべてを壊し、Windows は立ち直れなかった。理由はモバイルプラットフォームの台頭と Microsoft の怠慢の 2 つだと思う
      今では、多くのアプリがデスクトップ版とモバイル版を別々に持つという、解きにくい問題が生まれている。一方は大画面とキーボード・マウス、もう一方は小さなタッチスクリーンなので、優れたデスクトップアプリと優れたモバイルアプリは完全に違うべきだ。しかし、ユーザーには両バージョンをなじみやすく感じてほしいため、最善を尽くしても妥協が生じる
      Microsoft ならそれでもうまくやれたはずだが、そうしなかった。コントロールパネルを見れば明らか。新しいコントロールパネルである設定は Windows 8 の頃から、12 年前から存在しているのに、いまだに従来のコントロールパネルの全機能を移行できず、両方が必要なまま。数か月前に完全移行を試みようとしたが準備ができておらず、今後できるのかも分からない。さらに、人気のあるカスタマイズオプションを頻繁に削除し、同梱アプリ間のスタイルも一貫していない。これは議論の余地がある程度ではなく、客観的に悪い
      Microsoft と Windows だけを責められないもう 1 つの要因は、アプリ開発者が OS 統合よりもブランディングと内部一貫性を優先している点。多くの現代的な UI は Electron のようなブラウザーエンジンでレンダリングした Web ページにすぎず、ネイティブの OS コントロールを使わず、テーマを無視し、ウィンドウ装飾も自前で描く。OS が一貫していないことはあり得るが、アプリ開発者たちも助けになっていない
    • フラットデザインは業界にとってほとんど災厄だった。スキューモーフィズムも実質的には絵を貼り付けたフラットデザインなので、かなり微妙だった
      Windows Forms は多くのことを正しくやっており、欠けていた記号を 1 つ挙げるなら「アクティブだが編集不可」くらいだったと思う
    • 伝え聞くところでは、Windows 11 はもともと携帯電話やタブレット向けにも作られていた Windows 10X だったという。スタートメニューには、インストール済みのものをすべてフラットに表示し、検索をより促す Android の影響がかなり見える
      それでも同意する。Win10 ベータにはタイルと Windows 7 風のリストを混ぜた形があり、これは Windows 2000 まで続く方式なので、それが頂点だったと思う。両方の長所を持てたはずだ。通知領域はずっと弱く、設定パネルはコントロールパネルに比べてひどい。もちろんコントロールパネルも雑然として複雑なので、最善だったかどうかは議論の余地がある

  • 筆者は DOS プロンプトをウィンドウモードで開くと画面が壊れると述べていたが、これは DOS プロンプトが別 VM、つまり V86 モードで実行され、INT 10h で VGA ROM BIOS を呼び出すために起きる可能性がある
    この機器の VGA ROM BIOS はおそらく VBE の上のラッパーである可能性が高く、つまり VBE I/O ポートである 0x1CE と 0x1CF にアクセスする IN/OUT 命令を含んでいたはず。DOS VM で発生したこうした読み書きは、VMM が仮想化しない限り、基本的には実ハードウェアまで到達する
    これは Windows 3.x/9x のディスプレイドライバ作者が対処しなければならなかった一般的な問題だったが、仮想化すべき I/O ポート番号はグラフィックアダプタごとに異なっていた。Win95 DDK には、VMM サービスである Install_IO_Handler と Enable/Disable_Global_Trapping で I/O ポートトラップを設定し、トラップハンドラ内で VDD_Get_VM_Info により現在 CRTC を所有している VM を判断する例がある。これにより、トラップハンドラは I/O をハードウェアへ送るか、どのように仮想化するかを決定できる。出発点として良い仮想化ポリシーは、CRTC 所有者ではない VM からの書き込みを単に捨てることで、必要な複雑さはその後に追加すればよい

  • Virtual Display Device（VDD） は基盤となる仮想マシンマネージャの一部として実行され、ビデオハードウェア用のマルチプレクサのように動作する。DOS アプリが全画面なら命令は「本物の」VGA アダプタへ直接渡され、そうでなければ VDD がエミュレートする
    こうした構造を他の人たちが再発見するのは興味深い。個人的には、ハードウェアパススルーを備えた現代のハイパーバイザよりも前にあった、かなり時代を先取りした構造だったと思う。プリエンプティブなマルチタスクプロセスを含む Windows 3.x GUI 自体が、実質的には DOS が動く VM の中で拡張保護モードの DOS プロセスとして実行され、ハイパーバイザカーネルである VMM32 がそれと他の DOS プロセス VM の間を多重化する。なのでディスプレイドライバの一部は GDI の下で「ハードウェア」とやり取りし、別の部分はリング 0 でハードウェアを仮想化して他の VM と多重化する
    これは DOSBox では直せるかもしれないが、その修正は DOSBox がエミュレートする特定のビデオアダプタに結び付く。望んでいるのはそれではなく、汎用 VBE パッチをよりうまく動かすことだ
    Intel GMA950 用の Win9x VESA フレームバッファドライバを書き、基本的なアクセラレーション、つまりブリッタと塗りつぶし命令まで追加したことがあるが、実質的に同じ問題に遭遇し、Win9x に汎用 VESA ドライバがなかった理由を理解した。VDD は GPU の状態を保存・復元する方法を知っている必要があり、その詳細は当然ベンダー依存だ。汎用的にできるアイデアも考えてみた。たとえば VBIOS をエミュレートまたは追跡して、モード切り替えのたびにどのポートや MMIO を触るかを見るといった方法だが、実装まではできなかった
    DOSBox では壊れた文字だらけのテキストモードになり、Eee PC では一部の色が消えた壊れた GUI になる
    これはパレットレジスタが正しく保存・復元されていないように見える。また画面上部の破損は、高解像度表示プレーンを 256K より上へ移動し、VRAM の最初の 256K を VGA プレーンと VGA エミュレーション用に残せば避けられる。幸い Intel GMA には公開資料がかなりある。900 と 950 の資料ではなく 810/815 と 965 以降の資料だが、大半のレジスタや命令は変わっていないので、詳細の参考にできる

  • 「x86_64 対応がないので最近の Linux ディストリビューションの大半も動かせない」とはいうが、私の Eee は 32ビット Debian でうまく持ちこたえている
    Firefox は重すぎてほとんどもたつくが、mpv での動画ストリーミングは十分できる。主に本の作業が溜まったときに pandoc を回せて、邪魔が少ないタイプライターのように使っている

    • 文章を書くときには邪魔の少ないコンピュータが良い、という点には完全に同意する。その用途に PS/2 386SX で WordPerfect 5.1 を使っている
      EEE は非常に携帯性が高くて好きだったが、本気でタイピングするにはキーボードが小さすぎると思う
    • Web や現代的なアプリなしで使うようなものなら、Haiku OS のようなものにとって興味深いユースケースになり得る
      PC で使ってみたが、実際の日常用 OS になるには使えるソフトウェアが明らかに不足していた一方で、タイプライターやメールのような接続性の低い用途なら、とても楽しい OS に感じられた
      UI、基本ソフトウェア、ファイルシステムまで一貫した感じが良かった。正しく理解しているなら、ファイルシステムがすべてのデータの表現であり、「ファイル」は任意のメタデータを持てて、ファイルマネージャでほとんど何でもできる。ファイルシステム全体が NoSQL データベースのようで、アプリもそれを自然に受け入れる構造だ。連絡先はフォルダ内の「ファイル」で、メールもフォルダ内の「ファイル」という具合だ
      当時 BeOS に触れたことはないが、接続性の低かった 90 年代にはこのパラダイムはかなりよく合っていたように思う。インターネットなしでメール「ファイル」を作成し、フロッピードライブへドラッグ＆ドロップしてから別のコンピュータでインターネット経由で送る、という全工程をファイルマネージャだけで扱える形で、驚くほど一貫していた
      残念ながら、BeOS/Haiku のファイルシステムと互換性のない他のコンピュータと相互運用しなければならない瞬間、このパラダイムの有用性は下がる。統計的には、ほぼすべてのコンピュータがそうだからだ
      ただしタイプライター用途の機器なら興味深いかもしれない
    • Debian は次のリリースで 32ビット x86 対応を削除する予定だと理解している
    • 1215B を持っていたが昨年壊れ、今は Android タブレットが代わりになっている
      タブレットがネットブック市場のセグメントを一掃してしまったように見える。ウルトラポータブルや 2-in-1 はまだあるが、それは価格帯の反対側に近い

  • タイトルは少し紛らわしかった
    それでも古い DOS ベースの Windows が内部でどのように動いていたのかを読むたびに、いつも畏敬の念を覚える。すべてがソフトウェア製のダクトテープで貼り合わされているようなのに、なぜか動く

    • Casey Muratori の話を聞けばよい。巨大な抽象化の山を作り上げたが、実際には必要ではなく、性能を悪化させているだけだということだ

  • ET4000H が出たとき、当時の Windows 3.1 ではサポートされていなかった記憶がある。MS の技術サポートに電話したらドライバーディスクを送ってくれて、8時間後に届いた。
    海賊版製品で受けたサポートとしては最高だった。

    • 正確に言うと、ET4000H は Windows 3.0 と 3.1 ですでにサポートされていた ET4000ax と同じだが、256色 DAC の代わりに HiDAC、つまり 15/16ビットのトゥルーカラーを搭載した製品だった。
      記憶は曖昧だが、標準ドライバーでは16色モードは動作し、256色以上は駄目だった気がするし、解像度の選択も制限されていたかもしれない。
      MS によると、HiDAC をサポートしたドライバーは1992年4月第3週に出ており、私の記憶している時点より1〜2週間後なので、だいたい合っているように思える。

  • 面白い。小型モデルの EEEPC 701 を持っていて、まだ動くが、レトロゲーム用途として考えたことはなかった。
    私のはただ埃をかぶっているだけだが、こういうことを試してみると面白そうだ。

    • 701 のことを言っているように思う。207g は Eee PC のモデル名ではない。

  • 小さな注釈を何気なく見比べてみると、おそらく意味飽和が来るほど見つめた後に見える状態変化がある。
    Functional GUI: M_LIN8 G800x600 > 800x600 @00000+100+Dch4
    Functional DOS: M_TEXT T80x25 > 720x400 @00000+050-W
    Broken GUI: M_VGA G400x600 > 400x600 @00000+200-Dch4
    Broken DOS: M_TEXT T80x25 > 720x400 @00000+250-W
    パターン上、壊れた DOS と壊れた GUI は 200 または 250 で、正常なものは 100 または 050 だ。あのアドレスは何なのだろう？
    壊れた GUI は、どういうわけか LIN8 ではなく M_VGA モードになっている。どうしてそうなったのか、また 800x600 の横幅の半分である 400x600 になっている理由と関係があるのだろうか？ 実際の「テキストモード」は、2つの DOS モードで見えるように 720x400 だ。

  • 筆者が見ているかは分からないが、この記事をパッチ作者に知らせておいた。
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...