中国DOS联盟

以下是引用不点在2003-11-20 16:02:38的发言：
FAST DEFRAG, 我在 google 中找到一些软件, 可以快速整理磁盘, 不知道这个怎么样:

http://www.techtv.com/callforhelp/freefile/story/0,24330,3425341,00.html

是免费下载的. 有人用过吗?

Fast Defrag
Free up memory and optimize how your system uses RAM and the swap-file

to Wengier斑竹:

我开始就猜测 你在国外，呵呵
你说的思路倒是可行，改动也应该不是太大，就是 我现在很懒惰，没有心思改程序，这种启动程序调试起来太麻烦了，开始 我觉得没有太大问题了，就没有用 虚拟机，重启动几次后
，可把我烦死了，
后来受不了了，才装了一个vmware，这才觉得测试容易些了。

关键是很久没看程序了，我都忘了怎么写的了，我就怕一改动，就多出来一堆bug，
你知道不知道有什么好的可以调试启动代码的调试器或者方法？我自己就用最土的print。

期待 您推荐一个好的调试方法

以下是引用lyh728在2003-11-20 19:26:38的发言：
to Wengier斑竹:
         
   我开始就猜测 你在国外，呵呵

不用猜了....他在加拿大呢

如果仅仅依靠软件调试器，我想应该没有什么好的办法了，或者你可以编写一些与print功能类似的汇编宏，简化你每回print的操作?

唉！测试 GRUB FOR DOS 是一个长期的、艰巨的、复杂的任务啊！就为照顾好 win98，很是需要时间了。

下面看看我的一部分测试：

map --read-only (hd0) (hd0)

chainloader (hd0)+1

boot

上述命令是用只读访问 C: 盘。【简单起见，我们以后说 C: 盘就是指第一个硬盘驱动器，不是指 DOS 的逻辑 C: 盘。同样 D: 也是指第二个硬盘驱动器，不是逻辑 D: 盘。】

原以为这样启动 win98 要失败的，结果，居然成功了！在启动之初，出现两次信息：

write protect error writing drive C:

Abort, Retry, Fail ?

按 F 就可以继续启动。这样进入 win98 之后，C: 盘并非写保护，仍然可以写入文件。这一点早就料到了。由于 C: 盘不使用 BIOS，所以，C: 盘不再写保护。win98 对 C: 盘实施的是 “保护模式的磁盘访问”。

再看看这个测试：

map --read-only --disable-chs-mode (hd0) (hd0)

chainloader (hd0)+1

boot

这时，windows 终于不能启动了。禁止 CHS 后，win98 的启动程序找不到 C: 盘了，由此可见，win98 在启动的时候是用 CHS 方式来读取 C: 盘的，而不用 LBA 方式。

换一换，这次用 D: 盘，看看这个测试：

map --read-only --disable-chs-mode (hd1) (hd1)

chainloader (hd0)+1

boot

这次顺利进入 win98，并且在 win98 中访问 D: 盘很正常。这也是意料之中的，因为 win98 对 D: 盘实施的是 “保护模式的磁盘访问”。所以，虽然 DOS 访问 D: 盘可能不行，但 win98 下却能够访问。

再看看这个奇特的测试：

map (hd0) (hd1)

map (hd1) (hd0)

map (hd1,0)/dos.img (fd0)

chainloader (hd1)+1

boot

把 C: 盘和 D: 盘交换，进入 win98 之后，A: 盘无法访问了。这是由于 A: 仍然在使用 BIOS，而在 BIOS 中，A: 被映射到 (hd1) 的一块区域，此时 BIOS 不知道 win98 已经把 C盘 和 D盘 的硬件信息都交换了，它还盲目地在原来 BIOS 的那个盘上去找自己的扇区，当然找不到了。这时，如果仅仅读出 A: 盘是不要紧的。然而如果此时写入 A: 盘，那就太危险！！！！了，因为很盲目地写到另外一个错误的盘上，可能把那个磁盘全毁了，不管毁掉多少，哪怕只是毁掉一个扇区，都是不对的。我们还应当意识到，此时假如仅仅毁掉了不重要的扇区，那么这其实是最糟糕的了，因为我们可能发现不了这是个错误，还以为是很正常的呢！！

