windows95 项目 v86 源码构建与更新指南fork 分支、五项补丁与探针验证全解析【免费下载链接】windows95Windows 95 in an app. Runs on macOS, Linux, and Windows.项目地址: https://gitcode.com/gh_mirrors/wi/windows95本文档是 windows95 桌面应用中 v86 仿真器组件的完整维护手册。windows95 不以 copy.sh 的预编译产物为准而是从 v86 源码自行编译wasm、libv86.js 与 BIOS 固件并将两个尚未合并上游的 bugfix 补丁承载在专用 fork 分支上。读完本文你将掌握从拉取 v86 上游变更、切换windows95-base分支、运行tools/update-v86.js完成构建安装到通过 5 项 sanity check 与启动探针脚本验证整条链路的完整实操流程并能理解每一项检查背后的 ATA、Electron、网络与 VGA 底层原理。为什么 windows95 要自己构建 v86windows95 的 v86 依赖不来自任何预编译分发渠道而是由仓库内的构建脚本从本地 v86 检出目录编译产出。这个决策的直接原因是windows95 对 v86 有两项必需的上游补丁Electron 渲染进程的文件加载修复、ATA IDE 共享寄存器修复它们以 fork 分支的形式随构建脚本一起维护直到对应 PR 被上游合并。此外项目的 SMB 文件共享服务直接构建在 v86 网络适配器之上对 v86 的事件 API 存在契约依赖详见下文集成契约一节因此任何 v86 版本变更都必须经过受控的构建、安装与验证流程。构建产物与来源对应关系产物文件构建/来源方式src/renderer/lib/libv86.jsmake build/libv86.js在../v86目录执行src/renderer/lib/build/v86.wasmmake build/v86.wasmbios/seabios.bin、bios/vgabios.bin从../v86/bios/直接复制负责执行这些目标的是 tools/update-v86.js它依次完成运行 make 目标 → 复制产物 → 执行 5 项 sanity check并在任何前置条件缺失时大声报错退出。脚本没有任何回退逻辑也不会从 copy.sh 拉取任何东西——「源码构建、无 fallback」是硬性约束。从源码看 update-v86.js 的执行管线tools/update-v86.js 的main()函数顺序清晰定位检出目录V86_DIR默认取../v86相对本仓库根目录也支持通过命令行参数node tools/update-v86.js [path/to/v86]传入自定义路径打印 v86 头部提交用git log -1 --format%h %s输出当前检出的 commit便于确认分支同步状态check_prereqs()前置检查逐一验证cargo、clang是否在 PATH 上rustup target list --installed是否包含wasm32-unknown-unknownJava 是否存在于/opt/homebrew/opt/openjdk/bin/javamacOS Homebrew openjdk 路径以及v86/closure-compiler/compiler.jar是否存在、v86/Makefile是否存在build_v86()在../v86中依次执行make build/v86.wasm与make build/libv86.js并在子进程 PATH 前缀注入/opt/homebrew/opt/openjdk/bin因为 v86 的 Makefile 直接调用javainstall()把build/v86.wasm复制为src/renderer/lib/build/v86.wasm、build/libv86.js复制为src/renderer/lib/libv86.js并打印各产物大小KB再把bios/seabios.bin、bios/vgabios.bin复制进仓库的 bios 目录sanity_check()对安装后的libv86.js做 5 项不变量断言详见下文。fork 分支windows95-base 与五项补丁v86 检出必须位于felixrieseberg/v86:windows95-base分支。该分支把多个特性分支合并进来每个特性分支都对应一个可独立上送上游的 PR补丁清单与说明维护在 docs/v86-patches.md注意该表格必须与本文档的补丁列表保持同步当某个 PR 被上游合并后需要删除对应行、删除特性分支并 rebasewindows95-base。以下五项补丁各自解决一个具体的、有据可查的问题1.electron-renderer-fs-loaderPR #1540修改src/lib.js使其使用require(fs)而非await import(node:fs/promises)。原因Electron 渲染进程中动态 importnode:协议的 URL 无法工作若缺失此修复Electron 渲染进程将无法加载磁盘镜像。2.ide-shared-registersPR #1541修改src/ide.js使 ATA Command Block 寄存器Features、Sector Count、LBA Low/Mid/High的写入同时命中 master 与 slave 两块设备。根因是 v86 提交1b90d2e7把这类写入改为只针对current_interface但按 ATA 规范这些寄存器是通道共享的——IDE 电缆上只有一份寄存器文件两块驱动器锁存的是同一个值。没有此修复任何大于约 535MiB 的磁盘都会让 Win95/98 卡死在启动画面splash screen。3.vmware-abspointer在src/vmware.js中实现 VMware backdoor端口0x5658GETVERSION ABSPOINTER_* 命令使客户机驱动VBADOS VBMOUSE见 guest-tools/mouse-driver无需指针锁定即可 1:1 追踪宿主机光标绝对位置同时实现旧式文本剪贴板命令 6–9使W95TOOLS.EXE见 guest-tools/agent能与宿主机同步CF_TEXT剪贴板文本。该补丁消费mouse-absolute与vmware-clipboard-host总线事件并发出vmware-absolute-mouse与vmware-clipboard-guest事件。4.fake-network-copy-tcp-addrs修改src/browser/fake_network.js当从入站 SYN 创建TCPConnection时复制四个地址子数组hsrc/hdest/psrc/pdest。上游实现把它们作为 NE2000 TX 环形缓冲区的零拷贝视图一旦客户机的 12 槽 TX 环形缓冲区回绕任何并发流量——SMB、NBNS、ping——都会触发pump()就会用当前占据该槽位的任意 IP 构造报文段客户机因该段不属于任何 TCB 而返回 RSTrecv()永久阻塞。该场景由 tools/probe-tcp.sh 演练验证。5.vga-defer-vbe-disable-v86修改src/vga.js把 V86 模式下写入的dispi[4]0VBE disable延迟到一次传统的 attribute-mode 写入真正到达硬件时才执行。Win9x 的 VDD 为窗口化 DOS 虚拟机虚拟化了端口 3B0–3DF但不虚拟化 1CE/1CF于是 vgabios 的 VBE-disable 泄漏出去而其 mode-set 的其余部分被捕获进虚拟机的虚拟寄存器文件——没有此补丁一打开 DOS 窗口屏幕就会变成平面像素垃圾。前置条件Prerequisites构建前需要一次性准备以下环境rustup target add wasm32-unknown-unknown brew install openjdk # one-time: fetch the Closure compiler v86s Makefile pins to curl -sL https://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v20210601/closure-compiler-v20210601.jar \ -o ../v86/closure-compiler/compiler.jarClosure 编译器必须是 v20210601 版本——更新的版本会在 v86 源码上触发closure-compiler#3972问题版本锁定位于 v86 的 Makefile 中。从 tools/update-v86.js 的check_prereqs()可见脚本会显式检查该 jar 文件是否存在并给出带下载命令的错误提示缺少wasm32-unknown-unknown目标、cargo、clang、Java 均会以明确报错终止绝不静默降级。更新步骤Stepscd ../v86 git fetch fork origin git checkout windows95-base git rebase fork/windows95-base # in case fork was updated elsewhere cd ../windows95 node tools/update-v86.js就这么简单脚本会运行两个 make 目标、复制产物、执行验证。若 fork 在其他机器上被更新过git rebase fork/windows95-base用于把本地分支同步到最新状态。五项 sanity check 及其 WARN 含义5 项检查断言的是src/renderer/smb/index.ts与tools/parcel-build.js所依赖的不变量。出现 WARN 意味着上游改动了某种承载性load-bearing行为——不要忽略#检查内容若 WARN 的含义与后果1await import(node:...)仍然存在PR #1540 被回滚或该模式移动了位置Electron 渲染进程将无法加载磁盘镜像2minified 产物中缺少master.features_regPR #1541 被回滚或windows95-base丢失了该提交Win95 在 535MiB 磁盘上卡启动画面。排查cd ../v86 git log --oneline windows95-base3导出模式改变tools/parcel-build.js 的 shim 需要更新检查module.exports.V86与window.V86是否存在4tcp-connection事件消失SMB 会回退到旧 API 的连接窃取thefthack——仍然可用但出人意料5on_tcp_connection消失旧 API 回退路径失效SMB 集成只能依赖tcp-connection总线事件。无害但需要更新 src/renderer/smb/index.ts 中的注释并退役窃取代码对照 tools/update-v86.js 的sanity_check()实现可见实际断言分别是!/await import\(node:/.test(js)、/this\.master\.features_reg\(this\.master\.features_reg/.test(js)minified 产物无空格、js.includes(module.exports) js.includes(window)、js.includes(tcp-connection)、js.includes(on_tcp_connection)并以sanity: N/5 checks passed汇总输出。更新后探针测试Probe-testnode tools/update-v86.js tools/probe-boot.sh预期约 40 秒内输出SUCCESS。tools/probe-boot.sh 的流程是清理残留 Electron 进程与状态文件 →node tools/vite-build.js构建渲染层 → 以WIN95_PROBE1环境变量直接启动 Electron → 轮询/tmp/win95-probe.done获得裁决 → 输出最终 CPU/指令增量/文本屏状态后杀掉进程。判定结果的含义完整裁决表见 .claude/skills/probe-win95/SKILL.mdSUCCESS画布 ≥640×480、CPU 活跃、运行时间 30s已到达桌面FAIL_SPLASH_HANG画布卡在 320×400 超过 70sIRQ 饥饿。若你正处在 v86 master 上检查 IDE 寄存器修复——对应命令grep master.features_reg src/renderer/lib/libv86.jsFAIL_VXDLINK出现 Invalid VxD dynamic link call属于偶发蓝屏直接重试规则单次 FAIL 不算数重试至多 3 次。探针体系还支持WIN95_PROBE_SCRIPTHOST/HOST向「开始 → 运行」键入\\HOST\HOST以联动 SMB 测试以及WIN95_PROBE_DOSBOX1复现窗口化 DOS 窗口的 VBE 泄漏回归场景后者对应补丁 5 的验证。当 PR 被上游合并时rebasewindows95-base以移除已冗余的提交cd ../v86 git fetch origin git checkout windows95-base git rebase origin/master # drops the merged commit cleanly git push fork windows95-base --force-with-lease若两个 PR 都已进入上游则可彻底退役 fork 分支把 tools/update-v86.js 的默认分支指向origin/master脚本本来就使用../v86只需在那里git checkout master删除fork/windows95-base移除本文档的 The fork branch 一节确认 5 项 sanity check 仍然通过——它们是与版本无关version-agnostic的。与 SMB 的集成契约SMB 服务器构建在 v86 网络适配器之上完整细节见 src/renderer/smb/README.md。简而言之新路径通过tcp-connection总线事件接入。对应 src/renderer/smb/index.ts 中的emulator.bus.register(tcp-connection, ...)收到连接后先检查conn.sport ! 139再accept()回退路径adapter.on_tcp_connection回调 连接窃取stealing——先用伪装成端口 80 的 SYN 让 v86 原始处理器构造一个TCPConnection再通过accept(packet)覆盖全部路由字段sport/dport/hsrc/psrc/seq/ack并把.on_data替换为 SMB 处理器重定向到端口 139两条路径对连接数据均使用.on_data扁平回调属性而非.on(data)因为Closure 死代码消除会删掉事件发射器管线——这正是补丁 3 与旧式.on_data契约存在的原因之一。因此任何 v86 更新若破坏上述假设需要更新的不只是tools/update-v86.js还包括 src/renderer/smb/index.ts。这也解释了为什么 5 项 sanity check 中第 4、5 项专门盯着tcp-connection与on_tcp_connection的存在性——它们守护的正是这条与 SMB 的集成契约而 SMB 又是 windows95 让客户机挂载宿主机文件夹作为网络驱动器的核心能力。维护要点小结v86 必须检出于windows95-base本地更新前先git fetch fork origin rebase 到fork/windows95-base前置条件缺一不可wasm32-unknown-unknown目标、clang、Homebrew openjdk固定路径/opt/homebrew/opt/openjdk/bin/java、v86 Makefile 锁定的 Closurev20210601jarnode tools/update-v86.js全自动完成构建、安装与 5 项 sanity check任何 WARN 都要当作上游行为变更来对待更新后务必跑tools/probe-boot.sh做启动探针FAIL_SPLASH_HANG优先怀疑 IDE 共享寄存器补丁是否到位补丁清单与 docs/v86-patches.md 保持同步PR 上游合并后及时 rebase 甚至退役 fork 分支同时确认 5 项版本无关检查依旧通过。【免费下载链接】windows95Windows 95 in an app. Runs on macOS, Linux, and Windows.项目地址: https://gitcode.com/gh_mirrors/wi/windows95创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考