LxLite

OS/2 LX executables packer.

Remarks
I think all of us are really bored of the big size and reduced functionality of all those modern executables written to run under OS/2 (windows too). I don`t understand why they are so big, because most compilers, even IBM CSet generate a modest size code. For a widely known example let`s take MultiMaint. What complex task does it perform that its executable occupies more that 700K? I don`t understand. Moreover, WHY duplicate (and triplicate) almost the same executable as it does (I mean MultiSafe and IniMaint which comes along with MultiMaint). It performs a nice work, but it is TOO big for the task it accomplishes. OS/2 kernel have the same size. I cannot afford such a large file on my HD, so I killed them. :`-(. Too bad for its author.

Here is a workaround for this. You can just pack the executable so it will be twice smaller and still perform the same task. Alas, it will grab the same amount of memory as original executable does - this is the fault of the program`s author.

As far as I know there is only one program which does the same - REPACK from IBM (EWS?). But compared to lxLite it gives larger files using the same algorithm. For example, COURIER.FON from OS/2 v8.192 it compresses into 44K and lxLite into 34K. Feel the difference. BTW, LINK386+Resource Compiler compiles COURIER.FON also into 44K-size file. This make me think that they use the same common library.

I packed ALL my executables (incuding but not limiting to ?:\os2\*.exe, ?:\os2\dll\*.* and ?:\os2\dll\ibmnull;laserjet) and my system is still working fine. One of lxLite users (Pavel Roskin) observed that lxLite packs even os2krnl. This is a very nice feature to create a SINGLE OS/2 boot diskette.

lxLite compresses the files in the same way as LINK386 does. There is NO way of implementing a executable packing method other than those two which Warp uses (or the only for 2.x). So, here is a brief description of those two algorithms:
 * 1) Run-length packing. This is generally the same method that Microsoft C for DOS uses. It gives VERY bad results because the structure of executable files aren't suited for that kind of packing. For example, PCX files uses approximately the same packing method.
 * 2) Kinda Lempel-Ziv algorithm. Lempel-Ziv is the same method which almost all DOS executable packers use - LZEXE, PKLITE, PGMPAK etc. The method standardized for OS/2 executable files is not the most effective (IMHO). Other thing is that OS/2 executable have a different loading algorithm in contrast to DOS executables - parts of OS/2 executables are loaded only when they are needed. So, Lempel-Ziv dictionary cannot cross the bound of a single page (4096 bytes). Because of this, it gives not such good results as it can.

lxLite can use any of these two methods either for packing or unpacking. Generally the second gives best compression rates, but may be (?) there are some files on which first will work better. Because of this the default is to try to pack page using both methods and then choose the smaller result. lxLite can be used as well for unpacking the files that previously have been packed - either by lxLite, LINK386 or REPACK from IBM.

What kind of files you can compress? The LX format is used almost everywhere in OS/2: almost everything is in LX format. So, you don`t have to limit only to .EXE files: you can pack .DLL, .PDR, .QPR, .DRV, .FON, .SYS (Virtual Device Drivers (VDDs) in \OS2\MDOS) as well. You can run lxLite on virtually any file: if it is not in Linear Executable (LX) format it will refuse to process it.

You can also consider compressing your entire \OS2\*\ directory structure, it will give you a lot of extra space and absolutely no overhead! The time spent for decompressing executables is recovered by the time which system does not spend for reading the executable from HD because it`s much smaller! So, reboot from stand-alone OS/2 diskettes (you can boot from OS/2 installation diskettes (first two) then press F3), then change to drive where your OS/2 is and type \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv and so on. Also you can compress now the executables which are run at system startup, because when they are run you cannot modify their executables and DLLs.

lxLite version 1.00 and above can replace executable modules even if they are currently in use. In this case it will warn you that module is already in use by another process, and will propose you either to replace it by its packed version or either to skip this module. Choose at your wish, but keep in mind that the modules you have replaced are kept now (their old versions) in memory, so they eat up your swapfile space. Better reboot as soon as you have this opportunity.

Versions above 1.00 are supplied in two different executables: one named lxLite.exe is the usual version for OS/2 v2.99, Warp and above. Other, named lxLite2x.exe is meant for use in old versions of OS/2 (i.e. 2.x, NOT 1.x because 1.x doesn't have the LX format). Delete it if you`re an OS/2 Warp user.

Articles

 * Getting Information from a DLL

Releases

 * 1.1.9
 * 1.2.1
 * 1.3.0

Links

 * Bitwise Source Code Github
 * Old Source Code Github