home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 31 / CDASC_31_1996_juillet_aout.iso / vrac_os2 / lxlt113.zip / LXLITE.ENG < prev    next >
Text File  |  1996-06-05  |  27KB  |  516 lines
  1.           ──────────────────────────────────────────────
  2.            LX lite - an compressor for OS/2 executables
  3.           ──────────────────────────────────────────────
  4.  
  5.                  Dedication: To my little daughter Alice,
  6.                          born 12 Feb, 1996 at 03:45.
  7.  
  8.   1. Distribution
  9.   ───────────────
  10.    This program is freeware. This mean that you can distribute it in any way,
  11.  except  for  commercial use. Commercial use is allowed ONLY with my personal
  12.  permission.  To  contact me see the the last section in this file. This also
  13.  means    that  you  have  NO  guaranties that it will perform exactly what YOU
  14.  need. I cannot carry any responsability for any damages, lost of profit etc.
  15.  caused  by  use  or  inability to use this program.
  16.    However,  you CAN use it to enhance any, even commercial, product. This is
  17.  not  for  YOUR benefit but rather for benefit of poor users who are BORED of
  18.  the big size of executables.
  19.    The    program is written exclusively in Virtual Pascal, beta 3, with use of
  20.  its  built-in    32-bit    assembler.  This is an excellent language which takes
  21.  full  advantages  of  OS/2`s possibilities, is BorlandPascal compatible, and
  22.  have  a  powerful  built-in optimizer. If you want the lxLite`s source code,
  23.  please  mail  me,  but  you have to tell me WHY do you need it, to avoid the
  24.  people which likes to re-sell other`s programs under their name.
  25.  
  26.   2. Introduction
  27.   ───────────────
  28.    I  think  all  of  us  are  really  bored  of  the  big  size  and reduced
  29.  functionality    of  all  those    modern    executables written to run under OS/2
  30.  (windos  too).  I  don`t  understand  why  they  are  so  big,  because most
  31.  compilers,  even  IBM    CSet  generate a modest size code. For a widely known
  32.  example  let`s  take  MultiMaint.  What  a complex task it performs that its
  33.  executable  occupies  more  that  700K?  I  don`t  understand. Moreover, WHY
  34.  duplicate  (and  triplicate)  almost  the same executable as it does (I mean
  35.  MultiSafe  and  IniMaint  which  comes along with MultiMaint). It performs a
  36.  nice  work,  but it is TOO big for the task it acomplishes. OS/2 kernel have
  37.  the  same  size.  I  cannot  afford such a large pile of shit on my HD, so I
  38.  killed MultiMaint & C°. :`-(. Too bad for its author.
  39.    Here is a workaround for this. You can just pack the executable so it will
  40.  be  twice  smaller  and  still perform the same task. Alas, it will grab the
  41.  same amount of memory as original executable does - this is the fault of the
  42.  program`s author.
  43.    As  far  as    I know there is only one program which does the same - REPACK
  44.  from  IBM  (EWS?).  But  compared  to lxLite it gives larger files using the
  45.  same algorithm. For example, COURIER.FON from OS/2 v8.192 it compresses into
  46.  44K  and  lxLite  into  34K.  Feel  the  difference.  BTW,  LINK386+Resource
  47.  Compiler  compiles  COURIER.FON  also into 44K-size file. This make me think
  48.  that they use the same common library.
  49.    I  packed  ALL  my executables (incuding but not limiting to ?:\os2\*.exe,
  50.  ?:\os2\dll\*.*  and  ?:\os2\dll\ibmnull;laserjet)  and  my  system  is stiil
  51.  working  fine    :-)  One  of lxLite users (Pavel Roskin) observed that lxLite
  52.  packs    even  os2krnl :-) This is a very nice feature to create a SINGLE OS/2
  53.  boot diskette.
  54.  
  55.   3. Features
  56.   ───────────
  57.    lxLite  compresses  the files in the same way as LINK386 does. There is NO
  58.  way  of  implementing a executable packing method other than those two which
  59.  Warp  uses  (or  the only for 2.x). So, here is a brief description of those
  60.  two algorithmhs:
  61.  
  62.    1.  Run-length packing. This is generally the same method that Microsoft C
  63.  for  DOS uses. It gives VERY bad results because the structure of executable
  64.  files    aren`t    suited    for that kind of packing. For example, PCX files uses
  65.  approximatively the same packing method.
  66.  
  67.    2.  Kinda Lempel-Ziv algorithm. Lempel-Ziv is the same method which almost
  68.  all  DOS  executables    packers  use  - LZEXE, PKLITE, PGMPAK etc. The method
  69.  standartized  for  OS/2  executable  files is not the most effective (IMHO).
  70.  Other    thing  is  that OS/2 executable have a different loading algorithm in
  71.  contrast to DOS executables - parts of OS/2 executables are loaded only when
  72.  they  are  needed.  So,  Lempel-Ziv  dictionary  cannot cross the bound of a
  73.  single page (4096 bytes). Because of this, it gives not such good results as
  74.  it can.
  75.  
  76.    lxLite  can    use any of these two methods either for packing or unpacking.
  77.  Generally  the second gives best compression rates, but may be (?) there are
  78.  some  files  on which first will work better. Because of this the default is
  79.  to  try  to pack page using both methods and then choose the smaller result.
  80.  lxLite can be used as well for unpacking the files that previously have been
  81.  packed - either by lxLite, LINK386 or REPACK from IBM.
  82.  
  83.    What  kind  of  files  you  can  compress?  The  LX    format is used almost
  84.  everywhere in OS/2: almost everything is in LX format. So, you don`t have to
  85.  limit    only  to  .EXE files: you can pack .DLL, .PDR, .QPR, .DRV, .FON, .SYS
  86.  (Virtual  Device Drivers (VDDs) in \OS2\MDOS) as well. You can run lxLite on
  87.  virtually  any  file:    if it is not in Linear Executable (LX) format it will
  88.  refuse to process it.
  89.  
  90.    You can also consider compressing your entire \OS2\*\ directory structure,
  91.  it  will  give you a lot of extra space and absolutely no overhead! The time
  92.  spent    for  decompressing  executables is recovered by the time which system
  93.  does  not  spend  for    reading  the  executable  from    HD  because it`s much
  94.  smaller!  So, reboot from stand-alone OS/2 diskettes (you can boot from OS/2
  95.  installation  diskettes  (first  two)    then  press F3), then change to drive
  96.  where your OS/2 is and type
  97.   \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv
  98.    and    so  on.  Also  you  can compress now the executables which are run at
  99.  system   startup,  because  when  they  are  run  you    cannot    modify    their
  100.  executables and DLL`s.
  101.  
  102.    lxLite  version 1.00 and above can replace executable modules even if they
  103.  are  currently  in use. In this case it will warn you that module is already
  104.  in  use by another process, and will propose you either to replace it by its
  105.  packed  version  or  either  to  skip    this module. Choose at your wish, but
  106.  keep  in  mind  that  the  modules you have replaced are kept now (their old
  107.  versions)  in    memory,  so they eat up your swapfile space. Better reboot as
  108.  soon as you have this opportunity.
  109.  
  110.    Versions  above  1.00 are supplied in two different executables: one named
  111.  lxLite.exe  is  the  usual  version  for OS/2 v2.99, Warp and aboves. Other,
  112.  named    lxLite2x.exe  is meant for use in old versions of OS/2 (i.e. 2.x, NOT
  113.  1.x because 1.x doesn`t have the LX format). Delete it if you`re a OS/2 Warp
  114.  user.
  115.  
  116.    Version 1.1.0 and above detects executables which contains some data after
  117.  the  LX  structure  itself  (i.e.  what`s  called  in DOS overlay data). For
  118.  example  Watcom`s  binded executables (such as WCC.EXE versions >= 10.0) and
  119.  Watcom  Visual  Rexx  executables  have  such structure. In this case lxLite
  120.  shows    an warning message and asks for confirmation whenever you really want
  121.  to  pack  such  executable.  It  is STRONGLY recommended that you backup the
  122.  executable  in  question  before trying to do it because it is VERY possible
  123.  that  it will become non-functional if something gets changed in it (because
  124.  lxLite  does  not change any of possible pointers in data binded to LX as in
  125.  VREXX executables).
  126.  
  127.  
  128.   4. Options
  129.   ──────────
  130.    There are alot of options in lxLite. I simply like options :-) So, you can
  131.  configure almost anything in lxLite. Moreover, to protect the user from need
  132.  of writing the same options lxLite support multiple configurations which are
  133.  kept  in  a  single  file.  lxLite  comes  with  some example configurations
  134.  (`factory defaults`) which are listed below:
  135.  ────────────────────────────────────────────────────────────────────────────
  136.   default: (loaded by default)
  137.    It is a `work` configuration. All parameters are set to maximize
  138.    compression. .BAK file creation is disabled. Note that this configuration
  139.    is ALWAYS loaded before any other options are in effect, so even /C{#}
  140.    option is executed AFTER default configuration is loaded.
  141.  
  142.   fast: Lowest compression level, fastest executable loading. According
  143.    to IBM when data objects are aligned inside of file on sector boundary
  144.    (512 bytes) executable will load faster. I cannot observe a difference,
  145.    so try it at your own. If some data in executable was previously packed
  146.    it is not de-packed then re-packed.
  147.  
  148.   fast2: Compress a bit better, but slower. Loads as fast as CFG#1 does.
  149.  
  150.   ver2x: Optimal for pre-Warp versions of OS/2. Versions before Warp (3.0)
  151.    does not know of the Lempel-Ziv (/EXEPACK:2) method. DON`T PACK
  152.    EXECUTABLES WITH LEMPEL-ZIV`s ALGORITHM if there is a chance to run
  153.    your program on OS/2 v2.xx (except 2.99).
  154.  
  155.   failsafe: Lempel-Ziv packing enabled. A `fail-safe` configuration.
  156.    All data are written just like LINK386 does, because of this creates a
  157.    bit bigger files than using default configuration. FOR WARP ONLY!
  158.  
  159.   max: Tightest compression level. VERY SLOW! It is rarely needed to use
  160.    this configuration.
  161.  
  162.   newStub: This is a particular configuration used to replace one DOS stub
  163.    in LX executable by another without altering anything else. You have to
  164.    specify a filename for new stub - this configuration only tells lxLite
  165.    not to depack old objects and not to pack unpacked objects.
  166.  
  167.   minStub: This is a configuration which is linked to newStub and replaces
  168.    stubs in given files by minimal possible stub of `say-error-and-exit`
  169.    type. You cannot make it smaller (at least I doubt it), only if you
  170.    shorten the error message.
  171.  
  172.   vdmStub: This configuration tells lxLite to replace in specified files
  173.    stub by a `run-from-VDM`-style one. This is also as short as possible :-)
  174.    Please read the /T{#} option description for further details.
  175.  
  176.   info: Use this configuration to get information about executables (see
  177.    options /V+) without rewriting them.
  178.  ────────────────────────────────────────────────────────────────────────────
  179.    To  use  a specific configuration use /C# where # is configuration`s name.
  180.  The  settings    are  stored  into file lxLite.CFG in the same directory where
  181.  lxLite.EXE resides. You shouldn`t care about paths - lxLite will always find
  182.  it. For example, to use `max` configuration run lxLite /cMax. For a detailed
  183.  description of .CFG file format see section right below the following.
  184.  
  185.    Here  is  a    detailed  explanation of what each switch does. Note that any
  186.  switch  which    accepts  '+'  or  '-'  sign  after  it (to enable/disable the
  187.  action which switch symbolizes) can be used without anything after it - this
  188.  is accepted as '+'. So, /V+ is equivalent to /V.
  189.  
  190.   ■ /A{P|S|N{P|S}}
  191.      Set alignment method for first and rest of objects. First object can
  192.      be aligned on [P]age shift, [S]ector or [N]o boundary. Note that the
  193.      last option (No boundary) is never used by LINK386, but it works well,
  194.      and the LX format allows it. All objects except first MUST be aligned
  195.      at least on a PageShift boundary. PageShift is a value that is specified
  196.      in LX header. If you want to redefine it use /R# option.
  197.  
  198.   ■ /B{+|-}
  199.      Enable (+) or disable (-) renaming of original file into .BAK.
  200.      Note that this is a BETA version - that is why .bak files are
  201.      enabled by default.
  202.  
  203.   ■ /C{#}
  204.      Use configuration with ID = #
  205.      The two predefined configuration names are "default" and "unpack".
  206.      First is always loaded as lxLite starts and second is used when /X+
  207.      option is specified (NOT equivalent to /cUnpack).
  208.  
  209.   ■ /D{#}
  210.      Set exclu[D]e filemask. All files that passes given filemask(s) will
  211.      be bypassed by lxLite. All filemasks must be separated by ':' (because
  212.      it cannot be a part of filemask). For example /D*.zip:*.arj:*.rar switch
  213.      will instruct lxLite to avoid all .zip, .arj and .rar files. Default
  214.      lxlite configuration (/Cdefault) includes the [exclude] configuration
  215.      which instructs lxLite to avoid all executables which are known to
  216.      have problems when packed. Note that the /D switches are additive, so
  217.      /D*.zip /D*.arj /D*.rar is equivalent to the example above. To clear
  218.      exclusion list simply specify /D.
  219.  
  220.   ■ /F{+|-}
  221.      Forced repacking. Use /F+ to bypass `already processed` message, i.e.
  222.      when lxLite thinks that file was already processed and it really wasn`t.
  223.      This usually doesn`t happen, but can happen when you try to replace a
  224.      stub by another of the same size in a already packed file.
  225.  
  226.   ■ /G[X|D]{#}
  227.      e[X]tra / [D]ebug data will [G]o into specified file. When lxLite will
  228.      encounter an LX file which contains debug or extra data and you will
  229.      tell it to discard that data, before discarding lxLite will put it into
  230.      specified file. The {#} component can be as well an filemask, so you can
  231.      for example put extra data into files with the same name as original, but
  232.      with different extension and so on. For example /GD*.dbg will instruct
  233.      lxLite to write discarded debug information into file with the same name
  234.      as original but with extension ".dbg".
  235.  
  236.   ■ /I{+|-}
  237.      Force (+) lxLite to run at idle priority. This mean that lxLite will do
  238.      its work only when no other activity in system occurs (waiting for an
  239.      keyboard/mouse event etc). This is the best in my opinion choice because
  240.      you can run lxLite in background and it will not degrade almost at all
  241.      system performance. However if you`ll run an `badly-behaved` VDM
  242.      session which grabs all CPU time lxLite will completely stop. When run
  243.      with /I- option lxLite does not changes its priority (i.e. you can run
  244.      lxLite /I- via priority.exe program which starts programs at given
  245.      priority).
  246.  
  247.   ■ /L{#}
  248.      Instructs lxLite to maintain an log file. It contains only those
  249.      file which lxLite processes, the files that were skipped by some
  250.      reason will not be present there. If no file name is specified the
  251.      default will be lxLite.log in the home lxLite directory. Beside the
  252.      filename, the start and final file size is written into log along
  253.      with the problems (if any) that were encountered when processing
  254.      (for example: 'Executable has been used by another process and replaced')
  255.  
  256.   ■ /M{R{N|1|2|3}|L{N|1}}
  257.      Set packing method & parameters. Second character defines the method
  258.      to set-up: `R` stands for run-length (/EXEPACK:1) and 'L' for Lempel-Ziv
  259.      (/EXEPACK:2). The third character is the level of compression using that
  260.      method; if N is specified the method is disabled. Three levels of
  261.      packing are provided for run-length compression. The level 1 is the
  262.      fastest. It searches only for 1-character strings. For example, the
  263.      'AAAAAAAA' string will be detected and packed as 8, 1, 'A' while
  264.      'ABABABAB' string will be stored as unpacked text. Level 2 detects
  265.      strings of any length up to 16 characters long. The example above will
  266.      be encoded then as 4,2,'AB'. This is the default setting for most
  267.      'factory` configurations. And last, 3rd level searchs for ALL strings
  268.      of any length (up to page size/2 = 2048). This compress VERY slow and
  269.      seldom gives real results, so use it only when you really need it.
  270.      The Lempel-Ziv algorithm can be either disabled (/MLN) or enabled (/ML1).
  271.      When enabled it searchs for all matches using a relatively fast
  272.      hash-table, so there is no need in gradations by compression speed.
  273.  
  274.   ■ /P{+|-}
  275.      Enable (+) or disable (-) pause before each file.
  276.      The program shows the name of file which will be processed and
  277.      offers a choice to continue or to abort.
  278.  
  279.   ■ /Q
  280.      Query all configuration options. Basically it simply types a colored
  281.      version of lxLite.cfg file :-) Any other options (if any) are ignored.
  282.  
  283.   ■ /R{#}
  284.      [R]e-align pages on specific boundary. (#) must be a power of two.
  285.      This is an analog of LINK386`s /ALIGN: switch. Many of the programmers
  286.      don`t care that the default setting for /A: is to align each page
  287.      inside the executable on 512 (sector) bound. The result is a lot of
  288.      unused space inside the executable. You can `re-link` such files with
  289.      another /ALIGN: option. Default is /R:4. To force lxLite to behave
  290.      like LINK386 you must use /R:512 option. This is equivalent to /ASS :-)
  291.      option.
  292.  
  293.   ■ /S{+|-}
  294.      Show (+) or don`t show (-) configuration in effect.
  295.      This is useful for examining which settings are stored into .CFG file,
  296.      especially for linked configurations (see below). For example
  297.      lxLite /Cdefault /S will show the default settings.
  298.  
  299.   ■ /T{#}
  300.      Use specified file as new DOS stub. DOS stub is a little DOS .EXE file
  301.      linked to OS/2`s LX file which is usually used to type an error message
  302.      in the case if the executable is not run from DOS command line. Usually
  303.      this looks like:
  304.  
  305.      This is an OS/2 executable module
  306.  
  307.      Along with lxLite are enclosed two stubs: stub_min.bin and stub_vdm.bin.
  308.      First is the standard `type-error-and-exit` type, but it is slightly
  309.      smaller than usual stubs used by various linkers. The second is an stub
  310.      which starts a new OS/2 session and runs program from it again. If OS/2
  311.      is not detected it types the same error message and exits. The default
  312.      for stub_vdm.bin is to let OS/2 decide the type of your executable
  313.      itself. Alternatively, you can specify the type of session to be started
  314.      by stub_vdm.bin. For this you need any hex editor - find the pattern
  315.      `SesType->' in stub and replace the byte that comes after arrow (->) by
  316.      needed session type. OS/2 recognizes next session types:
  317.  
  318.     00 - OS/2 session manager determines type (default)
  319.     01 - OS/2 full-screen session
  320.     02 - OS/2 windowed session
  321.     03 - PM application
  322.     04 - VDM full-screen session
  323.     07 - VDM windowed session
  324.  
  325.   ■ /U{+|-}
  326.      Enable (+) or disable (-) unpacking file before packing
  327.      lxLite know how to unpack any of two methods described, so default
  328.      option state is enabled. Disable it only if you wish to save time.
  329.  
  330.   ■ /V{+|-}
  331.      Verbose (show alot of file information)
  332.      This is a switch for curious ones :-) It displays a little information
  333.      about processed file (to get full information on .LX file use exeHdr.EXE
  334.      from OS/2 Programmer`s Toolkit).
  335.  
  336.   ■ /W{+|-}
  337.      Enable (+) or disable (-) the [W]riting of resulting file to disk.
  338.      By default it is enabled, but you can disable it if you wish to examine
  339.      the executable information (/V+) without having rewritten or repacked file.
  340.      Also this option can be useful for debugging your options.
  341.  
  342.   ■ /X{+|-}
  343.      e[X]pand (+) or pack (-) given files.
  344.      Use this switch to decompress files. lxLite can decompress files
  345.      which has been compressed by itself as well as by other programs which
  346.      uses standard methods (i.e. Resource Compiler, LINK386, REPACK). It
  347.      is NOT identical to /cUnpack option.
  348.  
  349.   ■ /Z{#}
  350.      This option will set the `threshold` for lxLite to help him determine
  351.      when stub is a `dummy` one and when it is a functional program. There
  352.      are a number of programs (for example, \os2\xdfloppy.exe) which runs
  353.      both under DOS and OS/2 - in such programs DOS executable is implemented
  354.      into OS/2`s LX as a DOS stub. By default (and using simply /Z) lxLite
  355.      considers all stubs bigger than 1024 bytes as functional ones, and
  356.      therefore on them the /T{#} option has no effect.
  357.  
  358.   /?,/H
  359.      Show a brief help. This is useful when you forget a particular
  360.      switch from all that list :-)
  361.  ────────────────────────────────────────────────────────────────────────────
  362.    The    .CFG  file  format is as simple as possible: it is a plain ASCII text
  363.  file  which  you can edit using any editor which supports them (almost any).
  364.  Any characters after a semicolumn ';' are ignored, i.e. you can put comments
  365.  in configuration file like this:
  366.  
  367.   ; This is an comment
  368.  
  369.    Any    line  begining    with a word and column (ex: "word:") are treated as a
  370.  particular  configuration.  This word is used to identify the configuration.
  371.  This is an example of a configuration entry:
  372.  
  373.   failsafe: /APP /B- /G+ /R4 /MR2 /ML1 /P- /U+ /V-
  374.  
  375.    As  you  can see, after column you should write any switches just like you
  376.  do  with  lxLite  itself.  Recursive  /C options are NOT ignored, so you can
  377.  link  one configuration to another, but /C option is proceeded last, so from
  378.  two overlapping options will be in effect the last one. Just for example:
  379.  
  380.   here: /app /b- /g+
  381.   there: /ass /b+ /p+
  382.  
  383.    Running "lxLite /cThere" will be equivalent to "lxLite /app /b- /p+ /g+"
  384.  Note that lxLite will ignore any sequenced links to the same configuration
  385.  to avoid infinite-loop recursion. So, "lxLite /cOne /cOne" will load `One`
  386.  configuration only ONCE.
  387.  
  388.   5. Error messages
  389.   ─────────────────
  390.    Like  most  normal  programs  :-)  lxLite  can  eventually  generate error
  391.  messages.  Some  of  them  can  appear  in similar conditions, but caused by
  392.  different causes. Here is a short list of the most frequent errors:
  393.  
  394.  * Invalid configuration file format
  395.    Self-explaining, I think :-)
  396.  
  397.  * Error reading configuration file
  398.    This error is generated ONLY if the file is not physically readable.
  399.    The program does not generate an error if the configuration file is
  400.    missing.
  401.  
  402.  * Error writing configuration file
  403.    Self explaining.
  404.  
  405.  * error reading executable
  406.    This is generated if executable is physically unreadable.
  407.  
  408.  * error writing executable
  409.    This is generated if executable cannot be written onto disk. The cause
  410.    can be the insufficience of disk space - lxLite does not check for this
  411.    particular error.
  412.  
  413.  * invalid executable file format
  414.    The file is not in [L]inear [E]xecutable. Note that you can get this
  415.    message for files with .EXE extension in the cause they are in old,
  416.    'New Exe (bwhahaha)' format or DOS executable or winDOS executable.
  417.  
  418.  * unsupported executable format revision
  419.    This error can happen (may be :-) if you try to process an executable
  420.    with other revision number than 0. OS/2 Warp works only with revision
  421.    0, so you will not normally encounter this problem.
  422.  
  423.  * invalid word/dword ordering in executable
  424.    The executable uses little-endian byte order. Seems that it is not for
  425.    Intel platform machines.
  426.  
  427.  * executable target is an unsupported CPU type
  428.    This happen if the target CPU is other than 286, 386, 486 or P5.
  429.  
  430.  * executable target is an unsupported OS
  431.    This mean that the executable is not for OS/2. The windos 95 uses similar
  432.    format, but its magic number is not `LX` but rather `LE`, so usualy
  433.    program will abort with `invalid format` error code.
  434.  
  435.  * unknown entry bundle type in executable
  436.  * unknown page flags in executable
  437.  * invalid object page detected in executable
  438.    It`s something about internal structure that lxLite doesnt know about.
  439.    Please mail me if you encounter such files.
  440.  
  441.  * not enough memory to load executable
  442.    I doubt this error can happen in OS/2 :-) Rather a swap-file full fault
  443.    will occur. BTW, it`s a bad idea of IBM programmers to trap instead of
  444.    returning NIL pointer at memory request :-(
  445.  
  446.   6. Todo list
  447.   ────────────
  448.    Here  is  a    list  of  features I plan to add in some future versions. Any
  449.  suggestions are welcome, to contact me see the last section.
  450.  
  451.  * May be a feature to pack the LX stub in VX-REXX files. However, I doubt
  452.    it is really needed because the difference in stub size (before and after
  453.    packing) is about 18K - lxLite cannot pack the real program data because
  454.    it is 1) out of LX structure and 2) because it is encrypted in some way
  455.    and such data cannot be packed at all (even PKZIP fails to do it).
  456.  
  457.  * May be a `extra-pack` option. I have an idea how to pack executables
  458.    as tough (and tougher :-) than DOS packers do, however such executables
  459.    will not work as usual - they will work always as `unlocked` executables
  460.    (see UNLOCK program) i.e. they will reside in swap file if not enough
  461.    memory will be available - this doesn`t mean that they will work slower
  462.    but this means that swap-file size will increase dramaticaly when such
  463.    executables will be launched). Tell me if you really wanna it - if I`ll
  464.    receive enough requests I`ll do it.
  465.  
  466.   7. Known bugs and limitations
  467.   ─────────────────────────────
  468.    Here are a list of executables which failed for some reasons to work
  469.  packed; avoid them.
  470.  
  471.    *  PMJPEG  v1.5.  However,  even IBM`s REPACK cannot repack it, so I think
  472.  this  is  because  of    either a bug in a linker used to generate it (and its
  473.  executable   has  a  strange  structure)  or  a  kind    of  debug  protection
  474.  (executable checksum checking?)
  475.  
  476.    *  VX-REXX  executables.  The main body of such executables (REXX ciphered
  477.  code)    is  simply  appended  to  a  small  LX stub. Such executables have an
  478.  unknown  structure  and  after  lxLite packs its stub they become completely
  479.  obsolete.
  480.  
  481.    *  Watcom C & C++ v>=10.0. Seems that Watcom likes to append garbage to LX
  482.  files. These executables are meant for running in both OS/2 and DOS sessions
  483.  and also have a strange structure.
  484.  
  485.   8. Contacting me
  486.   ────────────────
  487.    You can contact me via e-mail at:
  488.  
  489.       FIDOnet:    2:5030/84.5 (prefered)
  490.       Internet: Andrew Zabolotny@p5.n84.r5030.z2.fidonet
  491.         bit@freya.etu.ru (seldom)
  492.  
  493.  Enjoy,
  494.    _\ndy
  495.  
  496.  I would thank Herwig Bauernfeind who contributed to German translation of
  497.  the documentation; he also mentioned some bugs which was (finally!) fixed
  498.  in this version. Alas he wrote the German version of documentation before
  499.  I added some changes to lxLite so it is (very little) out of date.
  500.  Here is a paragraph written completely by Herwig:
  501.  
  502.  9. Translator
  503.  ─────────────
  504.  
  505.    As  I  really was very happy about Andys program, I asked whether he would
  506.  like  a  german translation of the documentation of version 1.01. Well, some
  507.  things  sound    a  bit    'bumpy', but first of all, I am doing this as a hobby
  508.  only,    secondly  I  am  not  professional  programmer.  I hope, it will help
  509.  anyway.
  510.  
  511.    You    can  reach  me    by  email  (although  this  is    quite  useless,  as I
  512.  contributed the translation only):
  513.  
  514.       FIDOnet:    Herwig Bauernfeind, 2:312/5.35
  515.       InterNet: H_BFD@fidonet.at (does not work reliably by now)
  516.