支持含有碎片的文件仿真

mdyblog · 发表于 2014-11-20 20:10:07

本帖最后由 mdyblog 于 2014-11-20 20:12 编辑

不点发表于 2014-11-20 19:52
对于您个人的判断和倾向，我不可以添加我个人的判断。我认为您的想法是有您自己的根据的。

每个人都 ...

>>DOS，Windows，Linux，grub，等等，许许多多都来源于西方，如果需要割掉西方的东西，大概现在我们都不该上网了，连电话，手机也不能用，火车也不能用，电灯，电视，都不能用。

其实倒是真的可以割掉这些东西。我准备养老的时候，在农村生活，所有西方的那些现代化工具和技术，都废弃掉。原汁原味回归大自然。但是，要让所有的人都这么做，那可是件困难的事。
---------------

思想和物质文化不是一回事。
说的是西方那种基于信仰的思想文化——极其低级的思想文化。

不点 · 发表于 2014-11-20 20:11:03

mdyblog 发表于 2014-11-20 20:04
-----有虚拟盘，但不是内存盘。
------（1）-------
map /pe.iso (hd32)

很简单啊，不是早就说过了吗？只要在 map --hook 之前先执行 map --e820cycles=0，那就完全不会保护任何内存了。这不正是你想要的开关吗？骑驴找驴。

mdyblog · 发表于 2014-11-20 20:15:19

不点发表于 2014-11-20 20:11
很简单啊，不是早就说过了吗？只要在 map --hook 之前先执行 map --e820cycles=0，那就完全不会保护任何 ...

-----有虚拟盘，但不是内存盘。
------（1）-------
map /pe.iso (hd32)
map --hook
--------------------

-----有虚拟内存盘。（稍微复杂点）
------（2）-------
map --mem /pe.img (fd0)
map --hook
--------------------

你能确认”只要在 map --hook 之前先执行 map --e820cycles=0“，能恰到好处地正确地处理上面2种情况吗？

不点 · 发表于 2014-11-20 20:22:38

mdyblog 发表于 2014-11-20 20:15
-----有虚拟盘，但不是内存盘。
------（1）-------
map /pe.iso (hd32)

我什么也保证不了，我也不知道你具体要怎么做，我只是陈述，grub4dos 有这样的开关，使用它，可以不再保护任何 grub4dos 的东西。就是说，使用它之后，int15 由原始的 ROM 来接管，grub4dos 不曾更改任何东西。至于说别的，我就不好去猜测了。

chenall · 发表于 2014-11-20 21:15:21

mdyblog太概是想让 grub4dos自动判断处理,也就是说傻瓜化,(任何人都不知道你映射的内容重要不重要,是否需要保护)

我觉得以目前的情况,不太可能,有得必有失,我知道你启动map --mem /pe.iso 这类方式启动pe.iso的内容不需要去管...

如果为了这个情况默认不管了,那我估计pseudo就第一个不同意

因为这样一来0pe就会启动失败(或者说启动失败的概率增加)..

另外也会导致兼容性问题.

在没有好的解决方案之前我觉得还是保留现状.

另外mdyblog你也是有编程功底的,你可以尝试研究一下grub4dos的源码,看看能不能找到一个两全齐美的办法.

mdyblog · 发表于 2014-11-20 21:32:39

本帖最后由 mdyblog 于 2014-11-20 22:08 编辑

