中国DOS联盟

I've tried several times, and it's all like this. The input and output related to the process are displayed as pasted above. Even if I have an input error (referring to grammatical errors), your program shouldn't execute but should give a usage prompt, right? And interestingly, the content of the error sector saved each time is different, heh.

The delay mainly occurs between "100% sectors done." and the last line "Done." displayed. I'm only reading one sector, and even on a 386 machine, there shouldn't be a perceptible delay. You write about ten thousand sectors and it only takes about 2 or 3 seconds, and I estimate there's about a half-second delay.

You can refer to my DOS memory configuration environment here:
http://www.cn-dos.net/forum/viewthread.php?tid=21215
The DOS version used is MS-DOS 6.22.

Strangely, when I tested in the DOS window of Windows 98, I could get the correct result (only reading the MBR).

But now, let you know a good news, I found the cause of the problem. It turned out to be due to loading the DMA driver under DOS. The DMA driver I'm using is version 2.7 of UDMA2.

Also, I don't know what compiler you're using, why can you mix the comment styles of C and C++?

Oh, thanks for participating in the test!
When writing this program, issues such as CPU type, operating system type, and hard drive driver compatibility were not considered, so it's inevitable that some problems will occur. After all, it's not a commercial software.
Program development configuration:
Pentium III, 733
MSDOS 7.1
Turbo C ++ 3.0 (if Borland C++ 3.1 is used, it's basically the same)
Generally, C++ compilers are compatible with the C specification (including comments), but the opposite is not true.

In theory, BIOS - level calls should be independent of the CPU (as long as it is X86 - compatible instructions), the OS, and the HDD. I once wrote a program to back up and restore the entire partition linked list, and it worked fine on the machines I tested. But I wrote it in pure assembly. Since I haven't used C much, I haven't fully understood your source program yet.

Well, handling the partition chain is still quite complicated because you have to go through the first partition table one by one to find the subsequent partition tables, especially dealing with extended partitions and the logical drives within them... It's quite complicated.

You know assembly, so it shouldn't be a big problem to understand C? Just get familiar with the syntax.

(Just added the basic principles and comments to the source code and re-uploaded it, so it's easier to understand...)

Now testing under the MS-DOS prompt in 98, everything is accurate except it doesn't support extended INT13 (verified with SPFDISK), and it takes less than a second to write ten thousand sectors! (Maybe it's the effect of the disk cache driver. I'm in pure DOS without loading any disk cache driver, so it takes about 3 seconds.)

But I don't know why it doesn't support extended INT13?

Is it because 98 added some hard disk restrictions?

Last edited by GOTOmsdos on 2006-7-9 at 23:56 ]

Whether Int13h ext is supported is not determined by the OS. Please tell me how exactly it's not supported and if there are any prompts. Are you using the DOS window of 98 or MS-DOS 7.10?

It's the 98 MSDOS window. The program prompts that it's not supported (the code has a check, using the extended INT13 function 41, if AH returns 1 and BX is not AA55, it means not supported...). Yes, logically, whether it's supported or not is determined by the hard disk controller and BIOS. I don't understand. Also, what I wrote is that both returning 0 and AA55 need to be satisfied. Is it just that returning 0 is enough? (Not necessarily returning AA55?) Wait a minute, I'll test it.

Wow! There is a major discovery!
Change the detection code to just return AA55 to indicate support!
The program runs, supports it, and the result after running is the same as SPFDISK!
It shows that the information about extension 13 is wrong! If it supports, AH doesn't necessarily return 0, or there will be special cases, etc. (such as operating system relationship, such as DMA, disk buffer driver, etc.), it won't guarantee to return 0. But it will return AA55.
In this way, the code has been improved again.

There is a misunderstanding in WIN98 that it is impossible to write the master boot record MBR or sectors in WIN, including tools like DISKGEN and Norton's DISKEDIT toolkit. At that time, they all added a function to detect whether the operating system was WIN in the program, and if it was WIN, they would prompt or directly exit.

When I was making a hard disk tool with qbasic under MSDOS of 98, I also thought so. In the practice of using the extended INT13, I cleared the MBR to zero, and really cleared it, and could write any sector, but the old INT13 could only read and not write.

I hope to give everyone an inspiration.

My program completely cleared a 6.4G old hard disk to zero, and it took about 7 minutes in total. I don't know how much faster the same kind of program written in C or assembly language would be.

Don't understand qbasic, the BASIC series may be interpreted? The speed may be a bit slower. It is said that the efficiency of C is only a little worse than assembly. Just now, I added that if there is an error in reading and writing, give a prompt. Updated.

TO DOSforever

Just added error prompt if there is an error, and the code has been updated.

One of them seems to be related to DMA settings.

I really hope you have time to test it again to see if the corresponding error prompt comes out?

I tested on my machine. It seems that the error prompt for extended 13 will come out, but for the same error, the basic 13 interrupt does not give an error prompt, and it seems that it is all considered successful (intentionally replaced with a bad hard disk, extended 13 can give a STATUS ERROR prompt). This point, I don't understand...

Last edited by GOTOmsdos on 2006-7-11 at 15:37 ]

