Hi, so aPack does not have an "unpack" function? UPX does have one, so no dependency problems. You can remove the UPX stub at any time by de-UPXing the binary again. Problem with UPX is that the author is very hard to reach, even if you send him GPG / PGP mail (required to bypass his spamfilter)... The UPX stubs do not support "driver EXE" file format - they simply compress the EXE part and the driver part stops to work because of that. Another thing is that the stub hooks the strategy, not the interrupt, part of SYS binaries, so it cannot check whether enough RAM is free before unpacking the binary in RAM. I think not even the COM stub checked the SP value (to know the amount of available RAM)...
So UPX does not work at all for the "driver EXE" file format, and it has no sanity checks for SYS and COM format (so if you use DEVICEHIGH / LOADHIGH into too small UMBs, you will only know what happened after the crash...). For the other cases (normal EXE, loading SYS / COM low, having big enough UMBs, other file formats like Win32 and Linux ELF), UPX is pretty nifty. I even dare to have LBAcache / CDRcache UPXed by default even though they are COM/SYS files. Maybe I should add a warning about that tiny-UMB problem? Eric. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
