标题: ****压缩分卷！扇区/镜象/扇区读写] 迷你硬盘读写器完工了Ｂ [打印本页]
作者: GOTOmsdos 时间: 2006-7-8 02:29 标题: ****压缩分卷！扇区/镜象/扇区读写] 迷你硬盘读写器完工了Ｂ
DOS下迷你硬盘读写器终于完工了！
可读写绝对扇区，支持大硬盘，U盘(需加载驱动)，软盘。。
由于代码效率高，速度很快。
初步通过测试。
最后在自己的机子上大胆进行了写测试，即用坏数据写入硬盘，硬盘崩溃后，再用本程序把预先备份的数据恢复到硬盘，结果硬盘完好如初。。
有源码大家玩玩。。。
对不起：第一次传错了可执行文件，现在重传了。。
刚加了如果读写出错，给原因的提示
换成了 C 的注释，这样，不用TC3（BC31），TC2就可编译了
刚解决了基本INT13不出现出错提示的BUG..
除了考虑到能读写2048GB,没有加入起始扇区和要处理的扇区参数的对误输入负数的检测外(,否则的话,只能读写1024GB左右了.)对其他几个输入参数都进行了检测..
考虑 DOSFOREVER 的中肯意见
今天 加了 如果 不支持扩展13中断，就先获取硬盘本身的参数来显示出来，调用基本13中断以其参数CHS值来读写，这样就兼容了 非 磁头255，扇区63 的硬盘（也就是很老的硬盘），这样程序的兼容性就很强了。。
也加入了读写 "非1.44mb"软盘的功能， 说明见主帖。。。
另，即使支持扩展，也根据扩展48号功能，获取硬盘参数，显示出来。
显示出硬盘参数，能让用户心中有数。。。
另，把扩展13的读写缓冲增为100扇区的字节数，这样速度就更快了！
（不能再超过了，否则，就超过了文件读写的最大数了）
程序到此 ，基本告一段落了。。。
需要在扩展程序功能的，可在程序上再加上去吧。。
欢迎大家下载玩玩。。。
希望对有兴趣的有点帮助。。
***********************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%
已成功加入了压缩和分卷功能！并采用LINUX帮助风格。。。
初步通过了测试！欢迎试玩！。。
主帖程序更新了！
[ Last edited by GOTOmsdos on 2006-8-8 at 12:14 ]
附件 1:mydisk.rar (2006-8-6 22:18, 170.57 K, 下载附件所需积分 1点 ,下载次数： 339)
作者: asbai 时间: 2006-7-8 03:26
支持一下GOTOmsdos兄！
作者: crshen 时间: 2006-7-8 12:18
深更半夜发贴子，看来颇费了一番精力，估计就是 C语言和汇编语言结合的 扩展INT13编程吧，好像暂时用不着，不过还是下载看看，支持
作者: GOTOmsdos 时间: 2006-7-8 12:32
感谢关注，
这几天在弄硬盘读写，DOS和2K/XP的都有，刚全部完工，都在熬夜。。
主要是扩展INT13和基本INT13，INT25,INT26结合。。
由于是命令行方式，所以，如果有程序需要以命令行方式读写硬盘扇区的话，就能用它解决问题了。。
[ Last edited by GOTOmsdos on 2006-7-8 at 12:35 ]
作者: gmy 时间: 2006-7-8 17:59
支持
作者: MySOFT2006 时间: 2006-7-8 18:40
辛苦了，学习一下。
作者: GOTOmsdos 时间: 2006-7-8 23:49
源码又更新了
作者: johnsonlam 时间: 2006-7-9 02:03
| Quote: | |
|
支 持 ! 辛 苦 了 gotoMSDOS 兄 熬 夜 編 程 ...
請 問 甚 麼 是 U 盤 ?
有 些 意 見 :
1) 記 得 從 前 玩 Apple][ 時 也 有 類 似 東 西 叫 RWTS (ReadWriteTrackSector) ， 這 程 序 其 實 叫 RWSector 或 RWLBA 也 不 錯
2) 幫 助 顯 示 可 以 這 樣 寫 嗎 ? 好 像 清 楚 一 點 ...
dolba [r|w] [driveNum] [startSector] [sectorToDo] [file]
Example:
Read to file: dolba r 2 0 254 c:\backup
Write from file: dolba w 2 0 c:\backup
謝 謝 分 享 !Example:
Read to file: dolba r 2 0 254 c:\backup
Write from file: dolba w 2 0 c:\backup
作者: Michael 时间: 2006-7-9 02:16
回楼上，U盘就是flash drive
作者: johnsonlam 时间: 2006-7-9 02:33
| Quote: | |
|
謝 謝 ， 我 們 這 裡 叫 "手 指" 。
作者: GOTOmsdos 时间: 2006-7-9 03:32
感谢关注
dolba [r|w] [driveNum] [startSector] [sectorToDo] [file]
这样好像不妥当
因为只有 当 w 时 才可 省略 sectorToDo
所以写成两行 才清楚:
dolba r|w driveNum startSector sectorToDo file
dolba w driveNum startSector file
[ Last edited by GOTOmsdos on 2006-7-9 at 03:33 ]
作者: DOSforever 时间: 2006-7-9 04:43
下载后测试了一下，就以读取第一个硬盘的主引导扇区为例，过程显示如下：
dolba r 2 0 1 sec0
dolba version 1.0 Copyright (c) 2006 by GOTOmsdos Email: tdaim@sina.com
Read :
Drive 2
Starting sector 0
1 Sectors
To :
File "sec0" ? (Y/N)y
Extended int13 supported.
Press Esc to stop.
100% sectors done.
Done.
没想到读出的不是主引导扇区的内容，也不知道是哪个扇区的。但如果使用 DOS 的缺省环境，即不使用 config.sys 和 autoexec.bat 的内存配置环境下读出的内容却正常。另外，按理做一个扇区的操作应该是很快的事，即便是几个扇区，在现在的机器上也应该在瞬间完成，但我这次读取MBR到文件的测试过程却可以察觉到人可以感觉得到的延迟（在有 config.sys 和 autoexec.bat 的内存配置环境下）。
作者: johnsonlam 时间: 2006-7-9 13:45
| Quote: | |
|
我 原 意 是 把 參 數 括 起 來 ， 沒 括 起 看 得 不 清 楚 ， 有 範 例 參 考 比 較 不 易 出 錯 。
作者: GOTOmsdos 时间: 2006-7-9 17:03
TO DOSforever
看了你说的情况，不知道是什么原因，如果你的输入没问题的话，找你说的，跟CONFIG.SYS,AUTOEXEC.BAT有关。
如果这是真的，就有点匪夷所思了，照理说，CONFIG.SYS,AUTOEXEC.BAT配置不可能对硬盘结构造成什么影响(我也一直用着其配置)
不妨把你的造成“影响”的CONFIG.SYS,AUTOEXEC.BAT配置贴出来，看一下。
另，最好重试一下，确认操作输入无误。。
建议烦请您，作个小试验吧：
在同样的CONFIG.SYS,AUTOEXEC.BAT配置下，试一下用其他读写硬盘扇区的工具也作同样的事，看看结果如何？如果此工具成功，而我的程序不成功，那就说明我的程序前考虑了。。
至于速度，
我的机子是733，应该说较老了， 速度非成快，（感觉比SPFDISK,DISKEDIT 还要快一点，可能没有引入 写校验，因为我觉得没必要，况且影响速度）
比如，写一万个扇区，大约只需要2,3秒。10万个扇区大约在半分钟左右。
这几天一直在测试，先用SPFDISK存一遍，然后用我的程序存，然后 FC /B 他们，
都一样。 并进行了好几次写操作，目前没有问题（有几个BUG，已改正了）
其他坛友，如有兴趣，可测试一下读操作。。看结果怎样？
最后，测8.4g外， 就是超过16434494扇区。
刚刚又改进更新了代码。。
[ Last edited by GOTOmsdos on 2006-7-9 at 20:02 ]
作者: GOTOmsdos 时间: 2006-7-9 17:08
| Quote: | |
|
可是方括号是表示可选的意思啊！不是表美观的啊。。
作者: DOSforever 时间: 2006-7-9 21:06
已经试过好几遍了，都是如此。有关过程的输入输出显示如上所贴。即使我有输入错误的话（指语法上的）你的程序应该不会执行而是给出用法提示的吧。而且有趣的是，每次保存得到错误扇区的内容都不一样，呵呵。
延迟主要出现在 "100% sectors done." 和显示最后一行的 "Done." 之间。我只读一个扇区，就算是386的机器也不可能有让人能够感觉得到的延迟啊。你写一万个扇区大约才只需要2、3秒，而我估计着大约有半秒的延迟。
关于我的 DOS 内存配置环境可以参看这里：
http://www.cn-dos.net/forum/viewthread.php?tid=21215
使用的 DOS 版本为 MS-DOS 6.22。
奇怪的是，我在 Windows98 的 DOS 窗口下测试反倒可以得到正确的结果（仅读MBR）
不过，现在，告诉你个好消息，我找到问题的所在了。原来是由于加载了 DOS 下的 DMA 驱动引起。我现在使用的 DMA 驱动是 UDMA2 2.7 版。
另外我不懂你用的是什么编译器，为什么可以混合使用 C 和 C++ 的注释方式？
作者: GOTOmsdos 时间: 2006-7-9 22:01
哦，感谢参与测试！
写这个程序，并没有考虑诸如 CPU类型，操作系统类型和有关硬盘的驱动的兼容性
等等问题，所以出一些问题，也是在所难免的，毕竟不是商用软件。。
程序的开发配置：
奔3，733
MSDOS 7.1
Turbo C ＋＋ 3.0（如用Borland C++ 3.1,也基本一样）
一般，C++编译器都是兼容C规范的（包括注释），反过来自然就不行了。
作者: DOSforever 时间: 2006-7-9 23:27
按理，BIOS层次的调用应该和CPU（只要是X86兼容指令的）、OS、HDD无关。我曾经写过一个整个分区链表的备份和恢复程序，在我用过的机器上测试都没什么问题。不过我是用纯汇编写的。由于我没怎么用过 C，所以还没完全看懂你的源程序。
作者: GOTOmsdos 时间: 2006-7-9 23:43
恩，处理分区链表，还是很复杂的，因为就要费很大的事从第一分区表去依次找出后面的分区表，尤其是要处理扩展分区，及其中的逻辑驱动器。。。还是挺复杂的。
你懂汇编，理解C应该没什么大问题吧？ 熟悉一下语法就行了。。
（刚刚为源码加了基本原理，注释，重新上传了，理解起来就容易一些。。）
现在又在98的MS-DOS提示符下测试，除了不支持扩展INT13外，一切都准确无误（用SPFDISK做验证），而且写一万个扇区，一秒钟都不要！（可能是磁盘高速缓冲驱动的作用，我在纯DOS下，是没有加载任何磁盘缓冲驱动的，所以需要3秒左右。。）
但不知道为什么不支持扩展INT13？
是不是98加了什么硬盘限制？
[ Last edited by GOTOmsdos on 2006-7-9 at 23:56 ]
作者: DOSforever 时间: 2006-7-9 23:53
是否支持 Int13h ext 不是由 OS 来决定的。请问你的这个不支持是怎么个不支持，有没有什么提示。你是98的 DOS 窗口还是 MS-DOS 7.10。
作者: GOTOmsdos 时间: 2006-7-10 00:02
是98 MSDOS窗口
程序提示不支持（代码写了检测，用扩展INT13的41号功能，AH返回1和BX不是AA55就表示不支持。。）是啊，照理，支持不支持是由硬盘控制器和BIOS决定的啊
不理解。。
另外，我写的是 返回0和AA55都要满足，
是不是只要返回0就行了？（不一定返回AA55？）
等一下，我试一下 。。
作者: GOTOmsdos 时间: 2006-7-10 00:26
哇！ 有重大发现！
把检测代码改成只要返回AA55就表示支持了！
程序运行，支持的，而且运行后的结果跟SPFDISK的一样！
说明，有关扩展13的资料出了问题！支持的话，AH不一定返回0，或者会有特殊情况等等（比如操作系统关系，如DMA，磁盘缓冲驱动等等），不会保证返回0。而会返回AA55的。。
这样，代码又得到了改进。。
作者: qb45 时间: 2006-7-10 07:38
在WIN98中流传着一个误解，说WIN中无法写主引导区MBR，也无法写扇区，包括DISKGEN，诺顿的DISKEDIT工具包，那时他们都在程序中加入了检测操作系统是否为WIN的功能，如果是WIN就提示或者直接退出。
我在98的MSDOS下用qbasic做硬盘工具的时候也以为是这样，在运用扩展INT13的实践中，我做MBR清0，真的就清掉了，也可以写任意的扇区，但是用老的INT13的确只能读无法写。
希望能给大家一个启示。
我的程序把6.4G的老硬盘完全清0，总共用了7分钟左右，不知道用C或者是汇编写的同类程序时间快多少。
作者: GOTOmsdos 时间: 2006-7-10 22:29
不懂 qbasic， BASIC系列可能是解释性的吧？ 速度可能会慢一些
据说，C的效率只比汇编差那么一点点
刚才为我的代码加上了，如果读写出错，给出提示
更新了
作者: GOTOmsdos 时间: 2006-7-11 02:59
TO DOSforever
刚刚加了如果出错的提示，代码更新了
其中有一项好像跟DMA设置有关
很希望你有时间在测试一下，看是不是有相应的出错提示出来？
我机子试了，好像扩展13的出错提示会出来，但是同样的错误，基本的13中断不给出错提示，好像都认为是成功的（有意换上坏硬盘，扩展13能给出 STATUS ERROR的提示），这点，我搞不懂。。。
[ Last edited by GOTOmsdos on 2006-7-11 at 15:37 ]
作者: GOTOmsdos 时间: 2006-7-11 11:20
TO DOSFOREVER
能不能把你的UDMA DOS驱动贴上来,我也来试一试 ?
*********
刚刚下载了UDMA2，说明中写了只支持 VIA 主板芯片组啊
你主板是吗？
[ Last edited by GOTOmsdos on 2006-7-11 at 12:26 ]
作者: johnsonlam 时间: 2006-7-11 14:46
| Quote: | |
|
你 說 的 是 VIA 提 供 的 UDMA2 嗎 ?
如 果 沒 有 作 者 名 字 的 UDMA2.SYS ， 就 是 Jack Ellis 的 , 很 舊 已 被 QDMA 取 代 。
http://johnson.tmfc.net/dos
單 擊 左 面 的 QDMA 下 載 試 試 吧 !
作者: zyl910 时间: 2006-7-11 15:20
不记得从QuickBASIC那个版本开始（好像是4.0）
QB不是以纯解释方式运行的
而是编译成P代码，运行时再即时编译（与现在Java、.Net用的技术差不多）
所以速度并没慢多少
而且现在是调用中断
时间主要耗在中断服务程序上
即此时的瓶颈是硬盘读写速度
可笑的是
十多年前QB使用P代码和即时编译仍被人认为是低效的解释执行过程
而现在Java、.Net鼓吹虚拟机技术
越来越感觉的这几十年来计算机科学领域并没有太大的进展
只是随着硬件技术的发展，应用领域急剧的扩展而以
作者: asbai 时间: 2006-7-11 20:46
| Quote: | |
|
兄台此言差以，即时编译（JIT，Just In Time）技术与语言效率并没有特别大的关系。主要是语言本身的设计问题。
具体来说，使用了垃圾回收和自动存储管理；无类型变量；反射等机制的语言本身就是低效的。这样的语言即使直接编译成机器码也快不起来，有意思的是，这样做甚至会更慢，IBM知识库里有一篇文章专门测量了各种情况下，Java运行的效率：Weighing in on Java native compilation（http://www-128.ibm.com/developerworks/library/j-native.html）。
当然，用C写出来的程序也不一定就比用QB/Java之类的来得快，程序运行效率取决于一些其它条件：
1. 程序使用的算法
例如：用C写的冒泡排序算法和QB写的快速排序算法相比，如果要输入的集合足够大，QB的快速排序一定比C的冒泡排序快。
2. 程序是否大量使用外挂模块
例如：极端情况下，可以构造出这样的代码，VB程序直接调用某个DLL和COM组件的入口，然后所有操作都由这些由C或其它语言实现的外挂组件完成。
等等。
不使用相同算法的比较不是语言效率间的对决，而是程序员个人技艺间的碰撞。
大部分运行时间都依赖外挂组件的比较同样也不能看作两种语言运行效率间的公平测试。
[ Last edited by asbai on 2006-7-11 at 20:48 ]
作者: GOTOmsdos 时间: 2006-7-11 22:21
代码又更新了..
作者: zyl910 时间: 2006-7-11 22:23
其实，我的主要意思是这段话：
| Quote: | |
|
| Quote: | |
|
既然那些因素会影响程序效率，那为什么不绕开它呢。优化的技巧是多种多样的，必须结合平台和编程语言特性，扬长避短。
垃圾回收机制的确会影响性能，但它也有好处的。
先不用STL等数据结构库情况下用那些纯编译型的编程语言写个链表程序
再用Java、.Net写同样的程序（当然不是使用它们的类库，而是自己一个个地new出链表节点）
现在填充大量节点数据看看
你会郁闷的发现，那些纯编译的代码居然没有虚拟机速度快
这是因为，一般编程工具的内存分配函数调用的是操作系统的内存分配功能，而操作系统的堆分配函数本来就不是为分配大量小型对象服务的。所以许多数据结构经典教材会推荐我们自己写个内存分配器，专门处理链表节点这样的小型对象内存分配，这就是为什么现在推崇STL。
而那圾回收机制，最初就是为了解决这样的问题而设计的，能够应付i这样的大量小型对象分配问题。
其实我也不喜欢像Java、.Net，因为它们是专门为Web服务设计的，所以许多测试结果具有欺骗性。但就是因为这样，我曾经认真分析过它们性能。结果发现，对于现在那些编程初学者所接触的那些领域，Java、.Net已经优化到了极致，看起来似乎确实速度很快。而对于传统领域，那当然不能比的。
[ Last edited by zyl910 on 2006-7-11 at 22:25 ]
作者: DOSforever 时间: 2006-7-11 22:50
我的印象中 BASIC 有解释型的也有编译型的，GWBASIC、QBASIC 就是解释型的，QuickBASIC 是编译型的，但 GWBASIC 在保存源程序的时候可以以P参数把源程序以加密的形式保存起来，即看到的不再是文本文件。不知 "zyl910" 所说的P代码是不是指的就是这个。QBASIC 好象没这个功能。QuickBASIC 我想应该是编译成独立的可执行文件，运行的时候不需要 QuickBASIC 的环境支持，由于我没用过，所以只是我想编译型的应该就是这样的。到底怎样，还是请咱们的 "qb45" 来说一下吧。呵呵
Re: gogo
不知你找到的 UDMA 驱动是哪里下的，确实是有一个 UDMA for DOS 的驱动只能用在 VIA 芯片组的主板上，因为它就是 VIA 开发的，不过已经很老了，在我694X的主板上都不能用。我目前用的 UDMA 驱动确实如 "johnsonlam" 所说的是 Jack Ellis 开发的。而且在它的说明中说
| Quote: | |
|
我用的是 UDMA.SYS 而不是 UDMA2.SYS 。现在，又试用了一下你最新改进过的程序（在你30楼的回帖之前），发现完全可以在我的内存配置环境下得到所要扇区的正确内容！而且没有感觉上的任何延迟。之前的延迟我认为还是和你的程序错误有关。不过我只测试了读，没测试写。呵呵。
顺便说一下，就种类型的小程序而言，我认为执行的速度与什么CPU速度，所使用的编程语言，甚至算法的关系不大。即使有也不是人可以感觉得到的。
另外我大致模模糊糊的看了一下你对不支持 Int13h ext 而用 CHS 方式处理的换算，如果我没理解错的话，你的换算是以假定每道扇区数为63，磁头数为255为基础的，严格的说这是不严密的，你怎么能肯定所有硬盘的每道扇区数都为63，磁头数都为255呢。至少在老硬盘（<8.4G）和新硬盘（>137G）上出现这样参数的可能性几乎没有。即使在这个范围以内的硬盘也只能说大多数的 BIOS 中的 HS 参数如此，因为很有可能由于种种原因，BIOS 识别该硬盘或该硬盘的分区表中的 CHS 参数不是以 LBA 方式识别出的参数出现的。这时候如果你还是以 H=255，S=63 的死参数去换算的话很可能读写的扇区不是所要的扇区。
作者: GOTOmsdos 时间: 2006-7-12 01:45
TO DOSforever:
关于 UDMA：
为了获得跟你一样的问题，我特地下了一些DMA DOS 驱动，试了WENGIER的
UDMA。DYS。 加载后，一切正常，没有你说的错读扇区
下了个UDMA2，说是只用于VIA
不知道你用的是什么UDMA？
关于 扇区换算：
没错，我只是以 H=255，S=63 的参数 去处理的。 当然可能会遇到不兼容的情况，我也考虑过。。
其实，较完善的方式当然是先获取硬盘的参数，再根据此参数去读写
不过，这种 H=255，S=63的实用性还是很广的，大部分的老硬盘都支持，还有新硬盘也支持（因为，新硬盘的控制器，能翻译各种读写方式）
不过，如果老硬盘设成了不兼容H=255，S=63模式，那就有问题了。。
有时间再改进吧。。
关于 我改进过的程序解决了问题：
确实改善更新了好几次（解决了几个BUG），不过，目前还不知道，是哪里代码的改变，解决了你的这个问题。。
刚才 解决了 基本INT13出错提示不显示的BUG。。。很高兴，装上了坏硬盘，都能显示出错原因了！。。。
真想用你的UDMA试一下。。
不是WENGIER的UDMA。SYS 吗？
[ Last edited by GOTOmsdos on 2006-7-12 at 01:52 ]
作者: asbai 时间: 2006-7-12 04:41
回zyl910兄：
既然那些因素会影响程序效率，那为什么不绕开它呢。优化的技巧是多种多样的，必须结合平台和编程语言特性，扬长避短。
■ 呵呵，让兄台见笑了，其实我这是有感而发。记得兄台说过汇编如果不用MMX和SSE等扩展指令，效率和VC比没优势，还举了一个完全使用不同算法的图像处理例子。当时就想说那是因为兄台的算法比起对手当算出神入化，并不是语言之间的公平比较。
垃圾回收机制的确会影响性能，但它也有好处的。
先不用STL等数据结构库情况下用那些纯编译型的编程语言写个链表程序
再用Java、.Net写同样的程序（当然不是使用它们的类库，而是自己一个个地new出链表节点）
现在填充大量节点数据看看
你会郁闷的发现，那些纯编译的代码居然没有虚拟机速度快
这是因为，一般编程工具的内存分配函数调用的是操作系统的内存分配功能，而操作系统的堆分配函数本来就不是为分配大量小型对象服务的。
■ 兄台用的是什么编译器？竟然拥有不带 small heap 的 malloc 和 new ？
■ .net 里似乎没有指针，用它实现链表的话。。。。。
所以许多数据结构经典教材会推荐我们自己写个内存分配器，专门处理链表节点这样的小型对象内存分配，这就是为什么现在推崇STL。
■ STL的容器统统使用标准 operator new 分配空间，对于list来说是每对象调用一次，这方面并不比自己手写的代码有什么优势。只有一个例外是 sgistl 里的池分配策略，不过该策略只是一个备选分配策略，默认不启用，并且不是C++标准兼容的。
■ STL之所以被推崇，是因为它为面向算法的程序设计思想（泛型编程）提供了一个高效的、可扩展的、规范的设计框架。
■ 当年的经典教材之所以推荐写自己的memory pool，主要目的不仅仅是O(1)+的分配效率，更重要的是内存碎片问题。该问题在所有使用分页内存管理的系统中已解决。而且所有现代编译器的标准库里也都有了small heap。
而那圾回收机制，最初就是为了解决这样的问题而设计的，能够应付i这样的大量小型对象分配问题。
■ 解释型语言的垃圾回收算法是伴随着大面积内存扫描的，兄台想说的是预分配和small heap？
■ 垃圾回收的效率是如此的底，而且其内存开销又是如此的高。在C里即使每次内存分配都没有small heap的帮助而直接向操作系统申请内存，其效率也应该垃圾回收。当然，这里有两个问题需要考虑：
■1. 程序运行了多久：垃圾回收是一种轮询机制，在2种情况下，垃圾回收会启动：
1. 内存耗尽－扫描整个内存段以释放不再使用的存储。
2. 轮询间隔到时－扫描所有正在使用的内存段以释放不再需要的存储。
因为伴随着大量扫描，所以垃圾回收的效率相当低。不过，对于一个运行时间不长、内存开销不大的应用来说，因为以上2点恰好都没满足，所以看不出来它的低效。
■2. 正在使用的操作系统：像DOS这样对内存管理较差的系统，在没有small heap帮助时高密度分配小量内存可能确实会比较慢。不过现在没有small heap的标准库已经很少了，而且现代操作系统的页式内存管理机制对这样的情况效率也高很多。
其实我也不喜欢像Java、.Net，因为它们是专门为Web服务设计的，所以许多测试结果具有欺骗性。但就是因为这样，我曾经认真分析过它们性能。结果发现，对于现在那些编程初学者所接触的那些领域，Java、.Net已经优化到了极致，看起来似乎确实速度很快。而对于传统领域，那当然不能比的。
■ 呵呵，窃以为，对于初学者来说，主要错误都发生在算法和程序逻辑上。
■ 差点忘记一条重要说明：俺其实很喜欢java和basic，并且对basic感情尤其深厚（大部分人编程基本都是从basic开始学起吧）。这里没有贬低任何语言的意思，每种语言本身就是为了解决不同的问题诞生的（不过俺对.net比较反感，嘿嘿）。这里只是想说，公平的比较的话，说basic、java的运行效率可以达到与C/C++并肩的程度，个人感觉有欠妥当。
当然，从另一个角度讲，只比效率也不公平。时空效率本身就不是这些语言的强项，使用简便、构造快速、可移植性强、丰富的功能/控件库等等才是这些语言的强项。
[ Last edited by asbai on 2006-7-12 at 07:56 ]
作者: qb45 时间: 2006-7-12 08:38
BASIC 有解释型的也有编译型的，GWBASIC、QBASIC 就是解释型的，QuickBASIC 是编译型的，我用的是版本是QuickBASIC4。5的版本，所以我给自己起网名就叫qb45，我只是一个爱好者，当初选择语言的时候，也是很犹豫，由于自己有工作，只是业余爱好编程，并不想当职业什么的，就选择了最简单的qb。
网友zyl910说的很对。确实编译成P代码。
对于一个使用者而言，可以说没有什么障碍。
在使用者眼中，qb可以编译成一个独立运行的EXE文件，也可以编译成需要qb库运行的程序。quick系列的basic支持中断调用、内嵌机器码，对于我这样的业余爱好者来说足够了。
我发现编程语言并不是主要的限制，对计算机原理、硬件、文件系统方面的深刻了解才能做出一些底层运用的软件
我的照片与简历希望大家能看看，最好能看完，谢谢大家。
http://www.programfan.com/club/showbbs.asp?id=82092
作者: wang6610 时间: 2006-7-12 11:45
谢谢GOTOmsdos制作的好东东！！！
[ Last edited by wang6610 on 2006-7-12 at 20:46 ]
作者: crshen 时间: 2006-7-12 20:52
| Quote: | |
|
你的那个页面还是不要宣传为好，对己对人都有以益。
完全同意楼上的看法，关于 轮子 的事情，能躲多远就躲多远，何必呢，自己倒无所谓，还连累家人。也没听说 洪战辉 是学这个的呀！
作者: GOTOmsdos 时间: 2006-7-12 23:55
程序作了较大更新了。。
更新的内容请参看主贴的补充。。
[ Last edited by GOTOmsdos on 2006-7-13 at 00:05 ]
作者: GOTOmsdos 时间: 2006-7-13 18:45
程序做了更新，估计能兼容老硬盘了！
也加入了读写 "非1.44mb"软盘的功能， 说明见主帖。。。
[ Last edited by GOTOmsdos on 2006-7-13 at 18:48 ]
作者: GOTOmsdos 时间: 2006-7-14 01:20
虽说更新为可读写老硬盘，老软盘（非1.44MB格式），单自己没有这些古董，试不了
如果谁有机会碰到的话，可以试一试，看看运行的情况怎样？
如果一切正常那当然好，如果有问题，就把出错贴出来，以便解决。。
作者: GOTOmsdos 时间: 2006-7-17 14:58
刚发现我的这个程序可以作为 GHOST 和HD-COPY 的迷你版 来使用
之所以叫迷你版，是因为：
GHOST：
本程序由于没有文件压缩功能（或分卷功能），所以最大只能处理4GB内的文件（也就是说，如果你要处理的分区在4GB内，就可以试用本程序了，当然你必须知道他的开始扇区位置和总扇区个数。。另外，如果是FAT16，那只能处理2GB内了）
HD-COPY：
HD-COPY有很多其他功能，而本程序只有读写主功能。
[ Last edited by GOTOmsdos on 2006-7-17 at 17:05 ]
作者: GOTOmsdos 时间: 2006-7-17 17:18
哈哈，以后要解压镜象或制作镜象就用自己写的这个东东就解决啦！
好爽！
作者: GOTOmsdos 时间: 2006-7-18 00:31
刚刚把注释掉的代码全清理掉了，并整理了代码，补充了注释，用VC 的对齐功能对齐了，看起来清爽了。
更新了。
作者: GOTOmsdos 时间: 2006-7-20 18:08
发现这个程序在获取老硬盘参数时的BUG，这个BUG导致读写老硬盘失败
已更正。
原BUG如下：
cylinder=regs.h.ch+1; /* 寄存器的 CH +1 为柱面数 应该是CL的高2位为高2位，CH的8位为低8位 */
sector=regs.h.cl; /* 寄存器的 CL 为每道扇区数 应该是 CL 的低6位 */
改为：
cylinder=((((unsigned int)regs.h.cl)>>6<<8) | regs.h.ch) + 1;
sector=regs.h.cl & 0x3F;
在取值时，没有用指针甚至一般运算，用高效而好玩的位运算。。
现在读写老硬盘就可以了。。
如果有老硬盘的，可以试玩试玩，我自己还没有呢。。
[ Last edited by GOTOmsdos on 2006-7-20 at 20:52 ]
作者: GOTOmsdos 时间: 2006-7-22 14:25 标题: 移除
移除
[ Last edited by GOTOmsdos on 2006-7-22 at 14:58 ]
作者: LiveOnLove 时间: 2006-7-27 22:31
是个难得的好东东！呵呵。非常感谢～
作者: GOTOmsdos 时间: 2006-7-28 01:12
已做好了分卷，现在正想办法加入 压缩功能。。。
谁有好的又好移植的压缩/解压源码，介绍给我啊！。。。
作者: wang6610 时间: 2006-7-28 10:29
要做ghost2了！
作者: GOTOmsdos 时间: 2006-7-28 10:52
做GHOST2不可能，但主要功能还是能做的，主要是DIY啊
如果作好了压缩，我就用自己的程序备份硬盘和分区啦！
这种满足是无与伦比的！
作者: GOTOmsdos 时间: 2006-7-29 23:33
刚成功地解决了 压缩引擎问题，下一步就是嵌入到我的程序中实现压缩功能了！
这几天，在国外的网上遨游，下了不下几十套源码！在几百个文件中穿梭！
终于找到了我要的！解决了我的问题
就是 zlib !
简要的过程如下：
1
试了，简单古老的
LZ， LZW，HUFFMAN，LZHUF，LZSS，LZHARC， LZ77，LZARI，LZRW1等等，都不理想，太老，效率太低，只能用来教学。。
2
看了 ARJ/UNARJ，有很多我不要的功能。。
3
曾定在 GZIP（BZIP2，基本差不多），很不错，也觉得有点适合我，压缩比和速度都很好，还有1-9的压缩比选项。。钻研了几天，发现没有内存压缩，只有文件压缩，。。。
4
看到一个提示： zlib 支持内存压缩！
确定它了！
（ZLIB和GZIP，PNG都采用相同的引擎：基于LZ77和HUFFMAN的结合，当然和前面提到的古老原始的版本是不可同日而语的）
在此过程中，与DDCOPY作者李治联系了。取得了DDCOPY源么，对我有启发。。
不过，试了DDCOPY的压缩，不太理想，豪时长，压缩比低。因为他采用的压缩/解压的类较简单，就两个文件（用简单的LZSS，胡颖卓编写的类，后来我也在网上看到了）
将要采用的压缩引擎是先进的最新版的 zlib-1.2.3 库(与GZIP，PNG图象用的同一个引擎)，
压缩比和压缩速度很快，解压速度更快的离谱！
在WIN32 控制台程序中，压缩50MB，大约要20秒，压为了25MB。
解压只要大约3秒！ 我靠！
还有 压缩比的1-9选项（类似GHOST）。。。
[ Last edited by GOTOmsdos on 2006-7-29 at 23:47 ]
作者: wang6610 时间: 2006-7-30 08:28
| Quote: | |
|
你真牛。。。
作者: johnsonlam 时间: 2006-7-31 00:32
| Quote: | |
|
外 国 的 好 东 西 多 着 呢 !
这 令 我 觉 得 好 幸 福 ， 可 分 享 他 人 的 成 果
也 觉 得 某 些 国 人 不 肯 分 享 ， 真 悲 哀 ...
作者: GOTOmsdos 时间: 2006-8-1 20:56
完全解决拉！
已经成功放入纯DOS程序中，被调用，运行结果正确！
并且，令人激动的是：所采用的 ZLIB库的表现相当棒！
刚才，测试结果：
压缩备份：
压缩1000000个扇区（500MB），采用6级（最高9级）就能压为312MB ！
（如用9级，大约能压到 250-280之间！）
而且用时仅12分钟！大约一秒钟1MB！（跟GHOST速度差不多！）
而且是读一个很老的2GB的硬盘！
（注意：由于GHOST不处理没有文件的的数据，所以，在备份分区时，所化的总时间自然就很少了。毕竟他不是整个扇区的全真备份。我的程序是的）
解压还原：
解压就快的离谱拉！
把压缩的景象文件（原500MB）解压后还原到硬盘上，大约1分钟左右！
简直不敢相信！这个ZLIB 的解压作者是 Mark Adler,真是牛！
他好象也美国火星计划的研究人员。。
现正在整理程序。进入最后阶段。。。
大概两三天能出来。。。
（DDCOPY 作者李治帮过我，由于我的程序采用了高效的压缩/解压库，出与感谢，我会把我的程序寄给他，希望在更加优越的压缩/解压方面，供他借鉴。。我会很高兴。。）
[ Last edited by GOTOmsdos on 2006-8-1 at 21:01 ]
作者: troylees 时间: 2006-8-5 23:41
GOTOmsdos你好！
我看过了你写的源代码，心里就两个字"高手"。
不过，我有个问题，如果我用DJGPP编译的话，ExInt13函数中用到的FP_OFF和FP_SEG宏都是只有TC才有的定义，请问在DJGPP下怎么解决呢？
谢谢！！
作者: GOTOmsdos 时间: 2006-8-6 18:40
程序加入了扇区到扇区方式的读写，也加了一些功能，完善了。。。
又更新了 ！。。
TO troylees
你查一下TC3 的HELP
感谢关注，高手谈不上啊
FP_OFF
和FP_SEG
是宏
FP_OFF没什么， 替换成他的内容
FP_SEG 的内容 跟 _seg 有关 不知道 DJGPP 是否支持
如果不行，也没大关系
可直接把 那个扩展INT13的 结构体的指针 直接赋值 给那个寄存器变量也可以的，我原来就是这样的（运行结果正确，。后 考虑到规范，才改成这样的）
ZLIB中原带了 MAKEFILE FOR DJGPP2 的文件，我一起加进去吧。。。
作者: GOTOmsdos 时间: 2006-8-6 20:58
将要添加如下功能：
1
支持古董级硬盘（不支持扩展INT13）的压缩分卷
2
四个主分区的读写（此功能，只有C有实用意义，因为，一般用户都把很多盘弄成了扩展分区的逻辑驱动器了）
[ Last edited by GOTOmsdos on 2006-8-6 at 21:52 ]
作者: GOTOmsdos 时间: 2006-8-6 22:20
刚才更新的代码中，有个小错误 CASE ：
现在已改过来重传了
作者: troylees 时间: 2006-8-6 23:14
To:GOTOmsdos
Tc定义如下：
#define FP_OFF(fp) ((unsigned)(fp))
#define FP_SEG(fp) ((unsigned)((unsigned long)(fp) >> 16))
可以看出，TC编译的程序是用16位地址的，而djgpp编译的是用32位地址的。
所以，如果in.x.si =(unsigned long) (&DAP_package)这样还可以，但是sregs.ds = (unsigned long) (&DAP_package)这样就不行了，一个是16位，一个是32位。
所以，我觉得直接赋值应该是不可以的！！
作者: GOTOmsdos 时间: 2006-8-7 02:22
不是 sregs.ds = (unsigned long) (&DAP_package)
是 reg.x.si =&DAP_package
这样一般就可以的，我试过的。。
作者: troylees 时间: 2006-8-8 12:28
To: dear all
问题终于解决了，是因为传统的中断调用只能访问低地址1M的内存，而DPMI下保护模式的DOS程序的缓冲区地址可能会超过1M，所以解决办法是，使用DJGPP预定义的低地址缓冲区,他的地址定义在“__tb”，然后用dosmemput和dosmemget函数实现低地址和高地址缓存区的数据交换操作。 详细看看这里http://www.delorie.com/djgpp/v2faq/faq18_2.html
作者: GOTOmsdos 时间: 2006-8-8 15:17
祝贺你！
作者: GOTOmsdos 时间: 2006-8-11 18:12 标题: 下面新增的功能已经实现了!
下面的功能已经实现了!
1
支持古董级硬盘（不支持扩展INT13）的压缩分卷
尽管不支持扩展INT13,把硬盘的扇区压缩成文件,还不成问题..
但是,把在某个硬盘的某个位置压缩成的镜象文件再恢复到另一个硬盘的不同位置,结果就不对。
要解决这个问题，就要费一翻脑筋啦!
因为之前的压缩了的文件中结构是不得不根据硬盘扇区的几何结构而来,
但是,以后,要把这个文件再解压到不同硬盘的不同位置时,就会不一致.解压后不能直接写到硬盘..
所以,要重新分析硬盘物理结构,然后,要先设几个缓冲,对解压出的数据进行调整到被允许的数据大小,还有剩余数据的处理等等,处理起来还是挺复杂的...
但是,被我拿下啦! 而且,只用了很少的代码!
测试的结果正确!
2
无论支持不支持扩展INT13,都能进行硬盘,分区(仅限于主分区)和任意扇区之间的复制.
这也涉及到对硬盘物理结构的解读,以及和支持扩展INT13的硬盘的协同工作..
***********************
************************
(小补充: 原先支持扩展INT13硬盘的读写,缓冲设为100扇区, 现发现可能能增大为125扇区(64000字节)!)
到此,想要加入的功能,都已完成了,很满足..而且,尽量力求代码的精简高效,和考虑使用者的常见习惯.
现在,正在归整代码,很快就全线完工啦!
(明天,再去买几块硬盘,以便全面,大规模的测试啦! 也看看 有没有不支持扩展INT13的古董硬盘?
前段时间买的老硬盘2GB左右,居然还是支持扩展INT13! 晕死!! 极度失望!
注：由于现在没有不支持扩展INT13的硬盘，之前对基本INT13（CHS模式）的读写的测试，是通过有意改反代码（即把支持扩展和不支持扩展有意弄反，这样，支持就是不支持，才能测试CHS模式代码的结果。。。还有就是拿软盘做测试）
)
[ Last edited by GOTOmsdos on 2006-8-11 at 18:50 ]
作者: GOTOmsdos 时间: 2006-8-15 01:04
已实现处理扩展分区！
马上将要加入此功能！。。。
作者: GOTOmsdos 时间: 2006-8-16 07:38
已实现支持处理DOS盘符的功能(当然，这就包括扩展分区的逻辑驱动器了)。
比如：
mydisk -r e: -fd:\cback.z -c /* 镜象模式*/
mydisk -r e: f: /* 扇区模式*/
作者: thzhx 时间: 2007-6-23 20:31
辛苦了，学习一下。
作者: johnsonlam 时间: 2007-6-26 16:58
請 問 gotoMSDOS 兄 有 沒 有 空 整 理 一 個 簡 易 一 些 的 說 明 ?
我 想 把 miniTO 放 在 網 頁 ， 讓 更 多 人 受 惠 。
作者: GOTOmsdos 时间: 2007-6-28 21:00
johnsonlam兄 你好，进来很忙 好长时间没上网了，刚抽空过来看看
miniTO DOS版有内嵌帮助的：也很简明，把这个弄上去就行的，要中文的话，就翻译一下吧，很短的
miniTO MBR/BOOT/FAT/CMOS Tool 1.9.1 Copyright(c) GOTOmsdos tdaim@sina.com
miniTO
[/?|/H]
[/D[.]] [/P[...]] [/V] [Common]
/S|/R|/E|/C|/L [n|n:n|?:] [/MBR|/BOOT|/FAT|/CMOS] [/A] [/Fxx] [/NoP] [/Y]
[Common]
/T n:n|?: [Common]
/CMOSKEY
Common:
/FLOPPY : Support Floppy
/NoHP : Do not get HDD Parameter
/NTFSPRO : Support NTFSPRO DOS letter
/IFS : ... IFS ...
n : No.drive
n:n : drive:partition, e.g. 1:2
?: : WIN letter, e.g. D:
/?|/H : Print help
/D[.] : Print Drive info. n=drive; A=Floppy
/P[...] : Print Partition info. A=Floppy; :=DOS letters; F=FAT N=NTFS
FN=FAT&NTFS; L=Linux; NoH=No Hidden
/V : WIN Vol prior to DOS label
/S : Save
/R : Restore
/E : rEplace BOOT1/FAT1 with BOOT2/FAT2, FAT32 only
/C : Compare with file (/MBR|/BOOT/FAT UNneeded)
/L : Look info in drive/file
/MBR : Master Boot Record
/BOOT : DOS Boot Record. i.e. DBR
/FAT : File Allocation Table
/CMOS : MainBoard CMOS
/A : All partitions/drives, allowed with n
/Fxx : File, xx=name
/NoP : Not Pause during looking, with /L
/Y : Yes to write drive
/T : Turn to print ?:|n:n from n:n|?:
/CMOSKEY : Generate a CMOS key
作者: z8232577 时间: 2007-11-23 19:38
能不能将一个BIN引导程序写入硬盘的引导扇区呢？
作者: wgzlong 时间: 2007-11-29 17:23
支持一下
作者: shim 时间: 2007-11-29 20:41
高人，学习中。。。
作者: qwjhunter 时间: 2007-12-5 15:21
妈哦 什么论坛还每到20分钟 急着做事呢
作者: bingo0717 时间: 2007-12-5 15:57
看看，辛苦了！！！
作者: maclover815 时间: 2007-12-13 22:36 标题: gmy你好啊
个性签名做的好呀。
作者: gosyzj 时间: 2008-1-9 20:21 标题: 啊，积分怎么来？
郁闷啊，DOS下自己写解压~~
作者: wzh442718973 时间: 2008-1-9 22:04
可以试试看，但我想如果能自己用汇编编写支持大硬盘就好了。连DOS可以省了。
作者: dragon123321 时间: 2008-3-7 16:01
晕。。没积分。。攒分了要。。唉。。
作者: dragon123321 时间: 2008-3-7 16:02
论坛的标题还是学习FREEDOS和GNU的自由精神。。
作者: dolba1 时间: 2008-4-7 23:46
我要
作者: yotoe 时间: 2008-4-9 00:19
下下来学习学习
作者: Joyoung 时间: 2008-9-30 11:25
支持下
作者: nfyanger 时间: 2008-10-1 10:52 标题: 可以把ddcopy的作者联系方式或者源代码发给我吗
我对着方面也很感兴趣 呵呵 想研究下
作者: dogbi 时间: 2009-6-6 08:07
学习一下，正在找相关
作者: ym0143 时间: 2009-6-14 13:19 标题: 感谢楼主啊，分享一下
作者: robinliu 时间: 2009-6-22 10:33
支持DOS
作者: tianjiyouyun 时间: 2009-6-30 12:46 标题: 多谢
先多谢,明天看用得上不!
作者: llg84 时间: 2010-2-1 10:51
感谢楼主，下下来看看
作者: dalong7137 时间: 2010-3-16 20:47
支持楼主，不知其程序怎么才能编译啊？
[ Last edited by dalong7137 on 2010-3-17 at 22:22 ]
作者: kmjlz 时间: 2010-4-30 22:04
学习！
作者: enjoyer 时间: 2010-5-4 01:12 标题: DISKRW 能不能加入物理扇区数据搜索、定位功能呢
今天在VC下干活时不知道点了左上角的什么按钮，就把我的主程序文件给删除了（当时还弹出个对话框，当时没细看就按确认了，后悔啊）。开始用了几款数据恢复的软件，结果都是有名无实（能搜到很多同文件名的，但没有内容，都是全0）。如果能有一个硬盘工具帮我确定文件大大致位置（可以指定分区，然后用文件容做关键字搜索），然后把有关的扇区全部转储，丢失的文件就能找回来了。网上搜了下，看来这样的工具不好找呢
作者: JustGo 时间: 2010-5-12 11:05
dos下的东西，很受用啊！
作者: JustGo 时间: 2010-5-12 11:06
在windows下用多了，现在觉得很多东西还是dos下很多工具方便，刚注册来学习的。
作者: haoc 时间: 2010-8-11 12:04
持 ! 辛 苦 了 gotoMSDOS 兄 熬 夜 編
作者: worldone 时间: 2011-1-22 09:11
好东东啊正是需要，谢谢了
作者: ling3882688 时间: 2016-8-9 06:54
早些年看到这个论坛就好了。