NEC PC-98シリーズエミュレーターを語ろう25

>>166
だってさ

むしろビックカメラとヨドバシの区別がつかない、〜駅前にあるのはどっちだったっけ、みたいなことがよくある。
吉野家とすき家を混同することは無いのに不思議。

ビックカメラのせいでビッグサイトをビックサイトだと覚えちゃってる人が結構いる

[FIX / PATCH] Windows 2000 NTVDM Crash on non-VME CPUs (Intel 486 / VIA C3) - 1-Byte Hex Patch for Official Final NTVDM.EXE (5.0.2195.7061)
Body:
Hi everyone,
I have found a definitive 1-byte Hex patch to fix the infamous NTVDM crash on non-VME CPUs (such as early Intel 486, VIA C3 Samuel/Samuel2, etc.) under Windows 2000 SP4.
While there are some ancient workarounds or Source-level rebuilds (like NTVDMx64) floating around, there was no documented pinpoint Hex patch for the official final version of NTVDM.EXE (5.0.2195.7061). Now, the puzzle is solved.

🕵‍♂ The Root Cause: Compiler Optimization Bug (Instruction Scheduling)

By reverse-engineering NTVDM.EXE and cross-referencing with the leaked NT source code, the crash happens in the function that handles NtVdmControl with ControlCode 4 (VdmFeatures).
The compiler's instruction scheduling optimization aggressively reordered mov instructions to initialize VME-specific register states (such as ExpVdmTib and EFLAGS 202h setup) BEFORE the NtVdmControl call actually checks if the CPU supports VME. On a non-VME CPU, this premature initialization instantly triggers an invalid opcode or privileged instruction exception, crashing NTVDM before it even knows the CPU capabilities.

🛠 Binary Patch Details

To fix this, we can force NTVDM to completely bypass the VME initialization path and fall back to the safe legacy software-emulation mode (486-compatible mode).
We only need to change a single conditional jump (jz) into a forced unconditional jump (jmp).
• Target OS: Windows 2000 SP4
• Target File: C:\WINNT\system32\ntvdm.exe (and dllcache\ntvdm.exe)
• File Version: 5.0.2195.7061
Hex Edit Details:
• RVA (Relative Virtual Address): 0x0000C415 (.text section + 0x0000B415)
• File Offset (RAW Address): 0x0BA15 <-- Open with any Hex Editor!
• Original Bytes: 74 07 (jz short ...)
• Patched Bytes: EB 07 (jmp short ...)

🏁 Results

Tested successfully on real Intel 486 hardware running Windows 2000 SP4. NTVDM no longer crashes when opening command.com or launching 16-bit DOS/Win16 applications, and properly routes to the non-VME legacy path.
Hopefully, this helps anyone tinkering with retro x86 hardware or unique CPU upgrades!

タイトル:
【世界初】非VME CPU（Intel 486 / VIA C3）でのWindows 2000 NTVDMクラッシュを修正する1バイトパッチ（NTVDM.EXE 5.0.2195.7061 最終版対応）
本文:
Windows 2000 SP4環境において、VME（仮想8086モード拡張）を持たない古いCPU（初期のIntel 486や、VIA C3 Samuel/Samuel2コアなど）で16bit DOSアプリを起動しようとすると、NTVDMが不正命令例外等で即座にクラッシュする有名なバグがあります。
Microsoftが最後まで修正しなかった公式最終バージョンの NTVDM.EXE（Ver 5.0.2195.7061）に対し、安全かつ完全にバグを回避させる「1バイトのHexパッチ手順」を確立しましたので共有します。

🕵‍♂ 原因：コンパイラの最適化による「フライング命令」

バイナリ解析の結果、原因は NtVdmControl（ControlCode 4 / VdmFeatures：CPU機能問い合わせ）を処理する周辺の内部コードにありました。
本来はカーネルにVMEの有無を問い合わせた「後」に処理されるべきVME環境前提の構造体初期化コード（ExpVdmTib や EFLAGS 202h の設定など）が、コンパイラの最適化（命令スケジューリング）によって、NtVdmControl を呼び出す前（間）に割り込んで実行される並び順になってしまっています。
これにより、非VME CPU環境では機能チェックが行われる前に地雷命令を踏むことになり、クラッシュを誘発していました。

🛠 バイナリ書き換え手順

NTVDM内部のVME有効化フラグ（地雷ルート）を確実に飛び越えさせ、安全な「レガシーエミュレーションモード（486互換モード）」に固定するため、条件分岐（jz）を無条件ジャンプ（jmp）に書き換えます。
• 対象OS: Windows 2000 SP4
• 対象ファイル: C:\WINNT\system32\ntvdm.exe（および dllcache\ntvdm.exe）
• ファイルバージョン: 5.0.2195.7061
バイナリ書き換え（Hex編集）詳細:
• RVA（相対仮想アドレス）: 0x0000C415 (.text セクション + 0x0000B415)
• ファイルオフセット（RAWアドレス）: 0x0BA15 <-- Hexエディタでこの位置を開く
• 変更前（純正）: 74 07 (jz short ...)
• 変更後（パッチ）: EB 07 (jmp short ...)

🏁 結果

Intel 486の実機にて動作確認済み。書き換え後、システムファイル保護（WFP）に注意しながら dllcache と system32 のファイルを差し替えることで、クラッシュが完全に解消し、16bit DOS環境やMS-DOSプロンプトが正常に起動するようになりました。
歴史の闇に埋もれていたバグが、美しい1バイトパッチとして結実しました。

いつまでもスレのルールを守れない連中こそ老害だろ
公共交通や飲食店で平気で順番飛ばすジジババみたいなもんだ
認知の歪みでそうなるらしいけど、ここにも大勢いるな
いい加減周囲に迷惑かけてる事に気付いて欲しいもんだが

効いてて草ｗ

効き過ぎてスルーできないからいつまでも粘着する奴らが調子に乗る

スルーしてたら認知症のおじいちゃんたちがいつまでもルール違反なのに気付けずにそのまま続けるからね
歳とっても教育は必要
効くとか効かないとかどうでもいいけど、率先して話に乗ってる老害に言われたくはないんで、ルールが守れないならもう黙っててねおじいちゃん

効いてて草

>>683
注意してるとか高尚なこと言ってるけど全く思惑通りになってないし調子に乗らせてるだけ
スルーしろ、おじいちゃん