支持含有碎片的文件仿真

2011yaya2007777

谢谢测试。问题解决。

mdyblog

2011yaya2007777 发表于 2017-8-26 08:23
你手动指定内存块到
Usable RAM: Base: 0x20200000, Length: 0x1FE00000

测试：
手动指定内存块到
Usable RAM: Base: 0x20200000, Length: 0x1FE00000
可以的。 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
  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 00000000001FFFF8 0000000000000008 M=S

mdyblog

2011yaya2007777 发表于 2017-8-26 09:51
我的猜测是:
(0x14)内存盘映射在 "Usable RAM: Base: 0xD6FFF000, Length: 0x1000"，从而误导Windows XP在 ...

测试这个版本可以， 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 <===20160321
  Reserved: Base: 0x20000000, Length: 0x200000
  Usable RAM: Base: 0x20200000, Length: 0x1FE00000
  Reserved: Base: 0x40000000, Length: 0x200000
  Usable RAM: Base: 0x40200000, Length: 0x94793000  <===20170826-测试版----本次测试版本
  Reserved: Base: 0xD4993000, Length: 0x250B000
  Reserved: Base: 0xD6E9E000, Length: 0xF1000
  Reserved: Base: 0xD6F8F000, Length: 0x70000
  Usable RAM: Base: 0xD6FFF000, Length: 0x1000 <===20170625
  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 <===4G以上

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

2011yaya2007777

在反应个 usb加速的问题

问题比较诡异。不是绝对发生，很难定位。

mdyblog

不点 发表于 2017-8-26 08:10
我个人不推荐你采用这样的办法。这会带来你意想不到的问题，有陷阱，你躲不过。

我建议你采取下面两 ...

明白了，谢谢！！！！

再反应个 usb加速的问题。 2016.03.21-0.46没问题， 2017.06.25-0.46 加速后读盘卡死。

2017.06.25-0.46  效果图：


2016.03.21-0.46 效果图：

2011yaya2007777

我的猜测是:
(0x14)内存盘映射在 "Usable RAM: Base: 0xD6FFF000, Length: 0x1000"，从而误导Windows XP在该区域申请512Kb内存失败。
设置小于1Mb的内存块不使用，估计就能解决问题。      

xcajcj

太高深 看不懂了

不点

2011yaya2007777 发表于 2017-8-26 08:23
你手动指定内存块到
Usable RAM: Base: 0x20200000, Length: 0x1FE00000

从报告来看，我猜，问题的根源有可能是因为这个长度为 0x1000 的内存块（即 Usable RAM: Base: 0xD6FFF000, Length: 0x1000）不适合用作内存盘。这有可能是 BIOS 的 bug（不是故意的），也有可能是厂商在 BIOS 中故意制造的陷阱（攻击性的）。

yaya 可以考虑增加一个 map 参数（比如 min-block-size），控制搜索时所使用的最小内存块的长度（单位是 512 字节块）。对等地，也可以增加另一个 map 参数（比如 max-block-size），控制搜索时所使用的最大内存块的长度（单位是 512 字节块）。

有了这样的限定参数，那么用户自己就可以很方便地躲过那些 BIOS 的 bug （或厂商恶意制造的陷阱）了。


补充：用 block-size 这个词汇，容易误导（让人理解错误）。可以改为 range-size、block-length 或别的词汇。


再补充：

继续猜测。问题的真正根源，有可能是“某个内存块被用光”造成的。注意到这个长度为 0x1000 的内存块刚好被这个内存盘用光。grub4dos 的 int15 处理程序让这个内存块的“剩余可用内存量”等于 0，这可能让 Windows “糊涂”了，或“不适应”了。接下来我准备试着修复一下 int15 代码，让它不产生“长度为 0 的内存块”，这样或许问题就解决了。请等待我的（试验性的）修复。

2011yaya2007777

你手动指定内存块到
Usable RAM: Base: 0x20200000, Length: 0x1FE00000  <====中间还有一个
看看是否成功?其他帖子报告可以.

不点

mdyblog 发表于 2017-8-26 07:33
谢谢详细的回答！！！

没有特别的用法。 都是规范的用法。连 --top都不用(兼容的原因)。

我个人不推荐你采用这样的办法。这会带来你意想不到的问题，有陷阱，你躲不过。

我建议你采取下面两种办法之一：

1、完全采用旧版，永不更新。

