中国DOS联盟

It's a rare good thing! Hehe. Thanks a lot~

The volume has been made, and now I'm trying to figure out how to add compression functions... Who has good and easily portable compression/decompression source code, introduce it to me...

It's impossible to do GHOST2, but the main functions can still be achieved, mainly DIY.
If the compression is done well, I will back up the hard disk and partitions with my own program!
This kind of satisfaction is unparalleled!

Just successfully solved the compression engine problem, and the next step is to embed it into my program to implement the compression function!
In the past few days, I've been surfing the Internet abroad and downloaded no less than dozens of sets of source codes! I've been shuttling through hundreds of files!
Finally found what I was looking for! Solved my problem
It's zlib!

The brief process is as follows:
1
Tried, the simple and old ones like

LZ, LZW, HUFFMAN, LZHUF, LZSS, LZHARC, LZ77, LZARI, LZRW1, etc., are not ideal. They are too old and inefficient, only suitable for teaching.
2
Looked at ARJ/UNARJ, there are many functions I don't want.
3
Once set on GZIP (BZIP2 is basically similar), it's very good, and I also think it's a bit suitable for me. The compression ratio and speed are both good, and there are compression ratio options from 1 to 9. I studied it for a few days and found that there is no in-memory compression, only file compression...
4
Saw a hint: zlib supports in-memory compression!
Decided on it!
(ZLIB and GZIP, PNG all use the same engine: a combination based on LZ77 and HUFFMAN. Of course, it's incomparable with the ancient and original versions mentioned earlier)


In this process, I contacted Li Zhi, the author of DDCOPY. Got the DDCOPY source code, which inspired me.
However, the compression of DDCOPY was not ideal. It took a long time and the compression ratio was low. Because the compression/decompression classes he used were relatively simple, just two files (using simple LZSS, the class written by Hu Yingzhuo, and later I also saw it on the Internet)

The compression engine to be adopted is the advanced latest version zlib-1.2.3 library (the same engine as GZIP, PNG images)
The compression ratio and compression speed are very fast, and the decompression speed is ridiculously fast!
In a WIN32 console program, compressing 50MB takes about 20 seconds, and compresses it to 25MB.
Decompression only takes about 3 seconds! Oh my god!
There are also compression ratio options from 1 to 9 (similar to GHOST)...

Last edited by GOTOmsdos on 2006-7-29 at 23:47 ]

Originally posted by GOTOmsdos at 2006-7-29 11:33 PM:
Just successfully solved the compression engine problem, and the next step is to embed it into my program to implement the compression function!
In the past few days, I've been surfing the Internet abroad and downloaded no less than dozens of sets of source codes! Among hundreds of files...

You're really awesome...

Originally posted by GOTOmsdos at 2006-7-29 11:33 PM:
Just successfully solved the compression engine problem, and the next step is to embed it into my program to implement the compression function!
In the past few days, I've been surfing the foreign Internet and downloaded no less than dozens of sets of source codes! Among hundreds of files...

There are many good things abroad!
This makes me feel so happy, and I can share the fruits of others
I also feel that some Chinese people are not willing to share, really sad...

It's completely solved!
It has been successfully put into the pure DOS program, called, and the running result is correct!

And, what's exciting is: the performance of the adopted ZLIB library is quite excellent!
Just now, the test result:

Compression backup:
Compress 1000000 sectors (500MB), using level 6 (up to level 9) can compress to 312MB!
(If using level 9, it can be compressed to about 250 - 280!)
And it only takes 12 minutes! About 1MB per second! (Almost the same speed as GHOST!)
And it's reading a very old 2GB hard disk!

(Note: Since GHOST doesn't handle data without files, so when backing up the partition, the total time naturally is very little. After all, it's not a full-sector true backup. Mine is.)

Decompression restoration:
Decompression is extremely fast!
Decompress the compressed image file (original 500MB) and restore it to the hard disk, about 1 minute!
Simply can't believe it! The author of this ZLIB decompression is Mark Adler, really awesome!
He seems to be a researcher of the US Mars program..


Now I'm organizing the program. Entering the final stage...

Probably can come out in two or three days...

(The author of DDCOPY, Li Zhibang, helped me. Since my program adopted an efficient compression/decompression library, out of gratitude, I will send my program to him, hoping to provide him with reference in more superior compression/decompression. I will be very happy..)

Last edited by GOTOmsdos on 2006-8-1 at 21:01 ]

GOTOmsdos Hello!
I have read the source code you wrote, and there are just two words in my heart: "expert".
However, I have a question. If I compile with DJGPP, the FP_OFF and FP_SEG macros used in the ExInt13 function are only defined in TC. How to solve this under DJGPP?
Thank you!

The program has added sector - by - sector reading and writing, and some functions have been improved...

Updated again!..

TO troylees

Please check the HELP of TC3.
Thank you for your attention, I'm not a master.
FP_OFF
and FP_SEG
are macros.
FP_OFF is nothing, replace it with its content.
The content of FP_SEG is related to _seg. I don't know if DJGPP supports it.
If it doesn't work, it's not a big deal.
You can directly assign the pointer of that extended INT13 structure to that register variable. I was originally like this (the running result is correct. Later, considering standardization, I changed it like this).
There is a MAKEFILE FOR DJGPP2 file originally in ZLIB, I will add it together...

The following functions will be added:
1
Support for compressed multi - volume for antique hard drives (does not support extended INT13)
2
Reading and writing of four primary partitions (this function is only meaningful for C because generally users have made many disks into logical drives of extended partitions)

Last edited by GOTOmsdos on 2006-8-6 at 21:52 ]

There was a small error in the code updated just now in the CASE: It has now been corrected and reuploaded.

To:GOTOmsdos
The Tc is defined as follows:
#define FP_OFF(fp) ((unsigned)(fp))
#define FP_SEG(fp) ((unsigned)((unsigned long)(fp) >> 16))
It can be seen that the program compiled by TC uses 16-bit addresses, while the program compiled by djgpp uses 32-bit addresses.
So, if in.x.si = (unsigned long) (&DAP_package) is okay, but sregs.ds = (unsigned long) (&DAP_package) is not okay, one is 16-bit and the other is 32-bit.
So, I think direct assignment should not be possible!

It's not sregs.ds = (unsigned long) (&DAP_package)
It's reg.x.si = &DAP_package. Usually this will be okay, I've tried it.

To: dear all
The problem is finally solved. It is because the traditional interrupt calls can only access the low-address 1M memory, and the buffer address of the DOS program in protected mode under DPMI may exceed 1M. So the solution is to use the low-address buffer predefined by DJGPP. Its address is defined as "__tb", and then use the dosmemput and dosmemget functions to realize the data exchange operation between the low-address and high-address buffers. For details, please take a look herehttp://www.delorie.com/djgpp/v2faq/faq18_2.html