中国DOS联盟

已经试过好几遍了，都是如此。有关过程的输入输出显示如上所贴。即使我有输入错误的话（指语法上的）你的程序应该不会执行而是给出用法提示的吧。而且有趣的是，每次保存得到错误扇区的内容都不一样，呵呵。 延迟主要出现在 "100% sectors done." 和显示最后一行的 "Done." 之间。我只读一个扇区，就算是386的机器也不可能有让人能够感觉得到的延迟啊。你写一万个扇区大约才只需要2、3秒，而我估计着大约有半秒的延迟。 关于我的 DOS 内存配置环境可以参看这里： www.cn-dos.net/forum ... 使用的 DOS 版本为 MS-DOS 6.22。 奇怪的是，我在 Windows98 的 DOS 窗口下测试反倒可以得到正确的结果（仅读MBR） 不过，现在，告诉你个好消息，我找到问题的所在了。原来是由于加载了 DOS 下的 DMA 驱动引起。我现在使用的 DMA 驱动是 UDMA2 2.7 版。 另外我不懂你用的是什么编译器，为什么可以混合使用 C 和 C++ 的注释方式？

DOS倒下了，但永远不死 DOS NEVER DIES ! 投票调查： www.cn-dos.net/forum/v ... 本人尚未解决的疑难问题： www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ...

哦，感谢参与测试！ 写这个程序，并没有考虑诸如 CPU类型，操作系统类型和有关硬盘的驱动的兼容性 等等问题，所以出一些问题，也是在所难免的，毕竟不是商用软件。。 程序的开发配置： 奔3，733 MSDOS 7.1 Turbo C ＋＋ 3.0（如用Borland C++ 3.1,也基本一样） 一般，C++编译器都是兼容C规范的（包括注释），反过来自然就不行了。

按理，BIOS层次的调用应该和CPU（只要是X86兼容指令的）、OS、HDD无关。我曾经写过一个整个分区链表的备份和恢复程序，在我用过的机器上测试都没什么问题。不过我是用纯汇编写的。由于我没怎么用过 C，所以还没完全看懂你的源程序。

DOS倒下了，但永远不死 DOS NEVER DIES ! 投票调查： www.cn-dos.net/forum/v ... 本人尚未解决的疑难问题： www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ...

恩，处理分区链表，还是很复杂的，因为就要费很大的事从第一分区表去依次找出后面的分区表，尤其是要处理扩展分区，及其中的逻辑驱动器。。。还是挺复杂的。 你懂汇编，理解C应该没什么大问题吧？ 熟悉一下语法就行了。。 （刚刚为源码加了基本原理，注释，重新上传了，理解起来就容易一些。。） 现在又在98的MS-DOS提示符下测试，除了不支持扩展INT13外，一切都准确无误（用SPFDISK做验证），而且写一万个扇区，一秒钟都不要！（可能是磁盘高速缓冲驱动的作用，我在纯DOS下，是没有加载任何磁盘缓冲驱动的，所以需要3秒左右。。） 但不知道为什么不支持扩展INT13？ 是不是98加了什么硬盘限制？ [ Last edited by GOTOmsdos on 2006-7-9 at 23:56 ]

是否支持 Int13h ext 不是由 OS 来决定的。请问你的这个不支持是怎么个不支持，有没有什么提示。你是98的 DOS 窗口还是 MS-DOS 7.10。

DOS倒下了，但永远不死 DOS NEVER DIES ! 投票调查： www.cn-dos.net/forum/v ... 本人尚未解决的疑难问题： www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ... www.cn-dos.net/forum/v ...

是98 MSDOS窗口 程序提示不支持（代码写了检测，用扩展INT13的41号功能，AH返回1和BX不是AA55就表示不支持。。）是啊，照理，支持不支持是由硬盘控制器和BIOS决定的啊 不理解。。 另外，我写的是 返回0和AA55都要满足， 是不是只要返回0就行了？（不一定返回AA55？） 等一下，我试一下 。。

哇！ 有重大发现！ 把检测代码改成只要返回AA55就表示支持了！ 程序运行，支持的，而且运行后的结果跟SPFDISK的一样！ 说明，有关扩展13的资料出了问题！支持的话，AH不一定返回0，或者会有特殊情况等等（比如操作系统关系，如DMA，磁盘缓冲驱动等等），不会保证返回0。而会返回AA55的。。 这样，代码又得到了改进。。

