China DOS Union

Originally posted by quya at 2008-7-9 23:16:
After taking a close look, there are still issues.



Everything is the same here.

This is because the files after decompression were not deleted in time, resulting in the next decompression failing. Therefore, each time it is the same CRC32 for the file.
ps: The problem with the code on floor 25 is still with expand.

[ Last edited by zw19750516 on 2008-7-9 at 11:28 PM ]

Please test my code on floor 28 and the modified code on floor 25.

[ Last edited by zw19750516 on 2008-7-9 at 11:25 PM ]

After multiple tests again.

The following pattern is found:

Under code page 936, it runs correctly. After running once, the code page becomes 437, and then the result is incorrect. There are many places that are incorrect, including those I mentioned above.

Can someone analyze the reason and improve compatibility? I myself think this problem is too weird.

Originally posted by zw19750516 at 2008-7-9 11:19 PM:

This is because the uncompressed files were not deleted in time, resulting in the next decompression failing. Therefore, the CRC32 of the same file occurs each time.
ps: The problem with the code on floor 25 is still with expand.

[ Last edited by zw19750516 on 2008-7-9 at 11:28 PM ]

No, expand overwrites the original file. It's a code page issue.

Lao Tu tested the code in floors 25 and 28 that I modified? There's one that was just modified. Really, as one gets old, one is so careless and always makes mistakes.

Originally posted by zw19750516 at 2008-7-9 11:35 PM:
Old Tu tested the code I modified on floors 25 and 28, there is still one that was just modified. Really, as one gets old, one is so careless, always making mistakes.

The test on floor 28 was wrong just now.

Now floor 25 is the same as floor 7, just don't know which one is more efficient.

But it can only be correct under code page 936. It didn't work before under code page 437.
So at the beginning of the batch line, we can only temporarily add CHCP 936 to ensure correct operation, because after using it once, it becomes 437.

This crc32.com is good in other aspects, the most admired thing is that it is less than 1KB, but it will change the code page. You can't have both fish and bear's paws.

If the result at floor 25 is completely correct now, then it starts with the issue of expand. Initially, I copied your expand %%~fsi exactly, and now I have changed it to expand "%%i". I'll take a look at floor 28 again. As for efficiency, it's completely incomparable with floor 7 because floor 7 directly uses the generated crc.txt.

Originally posted by zw19750516 at 2008-7-9 11:47 PM:
If the result in floor 25 is completely correct now, then it starts with the issue of expand. Originally, I copied your expand %%~fsi, and now I have changed it to expand "%%i". I'll take a look at floor 28 again. As for efficiency, it can't compare with floor 7 at all because floor 7 directly uses the generated crc.txt.

Floor 25, I ran it under code page 437 before. Later, I found the issue with the code page and re-run it. %%~fsi has absolutely better compatibility than %%i, which should not be doubted.

The improved code in floor 7 is in floor 24. I think the code in floor 24 is more efficient because many variables are used to replace FOR and FINDSTR statements.

Again:
@echo off&setlocal enabledelayedexpansion for /f "delims=" %%a in (2.txt) do ( if /i "%%~xa" equ ".cat" ( for /f "tokens=2" %%b in ('crc32 %%~fsa') do set str=%%b ) else ( expand "%%a" %temp%\oembios.cat for /f "tokens=2" %%b in ('crc32 %%temp%\oembios.cat') do set str=%%b ) for /f "tokens=1,2" %%c in (1.txt) do if "!str!" equ "%%d" echo %%c %%a %%d if exist %temp%\oembios.cat del /q /f %temp%\oembios.cat ) pause>nul

Originally posted by quya at 2008-7-9 23:52:


I ran it under code page 437 before floor 25. Later I found the problem with the code page and ran it again. %%~fsi is definitely more compatible than %%i, which should not be doubted.

The improved code on floor 7 is on floor 24. I think...

Old man, did you carefully look at the code on floor 24? The whole thing is just a code to generate crc.txt, and it doesn't involve comparison at all!

I have 5 command-line CRC check software, 2 are over 40K, 1 is 19K, 1 is 15K, and 1 is 1K.

Because the 1K program is used in pure DOS and has poor support in 32-bit environments, changing the code page, etc., so I have to use %%~fsi to get the path.

At first I didn't want to use it, I wanted to use the 15K one, but the 15K program is extremely strange.

I can't get the result when I do CRC32 >result.txt, it still displays on the screen, and using 1>result.txt doesn't work either. I wonder if you guys have encountered such a command-line program before? I'm just encountering it for the first time.

Originally posted by zw19750516 at 2008-7-9 11:58 PM:

Lao Tu, have you carefully looked at the code on floor 24? The entire thing is just a code to generate crc.txt, and it doesn't involve comparison at all!

This is his cleverness. Take another look, it's definitely running accurately.

He uses not defined to detect variables. That is, a disguised comparison.

The code on floor 39 still doesn't work, the same as floor 28, prompting that the command syntax is incorrect.

[ Last edited by quya on 2008-7-10 at 12:04 AM ]

Try crc32>result.txt, or else >result.txt crc32

Originally posted by zw19750516 at 2008-7-10 12:03 AM:
Try crc32>result.txt, or >result.txt crc32

Tried both, it's definitely an extremely strange program.

If you don't believe it, go download it from my FTP://quya.2mydns.com/crc32.exe.

Note that my computer is off and my FTP is also gone.

[ Last edited by quya on 2008-7-10 at 12:09 AM ]

Originally posted by quya at 2008-7-12:


This is his clever place, take a look again, it will definitely run accurately.

He uses not defined to detect variables. That is, a disguised comparison.

The code on floor 39 still doesn't work, the same as floor 28, prompting command syntax...

Is there something wrong with my eyes? I've looked at the code on floor 24 many times, but I didn't see a single defined. Old-timer, can you take a look again?