中国DOS联盟

A small program written a few years ago, recently I dug it out when making a boot disk to play around
See if any friends can help test it :lol:
The original purpose was to write an xcopy tool that can work with DOSLFN
But I was too lazy to write too many functions, only implemented the most commonly used /s parameter

After finishing it before, I hardly tested it, so there may be some bugs
Be careful when using it (especially when adding the /M parameter)

Parameter description:
CP source
There can be multiple sources, wildcards can be used, the last parameter specifies the destination
If there is only one parameter, it is regarded as the source, the destination is the current directory, the same as DOS's COPY
/S Copy subdirectories
/M Move files (delete source after successful copy)
/J Combine files
/D Specify destination as directory, not file
/V Verify copy result
/Y Do not ask, always answer Yes
/N Do not use long filenames even in environments with long filename support

Supplementary instructions:
1. If there is no /j or /d, and it cannot be judged whether the destination is a file or a directory, a prompt will appear
2. Long filename support needs to be under Win9x/2K/XP or pure DOS with DOSLFN or LFNDOS mounted
3. When specifying the destination as a directory, non-existent directories and subdirectories can be automatically created

http://zhenlove.com.cn/cndos/fileup/files/cp.zip

Last edited by silveregg on 2007-3-22 at 06:47 PM ]

A simple test was done, and it feels very good. No bugs have been found for the time being. I will do a more detailed test when I have time in a few days.

It is suggested to add an option (such as /I): only copy files that do not exist, and automatically ignore existing files, which is equivalent to "do not ask, always answer No". In addition, it is suggested to directly press keys like Y, N, etc. when asking whether to overwrite the file, without having to press the Enter key again.

Thanks to Wengier for testing and suggestions.

Currently known bugs:
The remaining disk space cannot be correctly judged in the XP command line window (insufficient space is misjudged when copying large files)
But this seems to be an issue with XP itself, and no solution has been thought of yet...
No such problem under DOS and Win98

Originally posted by silveregg at 2007-3-22 06:51 PM:
Thanks to Wengier for testing and suggestions

Known bugs:
The remaining disk space cannot be correctly judged in the XP command line window (insufficient space is misjudged when copying large files)
But this seems to be due to XP itself...

Well, but generally it is used under DOS because this software is really needed only under DOS. Under XP, people usually directly use XP's own XCOPY that supports long filenames.

By the way, maybe renaming this software to XCP would be better. On one hand, it can show that it is more powerful than ordinary COPY, supports more functions, and on the other hand, it can be distinguished from the CP command in Unix/Linux/Cygwin to avoid confusion.

Yeah, this software is fine as long as it performs perfectly under DOS. It's great that it supports long filenames.

During testing, it was found that certain CP950 traditional Chinese filenames still cannot be properly handled in the DOS environment. It has been confirmed that this is an issue with DOSLFN. Currently, an attempt is being made to contact the author for assistance in improvement. (Although DOSLFN comes with source code, there are no奈德 documents explaining it, which is really hard to understand, and I'm too lazy to study it slowly.) When all problems are solved, the plan is to re - make XCP and add the functions suggested above.

Is there any progress on that side now?

Originally posted by silveregg at 2007-3-23 07:51 AM:
Known bugs so far:
In the XP command line window, the remaining disk space cannot be correctly judged (insufficient space is misjudged when copying large files)
But this seems to be an issue with XP itself, and no solution has been thought of yet...
There is no such problem under DOS and Win98

Under XP, it is necessary to use Win32 functions, otherwise it will not be accurate, but this is not compatible under pure DOS.

There are solutions, but the former is a bit clumsy, and the latter is quite troublesome...

1) Separate the DOS version and the Win32 Console version (just like OneDir and OneDir32)

2) There is something called a Stub in the DOS header to judge whether it is DOS or Win32 (this function has been available since MSVC 6), put the Win32 and DOS in one file, and judge whether it is the Win32 and DOS version through the Stub to jump to the relevant position

Originally posted by silveregg at 2007-3-25 05:10 AM:
(Although DOSLFN comes with source code, there is really no奈德文explanation, so it's really hard to understand, and I'm too lazy to study it slowly)

You can contact Jason Hood, who is Australian and can use English.

Website:

http://www.geocities.com/jadoxa/doslfn/index.html

Email:

jadoxa@yahoo.com.au

The subject must be DOSLFN

I have thought about using the stub method, but first, it increases the file size, and second, this tool is obviously not practical under Win32, so I didn't consider it.

In fact, the stub is not to jump to the relevant position after judgment; the stub itself is a complete DOS program. Because basically, DOS and Win32 programs are completely incompatible, and normally they cannot share code. But this is aside from the main topic and won't be discussed here.

Still, I thank johnsonlam for the suggestion.

As for contacting Mr. Jason Hood, I wrote to him before and explained the problem.

The reply I got is:

I shall look into it, but no promises when.

Jason.

That is to say, he will pay attention to it, but just don't know when the problem can be improved :(

Look! ! ! ! ! ! ! ! !