___.__ _.____.___ __/\__ __/\__ \ | ____ __/\__\. \ / \/ ___\| \| < | / | < < T < | /_.___| /__._/ /__.__\_ __.__\ l_.___\ /__.___\ /______| l___.__\ \/ /_______\AnG .:the:smaller:the:better:. Copyright (c) 1997-98 by 퀭Jibz饗 All Rights Reserved aBOUT: 컴컴컴 Humm .. well .. nothing much to say yet .. the whole idea behind this packer is to make executable files (especially small ones) as small as possible (hence the slogan).. Exe-packers like LZEXE are ok for small files .. but the unpacker takes up 330 bytes... WWPACK is great for medium and large files because its compression is great ;) .. but _at_least_ 380 bytes for an unpacker is way too much for 4k intros and BBS-intros (IMHO ;).. The unpacker in aPACK is between 153 and 253 bytes long (depending on the input file). I have put a lot of work into making it as small as possible. Compression ratio is pretty much the same as WWPACK. If you want your file to be as small as possible - try them both :) On small files (below 20k or so) I have not been able to find anything better than aPACK). Furthermore LZEXE can be unpacked by any decent unpacker out .. and WWPACK can be unpacked by CUP386. I have not been able to find an unpacker able to automatically unpack aPACK files (except files that UPC works on ... but then you can just use AntiUPC or something like that). Of course anybody who knows anything about packers will be able to unpack files packed with aPACK .. but at least most lamers won't be able to ;) So far aPACK is GREET-WARE for non-profitable use (if nobody charges money for programs that are packed with it) which means that if you use it, then please greet me (well, ain't that cheap!). If you (or anybody else) plans to sell a program packed with aPACK then contact me (email address later..) You may not distribute aPACK without the rest of the files (aPACK.DOC and WHATS.NEW). And you may not edit any of the files or sell aPACK for money (except for charging for the media). Feel free to upload aPACK to any BBS or site, or including it on a CD.. Bla bla bla .. the usual stuff - you know it anyway: If anything goes even remotely wrong - blame _yourself_, NOT me! aPACK "LIMITATIONS": 컴컴컴컴컴컴컴컴컴컴 In the following: 1) if your program has a problem with that - use some other packer!!! aPACK does NOT unpack the code back to where it would have been (why waste space on code to do that ?) .. instead the unpacker is at the front of the exe, and it unpacks the code further into memory. This, of course, requires more memory .. but 1). When the unpacker jumps to the unpacked code, ES and DS, as usual, point to the PSP (which has not been moved) .. hence the PSP is NOT at CS-10h anymore, 1). I do NOT zero any registers in the unpacker .. if you need any registers to be zero, then zero them in your code (the packed file will be smaller that way ;). Again, 1). The experimental COM-packer only works (so far) on files where both packed and unpacked data fit into 64k. The aPACK unpacker has NO funky little messages or other forms of "wastefull bytes" - I have tried to make the unpacker as small and "clean" as possible. The unpacker depends on the input-file .. Eg. if all unpacked code fits into 64k then no code to handle segments will be added. And if there are no relocations then no relocation-handling-code will be added (why add a full- blown super-duper unpacker to a mini-file??) A "code-mover" will propably be included in one of the next releases :-) aRGUMENTS: 컴컴컴컴컴 So far there are only a few switches and arguments for aPACK: Syntax: aPACK [options] [output file] General options: -i Invert literals EXE-specific: -d Don't save DS and ES -r Don't pack relocation-table and code together -s Force own stack in unpacker COM-specific: -p Leave segment of PSP in DS and ES The switches can be given anywhere in the argument-list, in any case and in any order you like. Input- and output file should be pretty self- explanatory. The switches work like this: -i : Invert literals - this inverts all literals that are transmitted. This makes it somewhat more difficult to read text-strings using an hex-editor or some other viewer (unless of course you invert them back :) .. This is NOT meant to be any kind of protection - it merely makes the exe-file look more uninviting ;) It costs you 3 bytes. -d : Don't save DS and ES - if you do not need anything from the PSP in your program, then use this switch. It makes the unpacker 4 bytes smaller. -r : Don't pack relocation-table and code together - by default the relocation-table is packed together with the code (unless there are LESS than 8 relocations - in which case they are hard-coded into the depacker). It is worth experimenting with this switch on files with more than 7 relocations, but "not too many". May save a few bytes .. on the other hand, may not ;) -s : Force own stack - forces aPACK to set up its own stack when unpacking (usualy it chooses to add it's own stack whenever necessary). Costs 12 bytes. -p : Leave segment of PSP in DS and ES - this will give you easy access to the PSP from COM-files, and it is compatible with EXE-files converted to COM-files with exe2bin. aLGORITHM: 컴컴컴컴컴 aPACK uses (right now) LZSS with 57300 bytes lookback and lazy-matching. Tag-bits are inserted in the data to distinguish literal bytes from code-pairs. Code-pairs are encoded using my own version of Gamma-encoding. aPPRECIATION: 컴컴컴컴컴컴� .. goes out to the following people: * x-otic for being a great beta-tester and drawing me a logo (thx mate ;) * "Jurik" for discussing the mysteries of Gamma-encoding with me * The people who made the Epsilon Compression Page * Piotr Warezak, for making a truly great exe-packer * Michael Tippach (Wuschel) for making WDOSX (all you need now is a good exe-packer, and I'll switch to WDOSX for sure ;) * All other people who make good software freely available for non- commercial use! aLWAYS THE NEWEST VERSION: 컴컴컴컴컴컴컴컴컴컴컴컴컴 You can find it at: ftp://ftp.elf.stuba.sk/pub/pc/pack/ aND HOW TO REACH ME: 컴컴컴컴컴컴컴컴컴컴 Well, if you have any questions, suggestions or bug-reports about aPACK (or you just like chatting), this email-address should work: jibz@hotmail.com