Hi, I found that a very "small" way to decompress CPI files would be using UPX to compress them and then patch the decompression process. Here is a sketch. I think this should work with both open source and NRV versions of UPX.
Copy file to 60k sized buffer at X:0x100 If no UPX signature found, CPI is ready. Else patch "cmp sp,... / ja okay / int 0x20 / okay:" sequence, e.g. by NOPing out the int 0x20 line and do the following decompression steps: Replace first raw byte by RETF (will be the 3rd byte in the compressed stream: UPX streams contain bitstring-words, offset-bytes and literal bytes. Compressed stream starts with 1 bitstring word and 1 literal byte for obvious reasons.) and set ES=DS to point to segment X. SS/SP stay at the value which MODE uses anyway, so they will be out of the way. Finally, call far x:0x100 to make the file deUPX itself in RAM (will use the end of the 60k buffer for that: UPX stub works like 1. check SP 2. copy self-and-compressed to end of a buffer of size=stub- size-plus-decompressed-size 3. jump to part 2 of the stub, which is at the end of the compressed file 4. decompress 5. do fixup for jmp/call near commands if needed (convert from absolute - used for better compression - to relative offsets again) 6. ret to the decompressed "program"). I see no reasons why "ren ega.cpi ega.com / upx --8086 ega.com / ren ega.com ega.cpx" and the above decompression trick should not work for all standard CPI files (do not forget to fix the RETF back to "proper first byte of a CPI" after the call far). And UPX-opensource license should be okay for the suggested use of UPX. Note that this works only because the COM decompression stub is small and simple and it is easy to patch the first byte of the original file even after compression. So if you want to suggest another exepacker... UPX packs very well (CPI will be 6k instead of 60k, much like with ZIP/GZIP) even though the decompressor does not do more than parsing a bitstring like "bit 1 means copy literal byte, bit 0 means copy N bytes from M bytes ago", but of course with a very clever method to encode the N and M values in the bitstring (and the literal-low-byte-of-M bytes which are used when M changes), which is very much the same as in LZEXE and PKLITE. The difference is that UPX uses a very small and optimized decompressor stub while the others use some tables and other complicated things in their N / M encoding scheme. Of course I do not suggest to use LZEXE or PKLITE for CPI compression - they are closed source shareware. Eric. ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