2、采用新版，你自己亲自修改代码，让搜索到第一个内存块（最低的内存块）就结束搜索。而不是像你现在那样，简单地、整盘地替换为旧版的 map_func——这样做陷阱很多，会遇到其他很多隐蔽的麻烦，让你自己以后找不到问题的根源。就是说，可以局部地修改 map_func，不要全盘采用旧版的 map_func，因为有陷阱，有不兼容的暗礁，将来撞上，不划算。


不过需要补充说明的是，从高到低搜索所带来的好处，你也得不到了。就是说，假如某个机器碰巧只适应于 “从高到低”搜索，那么你的程序就要失败了。只是简单提醒一下，因为你是开发者，你自己也应该会很明白的。

mdyblog

不点 发表于 2017-8-26 07:11
你的报告严肃、认真，很详细。可能是因为你是开发者吧，能抓住要害，而与一般的报告不同。那么，我的答复 ...

谢谢详细的回答！！！

没有特别的用法。 都是规范的用法。连 --top都不用(兼容的原因)。

5) 我重新做了个测试。
修改源码， 用2016.03.21的内存盘函数 map_func 替换 2017.06.25的map_func.编译后测试。

结果：
使用的内存地址和上面2016版的一样，NTLDT/2003也没有任何抱怨了， 能正常启动

不点

mdyblog 发表于 2017-8-25 21:47
1) 就是纯 U盘启动， 没有PXE
2）就是纯grub4dos环境， 没有其他磁盘仿真软件
3)  仅仅换个grldr到20 ...

你的报告严肃、认真，很详细。可能是因为你是开发者吧，能抓住要害，而与一般的报告不同。那么，我的答复，也得格外负责才行，否则对不起你的报告。

首先，你忽略了（或混淆了）两个问题：常规内存和扩展内存。

这两部分应该单独报告，不可以揉在一块。

常规内存中的问题，前面已经解释清楚了，不再重复。

特别提醒一下，你没有提到你是如何使用 grub4dos 的。有可能是你自己使用过程、步骤“不合理”、“不正确”等，而引起的问题。譬如说，你的使用过程或步骤“异常”，超出 grub4dos 开发者的想象，超出了 grub4dos 的适用范围，使用了 grub4dos 文档中不曾提到的那些用法或步骤（比如你自己想当然的、误以为 grub4dos 应该具有某个功能但实际上并不具有，而你去使用那样的功能，自然会出问题）。你得明白，grub4dos 开发者的支持范围是啥（那就是开发者认可的那些文档中提到的用法）。超出支持范围的使用，那就是不支持的。超出范围的报告，也是不支持的。

以下假定你没有任何超限的、超范围的使用，全都是 grub4dos 文档中规定的使用方法。如果你不能满足这一点，那就不要往下看了。你需要用 grub4dos 文档规定的使用方法来重新进行试验和提交报告（有可能完全没问题了，因而也就无需报告了），那样，我才认为，报告是合理的、问题是认可的、bug 是承认的。否则，报告不被认可，问题不认为存在，bug 也不承认有。在进行 bug 报告时，不可以有任何超范围的使用，连一丝一毫都不行。（特别声明：我现在不是开发者，我不代表开发者、维护者，我只代表我自己；所有的见解、想法，都是我自己的，我不代表别的任何人。今后都是如此，希望不需要每次都声明，太累。）

请在符合上述要求的情况下，继续阅读。否则，停下来，不要继续。

---

下面根据你的描述，我来试图解决你所提到的扩展内存中所表现出来的问题。

你可能不了解，新版 grub4dos 对于虚拟内存盘所使用的内存块的搜索方向，进行了比较大的改造。旧版是从低到高，新版是从高到低。就是说，旧版会使用“能够放得下内存盘的最低端的内存块”，而新版会使用“能够放得下内存盘的最高端的内存块”。--top 参数的意义也与旧版不同，这里不讨论（因为你的问题没有涉及到它，因而不需要讨论 --top 在新旧版中的差别）。

你发现了，旧版使用了位于最低端的这个内存块

1. Usable RAM: Base: 0x100000, Length: 0x1FF00000

复制代码

而新版使用了位于最高端的这个内存块：

1. Usable RAM: Base: 0xD6FFF000, Length: 0x1000

复制代码

这是正确的。这不是 bug，这不是异常，这是设计成这样的。

由于新版 --top 的意义不同于旧版，因此，如果新版未指定 --top 参数，那就不会使用位于 4G 以上的这个“高位内存块”：

1. Usable RAM: Base: 0x100000000, Length: 0x11FE00000