chenall 发表于 2014-11-20 21:15
mdyblog太概是想让 grub4dos自动判断处理,也就是说傻瓜化,(任何人都不知道你映射的内容重要不重要,是否需要 ...

P大的 0PE最复杂，那就不说了。

》》我觉得以目前的情况,不太可能,有得必有失,我知道你启动map --mem /pe.iso 这类方式启动pe.iso的内容不需要去管...
》》如果为了这个情况默认不管了,那我估计pseudo就第一个不同意

我的意思说，用户自己(比如我)确认：

（1）有虚拟盘，但不是内存盘。
（2）有虚拟内存盘。
进PE不再访问虚拟盘，因此不用在PE运行时保护他们。
只是 BIOS启动阶段访问以上虚拟盘中的 BIOS启动文件（BCD，BOOTMGR，BOOT.WIM ......）

复制代码

显然P大的0PE不属于上面的情况。
同时，不是G4D默认就这样，而是另外多提供一个傻瓜式的开关（就叫傻瓜map吧），这样 P大也不会抱怨了。

如果目前，不能确认有这种功能，能否努力下，实现这种功能？

mdyblog · 发表于 2014-11-20 21:36:24

本帖最后由 mdyblog 于 2014-11-20 21:48 编辑

chenall 发表于 2014-11-20 21:15
mdyblog太概是想让 grub4dos自动判断处理,也就是说傻瓜化,(任何人都不知道你映射的内容重要不重要,是否需要 ...

>>另外mdyblog你也是有编程功底的,你可以尝试研究一下grub4dos的源码,看看能不能找到一个两全齐美的办法.
术业有专攻。
G4D没有一定功夫，进去也没用。

每个人有专攻，才能有所成就。到处钻，什么都成不了。
当初有人拉我搞nativePE，就没去。
————一个人的业余时间是很有限的。

chenall · 发表于 2014-11-25 12:07:02

@yaya
cc53a00 版本的改动导致grldr_cd.bin和grldr.pbr生成错误,已经修复.

你有空的时候看看还有没有其它问题.

2011yaya2007777 · 发表于 2014-11-25 16:15:02

build 也有错误，已经修正上传。

2011yaya2007777 · 发表于 2014-11-25 16:31:58

关于 2014-11-19 补丁：
if (fb_drive_virtual && fb_drive == (unsigned char)(fb_status >> 8)) 的逻辑关系是：
G4D 已经拦截 BIOS 的 int13，并且 fb 驱动器存在。
fb 驱动器的 ID 可能是 0x80，也可能是 0x00，此语句漏掉了 0x00。

似乎应当修改为：
if (fb_drive_virtual && fb_drive == (unsigned long)(fb_status))

按说使用 G4D 的 int13，也会正确找到 fb 驱动器，使用保存的原 BIOS 的 int13 来读写驱动器。不知不点在此考虑了什么因素？

不点 · 发表于 2014-11-25 17:24:01

本帖最后由不点于 2014-11-25 17:32 编辑

(unsigned char)(fb_status >> 8) 是宿主盘的 drive number，因而可以与 fb_drive 进行比较。

但 (unsigned long)(fb_status) 可不是 drive number，因而不能与 fb_drive 进行比较。

当 fb_drive 已经是虚拟盘的情况，(ud) 盘的读写将发生错误，因为 ud 盘把虚拟盘当成宿主盘了。

经过修复以后，首先暂时 unhook int13，保证 ud 盘的读写发生在真实的 fb_drive 上。读写完成之后，再进行恢复 hook 的动作。

如此一来，无论 map 状态如何变化，ud 盘总是可以正常访问。这已经被证明成功。没有任何问题。

当 ud 的宿主盘是 00 时，(char)(fb_status >> 8) 就是 00
当 ud 的宿主盘是 80h 时，(char)(fb_status >> 8) 就是 80h。

不存在 “漏掉” 的问题。你好像也是眼睛看花了吧，或者你没有时间仔细阅读 fsys_fb.c 里面的代码，只是粗略浏览了一下，没能完全理解它的逻辑关系。

2011yaya2007777 · 发表于 2014-11-25 20:20:27

本帖最后由 2011yaya2007777 于 2014-11-25 21:23 编辑

不好意思，没有仔细斟酌。应当是建议修改为：
if (fb_drive_virtual && fb_status)

执行 fb_mount 时，假设 G4D 已经接管 int13，假设 current_drive=00，并且假设 current_partition = 0xFFFFFF（即没有 MBR，首扇区有 FAT32 的 BPB表），此时程序设置 fb_drive=00。
然后执行 fb_init。由于没有 ud 驱动器，此时 fb_status=00，则 (unsigned char)(fb_status >> 8)=00，也即：
if (fb_drive_virtual && fb_drive == (unsigned char)(fb_status >> 8))  满足条件，然后执行 quick_hook (0)。
注意，没有 ud 驱动器存在时，是不应当执行的。

严谨一些，应当是：
if (fb_drive_virtual && fb_status  && fb_drive == (unsigned char)(fb_status >> 8))
逻辑关系是：G4D 已经拦截 BIOS 的 int13，并且 fb 驱动器存在，而且 fb_drive 是 ud 设备。

不点 · 发表于 2014-11-25 21:19:12

本帖最后由不点于 2014-11-25 21:53 编辑

你再看看什么时候满足 fb_drive_virtual 的条件？

这个条件的满足，当且仅当 int 13 hook 上，并且 fb_drive 是虚拟盘。

既然 fb_drive 已经是虚拟盘了，当然应该执行 quick unhook 的操作。

即便不是从 ud 启动，也可能存在 fb 文件系统。

bean 的这段代码，如果我理解正确的话，那就是，对于普通的 fb_drive，尝试检查它是不是 fb 文件系统。
如果是的，就应该把它视为 fb 文件系统。即便它不是启动盘，也需要检查它是不是 fb 文件系统。

当然了，我猜这是 bean 的思路，他是如此来处理的。至于说究竟合理不合理，该不该改变一下，那是另外一个问题了。

很抱歉，看了你最后的修改，好像你是对的。

那就照你说的去做吧。

2011yaya2007777 · 发表于 2014-11-26 10:02:46

我大致比对了一下，这些代码是后加的。

按当前的 grldr，测试截图如下，可见是有问题：

不点 · 发表于 2014-11-26 11:28:55

是的，确实有问题，不严谨。

那就证明了你的判断。

赶快修改提交吧。

chenall · 发表于 2014-11-26 12:00:05

yaya可以直接修改提交到0.4.6a上.

0.4.5c的我可以再从0.4.6a上提取补丁.

不点 · 发表于 2014-11-26 12:32:30

chenall 发表于 2014-11-26 12:00
yaya可以直接修改提交到0.4.6a上.

0.4.5c的我可以再从0.4.6a上提取补丁.

何必那么麻烦，你自己修改一下不就行了，无非是在我上次更动的基础上增加了一个 && fb_status 罢了。

jack95 · 发表于 2014-11-26 12:32:33

2014-11-25 4.6a md5不正确

chenall · 发表于 2014-11-26 13:44:59

jack95 发表于 2014-11-26 12:32
2014-11-25 4.6a md5不正确

刚下载测试了一下,是正确的呀,不正确估计是缓存的问题.

因为11-25 0.4.6a昨天更新了两次.

chenall · 发表于 2014-11-26 13:55:40

@不点,@yaya
已更新

jack95 · 发表于 2014-11-26 16:02:41

@cheall

6开头的是什么？？

mdyblog · 发表于 2014-12-19 19:27:41

本帖最后由 mdyblog 于 2014-12-19 19:34 编辑

发现个奇怪的问题：map 很花时间，本地硬盘竟然12秒。感觉不正常。
请问怎么才能加快到 1秒以内。
如图：

chenall · 发表于 2014-12-19 20:22:18

mdyblog 发表于 2014-12-19 19:27
发现个奇怪的问题：map 很花时间，本地硬盘竟然12秒。感觉不正常。
请问怎么才能加快到 1秒以内。
如 ...

U盘的吗???
geometry (0x80)看一下.

mdyblog · 发表于 2014-12-19 21:39:23

本帖最后由 mdyblog 于 2014-12-20 12:56 编辑

chenall 发表于 2014-12-19 20:22
U盘的吗???
geometry (0x80)看一下.

是本地ATA硬盘。（USB2.0的U盘效果也一样， 12~17秒）
本地ATA硬盘，重新截图，如图：

这次是14s

tst.sh:

!BAT
echo geometry (0x80)
geometry (0x80)
echo [map (hd0)0x34F38+0x7D0000 (0)] ... %@time%
map (hd0)0x34F38+0x7D0000 (0) > nul
echo [map (hd0)0x34F38+0x7D0000 (0)] end %@time%

复制代码

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
好像时间随分区大小变大而变大！！！！！！！！！！！！！---妈呀！！

10G的win7分区，测试要39s，（还是前面那个ATA硬盘）：

--------------------------------------------------------
测试方法如下,你也可以这样测试体会下。
--------------------------------------------------------
测试方发如下：
用任意一款分区软件看看本机的分区，找个大点的分区，我这里用10G的WIN7分区测试（我用的MBROSTool自带的，能自动转换为扇区单位）。如图：

记住其起始28571648K和大小10498432K，（扇区单位则为：起始57143296扇区，大小20996864扇区）
对应的G4D的写法就是 (hd0)57143296+20996864
对应测试代码tst7.sh:

!BAT
echo geometry (0x80)
geometry (0x80)
echo [map (hd0)57143296+20996864 (0)] ... %@time%
map (hd0)57143296+20996864 (0) > nul
echo [map (hd0)57143296+20996864 (0)] end %@time%

复制代码

mdyblog · 发表于 2014-12-20 12:59:13

请问 #564楼 map 慢的问题能解决吗？

不点 · 发表于 2014-12-20 13:11:15

mdyblog 发表于 2014-12-20 12:59
请问 #564楼 map 慢的问题能解决吗？

BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你也没兴趣去提意见，即使提了，人家也不一定采纳。

mdyblog · 发表于 2014-12-20 13:58:29

本帖最后由 mdyblog 于 2014-12-20 13:59 编辑

不点发表于 2014-12-20 13:11
BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你也没兴 ...

》》BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你也没兴趣去提意见，即使提了，人家也不一定采纳。

map  要39秒，这和  "BIOS 读盘慢"没啥必然关系吧！
map 不是必然需要读取整个分区。
只是建一个仿真硬盘，又不是那种  要读到内存里去的内存盘！
应该是毫秒级。
还是上面那个10G win7分区
map --in-place    (hd0,1) (hd1,0)
map --rehook
就是瞬间完成。这里同样建立了个仿真硬盘。

不点 · 发表于 2014-12-21 08:46:57

本帖最后由不点于 2014-12-21 09:01 编辑

mdyblog 发表于 2014-12-20 13:58
》》BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你 ...

抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

顺便说明一下，下面这条命令

map --in-place (hd0,1) (hd1,0)

完全等价于

map --in-place (hd0,1) (hd1)

解释：只可能创建虚拟硬盘 (hd1)，不可能创建某个虚拟分区。BIOS 只认识盘号 DL，不知道什么叫做分区号。分区是操作系统定义的数据结构。所以，我们可以创建虚拟硬盘、虚拟软盘、虚拟光盘，但不可能创建一个虚拟分区。BIOS 没有分区的概念。硬盘上有分区，是操作系统对硬盘数据进行分析后的概念。而 BIOS 只懂得扇区号和盘号，不知道分区号是什么意思。在 BIOS 的 int13 接口规范里面，找不到分区号这种东西。它只能很单纯地进行扇区的读写。

mdyblog · 发表于 2014-12-21 09:59:24

不点发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

谢谢回复！
最新0.45C测试了2此， 1此11秒，1次12秒。都是前面测试的ATA的10G的Win7分区。比0.46快多了，但还是很慢。
如图。

mdyblog · 发表于 2014-12-21 10:08:48

本帖最后由 mdyblog 于 2014-12-21 10:13 编辑

不点发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

基本可以确定是新版本的BUG。
我用珍藏的旧版 0.45B20110714， 2秒就成功完成了。虽然不是毫秒级。但真的快多了。如图：

		自动登录	找回密码
密码			注册

支持含有碎片的文件仿真

点评

点评

点评

点评

点评

点评

点评

点评

点评

点评

点评

点评