China DOS Union

The necessary files such as COMMAND.COM in MS-DOS 7.x are relatively large and occupy quite a bit of space, so they should be slimmed down properly. However, software like UPX, aPack, etc., cannot compress it. And the result of compression with COMPREXE is that it can run but cannot be used as a SHELL; otherwise, an "Invalid COMMAND.COM" error will occur.

I observed and found that COMMAND.COM can currently be reduced by at most 2 bytes, not even 3 bytes. It is also possible to add bytes or modify the original bytes, but just cannot reduce by more than 2 bytes. Obviously, COMMAND.COM will perform a volume check when acting as a SHELL, and it won't work if it is less than 94,290 bytes. Does anyone have a way to solve this?

From a cracking perspective! He is checking his own size, right! You don't let him check! He uses conditional statements! You use unconditional statements! Then change the size to the size you modified! Don't look at me with an adoring eye! I just know the principle! I don't know the method!

Haha.....I can say it too. Who will come to worship me.....

Experts like Roy, lydong, etc., also come and share the methods.

There was a game before that needed to play a movie file larger than 10M. As a result, when I checked the executable file, there were only two places at 10M. The first time it wasn't right, the second time..... From then on, that game could be played on the hard drive.

............Give it a try.

Just now I did some research on COMMAND.COM and found that it's really not easy to drastically streamline COMMAND.COM, unless some major modifications are made. Because COMMAND.COM directly accesses the internal addresses of files, unlike ordinary programs. For example, by modifying the 5F10H position in COMMAND.COM, at least tens of bytes of content in COMMAND.COM can be reduced, but to streamline further, more content in COMMAND.COM needs to be modified. I hope everyone can work together.

The command program is just an external command parsing program. Why can't we replace it with others? For example, ndos

The following is a quote from dos era rookie on 2003-6-13 9:26:29:
The COMMAND program is just an external command parsing program. Why can't we replace it with others? For example, NDOS

Because NDOS and others do not support long filenames. However, COMMAND in MS-DOS 7.10 fully supports long filenames under DOSLFN and has good compatibility.

Use the COMMAND.COM of ROM-DOS

The following is a quote from Roy at 2003-6-13 15:35:51:
Use the COMMAND.COM of ROM-DOS

There are some problems with the cooperation between COMMAND.COM of ROM-DOS and MS-DOS 7.10, and it does not support commands like LOCK.

The new logo of moderator Wengier is quite beautiful!
It's a pity why a boy would choose a girl's avatar as the logo,
In comparison, the avatars of Roy and Master Rushiyou are more manly!

And also hope that moderator Wengier can successfully compress command!

The following is a quote from Wengier on 2003-6-4 19:36:34:
Experts like Roy, lydong, etc., also come and share some methods.

Being called a "expert" by Wengier really makes me feel unworthy (a bit embarrassed)! In the forum, I mainly am still learning from everyone. Although I am very interested in researching DOS-related issues with everyone, my own knowledge is superficial, and I really don't dare to be in the "expert" category (a bit ashamed)...

Regarding the problem mentioned above, I think whether COMMAND.COM can also be divided into several segments like when streamlining IO.SYS, and some unimportant contents can be removed to achieve streamlining. Secondly, the program that checks the size of COMMAND.COM should be in IO.SYS, because when other SHELLs are replaced, there will be the same error prompt. The problem should not be with COMMAND.COM itself. Instead, it is the check by IO.SYS on the size of COMMAND.COM that causes the issue. I don't know if what I said is correct. Please give me your advice, Wengier!

The following is a quote from lydong on 2003-6-14 4:19:17:
   Among the problems mentioned above, I wonder if COMMAND.COM can also be divided into several segments like when slimming down IO.SYS, and some unimportant contents removed to achieve slimming. Secondly, the program to check the size of COMMAND.COM should be in IO.SYS, because when replacing with other SHELLs, there will be the same error prompt, the problem should not be with COMMAND.COM itself. Instead, it is the check of the size of COMMAND.COM by IO.SYS that causes the problem. I don't know if it's right. Please give your instructions, Wengier!

Alas, it's not like that. As I observed, the structures of IO.SYS and COMMAND.COM are completely different, so the previous experience of slimming down IO.SYS cannot be applied to COMMAND.COM. What was done to IO.SYS is slimming, while for COMMAND.COM it can only be compressed. But the size check is not in IO.SYS, but inside COMMAND.COM, which has been confirmed by my research and experiments, but there is currently no good solution.

This is troublesome. First, compress it to know the volume after compression, then modify the address of the annotation file volume in the uncompressed command, and finally compress this program again in the same way! It's really troublesome!