Some senseless babbling from Jonathan De Boyne Pollard to Peter Knapper
on 11-13-99  22:12 about "Paging Peter Knapper! .....

[snip]
 JDBP> runs of zero bytes.  LX executables generally do not.  (I say
 JDBP> "generally", because if they use Watcom C/C++ the linker doesn't
 JDBP> support compression, alas.  This is a deficiency in Watcom's linker,
 JDBP> and an unfortunate example of the "jack of all trades, master of none"
 JDBP> adage.)  This is, of course, visible in the comparative sizes of Win32
 JDBP> and 32-bit OS/2 executables. 
[snip]

FYI, folks, one needn't rely on the compression abilities of a linker in
OS/2 to compress an executable.

There's a utility called LxLite which you can use to compress or recompress
an executable.

It's important to note that there are two levels of compression in the LX
format - code and data.  OS/2 2.x only supports data compression, but Warp
3 and later supports both code and data compression.  LxLite can be
configured to do both or either.

The best part is that it does a better job of compressing than any linker
I've seen, including IBM's LINK386.

It will also strip debug information from an executable, unless you tell it
otherwise.  Useful for released programs which the distributor neglected to
link without the debugging info, usually increases the size of the
executable by over 100%.

One can be surprised by how much space is regained after running LxLite on
every executable on a large drive.  When I did it to my primary data drive,
which is about 1.3GB of stuff in 50,000 files or so, I gained over 60MB.

In general, LxLite decreases the executable size by 25% if it wasn't
compressed at all (but doesn't contain debugging info - stripping debug
info usually more than halves the size), and by around 10% over what's
already been compressed by LINK386 with the /EXEPACK:2 switch.

Mike Ruskai
thannymeister@yahoo.com


... Alzheimer's advantage - new friends every day.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
143/1