无忧启动论坛

标题: 对于UD启动为FD0的机器,加载软盘镜像启动到DOS,看不到UD可见分区的内容 [打印本页]
作者: 2011yaya2007    时间: 2013-5-22 21:43
标题: 对于UD启动为FD0的机器,加载软盘镜像启动到DOS,看不到UD可见分区的内容
本帖最后由 2011yaya2007 于 2013-5-26 15:47 编辑

ud 启动后，被分配驱动器号 00 。
find 可见 fd0  fd0,0  hd0,0 ...
菜单：
title 本人Dos工具箱
map (fd0) (fd1)
map --mem /program/mydos.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
进 dos 后， dir b:    提示错误。
从非 ud 启动没有此问题。

修改菜单：
map --mem /program/mydos.img (fd1)
map --hook
chainloader (fd1)+1
rootnoverify (fd1)
进 dos 后，提示找不到 command.com  , 输入 a:\command.com ，提示盘符不对，输入 b: ，正常
但 dir a: ，提示错误

怎样修改菜单，才能在 dos 下看见 ud 可见分区（即 fd0,0 ）的内容？
作者: 2011yaya2007    时间: 2013-5-23 08:50
使用网友推荐的2个方法，均失败，死机且不能三键重启。是那条语句出错了？
方法1：
find --set-root /g4d.id
map --mem /program/mydos.img (fd1)
map (fd0) (fd1)
map (fd1) (fd0)
map --rehook
chainloader (fd0)+1
rootnoverify (fd0)
boot

方法2：
map (fd0) (hd0)
map (hd0) (hd)
map --rehook
rootnoverify (hd0,0)
find --set-root /g4d.id
map --mem /program/mydos.img (fd0)
chainloader (fd0)+1
rootnoverify (fd0)
boot
作者: 不点    时间: 2013-5-24 20:30
fd0  fd0,0

说明有分区表。这是一个硬盘映像。

检查 MBR 是否含有 BPB，检查 grub4dos 是否可以列出 (fd0)/ 之下的文件。

如果 grub4dos 列不出 (fd0)/ 的文件，那就怀疑 MBR 上没有 BPB，或者 BPB 是错误的。

如果能列出 (fd0)/ 里面的文件，再检查 BPB 的 OEM 制造商字符串是不是微软承认的 MSDOS5.0 或者 MSWIN4.1，如果不是的，马上改成 MSDOS5.0 或者 MSWIN4.1，即可。

作者: 2011yaya2007    时间: 2013-5-25 09:28
我感觉是 ud 分区的特殊性造成的。
ls (fd0)/ 与 ls (ud)/  的结果相同，是隐藏分区的文件。
ls (fd0,0)/ 是可见分区的文件。
MBR 中不含 BPB 与含 BPB 结果一样（含 BPB 时有 MSWIN4.1）

我怀疑，从 ud 分区启动，只要被 bios 分配驱动器号 00，加载软盘镜像后，就看不到 ud 可见分区的内容。
作者: sunsea    时间: 2013-5-25 09:36
  1. title 本人Dos工具箱
  2. map --mem /program/mydos.img (fd1)
  3. map --hook
  4. chainloader (fd1)+1
  5. rootnoverify (fd1)
复制代码
作者: 不点    时间: 2013-5-25 10:36
本帖最后由 不点 于 2013-5-25 10:53 编辑
2011yaya2007 发表于 2013-5-25 09:28
我感觉是 ud 分区的特殊性造成的。
ls (fd0)/ 与 ls (ud)/  的结果相同，是隐藏分区的文件。
ls (fd0,0)/ ...


你的意思是说，fd0 上的 BPB 没有指向 FAT 文件系统，反而指向了 UD 自己的 fb 文件系统？这当然是不行的。

你搞错了，必须让 BPB 指向 FAT 文件系统，才能够让 DOS 认这个软盘。DOS 不可能知道 fb 文件系统，不可能支持 fb 文件系统。

BPB 中的保留扇区数（reserved sectors，2字节的 WORD），可以理解为 FAT 的 PBR 所占据的扇区数。PBR 之后紧接着就是 FAT 表。你需要修正保留扇区数，让 FAT 表之前的扇区（直到 MBR）都算在保留扇区数之内。