复制代码

好的，已经解释了，新版 grub4dos 没有任何问题。那么有问题的是啥呢？有问题的，是你的 Windows，也或者是你的 BIOS。

你的 BIOS 指示我们，说这些内存块都是 Usable RAM。换句话说，随便用哪一块，都是允许的。旧版挑选最低的那一块，新版挑选最高端的那一块。这能是 grub4dos 的错吗？肯定不是啊！那么错在哪里呢？动动脑子，猜猜就知道啊，必然是下面两者之一有错（或者两者都有错）：

可能性一。BIOS 把一个不该是 Usable RAM 的内存块标记为 Usable RAM，让 grub4dos 使用它来放置内存盘，导致 Windows 无法启动。

可能性二。Windows 不能适应某个内存块。换句话说，它“挑剔”，它拒绝某个内存块。你可以认为这是 Windows 的 bug，或者你认为这是 Windows 的 “要求”也行，反正不管怎么称呼它，实质都一样，都是 “Windows 不明不白地拒绝使用某个内存块”。既然 Windows 是必须启动的，那这就是无条件要执行的命令，必须适应它，不适应就得死。其实你已经找到办法了（这是你作为一个开发者，具有不同于一般人的那种便利吧；一般人不一定能找到这个办法），你已经知道如何在新版下让它顺利通过了。你已经适应了，它难不住你！

从哲学上讲，这种情况以前也碰到过。那就是你以前可能很熟悉的 --e820cycles 参数。有些变态的主板（或变态的显卡驱动程序）必须要有这个变态的 --e820cycles 参数才行！否则就死给你看！！变态的主板或驱动程序，能挡得住 grub4dos 的前进？能让 grub4dos 退回到不曾具有 --e820cycles 参数的老版本、旧时代，而永远不前进？挡不住吧？

似曾相识吧？今天你遇到的是类似的情况了。你所遇到的这个变态的情况，也不应该挡住 grub4dos 的前进。换句话说，grub4dos 不该退回到 “从低到高搜索可用内存块”的旧时代。

以上就是我全部的答复。我力求答复得全面、细致（不知做到没有），希望我的答复能够易于理解、让人看懂。

不厌其烦地再次声明：以上言论只代表我个人。永远都是这样，我不代表其他任何人（希望以后不需要类似的声明了，太累）。

mdyblog

不点 发表于 2017-8-25 18:04
常规内存 0x9D800 = 630K，不算低。

可是你已经把 0x80000 以上的内存占用了！否则，Windows NT 不 ...

1) 就是纯 U盘启动， 没有PXE
2）就是纯grub4dos环境， 没有其他磁盘仿真软件
3)  仅仅换个grldr到2016.03.21-0.46，就能启动。
下面是2016.03.21-0.46的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    <=====2016
  Reserved: Base: 0x20000000, Length: 0x200000
  Usable RAM: Base: 0x20200000, Length: 0x1FE00000  <====中间还有一个
  Reserved: Base: 0x40000000, Length: 0x200000
  Usable RAM: Base: 0x40200000, Length: 0x94793000
  Reserved: Base: 0xD4993000, Length: 0x250B000
  Reserved: Base: 0xD6E9E000, Length: 0xF1000
  Reserved: Base: 0xD6F8F000, Length: 0x70000
  Usable RAM: Base: 0xD6FFF000, Length: 0x1000      <=====2017
  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  <==4G以上

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 00000000000FEFF8 0000000000000008 M=S

从对比看，直观上，
区别在于： 2016版 分配的内存在低地址的内存块中。  Usable RAM: Base: 0x100000, Length: 0x1FF00000
           2017版 分配的内存在低地址的内存块中。  Usable RAM: Base: 0xD6FFF000, Length: 0x1000


4) 2017版自己和自己的对比试验。
手动指定地址map,使得使用的内存地址和上面2016版的一样，NTLDT/2003就没有任何抱怨了， 能正常启动。

不点

mdyblog 发表于 2017-8-25 00:20
反馈个内存问题：NTLDR/2003抱怨低位内存不足

常规内存 0x9D800 = 630K，不算低。

可是你已经把 0x80000 以上的内存占用了！否则，Windows NT 不会报错。

0x9D800 - 0x80000 = 118K

grub4dos 的 int13 处理程序不可能占用 100K 多 K 的空间。

推测：你一定使用了别的磁盘仿真软件，或者其它类似的软件，占用了常规内存顶部的大量空间，从而与 Windows 的实模式启动程序发生了冲突。

