中国DOS联盟

Format Accelerator 4.COM = Super Speed + Safe + Convenient + Cache Save!
4.COM = QF.COM + KILLER.EXE + SHELL + SaveCache!


!!!Strongly not recommended to use in MS-DOS 7.x environment with EMM386.EXE enabled!!!
4.COM (2.53K) -- Disk Formatting Acceleration Execution Environment V2006 Designed by Luo Ming'an (C) Fengkuang Software 2006
lmayylxt@pub.sz.jsinfo.net

　　1. No need to reside in memory >> Disappear after use: Convenient Self-removing
　　2. Omit disk verification >> Instant partition formatting: High Speed Speedy
　　3. Intercept abnormal instructions >> Enhance system stability: System Safe CPU-Safe
4. High-speed cache write disk >> Data saved to the real place: Data-Safe


New functions:
If there is an EGA/VGA or higher graphics card, Chinese characters will always be displayed (regardless of whether the Chinese character system has been started),
and after displaying Chinese characters using VT technology (multiple fonts <effect see attached picture>), it can automatically restore the original system Western character shape;
If not, it depends on the Chinese character system to display Chinese characters.
But the help will display English while displaying Chinese characters, which can be corresponding; it is also convenient for the use of MDA/HGA/CGA and other graphics cards without a Chinese character system.


　　4.com provides an environment shell for accelerating disk operation. After running other programs on the command line, it immediately returns the DOS memory.
　　4.com achieves acceleration by omitting disk verification. Only operations and commands involving disks can be accelerated! Disk formatting always needs to set detailed disk (cylinder head sector) parameters.
Calculation is complex and time-consuming, and repeated calls lead to long user waiting. Omitting disk sector verification can be completed instantly. Floppy disks, USB drives are also accelerated, no matter how large the hard disk is! Moreover, because it does not reside in memory, it will not produce side effects that the disk verification is not possible when needed.
　　4.com provides chip-level soft safety, automatically intercepts incorrect instructions during program operation, ends the program that issued the instruction, and returns to DOS. This enhances system stability and prevents system crashes.
4.com performs an operation to write the high-speed cache to the disk before each run ends. Why? The speed of accessing memory is much faster than that of the hard disk. Store some disk contents in memory, so that when reading disk data, you can first search in the memory buffer, if available, it is high speed, otherwise it is on the disk; when writing to the disk, it is also first written to the high-speed cache. In the case of repeated reading and writing to the disk, such as when executing compilation or using database management system software, using SMARTDRV is particularly suitable. If you immediately restart or the system crashes, the data may not have been written to the real disk ---- that is, loss occurs!

　　4.com is suitable for DOS internal and external commands and tools, and realizes functions such as accelerated partitioning and formatting. The usage is as:
4 FORMAT A: /S
......

The latest attachment can be found at http://www.cn-dos.net/forum/attachment.php?aid=945&checkid=b0965&download=1

Top. If it can be used, it would be great

: :lol:Welcome everyone to test!
Please post if you have any questions to improve it.
Also please report the usage effect.
Thanks in advance!

Tested under the DOS environment of the virtual computer Connectix Virtual PC 5.2, still shows English!

I haven't used VPC. The virtual floppy disk, the real environment DOS, and the DOS window of Windows seem to be okay!

Borrowing the words of the moderator willsort: "But, this software cannot run through in the virtual machine VPC. It is estimated that the simulation degree of VPC is not high enough, probably."(http://www.cn-dos.net/forum/viewthread.php?tid=17096&fpage=1)

Last edited by born2be on 2005-10-7 at 01:22 ]

Re:

In my testing on real machines and virtual machines, I encountered a problem of misalignment in concatenation. The details are as follows: If I first run 4readme.com, it will display as extended ASCII characters, which is normal; and if I run 4.com, it will display normally, but the content will be less than that of 4readme.com, which should also be normal; but if I run 4readme.com again at this time, it will display incorrectly concatenated Chinese characters. It feels like the character fonts are correct, but there seems to be a problem with the encoding; and if I enable the Chinese character system (ccdos/tway/ucdos) and then run 4readme.com, it will get stuck in a死机 state at different times and to different extents. I have already run 4.com before, and I wonder if it is a problem that the character fonts have not been changed back. Attached is a running screenshot of 4readme.com in VPC's MSDOS7.10, at this time I have run 4.com but not run the Chinese character system.

The problem is as follows:

4readme.com always displays the normal Chinese character internal code, regardless of whether the Chinese character system is running or not: when the Chinese character system is running, it displays Chinese character shapes; when there is no Chinese character system, it displays the regular character patterns of English characters.