在WIN98中流传着一个误解，说WIN中无法写主引导区MBR，也无法写扇区，包括DISKGEN，诺顿的DISKEDIT工具包，那时他们都在程序中加入了检测操作系统是否为WIN的功能，如果是WIN就提示或者直接退出。 我在98的MSDOS下用qbasic做硬盘工具的时候也以为是这样，在运用扩展INT13的实践中，我做MBR清0，真的就清掉了，也可以写任意的扇区，但是用老的INT13的确只能读无法写。 希望能给大家一个启示。 我的程序把6.4G的老硬盘完全清0，总共用了7分钟左右，不知道用C或者是汇编写的同类程序时间快多少。

我(QB45)的照片与简历 www.programfan.com ...

不懂 qbasic， BASIC系列可能是解释性的吧？ 速度可能会慢一些 据说，C的效率只比汇编差那么一点点 刚才为我的代码加上了，如果读写出错，给出提示 更新了

TO DOSforever 刚刚加了如果出错的提示，代码更新了 其中有一项好像跟DMA设置有关 很希望你有时间在测试一下，看是不是有相应的出错提示出来？ 我机子试了，好像扩展13的出错提示会出来，但是同样的错误，基本的13中断不给出错提示，好像都认为是成功的（有意换上坏硬盘，扩展13能给出 STATUS ERROR的提示），这点，我搞不懂。。。 [ Last edited by GOTOmsdos on 2006-7-11 at 15:37 ]

TO DOSFOREVER 能不能把你的UDMA DOS驱动贴上来,我也来试一试 ? ********* 刚刚下载了UDMA2，说明中写了只支持 VIA 主板芯片组啊 你主板是吗？ [ Last edited by GOTOmsdos on 2006-7-11 at 12:26 ]

我 的 網 站 - optimizr.dyndns.org

不记得从QuickBASIC那个版本开始（好像是4.0） QB不是以纯解释方式运行的 而是编译成P代码，运行时再即时编译（与现在Java、.Net用的技术差不多） 所以速度并没慢多少 而且现在是调用中断 时间主要耗在中断服务程序上 即此时的瓶颈是硬盘读写速度 可笑的是 十多年前QB使用P代码和即时编译仍被人认为是低效的解释执行过程 而现在Java、.Net鼓吹虚拟机技术 越来越感觉的这几十年来计算机科学领域并没有太大的进展 只是随着硬件技术的发展，应用领域急剧的扩展而以

人类存在的目的就是试图理解人类为何存在

Originally posted by zyl910 at 2006-7-11 15:20: 不记得从QuickBASIC那个版本开始（好像是4.0） QB不是以纯解释方式运行的 而是编译成P代码，运行时再即时编译（与现在Java、.Net用的技术差不多） 扠...

兄台此言差以，即时编译（JIT，Just In Time）技术与语言效率并没有特别大的关系。主要是语言本身的设计问题。 具体来说，使用了垃圾回收和自动存储管理；无类型变量；反射等机制的语言本身就是低效的。这样的语言即使直接编译成机器码也快不起来，有意思的是，这样做甚至会更慢，IBM知识库里有一篇文章专门测量了各种情况下，Java运行的效率：Weighing in on Java native compilation（www-128.ibm.com ...）。 当然，用C写出来的程序也不一定就比用QB/Java之类的来得快，程序运行效率取决于一些其它条件： 1. 程序使用的算法 例如：用C写的冒泡排序算法和QB写的快速排序算法相比，如果要输入的集合足够大，QB的快速排序一定比C的冒泡排序快。 2. 程序是否大量使用外挂模块 例如：极端情况下，可以构造出这样的代码，VB程序直接调用某个DLL和COM组件的入口，然后所有操作都由这些由C或其它语言实现的外挂组件完成。 等等。 不使用相同算法的比较不是语言效率间的对决，而是程序员个人技艺间的碰撞。 大部分运行时间都依赖外挂组件的比较同样也不能看作两种语言运行效率间的公平测试。 [ Last edited by asbai on 2006-7-11 at 20:48 ]

代码又更新了..