还有一种可能性，你如果是从 PXE 来启动电脑，你的 PXE BIOS 有可能占用 100 多 K 的空间，从而与 Windows 的实模式启动程序发生了冲突。

---

背景：

常规内存空间很紧张，很 “值钱”（物以稀为贵）。有 N 多程序都在争用常规内存。

微软的 Windows 要占用低端的 512K 内存。而常规内存总量，最多也只有 640K。

因此，其它软件总共最多也只有 128K 的空间可以利用。

有些 BIOS 本身还要占据一些空间，比如你这个 BIOS 都已经占用了 10K 的空间了！这样的话，其它软件只有 118 K 的空间了。

---

PXE 的 BIOS 会占用 100K 左右的空间。你没提到你是使用 PXE 启动方式，所以，假定你不是从 PXE 启动的。

那么我猜，可能性最大的，就是你自己编写的某个程序（或者你使用了某个 “很吃常规内存” 的软件）占用了很多常规内存空间——占用了大家都在争用的、宝贵的常规内存空间。这是造成冲突的根本原因。

---

为了明确起见，再补充一下。你贴出的 Windows 出错信息证明了问题出在常规内存上，而不是扩展内存上。因此，你不要考虑扩展内存方面的问题了——根本就只是常规内存的问题，与扩展内存 “完全不沾边”。

你贴出的 displaymem 信息，基本上证明了产生问题的根源不在 grub4dos，而在于其它某个消耗常规内存的 “大户”。grub4dos 的 int13 处理程序只会占用很少的空间，0.4.5 之前的版本通常占用 12K。而 0.4.6 究竟占用多少，我不太了解；但我猜，也不会很多，应该在 30K 以内吧？假定就是 30K，那么还剩下 80 多K 被谁占用了？你应该找出那个占用内存的 “大户”，从它身上 “讨回” 一些空间。这种事情，尽量不要在 grub4dos 上动脑筋，因为 grub4dos 的开发者会尽量节约空间的，不会浪费很多空间。

mdyblog

反馈个内存问题：NTLDR/2003抱怨低位内存不足


用的是2017.6.25-0.4.6版
好像是新版内存改了。 2016.3.21-0.4.6版没这个问题。

（用 --top没这个问题，但是带来兼容性问题，也不能正常启动）

建了很小的内存盘。
map --statuts 和displaymem如下：
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
  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 00000000006B7FF8 0000000000000008 M=S

2011yaya2007777

usb --init不能動USB 3.0 mode。
以后也不打算支持USB 3.0 mode。主要是为了支持老旧电脑启动。

saiz

想請問一下
usb --init是否會驅動USB 3.0 mode?
或是日後會有可能支援嗎?
我曾發現在一台有USB 3.0介面的PC上
使用同一個隨身碟 進入8PE 載入速度不一樣
一般都是大概8MB/s在載入
有次發現它居然跑很快 不是8MB 8MB在載入的
看來好像是跑超過USB 2.0的速度了

2011yaya2007777

是的

netmjwork

2011yaya2007777 发表于 2016-5-9 21:08
--box x=5 w=0 y=3 h=18 l=0
修改为
--box x=5 w=0 y=3 h=26 l=0

多谢yaya大师，可以一页显示了，这里h的值是直接代表行数的吗？

2011yaya2007777

--box x=5 w=0 y=3 h=18 l=0
修改为
--box x=5 w=0 y=3 h=26 l=0

netmjwork

请教一个问题： 同样的菜单，界面为什么不能像原来版本一样在一页内完全显示菜单（20几行）

求指点：怎么调整在一页内显示的行数？（所用udmsmenu.lst见附件），谢谢！

应用环境： MBROSTool6.18  ，使用grub4dos版本2016-03-21 ，以前老版本是可以正常显示的

使用udmsmenu.lst ，输入密码错误N次，菜单还是只能分2页显示，下面空着，不知道是哪里的问题


使用udmsmenu.sh ，第一次分2页显示，输入错误密码1-3次之后，20几行菜单自动在一页内显示正常


udmsmenu.lst ： 使用该文件后udmsmenu.sh失效，此时无论输入密码错误多少次，界面还是分2屏显示；顶部一直显示的是“菜单 主菜单”。

udmsmenu.sh ： 第一次进入界面是分2屏显示，但输入密码错误1-3次之后就能自动在一页内显示全部20几行菜单；顶部第一次显示的是“菜单 主菜单”，输入密码错误、一页显示全部菜单时显示的是grub4dos的版本号信息，而不是“菜单 主菜单”。