注意，不要更改 (fd0,0) 的 PBR 里面的信息。你需要更改的仅仅是 MBR 上的 BPB 中的保留扇区数。就是欺骗 DOS，让 DOS 认为这个软盘就是一个 FAT 文件系统，其 PBR 占据 N 个扇区（即 reserved sectors），而不是通常的 1 个扇区。MBR 同时也是这个软盘的 PBR，是其 PBR 的第一个扇区，PBR 总共有 N 个扇区。

否则的话，DOS 怎么可能知道 (fd0,0) 呢？DOS 认为，软盘就是软盘，没有分区表，只有 PBR。DOS 认为，只有硬盘才有分区表。

想让 DOS 直接识别软盘的分区表？进而再识别出分区 (fd0,0) 里面的 FAT 文件系统？没门。必须在 MBR 上安放 BPB 来欺骗 DOS 才行。
作者: 2011yaya2007    时间: 2013-5-25 20:45
Re sunsea :
这方法不行。
启动到 dos，盘符是 A> ，提示找不到 command.com ，键入 b:\command.com ，提示盘符不对，键入 b:  ，盘符正常，为 B:\> 。
dir ，显示 mydos.img 内容。
dir a:  ，提示错误。
总之，看不到 ud 可见分区的内容。
作者: 2011yaya2007    时间: 2013-5-25 21:08
Re 不点：
我以前都是从常规分区启动，最近由于反馈 usb2.0 加载问题，出在 ud 分区，故初步探讨了一下 ud 启动。
格式化为 ud 分区，本来 MBP 没有 BPB ，因为发现问题，故复制了 BPB ，是从可见分区（0x4000扇区）复制的，隐藏分区由 0x4000 修改为 0，保留扇区由 1 修改为 0x4001，这不会错的。
按常规，ls (hd0,0)/ 显示硬盘第一分区内容，而 ls (hd0)/ 是不行的。可是 ud 分区却可以。推测 ud 有他自己的特殊映射。正因为如此，使用 map 交换 ud分区（或者是 fd0，或者是 hd0），就会出错。
启动软盘映像，dos 肯定分配 A: 盘符，尽管是从 fd1 加载。按 sunsea  所示方法，没有交换，却也看不到 ud 可见分区。
作者: 不点    时间: 2013-5-25 21:35
本帖最后由 不点 于 2013-5-25 22:04 编辑

论坛上早就研究过，结论是， ud 盘不可以用 map 映射。就是说，一般而言是不应该用 map 来映射 ud 所在的盘的。为什么要交换呢？如果能够避免使用 map，为什么要用 map 呢？

另外，不知是你没说清楚，还是我没看明白，前面一直在说 fd0 和 fd0,0，怎么现在变成 hd0 和 hd0,0 了？

软盘、硬盘，这差别可太大了。对于 grub4dos 而言，软盘、硬盘没有本质区别。但对于 dos 而言，那可差太远了。

如果是 map 造成的，那取消使用 map，就没问题了。

另外，你只谈到了修改 reserved sectors 和 hidden sectors，却没有谈到 heads 和 sectors per track 怎么办？你保证 BPB 中的 H 和 S 都正确吗？对于软盘，msdos 根本不采用 lba 模式，只采用 chs 模式。即使软盘支持 lba，msdos也不采用，而只用 chs 模式。所以，H 和 S 最要紧。必要时，用 geometry 的 --sync 选项来自动调整 BPB 上的 H、S 参数。

对 ud 盘进行 map，会造成 ud 区不可访问。但不会造成 FAT 格式识别的问题。因此，DOS 不受 map 的影响，仍然能找到其中的文件。如果 dos 找不到 FAT 中的文件，那基本上能够确定是 BPB 的错误引起的。

DOS 最好对付了。DOS 里面也藏不住太多的秘密，就连 OEM 字符串都已经被研究透了。如果 dos 启动失败，那一定能解决，而且不困难。



作者: 2011yaya2007    时间: 2013-5-26 11:26
论坛上早就研究过，结论是， ud 盘不可以用 map 映射

这我就明白了。之前是看到 http://bbs.wuyou.net/forum.php?mod=viewthread&tid=205247 帖子，提到映射fd0到hd0。