TO DOSFOREVER

Can you post your UDMA DOS driver here? I also want to give it a try?

*********
Just downloaded UDMA2, and the instructions say it only supports VIA motherboard chipsets. Is your motherboard...?

Last edited by GOTOmsdos on 2006-7-11 at 12:26 ]

Originally posted by GOTOmsdos at 2006-7-11 11:20 AM:
TO DOSFOREVER
Can you post your UDMA DOS driver here, I also want to give it a try?

*********
Just downloaded UDMA2, the instructions say it only supports VIA motherboard chipsets.
Is your motherboard?

Are you talking about the UDMA2 provided by VIA?
If there is no UDMA2.SYS with the author's name, it is Jack Ellis's, which is very old and has been replaced by QDMA.

http://johnson.tmfc.net/dos

Click the QDMA on the left to download and try!

I don't remember from which version of QuickBASIC it started (it seems to be 4.0). QB is not running in a pure interpretation mode. Instead, it is compiled into P-code and then just-in-time compiled during runtime (similar to the technology used in Java and .Net now). So the speed is not much slower. And now it's calling interrupts. The time is mainly spent in the interrupt service routine. That is, the bottleneck at this time is the hard disk reading and writing speed. Ridiculously, more than ten years ago, QB using P-code and just-in-time compilation was still regarded by people as an inefficient interpretation execution process, while now Java and .Net advocate virtual machine technology. I'm more and more feeling that there hasn't been much progress in the field of computer science in these decades, just with the development of hardware technology, the application fields have expanded sharply and that's all.

Originally posted by zyl910 at 2006-7-11 15:20:
I can't remember from which version of QuickBASIC it started (it seems to be 4.0)
QB does not run in a purely interpreted manner
but compiles into P-code and then just-in-time compiles at runtime (similar to the technology used in Java and .Net nowadays)
Oh...

Sir, what you said is wrong. The just-in-time compilation (JIT, Just In Time) technology is not particularly related to the efficiency of the language. It's mainly a design issue of the language itself.

Specifically, languages that use garbage collection and automatic storage management; untyped variables; reflection and other mechanisms are inherently inefficient. Such languages won't run fast even if directly compiled into machine code. Interestingly, it might even be slower. There's an article in IBM's knowledge base that specifically measures the efficiency of Java running in various situations: Weighing in on Java native compilation (http://www-128.ibm.com/developerworks/library/j-native.html).

Of course, a program written in C isn't necessarily faster than one written in QB/Java, etc. The running efficiency of a program depends on some other conditions:

1. The algorithm used in the program
For example: Comparing a bubble sort algorithm written in C with a quick sort algorithm written in QB, if the set to be input is large enough, QB's quick sort will definitely be faster than C's bubble sort.

2. Whether the program uses a large number of external modules
For example: In an extreme case, you can construct code where a VB program directly calls the entry of a certain DLL and COM component, and then all operations are completed by these external components implemented in C or other languages.

Etc.

Comparisons that don't use the same algorithm aren't a contest of language efficiency, but a collision of programmers' individual skills.
Comparisons where most of the running time relies on external components also can't be regarded as a fair test of the running efficiency of the two languages.

Last edited by asbai on 2006-7-11 at 20:48 ]

The code has been updated again..