支持含有碎片的文件仿真

mdyblog

2011yaya2007777 发表于 2017-8-26 15:11
麻烦 mdyblog 再测试一下。不要吃光内存，而是留下小于512Kb，即496Kb。
map --mem=0x201000 (md)0x800+0x ...

还是你上面给为grldr (20170826测试版）
新测试， 这次NTLDR-2003抱怨低位内存不够----同前图。
就是再分配一个大内存盘，将某一大块内存耗光。（整个系统4G小空闲内存还一大把）
其他一致。结果不能运行。
map --mem=0x201000 (md)0x800+0x4A3C98 (100)

请继续看后面的测试。

下面是displaymem 和map --status 信息:
EISA Memory BIOS Interface is present
Address Map BIOS Interface is present
Lower memory: 630K, Upper memory (to first chipset hole): 523264K
[Address Range Descriptor entries immediately follow (values are 64-bit)]
  Usable RAM: Base: 0x0, Length: 0x9D800
  Reserved: Base: 0x9D800, Length: 0x2800
  Reserved: Base: 0xE0000, Length: 0x20000
  Usable RAM: Base: 0x100000, Length: 0x1FF00000
  Reserved: Base: 0x20000000, Length: 0x200000
  Usable RAM: Base: 0x20200000, Length: 0x1FE00000
  Reserved: Base: 0x40000000, Length: 0x200000
  Usable RAM: Base: 0x40200000, Length: 0x94793000 <===14在这里    <===100也在这里,在14前面
  Reserved: Base: 0xD4993000, Length: 0x250B000
  Reserved: Base: 0xD6E9E000, Length: 0xF1000
  Reserved: Base: 0xD6F8F000, Length: 0x70000
  Usable RAM: Base: 0xD6FFF000, Length: 0x1000
  Reserved: Base: 0xD7000000, Length: 0x800000
  Reserved: Base: 0xD7800000, Length: 0x8200000
  Reserved: Base: 0xF8000000, Length: 0x4000000
  Reserved: Base: 0xFE800000, Length: 0x10000
  Reserved: Base: 0xFEC00000, Length: 0x1000
  Reserved: Base: 0xFED08000, Length: 0x1000
  Reserved: Base: 0xFED10000, Length: 0x8000
  Reserved: Base: 0xFED18000, Length: 0x1000
  Reserved: Base: 0xFED19000, Length: 0x1000
  Reserved: Base: 0xFED1C000, Length: 0x4000
  Reserved: Base: 0xFEE00000, Length: 0x1000
  Reserved: Base: 0xFFD80000, Length: 0x280000
  Usable RAM: Base: 0x100000000, Length: 0x11FE00000

floppies_orig=0, harddrives_orig=2, floppies_curr=0, harddrives_curr=2

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 0000000000201000 00000000004A3C90 M=S  <====测试加的
怎么和前面的测试一样,耗光了？？？？。






哦，map应该是
map --mem=0x2013E0  (md)0x800+0x4A38B0  (100)
这次 NTLDR-2003没有任何抱怨，启动成功。
下面是displaymem 和map --status 信息:
EISA Memory BIOS Interface is present
Address Map BIOS Interface is present
Lower memory: 630K, Upper memory (to first chipset hole): 523264K
[Address Range Descriptor entries immediately follow (values are 64-bit)]
  Usable RAM: Base: 0x0, Length: 0x9D800
  Reserved: Base: 0x9D800, Length: 0x2800
  Reserved: Base: 0xE0000, Length: 0x20000
  Usable RAM: Base: 0x100000, Length: 0x1FF00000
  Reserved: Base: 0x20000000, Length: 0x200000
  Usable RAM: Base: 0x20200000, Length: 0x1FE00000
  Reserved: Base: 0x40000000, Length: 0x200000
  Usable RAM: Base: 0x40200000, Length: 0x94793000 <===14在这里    <===100也在这里,在14前面 <====100前面有496K空闲
  Reserved: Base: 0xD4993000, Length: 0x250B000
  Reserved: Base: 0xD6E9E000, Length: 0xF1000
  Reserved: Base: 0xD6F8F000, Length: 0x70000
  Usable RAM: Base: 0xD6FFF000, Length: 0x1000
  Reserved: Base: 0xD7000000, Length: 0x800000
  Reserved: Base: 0xD7800000, Length: 0x8200000
  Reserved: Base: 0xF8000000, Length: 0x4000000
  Reserved: Base: 0xFE800000, Length: 0x10000
  Reserved: Base: 0xFEC00000, Length: 0x1000
  Reserved: Base: 0xFED08000, Length: 0x1000
  Reserved: Base: 0xFED10000, Length: 0x8000
  Reserved: Base: 0xFED18000, Length: 0x1000
  Reserved: Base: 0xFED19000, Length: 0x1000
  Reserved: Base: 0xFED1C000, Length: 0x4000
  Reserved: Base: 0xFEE00000, Length: 0x1000
  Reserved: Base: 0xFFD80000, Length: 0x280000
  Usable RAM: Base: 0x100000000, Length: 0x11FE00000

floppies_orig=0, harddrives_orig=2, floppies_curr=0, harddrives_curr=2

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 00000000002013E0 00000000004A38B0 M=S  <====测试加的

（100）前面还有：
LEN=0x2013E0*0x200 - 0x40200000 = 0x7C000=496K

2011yaya2007777

如果首先分配(0x64)，再分配（0x14），则在（0x14）后面剩余小于512Kb空间。
map --mem=0x201000 (md)0x800+0x4A38B0 (100)

先使用测试版本，麻烦再使用不点的补丁试一试。

不点

我感觉，既然 mdyblog 测试 asm.S.new 成功，那就证实了我前面的猜测。于是我们就又摸清楚了 Windows 的一个 “脾气”，即，Windows 不喜欢存在 “长度为 0”的内存块。一旦存在这样的内存块，Windows 就“乱了阵脚”或 “找不到北”了。

当一个内存块被（一个或多个）内存盘占据时，剩余未被占据的部分，如果恰好是 0（也即正好全部被内存盘占满），这是旧版本的 grub4dos 处理不好（无法处理）的情况。旧版本的 grub4dos 用 int15 来返回 0 的可用内存块长度给 int15 的调用者（比如操作系统）。Windows 遇上这个 0 长度的内存块，彻底乱套，拒绝继续启动。

我的解决办法是：当这种情况发生时，不修改这个可用内存块（usable RAM）的长度，即，保持这个内存块长度不变，而把它的 type（类型） 从 “usable RAM（用户可用）”更改成 “reserved（系统保留，用户不可用）”。这就完美解决了。

错误的技术根源猜测。我猜 Windows （有可能）把长度为 0 的内存块当成长度为 4G（=2 的 32 次方） 来处理了，也有可能是当作 2 的 64 次方来处理了，于是就全乱了。大家很熟悉：在二进制表示中，负1（即 “-1”） 与最大的数是相同的，而“最大的数”再加上 1，就等于 0。所以，在 long 整数（即 32 位整数）中，0 和 4G 是一样的（4G 就是 2 的 32 次方）。在 long long 整数（即 64 位整数）中，0 就等于 2 的 64 次方（可以粗略理解为 “无限大”）。

换句话说，Windows 的实模式启动代码把长度为 0 的内存块（有可能）当成长度为“无限大”来处理了。那么，由于 Windows 认为整个内存全部被（这个内存块）占用，完全没有可用内存了。于是，Windows 就认为内存不够了。因此，它就要报错，并且拒绝继续启动 Windows 的内核。

mdyblog

2011yaya2007777 发表于 2017-8-26 16:14
如果首先分配(0x64)，再分配（0x14），则在（0x14）后面剩余小于512Kb空间。
map --mem=0x201000 (md)0x80 ...

还是你上面给为grldr (20170826测试版）
后面留496K，抱怨，不能启动，
map --status:
Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A48B0 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 0000000000201000 00000000004A38B0 M=S
Usable RAM: Base: 0x40200000, Length: 0x94793000 内存块的使用情况：
0x40200000：                    （100）                    （14）        【free】      
                            (100)=2432580K                (14)=4K        free=496K




还做了3个测试.
前留4K，没有抱怨，可以启动，。
Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 0000000000201008 00000000004A3C88 M=S
Usable RAM: Base: 0x40200000, Length: 0x94793000 内存块的使用情况：
0x40200000：   【free】                          （100）                        （14）  
               free=4K                       (100)=2432580K                   (14)=4K      


后面留4K，抱怨，不能启动，
Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C88 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 0000000000201000 00000000004A3C88 M=S
Usable RAM: Base: 0x40200000, Length: 0x94793000 内存块的使用情况：
0x40200000：                         （100）                        （14）    【free】  
                                  (100)=2432580K                   (14)=4K     free=4K

中间留4K，抱怨，不能启动，
Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S
64 FF FE 3F 83FF FE 7F 0000000000201000 00000000004A3C88 M=S
Usable RAM: Base: 0x40200000, Length: 0x94793000 内存块的使用情况：
0x40200000：                         （100）                        【free】    (14)   
                                  (100)=2432580K                   free=4K     (14)=4K


可能方向：
    分配内存盘的时候，保证该块前面有4K的footprint剩余空间。
再配合不点的补丁，防止漏网之鱼。

2011yaya2007777

明白了。不是剩余空间不足512kb时，Windows XP报警，而是如不点所言，剩余空间为零时，Windows XP报警，返回“0K”错误提示。

2011yaya2007777

还请mdyblog再测试一下。正常测试。

mdyblog

2011yaya2007777 发表于 2017-8-27 10:13
还请mdyblog再测试一下。正常测试。

实际机器测试， 能正常启动，没有抱怨。

map --status:
Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S

另外，显示的版本是0826， 不是0827.

2011yaya2007777

他怎么位于6A4C90？而不是6B7FF8?

不点

2011yaya2007777 发表于 2017-8-27 11:54
他怎么位于6A4C90？而不是6B7FF8?

是啊，浪费了 6B7FF8 处的空间。莫非 mdyblog 抄错了？mdyblog 是不是简单复制粘贴前面一帖的内容了？

2011yaya2007777

直接使用grldr，不用编译。

mdyblog

不点 发表于 2017-8-27 12:00
是啊，浪费了 6B7FF8 处的空间。莫非 mdyblog 抄错了？mdyblog 是不是简单复制粘贴前面一帖的内容了？

肯定是今天测试的，不是copy昨天的。
LOG中还打印了%@DATE% %@TIME%
2017-08-27 11:27:47


floppies_orig=0, harddrives_orig=2, floppies_curr=0, harddrives_curr=3

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006A4C90 0000000000000008 M=S

不知道grldr的版本对不，怎么是0826？ 不是今天编译的么？

我没编译，直接用 grldr。

6A4C90 真是我想要的地址。 你不是这么设计的么。真的要分配那个4K的碎片么？ 觉得最好不要改变属性的好。 4K无所谓的。



我再测一遍。

不点

2011yaya2007777 发表于 2017-8-27 12:11
直接使用grldr，不用编译。

好像程序是错的，yaya。

1.          subl        %es:(%di), %eax
   
2.          sbbl        %es:4(%di), %edx        /* EDX:EAX=new length */
   
3.          jb        5f                        /* start_address is below the base */
   
4. +        /* now EDX=0 */ 此处怎能断定 EDX=0 ？  在 4G 以上的空间，它可能是大于 0 的。用的是 64 位地址，不是 32 位。EDX 是 高32位，EAX 是低32位
   
5. +        testl        %eax, %eax                /* EAX also be zero? ZF holds it! */
   
6. +        jne 7f
   
7. +        /* Change memory address type from 1 (usable) to 2 (reserved). Note
   
8. +         * that original value is long integer of 1 (all higher 3 bytes = 0).
   
9. +         * So only the lowest byte needs to be incremented. */
   
10. +        incb        %es:16(%di)                /* memory address type */
    
11. +        jmp        5f
    
12. +7:
    
13.          subl        %es:8(%di), %eax
    
14.          sbbl        %es:12(%di), %edx        /* EDX:EAX=difference */
    
15.          jnb        5f                        /* new length is too big */

复制代码

就算 mdyblog 测试通过了，有问题的代码也是不能用的。

补充：感觉 yaya 的程序确实比我的简化了不少。赞！上述毛病稍微改进一下，不知道行不行：

1.          subl        %es:(%di), %eax
   
2.          sbbl        %es:4(%di), %edx        /* EDX:EAX=new length */
   
3.          jb        5f                        /* start_address is below the base */
   
4. +        ja        7f        <-------------------  就增加这一句
   
5. +        /* now EDX=0 */
   
6. +        testl        %eax, %eax                /* EAX also be zero? ZF holds it! */
   
7. +        jne 7f
   
8. +        /* Change memory address type from 1 (usable) to 2 (reserved). Note
   
9. +         * that original value is long integer of 1 (all higher 3 bytes = 0).
   
10. +         * So only the lowest byte needs to be incremented. */
    
11. +        incb        %es:16(%di)                /* memory address type */
    
12. +        jmp        5f
    
13. +7:
    
14.          subl        %es:8(%di), %eax
    
15.          sbbl        %es:12(%di), %edx        /* EDX:EAX=difference */
    
16.          jnb        5f                        /* new length is too big */

复制代码

我的那个程序可能比较罗嗦、复杂，但逻辑的正确性是没问题的（我只是检查了几遍，没发现问题；也不敢肯定真的没问题）。要是上述这个代码在逻辑上没问题的话，那可是非常漂亮的了。

不点

mdyblog 发表于 2017-8-27 13:11
肯定是今天测试的，不是copy昨天的。
LOG中还打印了%@DATE% %@TIME%
2017-08-27 11:27:47

没有使用最高的可用地址，就是错误啊（程序的逻辑包含着错误，属于 bug）。与你想不想节约这点空间没关系。

mdyblog

2011yaya2007777 发表于 2017-8-27 12:11
直接使用grldr，不用编译。

这次先升级到2016 在升级到这个版本， 确认版本变化了。
这次版本对了，果然是20170827

能启动，无抱怨。

----2017-08-27 14:36:40----

*0x8278 GRUB4DOS:20170827


floppies_orig=0, harddrives_orig=2, floppies_curr=0, harddrives_curr=2

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
14 FF 01 12 83FF FE 7F 00000000006B7FF8 0000000000000008 M=S
果然是 6B7FF8

对不起了，前面测试的版本不对。

2011yaya2007777

不点所言极是，确实应当增加
04.+        ja        7f        <-------------------  就增加这一句

我现在也可以再现 “Windows 0K"错误了。

不点

2011yaya2007777 发表于 2017-8-27 14:57
不点所言极是，确实应当增加
04.+        ja        7f

昨天我写代码，纠结了半天，费了不少工夫。看到我以前写的这段 int15_e820_handler 代码，我甚至觉得很棒、很简练，有些地方竟然看不懂，还要琢磨半晌才能弄懂，就好像不是我写的一样。这说明，我现在的水平已经下降了！可能是脑细胞退化了吧！有点悲哀，但不能不承认。

chenall、yaya 你们比我可年轻多了。我希望你们到我这岁数的时候，可不要像我这样了。趁着你们现在年轻，要多多的用脑子，宝剑锋自磨砺出，脑子不用就迟钝了。当然了，身体是第一位的，一定要注意营养，注意锻炼，注意休息。

我现在脑子不好使，暂时没有发现上述代码是否有别的问题。yaya 可再检查确认一下。

2011yaya2007777

看到我以前写的这段 int15_e820_handler 代码，我甚至觉得很棒、很简练，有些地方竟然看不懂，还要琢磨半晌才能弄懂，就好像不是我写的一样。这说明，我现在的水平已经下降了！可能是脑细胞退化了吧！有点悲哀，但不能不承认。

其实都一样。自己写代码时比较清楚，过上一段时间再看，就难理解了。所以我现在尽量备注详细的说明，以便将来查询。

2011yaya2007777

补丁已经上传。

2011yaya2007777

经过进一步测试，结论如下：
使用 int15/eax=e820， 返回4Gb以下可用内存块(4Gb及以上可用内存块无影响)，当长度为零时, Windows XP 会提示:
windows nt has found only 0k low memory.  512k of low memory is required to run windows nt.  you may need to upqrade your computer or run a configuration program provided by the manufacturer.

不点

2011yaya2007777 发表于 2017-8-29 09:11
经过进一步测试，结论如下：
使用 int15/eax=e820， 返回4Gb以下可用内存块(4Gb及以上可用内存块无影响)， ...

非常好，又弄清楚了一个问题。这也间接说明 XP 不去处理 4G 以上的内存。可以试试 64 位的操作系统（Win7～Win10），看看情况又有什么不同？说不定 0K 问题不存在了，也未可知。弄清楚总是有好处的。

假如 Win7～Win10 不存在 0K 问题，说明微软认为 XP 是个 bug，已经修复。

假如 Win7～Win10 也存在 0K 问题，说明微软所理解的 int15 规范是不允许有 0 长度的内存块的。

2011yaya2007777

经测试，Win7～Win10 不存在 0K 问题。
看来 WinXP 启动时检查 4Gb 以下的所有可用内存块，如果长度为零就报 0K 错误。
可能 Win 觉得所有程序都在我的壳下运行，是谁先占用了内存块？
不过 WinXP 反馈的信息有待商榷。它说低内存，让人误解为常规内存不足。再说与分配 512Kb 内存有何关系，这一块内存为零，你可以在另一块内存分配吗。

不点

2011yaya2007777 发表于 2017-8-29 16:15
经测试，Win7～Win10 不存在 0K 问题。
看来 WinXP 启动时检查 4Gb 以下的所有可用内存块，如果长度为零就 ...

关于 XP 反馈的信息，你给出的这种解释，或许不符合 Windows XP 开发者的想法。Windows 开发者有可能是把内存块长度减去 1，算出内存块最末尾的字节（相对于内存块开头）的偏移量。0 长度算出的最大偏移量就是 0xFFFFFFFF 了。既然有这么大的一个偏移量，就相当于说，该内存块占满了所有的内存，于是，常规内存也被 “吞噬”，或者说，与该内存块 “有重叠”。如果 “被吞噬” 的常规内存算作 “不存在” 的话，那么，常规内存量就成为 0 了。

XP 所说的 512K，是指常规内存底端的 512K，这不能随便从别处分配（不能位于扩展内存中）。它是指 “起始于物理地址 0，终止于物理地址 0x80000” 的这段常规内存。Windows 启动程序（甚至 Windows 内核），有可能使用这 512K 的空间。只要这个空间被别的软件占用，Windows 就要报错。

Win7～Win10 可能发现 XP（对于长度为 0 的内存块）的那种 “理解” 太过于 “绕弯”，于是就纠正过来了。这说明微软（或者 Windows 的开发者）认为 XP 的那种处理，是个 bug。

2011yaya2007777

长度是指基地址开始的长度。如果觉得太大，那也是从基地址开始的长度太大，此时不应当包含常规内存吧。

不点

2011yaya2007777 发表于 2017-8-29 18:14
长度是指基地址开始的长度。如果觉得太大，那也是从基地址开始的长度太大，此时不应当包含常规内存吧。

现在不是跟别人 “讲道理”的时候。我们作为 “外界”的人，程序不是我们写的，我们只能 “猜测”，只能尽量想出一些 “可能性”（这些 “可能性”还都“堂而皇之”、能够“说得过去”）。换句话说，我们是尽量替人家“找理由”。

譬如你刚刚提到的这个疑问，那我们如何替人家“自圆其说”呢？我觉得可以像这样（仅仅是举例，其实可能性多得很）：

人家只要发现内存块长度为 4G，就认为这个内存块已经“包括所有的内存”了，此时忽略内存块的基地址。

是我们得替人家找理由；不是反过来，即，由人家来回答我们的问题。

hhh333

怪不得MS要不断打补丁。比尔起先不是说PC机最多2M内存就够了吗？

求道者

hhh333 发表于 2017-8-30 17:34
怪不得MS要不断打补丁。比尔起先不是说PC机最多2M内存就够了吗？

ibm那边不是说有512k内存就够了吗？

mdyblog

反应个现象。 不知道是否算问题。
关于 map --in-situ 的。
map --in-situ (hd0)0x80+0x1000 (hd0) && map (hd0) (hd1) &&  map --hook
floppies_orig=0, harddrives_orig=1, floppies_curr=0, harddrives_curr=2

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
80 80 FE 01 000E FE FF 0000000000000080 0000000000001000 H=S
81 80 00 01 8001 FE 7F 0000000000000000 0000000000000000 H=S

注意红色的部分：虚拟盘 偏移和长度信息



后面再要map到 (hd0)
于是 虚拟 (hd0) “备份到” (hd2) 这个名目下。
map --in-situ (hd0)0x1080+0x1000 (hd0) && map (hd0) (hd2) &&  map --hook
或者：map --in-situ (hd1)0x1080+0x1000 (hd0) && map (hd0) (hd2) &&  map --hook

但是备份出来的(hd2) 不是 要备份的前面的虚拟(hd0)，而是原始的(hd0),偏移和长度信息都没了。

floppies_orig=0, harddrives_orig=1, floppies_curr=0, harddrives_curr=3

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
80 80 FE 01 000E FE C1 0000000000001080 0000000000001000 H=S
81 80 00 01 8001 FE 7F 0000000000000000 0000000000000000 H=S
82 80 00 01 8010 FE 41 0000000000000000 0000000000000000 H=S
注意红色的部分：虚拟盘 偏移和长度信息 变了。

这样就无法访问原来虚拟的(hd0,0)里面的文件了。

怎样方便地备份前面的虚拟 (hd0)到(hd2),后面还要访问里面的信息。

测试VHD。 加载VHD后，用finsbtool  MBT Qemu启动测试器 VMware 模拟启动，即可复现显现。
V10M.VHD.rar (179.24 KB, 下载次数: 5)

2017-9-18 15:42 上传

点击文件名下载附件

不点

请稍等，容我先慢慢理解一下你的意思，然后再回复。

不点

首先，注意 --in-situ 的含义：它只是把分区表虚拟化，别的保持不动。

它只是把——比如说，从偏移扇序号 80h 开始的 1000h 个扇区——虚拟为主分区。也就是说，让主分区表的某一项（如果有空位的话）指向这个位置（起始地址和长度）。

特别注意，虚拟磁盘的其他扇区都是 “实在” 的，未进行虚拟化。这一点很重要，不要在理解上有偏差。

因此，你那种 “备份” 的想法，感觉就有点 “奇葩” 了。本来 --in-situ 就是一个指针而已，根本没有什么东西需要备份。如果 “非要备份不可” 的话，那也是备份这个指针，即备份 80h 和 1000h 这两个数字（即，虚拟主分区的起始扇区号和虚拟主分区的长度）。

假如你希望达到这样的目的：

Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
82 80 FE 01 000E FE FF 0000000000000080 0000000000001000 H=S

你应该直接使用

map --in-situ (hd0)0x80+0x1000 (hd2)

嵌套的 --in-situ，容易出问题。我是说，我在编程的时候，就有可能出现 bug 之类的（即，没有处理好的情况）。如果你发现了 bug，你可以让 chenall、yaya 解决。我发现，chenall、yaya 都解决过以前我没处理好的一些问题，而且都解决得很漂亮。

但最好别让 chenall、yaya 他们太过于忙碌——我认为，能不做就不要做；能躲过，就尽量躲过。因为万一改动坏了，不是还得折腾吗。这年月（BIOS 逐步被抛弃），grub4dos 也不值得再投入太大的精力了——我认为。

因此，建议尽量避免嵌套使用 --in-situ。否则，你让开发者修复 bug，这恐怕有工作量吧？

mdyblog

不点 发表于 2017-9-18 17:28
首先，注意 --in-situ 的含义：它只是把分区表虚拟化，别的保持不动。

它只是把——比如说，从偏移扇序 ...

你应该直接使用

map --in-situ (hd0)0x80+0x1000 (hd2)
----------------------
显示中， 这两步是没关联的。这里只是演示下。
第一步可能是另外一个grldr 传过来的。（同样可能 第2步后又启动第3个grldr）


map --in-situ (hd0)0x1080+0x1000 (hd0)
时，我不知道  (hd0) 怎么来的。
我需要为后续的系统菜单创建一个虚拟的(hd0),作为他的磁盘。

同时原(hd0)要 备份到 （hd2)这个名目下，后续可能需要里面的文件。

怎样方便实现这个目的。 我想很多人需要这个吧。

嵌套--in-situ， 这是另外一个问题了。

这样2个问题（假定(hd0)是另外一个同版本grldr的另外一个作者的菜单传过来的）：
（1） 在独立的第2步中， 如何方便 原(hd0) 备份到 (hd2)这个名目下。
（2） 在独立的第2步中， 如何方便 map --in-situ ，以避免 嵌套--in-situ。
能加强map功能吗？增加新的开关也可以接受。智能处理也能接受。

备份是否扩成成：
map --move (hd0)  (hd2)
--move 告诉map, 如果是虚拟的， 直接移到 (hd2)上

避免 嵌套--in-situ。是否扩成成：
map --in-situ --exp  (hd0)0x1080+0x1000  (hd0)
--exp 告诉map, 避免 嵌套--in-situ。 map应该用相关信息。


因此，你那种 “备份” 的想法，感觉就有点 “奇葩” 了。
------------------------
这只是一种说法。不必较真。
现实中需要这种应用。
不知道(hd0)怎么来的。 有需要重新虚拟一个(hd0)用。但是有需要保留原(hd0)的访问能力。