不交换，map --mem /program/mydos.img (fd0) ，占了 ud 分区（他原来是 fd0)，启动到 dos 肯定看不到 ud 可见分区。
交换，又不可以。
结论：对于 UD 启动为 fd0 的机器，加载软盘镜像启动到 dos ，看不到 ud 可见分区的内容。
作者: 不点    时间: 2013-5-26 13:30
本帖最后由 不点 于 2013-5-26 13:55 编辑

哪会这么简单？
前面已经说了，交换不影响dos访问ud上的fat文件系统。访问失败基本可以肯定是bpb的错误引起的。当然，什么事情都不是那么绝对的，也有可能由于ud已经占据有利地盘，而使得后面的fat所占据的位置超出bios访问能力。

另外，如果采用不交换，也是有办法的。把 img 映射为 hd0 也是可以的。只需要在如何制作 img上动脑筋即可。
作者: 2011yaya2007    时间: 2013-5-26 16:24
本帖最后由 2011yaya2007 于 2013-5-26 16:29 编辑

跟踪了一下启动过程，DOS 检测引导程序：
偏移 0 起始的 3 字节必须为  69 xx xx  或 E9 xx xx  或 EB xx 90
偏移 0x15 必须为 Fx
问题出在偏移 3 为 00

修正后，按 5 楼的方法
map --mem /program/mydos.img (fd1)
map --hook
chainloader (fd1)+1
rootnoverify (fd1)
启动后，A: 为 ud 可见分区，B: 为 mydos.img

修正后按以下方法
map (fd0) (fd1)
map --mem /program/mydos.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
启动后，A: 为 mydos.img ，B: 为 ud 可见分区

看来正确的结论应当是：
1. 对于 UD 启动为 fd0 的机器，MBR 必须有 BPB 表，且注意起始 3 字节。
2. UD 分区可以交换。
作者: 不点    时间: 2013-5-26 18:10
本帖最后由 不点 于 2013-5-26 18:27 编辑

这还差不多，像是 yaya 写的帖子。

得益于个人调试技术强，你找到了技术关键点。

不过，grub4dos 的readme里面也有提到，那个偏移 02 处的字节必须是 0x90。

你发现的69 和 e9，倒是新的。而e9容易理解，它也是jmp。可是，69 是啥，我就记不得了。

嗯，想了想，你的新发现确实很重要。看来我们需要扩展 bpb 这个概念了，让它从偏移 00 开始，而不是从偏移 03 开始，更不是从偏移 0B 开始。或者我们启用一个新名词，叫做 “ 广义 BPB ”。
作者: 2011yaya2007    时间: 2013-5-27 07:23
本帖最后由 2011yaya2007 于 2013-5-27 07:40 编辑

69 是 有符号数乘，格式：
IMUL 目的通用寄存器，16位立即数
IMUL 目的通用寄存器，源通用寄存器（也可以是存储单元），16位立即数

叫做 “ 广义 BPB ”。

很好

之所以发这个帖子，是由于对菜单的批处理不熟悉，怀疑哪里出错了。
作者: 不点    时间: 2013-5-27 09:47
本帖最后由 不点 于 2013-5-27 09:55 编辑
2011yaya2007 发表于 2013-5-27 07:23
69 是 有符号数乘，格式：
IMUL 目的通用寄存器，16位立即数
IMUL 目的通用寄存器，源通用寄存器（也可以 ...


第一条指令是乘法指令，这不知道是哪个版本的 DOS 引导扇区。而且，微软的 debug 不支持 69，不能反汇编它，只能显示为

DB         69

这说明，69 不是 8086 指令，它可能是后来增强的指令，比如 80186 指令。

另外，69 之后，至少有 16 位的立即数，连同 69 一起，至少是 3 个字节。这样的话，OEM 字符串的位置，也要被后续的指令占据。因此，那时候还没有开始出现 BPB。

如果确实要追本溯源，就应该找出这样的 DOS 版本（不过可能不容易找到，因为年代久远）。

另外，E9 虽然也是跳转，我怀疑实际上不会用到它。也就是说，实际的 DOS 版本中，可能没有用 E9 的，只用 EB 就够了。