4.com adopts intelligent identification of the Chinese character screen status of the Chinese character system. After the Chinese character system is run, if the screen status is Chinese, it displays the normal Chinese character internal code; if the screen status is English - at this time, the screen is equivalent to the state when the Chinese character system is not run, at least for my 4.com - the program will implement the VGA display character set replacement with Chinese character pattern information, so the number of displayed Chinese characters is limited. I reduced the Chinese character information out of helplessness. At the same time, since the character patterns of the English extended ASCII code characters have been replaced with half of the Chinese character shape information, it is impossible to display the normal Chinese character internal code information again. Therefore, in the English screen, after running 4.com first and then running 4readme.com or TYPE Chinese character files, what will be seen is that only half of the Chinese characters can be recognized and the splicing is incorrect! - At this time, it is the Chinese character shape in the English screen, that is, the technology of " being able to display Chinese character shapes without loading the Chinese character system".

4.com is an environment shell for accelerating disk operation. When running other programs without command lines, it only displays help information; only when running with command line parameters does it provide an accelerating environment, and immediately exits from the DOS memory after other programs finish running.

Is it made clear?

Last edited by born2be on 2005-10-7 at 01:24 ]

Re regarding the issue:
　　You mentioned: "If you run 4readme.com after enabling a Chinese character system (ccdos/tway/ucdos), it will get stuck in a死机state at different levels and different times". I can't analyze the reason because the display method used by 4readme.com is not special: it compresses the characters and attributes in the text screen display buffer, then decompresses and writes them to the video buffer when displaying. Any Chinese character system that supports direct screen writing (such as TW, UCDOS, CCDOS97, etc.) should be able to display normally.
　　Those expert masters who know the reason, please give a hand! :(

Last edited by born2be on 2005-10-7 at 12:18 ]

Re born2be:

I thought that 4readme.com had the ability to automatically switch encodings like 4.com, but only without the character pattern replacement function. It seems I misinterpreted the relationship between the two programs.

As for the conflict of Chinese character systems, it also exists when running 4.com alone or 4readme.com alone. I wonder if it is related to the machine configuration. What are your test results? Or does anyone else have usage reports.

In addition, for the disk checksum omission function of 4.com, does it only have an acceleration effect on formatting, or on all disk read and write operations?

Re: willsort:
I> I have tested Chinese character systems, namely HanWang HW, UCDOS, and CCDOS97, and there were no system crash issues. My environment is the real-mode DOS and the DOS window under Command.Com in Windows XP.

　　Testing method (note: the Chinese character system mentioned below refers to a direct screen-writing Chinese character system and is in the state of activating the direct screen-writing function.):
1) Test once before running the Chinese character system;
2) Test once after running the Chinese character system (at this time, it is a Chinese character display screen);
3) Switch to the English screen with Ctrl F7 and test again;
4) Switch to the Chinese character screen with Ctrl F7 and test again.
1 and 3 have the same display effect, which is a Western VGA text screen (the character patterns have been replaced with Chinese character information).
2 and 4 have the same effect, which is the direct screen-writing display of the graphic screen with Chinese pseudo-characters.

II> Theoretically speaking,
　　Because 4.com achieves the acceleration effect by omitting the disk check function,
　　Therefore, anything related to disk check can be accelerated;
　　Therefore, anything not related to disk check has no acceleration function.
　　In practice,
　　The typical case related to disk check is formatting, especially for large hard disks and floppy disks. This is what I have noticed. The effect on hard disks is the most obvious, but it can also speed up the A drive. I haven't made a precise statistics - a friend can accurately test it through the TIMER function.

　　As "Ben Shi" said: "I am not a computer major", not even related to science, and I learned computers by self-study after graduation (didn't attend a single computer course!). So, for what operations or commands are related to check, please ask:cool: experts to answer.

Last edited by born2be on 2005-10-7 at 23:05 ]

Re born2be:

Thanks for Brother Ben Shi's tip, I have found the problem.

The above problem only occurs in MSDOS7.10 running with EMM386 loaded. In MSDOS6.22, there is no such problem whether EMM386 is loaded or not. In various tests of COMMAND in WinXP, it is also normal. I used the EMM386 of 6.22 in 7.10, and the problem still exists.

It seems that this is the result of the joint action of the MSDOS kernel, EMM386, Chinese character system and 4.com. Now it is difficult to say where the problem is. But since 4.com can be used in other various environments and configurations, it shows that its usability is still very high.

In addition, in the EMM386 memory environment of MSDOS7.10, TWAY will also crash when exiting, and your UCDOSmin will have a screen corruption when exiting. CCDOS has passed for the time being. It seems that such an environment must have problems.

Fortunately, I don't use EMM.EXE; I only use UMBPCI.SYS.

Actually, the core code to implement the 4.COM acceleration shell is very short. If listed as a separate program, it only needs a few hundred bytes and won't cause conflicts with DOS and CDOS in terms of display. To explain the functions, add a readme.txt additionally. This is both concise and reduces conflicts. Is there a need for this? Please participate in the discussion!!!

Small version of 586 bytes formatting accelerator 4.COM using only the character interface!
Compatibility Stronger compatibility!!!

Last edited by 本是 on 2005-10-12 at 23:33 ]

Great! More and more refined! I want to bookmark it.