也就是说，只用udmsmenu.lst 的话就存在分2屏显示的问题，但用udmsmenu.sh 的话不光显示有时正常有时不正常，还有顶部显示的问题，看着好像两个设置都一样。

不点

rehook 有可能有 bug，可能没有处理 --top

rehook 会重新进行 map --mem 的操作。有可能在此时都重新 map 到低端了。

chenall 可看看 rehook 的问题，修复这个 bug（如果有的话）。


mem64 是我开发的。可能有 bug。我初步怀疑，它可能适用于 AMD，不适用于 intel。

待我有时间试试看。

唉，真泄气。mem64 根本就不工作。我自己看了，也没找出问题。我打算让 karyonix 帮忙修复 bug，或者干脆重写。

mdyblog

请问:
(1):
map  --mem=-4096  --top  (md)4+8  (9) && map --rehook
(2):
map  --mem=-4096         (md)4+8  (9) && map --rehook

再获取该内存盘 的内存地址.

这样获的内存地址会超过4G吗?

测试中, VMWARE开7G,地址也只是3.2G,没超过4G . 请问这是特例吗?

mdyblog

chenall 发表于 2016-4-14 09:18
从上面的注释中可以得知用法如下
call Fn.74 FUNC dest_L dest_H src_L src_H len_L len_H

谢谢!


不过我试了没有效果.
------------------
是啊, 我示例也没有效果.
就是在C中调用 mem64(), 没没有效果.
宏定义转成32为的 memxxx(), 程序就正常了. (测试中,内存不超过4G)

chenall

mdyblog 发表于 2016-4-14 07:18
请问 Fn.74  (mem64) 怎么用?
请举例说明:
1) 将  0x40200 处的10个字节 memmove64 到 0x40000

1. /*
   
2. *   int mem64 (int func, __u64 dest, __u64 src, __u64 len)
   
3. *
   
4. *        SRC and DEST should better align 8 for efficiency.
   
5. *
   
6. *   input:
   
7. *                func = 1 for memmove, 2 for memcmp, 3 for memset
   
8. *
   
9. */

复制代码

从上面的注释中可以得知用法如下
call Fn.74 FUNC dest_L dest_H src_L src_H len_L len_H

所以1
call Fn.74 1 0x40000 0 0x40200 0 0x10 0

不过我试了没有效果，我没有用过这个功能，具体原因未知。可能这个是指对高端内存的。

mdyblog

请问 Fn.74  (mem64) 怎么用?
请举例说明:
1) 将  0x40200 处的10个字节 memmove64 到 0x40000
请贴出效果图片
2)   0x40000 处的10个字节 memcmp64  0x40200 的10个字节
请贴出效果图片

3)   0x40000 处的10个字节 memset64 为 0x41
请贴出效果图片

测试环境: mem64.fba.rar (156.77 KB, 下载次数: 0)

2016-4-14 07:17 上传

点击文件名下载附件

0x40000 预先放了20个0x30
0x40200 预先放了20个0x31
  

mdyblog

不点 发表于 2016-4-13 18:48
从 asm.S 结尾的代码可以知道，25 已经废除了，改用 74。

头文件可能没有调整过来。你向 chenall 报告 ...

谢谢!

不点

mdyblog 发表于 2016-4-13 18:38
请问 mem64是25好还是74.2个地方不一样.
头文件:
#define mem64 ((int (*)(int, unsigned  ...

从 asm.S 结尾的代码可以知道，25 已经废除了，改用 74。

头文件可能没有调整过来。你向 chenall 报告 bug。

mdyblog

请问 mem64是25好还是74.2个地方不一样.
头文件:
#define mem64 ((int (*)(int, unsigned long long, unsigned long long, unsigned long long))((*(int **)0x8300)[25]))


CHM:

不点

这要看你的用途了。只有你自己清楚该怎么做。

这个内存盘究竟是要在 grub4dos 范围内使用呢？还是要在 DOS、Windows 中使用？

如果是前者，你不需要虚拟盘（即无需挂上 int13），你只需要调整好 rd 的起始地址和长度即可。

如果是后者，你必须使用虚拟盘（挂上 int13）。目前的 grub4dos 不支持从一个内存块中间截取某一段内存当作内存盘，只能把某个内存块的尾部一整块都当作内存盘。就是说，你的特殊要求，做不到。