总之，win98 的 “保护模式磁盘访问” 是一层独立于 BIOS 的磁盘访问。弄不好，这两个访问会冲突、会打架的，也潜藏着巨大的危险性。所以，我们所有的使用者都得小心，也因此，我们测试的时间会拉得很长很长，毕竟安全第一嘛，宁愿没有这个软件，也不要一个危险的软件。

有点线索了.

在 c:\windows\ios.log 中列出了 mbrint13.sys , 这说明 windows 把这个仿真程序当成病毒来对待了(注: 这一点是肯定的), 所以它要对 A: 盘进行破坏!!!! (注: 这只是猜测)

在 google 中搜索 mbrint13 可以找到这方面的信息.

=========

另外, 发现 grub_t07 , grub_t08 有一个小的 BUG, 导致 int13 扩展功能引起死机. 已经解决, 但现在先不发布更新程序(因为这个 BUG 的影响不大, 所以等到下次再一并更新).

支持，不懂编程帮不上忙了，抱歉。

不懂编程大概是谦虚. 学一学, 不会也得会了. 比如, 我也不懂, 但从 google 上就能找到很多资料了. 为了解决一个问题, 可以逼着你从不会到会.

这次 windows 把 MBR 之前加载的 int13 挂接程序当做病毒来对待, 出现很多异常情况. 现在发现在 DOS 窗口下使用 int13 不正常, 得到错误的结果, 很可能这就是最后的原因(我觉得几乎有 100% 的可能性是这个原因). 现在得考虑为 windows 除错了, 我下载了 SoftICE , 但还没有安装. 真希望有个熟悉 SoftICE 的老兄来作这个除错呀. 唉! SoftICE 很强大, 但是我不太熟悉它, 还不知道能否干掉这个 BUG.

以下是引用不点在2003-11-26 14:26:07的发言：
不懂编程大概是谦虚. 学一学, 不会也得会了. 比如, 我也不懂, 但从 google 上就能找到很多资料了. 为了解决一个问题, 可以逼着你从不会到会.

这次 windows 把 MBR 之前加载的 int13 挂接程序当做病毒来对待, 出现很多异常情况. 现在发现在 DOS 窗口下使用 int13 不正常, 得到错误的结果, 很可能这就是最后的原因(我觉得几乎有 100% 的可能性是这个原因). 现在得考虑为 windows 除错了, 我下载了 SoftICE , 但还没有安装. 真希望有个熟悉 SoftICE 的老兄来作这个除错呀. 唉! SoftICE 很强大, 但是我不太熟悉它, 还不知道能否干掉这个 BUG.

You can try to add

mbrint13.sys

into \windows\ios.ini

under

to make Win98 think that mbrint13.sys is safe.

See if it works for you.

谢谢 windrv 兄, 这个已经试验过了, must_chain, must_not_chain, 等等都试验过了, 全都不行, 当用 must_chain 从而使用 real mode mapper 时, win98 早早死掉, 根本进不去了. windows 认定这是一个病毒, 没有办法为它加载保护模式的驱动程序.

只有一种例外: OnTrack 公司的 geometry translation 软件可以被 windows 识别, 但是我不知道怎么让 windows 认为 MBR 上的 INT13 是 OnTrack 公司的软件.

以下是引用不点在2003-11-26 18:36:14的发言：
谢谢 windrv 兄, 这个已经试验过了, must_chain, must_not_chain, 等等都试验过了, 全都不行, 当用 must_chain 从而使用 real mode mapper 时, win98 早早死掉, 根本进不去了. windows 认定这是一个病毒, 没有办法为它加载保护模式的驱动程序.

只有一种例外: OnTrack 公司的 geometry translation 软件可以被 windows 识别, 但是我不知道怎么让 windows 认为 MBR 上的 INT13 是 OnTrack 公司的软件.

I am not a very technical man. But I remember one scenario when my staff developed one of our products as follows:

when we map or substitute one driver letter for another with our real-mode assembly DOS program, not using Windows' SUBST command; all drives enter into real-mode under Win98. However, when we call another DOS program doing something not essential within our DOS program before issuing win.com, after entering in Windows,Win98 can recognize all hard disk drives, using Protected Mode.

This is strange.

If we are not so busy, may be we can later learn from you what is happening.

I am not a very technical man. But I remember one scenario when my staff developed one of our products as follows:

when we map or substitute one driver letter for another with our real-mode assembly DOS program, not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when we call another DOS program doing something not essential within our DOS program before issuing win.com,
after entering in Windows,Win98 can recognize all hard disk drives, using Protected Mode.

This is strange.

If we are not so busy, may be we can later learn from you what is happening

这一行太长， 在我的 mozilla 浏览器中显示得不正常，所以用回车截断：

when we map or substitute one driver letter for another with our real-mode assembly DOS program,
not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when
we call another DOS program doing something not essential within our DOS program before issuing
win.com, after entering in Windows, Win98 can recognize all hard disk drives, using Protected Mode.

＝＝＝＝＝＝＝

确实奇怪， 而且，我也是初次接触这类问题，我觉得恐怕是您的技术人员能够帮助我了，他们毕竟长期接触这方面的东西。我觉得，其一，win98 可能存在 bug，尤其是您的公司所遇到的奇怪情况，加上我们这里的 int13 所遇到的情况，都说明了这一点。其二，也存在这样的可能性，那就是，win98 把我们当作病毒来对待，它故意让系统在这种环境下运行失常。我在 DOS BOX 中用 debug 运行 int13 来读取某些扇区，这些扇区的第 2n 个字节都是对的，而第 2n+1 个字节都是 0。也就是说每隔一个字节都是 0，其余的半数字节都是对的。根据这个，我就觉得并非是 BUG 这么简单了，而是故意的。想想看，什么软件读扇区的时候会发生这种错误呢？根本不可能，不管是用 BIOS，还是用 IO port 硬件直接读写，都是整个扇区一齐读出，不是一个字节一个字节这样读出。所以，要错的话，应当是整个扇区全部面目全非，要对的话，就都对，丝毫也不差。所以，像上述所说交替出现错误，我认为几乎 100% 是故意制造的。 因此，我们查找 win98 的这段程序，把它纠正过来，应当就 OK 了。同样的，您公司所遇到的情况，（我觉得）也可以通过调试 win98 来解决（当然您公司的情况不很严重，所以也可以不解决）。

以下是引用不点在2003-11-27 19:11:06的发言：
这一行太长， 在我的 mozilla 浏览器中显示得不正常，所以用回车截断：

when we map or substitute one driver letter for another with our real-mode assembly DOS program,
not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when
we call another DOS program doing something not essential within our DOS program before issuing
win.com, after entering in Windows, Win98 can recognize all hard disk drives, using Protected Mode.

＝＝＝＝＝＝＝

确实奇怪， 而且，我也是初次接触这类问题，我觉得恐怕是您的技术人员能够帮助我了，他们毕竟长期接触这方面的东西。我觉得，其一，win98 可能存在 bug，尤其是您的公司所遇到的奇怪情况，加上我们这里的 int13 所遇到的情况，都说明了这一点。其二，也存在这样的可能性，那就是，win98 把我们当作病毒来对待，它故意让系统在这种环境下运行失常。我在 DOS BOX 中用 debug 运行 int13 来读取某些扇区，这些扇区的第 2n 个字节都是对的，而第 2n+1 个字节都是 0。也就是说每隔一个字节都是 0，其余的半数字节都是对的。根据这个，我就觉得并非是 BUG 这么简单了，而是故意的。想想看，什么软件读扇区的时候会发生这种错误呢？根本不可能，不管是用 BIOS，还是用 IO port 硬件直接读写，都是整个扇区一齐读出，不是一个字节一个字节这样读出。所以，要错的话，应当是整个扇区全部面目全非，要对的话，就都对，丝毫也不差。所以，像上述所说交替出现错误，我认为几乎 100% 是故意制造的。 因此，我们查找 win98 的这段程序，把它纠正过来，应当就 OK 了。同样的，您公司所遇到的情况，（我觉得）也可以通过调试 win98 来解决（当然您公司的情况不很严重，所以也可以不解决）。

Hi, are you the author of the project Grub for Dos?

We are at Guangzhou. And where are you?

If we are close together, we can meet to help out each other.

是的，我是 tinybit。我现在居住在北方，不过由于网络这么方便，那么地理上的障碍应该是微不足道的了。网络这个世界既是虚拟的，又是真实的；我喜欢网络，甚至胜过喜欢真实世界。我也很喜欢技术，只要是技术，只要我力所能及，我就会尽力，而不管问题来自何方。