China DOS Union

**New Discovery: After QF runs, DIR all directories on the disk where WinXP is located actually crashes the computer**!

Under DOS, to speed up disk operations, you can run QF.COM Disk Format and Partition Companion and load it into memory, and then you can perform disk formatting and partitioning at lightning speed, and the larger the disk, the more obvious the effect. Originally, this was a good thing, but unexpectedly, if you then run DIR C:\/S (assuming WinXP is installed on drive C:), it will actually crash the computer!!! And it often happens in a subdirectory of WINDOWS, a directory with characters like X86_, with a particularly long name!

What is the reason?

This problem is very important because many websites recommend it, and some DOS boot disks use it!!!

[ Last edited by born2be on 2005-10-22 at 08:30 ]

First run KILLER.EXE to partially solve the problem!

It may be that an invalid execution code is sent to the CPU, activating the program KILLER to return to DOS, thus exiting the deadlock state where the command prompt is not visible.

Is this the real reason?

Format accelerator 4.COM=QF.COM+KILLER.EXE+SHELL+Always display Chinese characters!
Refer to http://www.cn-dos.net/forum/viewthread.php?tid=17090&fpage=1

Anyway, I don't like this software.
The last time there was a problem with the disk, I tried Sanming Disk Repair, and it made it worse.
It seems that it is only suitable for disks with one primary partition~

No!
Maybe it's caused by a very long long filename. Using 4.COM(

Formatting accelerator 4.COM = QF.COM + KILLER.EXE + SHELL + Always display Chinese characters!
Refer to http://www.cn-dos.net/forum/viewthread.php?tid=17090&fpage=1

), it seems to work.

Recently I discovered that the problem of DIR XP full directory causing a system crash is probably related to the DOSLFN software. When I boot with a virtual floppy disk, I find that the data file of DOSLFN is not loaded (...or not loaded). And every time a crash occurs, it is always with extremely long file names. Obviously, it is a failure in loading the long file name driver data, resulting in mishandling of long file names and thus causing a system crash!!!

But even so, my 486-byte format accelerator still has significance. It has the dual functions of accelerating formatting (completing instantly without leaving any aftereffects) and automatically intercepting invalid instructions sent to the CPU chip to avoid system crashes!

[ Last edited by 本是 on 2005-10-22 at 08:49 ]

Originally posted by bush at 2005-10-3 01:03:
Anyway, I don't like this software.
The last time the disk had a problem, I tried Sanming Disk Repair, and the result was worse.
It seems that it is only suitable for a disk with one primary partition~

According to my own experience of repairing hard drives many times, it's best not to use HDD21! But you can use DISKFIX from WASAY Company. Moreover, DISKFIX is not absolutely error-free. After running DISKFIX, please run PQMAGIC again to repair the partition table calculation error, and exit immediately after entering the interface.

Originally posted by 本是 at 2005-10-22 08:48 AM:
Based on my own experience of repairing hard drives many times, it is best not to use HDD21! But you can use DISKFIX from WASAY company. Moreover, DISKFIX is not absolutely error-free. After running DISKFIX, please run PQM again...

Great minds think alike. Last time I exactly used diskfix to solve the problem,
Additionally: PQ is not the ultimate solution. That time I used it - it simply couldn't boot. Later I used diskginus and found that the reason was that there were two areas of sector interleaving after diskfix repair. Fixed it by manual editing～

Master!Dare to manually edit the disk!
Admiration! Admiration!

Study from the experts earnestly

Originally posted by 本是 at 2005-10-22 08:44 AM:
Recently I discovered that the issue of DIR XP full directory causing a system crash is likely related to the DOSLFN software. When I boot with a virtual floppy disk, I find that the data file of DOSLFN is not loaded (...or not loaded). And every time a crash occurs, it is always with extremely long filenames. Obviously, it is due to an error in loading the long filename driver data, resulting in incorrect long filename processing and causing a crash!!! ...

Is DOSLFN loaded using the LH command? If the UMB memory at this time is greater than the memory required by DOSLFN itself but less than the total memory required by DOSLFN plus the Chinese code page, then the Chinese code page will be loaded incorrectly! Try not using the LH command to load DOSLFN and see if it works.