另外，69 也不一定是微软的引导扇区，即，有可能是别的公司的引导扇区。

---------------------------------------------

通过这样的分析，我们就可以知道，69 是很久远的事情了，不支持 BPB。所以，后来的引导扇区都不会是 69。因此，69 就可以不用考虑了。

刚才说了，E9 也不太可能出现，实际出现的可能只是 EB（估计没有例外）。因此，我们可以认为，偏移 00 处固定为 EB，偏移 02 处固定为 90。否则就按非法处理。

作者: 不点    时间: 2013-5-27 21:34
今天我想引申一下。看到你调试技术这么好，我觉得太难得了。

我很早就有开发dos的想法，这你也知道。可是主要因为身体条件不允许，只好作罢。

如果我有你这样的调试技术，以及一个良好的身体，我一定不会放弃dos的。

不过，由于bios有可能被强制取缔，不开发dos也罢。

作者: 2011yaya2007    时间: 2013-5-28 17:19
估计 69 可能有他自己的含义。如果是 imul，他至少 4 字节。以下是 80386 增强指令。
imul ax, 1234         69c03412
imul ax, bx, 1234    69c33412

另外，dos 还探测偏移 3 是否为 MSDMF3 ，如果是，设置了 1 个标记。
作者: 不点    时间: 2013-5-28 17:37
用 google 搜 MSDMF3，得到以下的解释：

For FAT32, it seems you must have "MSWIN4.1" here. If this is "MSDMF3.2" (afaik only the "MSDMF" is checked") the partition can't be written under Windows 9x, ...

69 不知道是哪年的了，甚至不一定是微软的代码，估计早淘汰了。
作者: 不点    时间: 2013-5-29 10:42
继续和 yaya 谈这个问题，依旧是有关 DOS 开发的事。但也只是随便聊聊，不用太认真，也不用有压力，只是说说而已。

BIOS 被取缔了，我觉得这事玄，不一定真能行。究竟行不行，那要靠长期实践来答复，不是现在就能下结论的。

哲学上，每个人都有自己的理由，都有自己的倾向、判断，每个人都是对的。下面就说说我的倾向。

根据我八卦出来的结果，取缔 BIOS 一事，大概应该是以失败而告终。总体上大致有以下几种可能：

1、取缔 BIOS 毫无问题，EFI 大行其道，厂商、开发者和用户皆大欢喜。
2、取缔 BIOS 遇到阻力，厂商很快又恢复对于 BIOS 的支持。
3、取缔 BIOS 遇到阻力，厂商坚持取缔，然而 x86 很快没落，直至逐渐消亡，此时，讨论在 x86 下是否该取缔 BIOS 的问题，已经无意义了。

我觉得情况1的可能性很小。因此，情况2和3的可能性较大。

如果发生情况 2，那么，DOS 依旧值得开发。

如果发生情况 3，那或许就不太值得开发了。但也不一定，因为有人在 ARM 下模拟 DOS，说明 DOS 依旧很经典。那就是说，即便发生了情况 1，仍然可以开发 DOS，因为总可以模拟运行。

总体来讲，我觉得 DOS 依然值得开发，即使在 BIOS 被取缔的情况下。

论坛是用来交流看法的。以上主要只是想和 yaya 讨论，因为主要涉及的是有关 DOS 开发的事情。

作者: 2011yaya2007    时间: 2013-5-29 15:22
我觉得 EFI 对于大硬盘自有其用，所谓取缔 BIOS ，要害在于是否支持实模式启动。
按网上说法，BIOS 的开发者苦于使用汇编，愿意采用 c 语言，再者觉得 ROM 容量小，故而把引导代码放在硬盘。
以往是主板设计者选择 BIOS ，现在要主板设计者选择硬盘？后来又把引导代码放在主板的 ROM 里了。至于叫不叫 BIOS ，其实是一回事。
原 BIOS 提供实模式硬件驱动，而新 "BIOS" 即 EFI 则提供保护模式硬件驱动。

我觉得取缔 BIOS （不提供实模式硬件驱动）过程一定漫长，到时也许有人开发出实模式硬件驱动。



欢迎光临 无忧启动论坛 (http://bbs.c3.wuyou.net/) Powered by Discuz! X3.3