            ----------------------------------------------------
             lxLite - ein Packer fuer ausfuehrbare OS/2-Dateien
            ----------------------------------------------------

                                     Widmung: Meiner kleinen Tochter Alice,
                                          geboren am 12 Feb, 1996 um 03:45.

0. Version der deutschen Dokumentation
--------------------------------------

   Die  deutsche Uebersetzung basiert auf der  englischen  Dokumentation zu
lxLite 1.1.5.

1. Distribution
---------------

   Dieses Programm  ist Freeware.  Das heisst,  man kann es verbreiten, wie
man will,  ausser fuer den kommerziellen  Gebrauch. Kommerzielle Verwendung
ist  nur  mit  meiner  ausdruecklichen  Zustimmung  erlaubt.  Wie  man mich
kontaktieren kann ist in der letzten Sektion dieser Datei zu sehen.

   Freeware heisst aber auch, dass es keinerlei Garantie fuer das gibt, was
das Programm  macht,  ob  es das macht  was man erwartet,  ob es ueberhaupt
etwas  macht.  Ich  uebernehme  keinerlei  Verantwortung  fuer  irgendeinen
Schaden,  entgangene Profite etc.,  die durch Fehler dieses Programms (oder
der Uebersetzung der Dokumentation) verursacht werden.

   Wie auch  immer,  es  ist erlaubt,  das Programm  dazu  zu verwenden, um
jedes, auch jedes kommerzielle Produkt zu verbessern. Und zwar nicht um den
eigenen  Vorteil,  sondern um  den Vorteil aller armen User,  die  sich mit
riesigen Programmdateien herumaergern muessen.

   Das  Programm  ist ausschliesslich  in  Virtual  Pascal  1.0  Beta #003,
geschrieben, vor allem mit dem eingebauten 32-bit Assembler. Virtual Pascal
ist eine excellente Sprache,  die alle Vorteile und Moeglichkeiten von OS/2
bedient und unterstuetzt,  gleichzeitig Borland Pascal kompatibel  ist, und
einen maechtigen eingebauten Optimierer hat.

   Falls du den Source  Code von lxLite willst,  bitte wende  Dich an mich,
aber  du  musst mir ganz  sagen WARUM du  ihn brauchst;  Leute,  die fremde
Programme unter eigenem Namen verkaufen wollen, bekommen ihn sicher nicht.

 2. Einfuehrung
 -------------

   Ich denke,  wir alle  sind recht  sauer ueber die gewaltige  Groesse die
fast alle modernen Programme haben, die unter OS/2 laufen (fuer WinDOS gilt
allerdings  das  gleiche),  ohne  oft  entscheidend  mehr  zu  koennen  als
Programme frueherer  Zeiten.  Ich verstehe nicht,  warum sie so gross sind,
weil die meisten Compiler,  sogar  IBM CSet  generieren  Code  in moderaten
Groessen.

   Nehmen wir als Beispiel das allseits  bekannte MultiMaint.  Was um alles
in der Welt macht das Ding in einer 700K grossen EXE-Datei? Ich verstehe es
nicht.  Dazu kommt noch,  warum  wird  die beinahe  gleiche  EXE-Datei noch
doppelt und dreifach dazugepackt (Ich meine MultiSafe und IniMaint, die mit
MultiMaint daherkommen).  Das Programm ist ja ganz nett und  es macht seine
Arbeit ganz  gut,  aber  fuer  diese Arbeit  ist es einfach  zu gross. OS/2
Kernel haben etwa  den gleichen  Umfang.  Wo ist da die  Relation? Ich kann
(und will)  es mir einfach nicht leisten so  einen grossen Haufen  Mist auf
meine Platte zu laden,  also habe ich MultiMaint & Co. wieder gekuebelt. Zu
Dumm fuer deren Autoren.

   lxLite ist ein Workaround fuer dieses Problem.  Programmdateien kann man
packen,  sie  nehmen dann nur noch  den halben  Platz ein,  und machen noch
immer den glichen Job.  Dummerweise braucht es  auch den  gleichen Platz im
Speicher - das ist die Schuld des Autors.

   Soviel ich  weiss,  gibt  es  fuer  OS/2  nur  ein  Programm,  das etwas
Aehnliches macht REPACK von IBM (EWS?). Aber vergleichen mit lxLite erzeugt
es  groessere Dateien,  obwohl  es den gleichen Algorithmus  verwendet. Zum
Beispiel, COURIER.FON aus OS/2 Warp Build 8.192 wird von REPACK zu 44K, von
lxLite aber in 34K  gepackt.  Spuer den Unterschied! BTW, LINK386+Ressource
Compiler  compilieren COURIER.FON auch in  ein 44K-Datei.  Daher denke ich,
dass das sie eine gemeinsame Library verwenden.

   Ich komprimierte  alle  meine Programmdateien (inklusive  aber nicht nur
?:\os2\*.exe,  ?:\os2\dll\*.*  und  ?:\os2\dll\ibmnull;laserjet)  und  mein
System ist nach  wie vor stabil.  Ein  lxLite  Benutzer  (Pavel Roskin) hat
festgestellt,  dass lxLite sogar os2krnl komprimiert:-)  Sehr  angenehm vor
allem  fuer  eine  einzelne  Bootdiskette  [Anmerkung  d.  Uebersetzers: Es
stimmt].

3. Features
-----------

   lxLite komprimiert die Dateien auf die  gleiche Art wie LINK386  es tut.
Es gibt  keine andere  Moeglichkeit gepackte Programmdateien unter  OS/2 zu
implementieren,  als die zwei, die OS/2 Warp (oder die eine die 2.x) kennt.
So, hier ist eine kurze Beschreibung dieser beiden Algorithmen:

   1. Run-length packing.  Das ist im Prinzip die gleiche  Methode, wie sie
Microsoft C fuer DOS verwendet.  Das Ergebnis ist sehr SCHLECHT, weils sich
Programmdateien  nicht fuer  die  Pack-Methode  eignen.  Zum  Beispiel, PCX
Dateien werden auf die gleiche Art gepackt.

   2. Eine Art Lempel-Ziv  Algorithmus.  Lempel-Ziv  ist  die  Methode, die
beinahe  alle  DOS-EXE Packer  verwenden -  LZEXE,  PKLITE, PGMPAK etc. Die
Methode  die fuer ausfuehrebare  OS/2  Dateien standardisiert ist, ist IMHO
nicht  die effektivste.  Dazu  kommt noch,  dass OS/2-Programmdateien einen
anderen    Ladealgorithmus   haben   als    DOS-EXE-Dateien,    Teile   von
OS/2-Programmdateien koennen auch  nur geladen werden,  wenn  sie gebraucht
werden.  Deshalb kann ein Lempel-Ziv Woerterbuch nicht ueber  eine einzelne
Page (4096  Bytes)  hinausgehen.  Folglich sind die Resultate auch nicht so
gut, wie sie theoretisch sein koennten.

   lxLite kann beide Methoden  verwenden,  sowohl zum Packen,  als auch zum
Entpacken. Im Allgemeinen ergibt die zweite Methode die besseren Resultate,
aber moeglicherweise (?) gibt es Dateien fuer die die erste besser ist. Aus
diesem Grund werden defaultmaessig beide Methoden  angewendet,  die mit dem
kleineren Ergebnis gewaehlt. lxLite kann auch benutzt werden, um Dateien zu
entpacken,  die  bereits komprimiert sind,  sei es mit mit  lxLite, LINK386
oder REPACK von IBM.

   Was fuer Dateien koennen nun mit lxLite  gepackt werden?  Das  LX Format
wird unter OS/2 beinahe ueberall verwendet: Beinahe alles ist im LX format.
Nicht  nur  EXE-Dateien,   sondern  auch  .DLL,  .PDR,  .QPR,  .DRV,  .FON,
.SYS-Dateien  koennen mit lxLite  gepackt werden.  Sogar  die VDDs (Virtual
Device Drivers)  in \OS2\MDOS koennen damit gepackt werden.  Praktisch kann
man lxLite auf jedes Datei loslassen:  Wenn es kein LX ist,  wird lxLite es
nicht anruehren.

   Es ist  also moeglich,  den ganzen \OS2\*\ zu komprimieren,  man bekommt
jede Menge Extraplatz  ohne irgendwelchen  Overhead! Die Dekompressionszeit
wird durch die verkuerzten Ladezeiten  der  verkleinerten  Dateien  von der
Platte bei weitem  aufgewogen.  Also,  Reboot von einer Diskette (eventuell
von  den  beiden  Installationsdisketten  und  dann  F3  waehlen,  dann das
entsprechende  Laufwerk waehlen,  wo das installierte OS/2  liegt. Dann ist
folgendes beim Command prompt einzugeben:

   \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv

und  so  weiter.   So  koennen  auch  die  Dateien,   welche  zur  Laufzeit
normalerweise gesperrt (EXE,DLL) sind, problemlos gepackt werden.

  lxLite Version 1.00  und hoeher ist sogar in der Lage Dateien, die gerade
benutzt werden,  zu packen. In diesem Fall kann warnt lxLite und fragt nach
ob es das Modul auslassen oder durch seine gepackte Version  ersetzen soll.
Grundsaetzlich  ist das ersetzen  auch  so  kein  Problem,  nur muss man im
Hinterkopf behalten,  dass das Original bereits im  Speicher  sitzt, und so
auch  jede  Menge Platz im  SWAPPER.DAT auffressen.  Ein  Reboot sobald wie
moeglich ist daher immer eine gute Idee.

   Versionen  von  lxLite  ueber  1.00   gibt  es   in  zwei  verschiedenen
EXE-Dateien:  lxLite.exe ist die normale Version fuer OS/2  v2.99, Warp und
hoeher.  Die andere,  namens lxLite2x.exe  ist  fuer  die  aelteren  32 bit
Versionen von OS/2 (i.e. 2.x, NICHT 1.x weil unter 1.x gab es das LX Format
noch nicht). Als OS/2 Warp User kann man es getrost loeschen.

   Version 1.1.0  und Hoeher erkennen Programme, die Daten nach der eigent-
lichen  LX-Struktur  stehen   (i.e.  was  auf  DOS  overlay  data  heisst).
Watcom`s   gebundene Programme (wie WCC.EXE Versionen >=  10.0) und  Watcom
Visual   Rexx   Programme haben so  eine  Struktur.  In diesem Fall erzeugt
lxLite eine   Warnung und ersucht um Bestaetigung,  ob ein solches Programm
wirklich gepackt werden soll.  Es ist SEHR empfehlenswert, dass zuerst eine
Kopie   von diesem Programm gemacht wird,  bevor man es zu packen versucht,
denn  die Chance,  dass es  danach  nicht mehr  geht,  ist  sehr  hoch. Das
deshalb,  weil  lxLite (natuerlich)  keine (prinzipiell moeglichen) Pointer
innerhalb des Programms,  die auf Daten,  die an das Programm gebunden sind
(wie zum Beispiel VX-REXX Programme), veraendert.




4. Optionen
-----------

   Es gibt jede Menge Optionen  in  lxLite.  Ich liebe Optionen einfach :-)
Deshalb kann man bei lxLite beinahe alles und jedes  konfigurieren.  Um den
User  vor allzuviel Konfiguration zu  schuetzen,  unterstuetzt  lxLite eine
einzelne   Konfigurationsdatei,   in  der  gleich   einige  Konfigurationen
mitgeliefert ('factory defaults') sind. Sie sind weiter unten aufgelistet:
---------------------------------------------------------------------------

DEFAULT (wird standardmaessig geladen): DEFAULT ist eine `Arbeitskonfigura-
   tion'.  Alle  Parameter sind  auf maximale Kompression gesetzt.  Die Er-
   zeugung  von  .BAK   Dateien  ist  abgeschaltet.   Beachte,  dass  diese
   Konfiguration  IMMER geladen wird,  bevor  irgendwelche  andere Optionen
   wirksam werden,  sogar  die /C{#} Option  wird  ausgefuehrt  NACHDEM die
   DEFAULT- Konfiguration geladen Worten ist.

FAST:  Niedrigste  Kompressionsrate,  kuerzeste  Ladezeiten.  Wenn  man IBM
   glaubt,  werden  Programmdateien  schneller  geladen,  wenn Datenobjekte
   innerhalb der Datei an  Sektorgrenzen (512  Bytes)  ausgerichtet werden.
   Ich  kann  eigentlich  keinen  Unterschied  feststellen,  daher:  Selber
   ausprobieren!  Vorkomprimierte  Daten  werden  nicht  de-komprimiert und
   wieder re-komprimiert.

FAST2:  Packt  ein bisschen  besser,  aber  langsamer.  Ladezeiten  sind so
   schnell wie bei CFG#1.

VER2X: Optimal fuer pre-Warp Versionen von OS/2. Versionen vor Warp (3.0)
  wissen nichts von der Lempel-Ziv (/EXEPACK:2)  Methode. Programme sollten
   nicht  mit Lempel-Ziv  gepackt werden,  falls  die Moeglichkeit besteht,
   dass sie unter OS/2 2.xx (ausser 2.99) laufen sollen.

FAILSAFE: Lempel-Ziv packen ist eingeschaltet. Ein fehlersichere Konfigura-
   tion.  Alle Daten werden genau wie von LINK386 geschrieben, deshalb sind
   die Dateien etwas groesser  als bei der DEFAULT-Konfiguration.  Nur fuer
   WARP (oder hoeher) und 2.99!

MAX:  Beste Kompressionsrate. SEHR LANGSAM! Wird wohl selten gebraucht wer-
   den.

NEWSTUB:  Das ist eine spezielle Konfiguration mit der man den  DOS-Stub in
   LX  Programmen  durch  einen  anderen  ersetzen  kann,  ohne irgendetwas
   anderen zu  veraendern.  Du musst einen Dateinamen  fuer  den neuen Stub
   angeben -  diese Konfiguration teilt lxLite mit,  dass es alte, gepackte
   Objekte nicht entpackt und unkomprimierte Objekte nicht packt.

MINSTUB:  Diese Konfiguration ist mit NEWSTUB verbunden  und  ersetzt durch
   den kleinstmoeglichen Stub  vom Typ `say-error-and-exit`.  Kleiner gehts
   nimmer (glaub ich zumindest), ausser du kuerzt die Fehlermeldung.

VDMSTUB:  Diese Konfiguration befiehlt lxLite, den vorgefundenen Stub durch
   einen`run-from-VDM`-Type  zu  ersetzen.  Dieser ist  auch  so  kurz, wie
   moeglich:-).  Bitte  die  Beschreibung  der  /T{#}  Option  fuer weitere
   Details durchlesen.

INFO:   Diese  Konfiguration  verwenden,  um  an  Informationen  ueber  die
   Programmdatei zu erhalten  ohne es neu zu  schreiben (siehe  auch Option
   /V+)

---------------------------------------------------------------------------

Um eine  spezifische Konfiguration zu  verwenden,  ist lxLite  mit  /C# als
Parameter aufzurufen,  wobei # der Name der Konfiguration ist. Die Einstel-
lungen sind in der Datei lxLite.CFG  im  gleichen Verzeichnis,  in dem sich
lxLite.EXE befindet.  Kuemmere dich nicht  um Pfade,  lxLite wird sein .CFG
schon  finden.  Beispiel:  Um die Konfiguration `max` zu  verwenden, starte
lxLite /cMax.

Fuer eine detailierte  Beschreibung des .CFG-Dateiformats,  lies die ueber-
naechste Sektion.

Nun kommt eine detaillierte Erklaerung  darueber was  jeder einzelne Switch
tut. Jeder Switch, der das '+'- oder '-'-Zeichen akzeptiert (um Aktion ein-
oder auszuschalten)  kann auch ohne Zeichen benutzt werden, das heisst dann
halt '+'. Das heisst z.B., /V+ ist gleich wie /V.

/A{P|S|N{P|S}}
   setzt  die  Ausrichtungsmethode  (Alignment)  fuer  das  erste  und  die
   weiteren Objekte.  Das erste Objekt kann man auf  [P]age shift, [S]ector
   oder [N]o boundary ausrichten.  Die letzte Option (No boundary) wird von
   LINK386 niemals benutzt, aber es funktioniert, und das LX Format erlaubt
   es.  Alle  Objekte ausser  dem ersten  MUeSSEN  zumindest  auf PageShift
   boundary  ausgerichtet  sein.  PageShift ist ein Wert,  der im LX Header
   spezifiziert  ist. Um ihn neu zu definieren, verwende die /R# Option.

/B{+|-}
   Das Umbenennen der Originaldatei in .BAK ein-  (+) oder ausschalten (-).
   Beachte bitte,  dass  das eine  BETA-Version  ist  -  deshalb  sind .BAK
   Dateien standardmaessig eingeschaltet.

/C{#}
   Verwenden  der  Konfiguration  mit  ID  =  #.  Die  zwei  vordefinierten
   Konfigurationsnamen sind  "DEFAULT"  und "UNPACK".  Die Erste wird immer
   geladen,  wenn lxLite startet und die  Zweite wird benutzt wenn  die /X+
   Option angegeben wird (NICHT gleichbedeutend mit /cUnpack).

/D{#}
   Ausschliessen[D]e Dateimaske.  Alle Dateien die zu einer der angegebenen
   Dateimasken passen,  werden  von  lxLite  uebergangen.  Alle Dateimasken
   muessen durch Doppelpunkte  (:)  voneinander  getrennt sein (weil  ein :
   nicht Teil einer Maske sein kann). Zum Beispiel wird /D*.zip:*.arj:*.rar
   lxLite  daran  hindern  .zip,  .arj  and  .rar  Dateien  zu  bearbeiten.
   Standardmaessig (/Cdefault)  enthaelt eine Liste aller Progreammdateien,
   von denen bekannt ist,  dass  sie nicht richtig gepackt  werden koennen.
   Mehrere  /D-Switches  hintereinander  werden addiert,  daher ist /D*.zip
   /D*.arj  /D*.rar das gleiche wie das obige  Beispiel.  Um  die  Liste zu
   loeschen ist einfach /D zu verwenden.

/F{+|-}
   Erzwungenes  repacking.  Ist  zu  verwenden  um  die  Meldung   `already
   processed` zu uebergehen, i.e.  wenn lxLite denkt, dass die  Datei schon
   bearbeitet wurde,  das aber  in  Wirklichkeit  nicht der  Fall  war. Das
   passiert  normalerweise nicht,  kann  aber passieren,  wenn man versucht
   einen Stub durch einen anderen Stub  derselben Groesse zu  ersetzen, und
   zwar bei einer bereits komprimierten Datei.

/G[X|D|S]{#}
   e[X]tra /  [D]ebug  /  [S]tub Daten werden  in  die  spezifizierte Datei
   [G]eschrieben.  Wenn lxLite  eine  LX  Datei  findet,  die  solche Daten
   enthaelt,   und   man  diese  Daten verwerfen (oder  ersetzen  bei einem
   Stub)  will,  wird lxLite sie in die spezifizierte Datei  stellen, bevor
   sie verworfen werden. Die {#} Komponente kann auch eine Dateimaske sein,
   sodass  man Daten in  Dateien mit demseleben  Namen,  aber einem anderen
   Extender schreiben kann. Zum Beispiel /GD*.dbg teilt lxLite mit, dass es
   zu verwerfende Debug-Informationen in  Dateien mit demselben  Namen aber
   der Endung ".dbg" schreiben soll; der switch /GS*.stub.$s$ auf die Datei
   "myfile.exe"  schreibt den Stub  in  die Datei  "myfile.stub.$s$". Siehe
   auch die /O Option.

/I{+|-}
   Zwingt (+)  lxLite dazu,  mit Idle Prioritaet zu laufen.  Das heisst, es
   arbeitet nur,  wenn keine andere Aktivitaet im System herrscht  (d.h. es
   wartet auf  Tasten und Mausbewegungen).  Das ist meiner Meinung  nach am
   besten,  da lxLite  so  im  Hintergrund laufen kann und  die Performance
   beinahe  ueberhaupt  nicht beeinflusst.  Nur  wenn  man  eine ungezogene
   DOS-Box laufen  hat,  die sich  alle  CPU-Zeit  schnappt,  bleibt lxLite
   stehen.  Wenn  lxLite  nun  mit  /I-  gestartet  wird  aendert  es seine
   Prioritaet  nicht auf Idle,  und  daher mit einer  bestimmten Prioritaet
   (z.B. via PRIORITY.EXE) gestartet werden.

/L{#}
   Instruirt lxLite ein Logfile anzulegen. Es enthaelt nur die Dateien, die
   lxLite auch bearbeitet, uebergangene Dateien werden hier nicht aufgenom-
   men.  wenn kein  Name angegeben  ist,  wird lxLite.log im Verzeichnis in
   dem sich auch lxLite.exe befindet  verwendet.  Neben dem Dateinamen wird
   die Anfangs- und Endgroesse und die Probleme (falls welche auftraten).

/M{R{N|1|2|3}|L{N|1}}
   Setzt  die  Kompressionsmethode  und  -parameter.   Das  zweite  Zeichen
   definiert  die  Methode,  die  verwendet  werden  soll:  `R`  steht fuer
   Run-Length (/EXEPACK:1) und 'L' fuer Lempel-Ziv (/EXEPACK:2). Das dritte
   Zeichen ist der Kompressionslevel,  der mit der  Methode erreicht werden
   soll;  Falls N spezifiziert  wird,  ist  die Methode  abgeschaltet. Drei
   Levels  gibt  es fuer die   Run-Length-Kompression.  Der Level 1 ist der
   schnellste.  Er  sucht nur nach  1-Zeichen  Strings.  Zum  Beispiel, ein
   'AAAAAAAA'  String wird erkannt und zu   8, 1, 'A' gespeichert, waehrend
   ein  'ABABABAB'  String unkomprimiert gespeichert wird.  Level 2 erkennt
   Strings  jeder Laenge  bis   16  Zeichen.  Das Beispiel von oben wird zu
   4,2,'AB'  kodiert.  Das ist  die  Standardeinstellung  fuer  die meisten
   'Factory`-Konfigurationen.  Und als letztes, der dritte Level sucht nach
   allen Strings   jeder Laenge bis zu  einen halben  Page-Laenge (= 2048).
   Diese  Kompressionsmethode ist SEHR   langsam  und   ergibt selten echte
   Ergebnisse,  man sollte sie nur verwenden wenn man sie wirklich braucht.
   Der  Lempel-Ziv Algorithmus  kann nur entweder abgeschaltet  (/MLN) oder
   eingeschaltet (/ML1)  sein. Wenn er eingeschaltet ist, sucht er nach al-
   len Matches unter Verwendung einer ziemlich schnellen Hash-Tabelle, des-
   halb gibts keinen Grund die Kompression abzustufen.

/O{X|D|S}{+|-}.
   [O]utput e[X]tra/[D]ebug/[S]tub Daten immer (+)  oder nur wenn verworfen
   (-).   Wenn es abgeschaltet ist (/O-,  Standard)  arbeitet der /G Switch
   wie vorher,  i.e. Daten werden nur geschrieben, wenn sie in der Quellda-
   tei verworfen werden sollen.   Wenn die /O+  Option benutzt wird, werden
   die  Daten immer geschrieben (wenn die  entsprechende  Dateimaske  in /G
   Option  angegeben wurde).  Falls {X|D|S} nicht angegeben  wird, gilt die
   Option fuer allen Arten von Daten (Extra,Debug,Stub)  (i.e. /O+ schaltet
   das Feature fuer alle X/D/S Daten ein, /O- schaltet es fuer alle ab).

/P{+|-}
   Ein-  (+) oder ausschalten (-) einer Pause vor jeder Datei. Das Programm
   zeigt den Namen der Datei,  die als naechstes gepackt  werden soll,  und
   ermoeglich eine Auswahl,  ob sie bearbeitet oder in Ruhe gelassen werden
   soll.

/Q
   Alle  Konfigrationsoptionen abfragen.  Im  Prinzip  ist  das  ein buntes
   Listing der lxLite.cfg Datei :-) Andere Optionen falls vorhanden, werden
   ignoriert.

/R{#}
   [R]e-align (ausrichten)  der Pages auf eine spezielle Boundary. (#) muss
   eine Potenz von 2  sein.  Diese Option ist analog zu   LINK386`s /ALIGN:
   Switch.  Viele  Programmierer kuemmern  sich  nicht darum,  dass das /A:
   standardmaessig auf eine Boundary von  512  (ein Sektor) gesetzt ist und
   richten jede  Page  der  ausfuehrbaren  Module  auf  512  Byte  aus. Das
   Ergebnis ist ein  Haufen unbenutzter Platz  innerhalb der Programmdatei.
   Man kann nun solche Dateien mit einer anderen /ALIGN: Option neu linken.
   Standardmaessig ist /R:4.  Um lxLite  zu zwingen sich wie  LINK386, muss
   man  /R:512 verwenden. Das ist equivalent zu /ASS :-) .

/S{+|-}
   Zeigen (+)  oder nicht zeigen (-)  der aktuellen Konfiguration.  Das ist
   ganz brauchbar,  um mal zu schauen welche Einstellungen in der CFG-Datei
   gespeichert  sind,  besonders  bei  verketteten  Konfigurationen  (siehe
   weiter   unten).     Beispiel:     lxLite   /CDEFAULT   /S   zeigt   die
   standardmaessigen Einstellungen.

/T{#}
   Die mit # spezifizierte Datei als neuen DOS-Stub verwenden. Ein DOS-Stub
   ist eine  kleine  DOS-.EXE-Datei,  die in eine  OS/2`s LX-Datei gelinked
   wird, damit das Programm eine Fehlermeldung ausgibt, wenn es von DOS aus
   gestartet wird. Normalerweise sieht das etwa folgend aus:

   Dieses Programm laeuft nur unter OS/2

   Mit  lxLite   kommen   2   DOS-Stub-Programme   mit:   stub_min.bin  und
   stub_vdm.bin.  Der  erste ist ein Standard-`Schreib geht nicht und Ende`
   Typ,  aber er ist etwas kleiner als die ueblichen DOS-Stub-Programme die
   von den ueblichen Linkern erzeugt werden.  Der zweite ist  ein Stub, der
   eine  neue OS/2-Session startet und das Programm  daraus  startet. Falls
   OS/2   nicht  gefunden  wird,  die  uebliche  Fehlermeldung  produziert.
   Standardmaessig  laesst  stub_vdm.bin  OS/2  den  Sitzungstyp bestimmen.
   Alternativ  dazuy,   kann  man  den  Sitzungstyp  auch  in  stub_vdm.bin
   festlegen. Dafuer braucht man einen Hexeditor - man muss nach dem String
   `SesType->' im Stub suchen und das Byte, das unmittelbar nach dem  Pfeil
   kommt (->)  durch den gewuenschten Sitzungstype ersetzen, wobei folgende
   Tabelle gilt:

          00 - OS/2 session manager determines type (default)
          01 - OS/2 full-screen session
          02 - OS/2 windowed session
          03 - PM application
          04 - VDM full-screen session
          07 - VDM windowed session

/U{+|-}
   Ein- (+) oder ausschalten (-) des Entpackens einer Datei vor dem Packen.
   lxLite weiss wie man  beide  der  beschriebenen  Methoden  zum Entpacken
   verwendet,  deshalb ist die Option  standardmaessig   ist eingeschaltet.
   Ausschalten ist nur dann sinnvoll, wenn Zeit gespart werden soll.

/V{+|-}
   Verbose  (zeigt  ein  ganzen  Haufen  Dateiinformationen)   Das  ist der
   Schalter fuer Neugierige:-)  Mit /V+ zeigt lxLite ein paar Informationen
   ueber  die bearbeitete Datei  an  (um  komplette  Information  ueber .LX
   Dateien zu bekommen, rate ich jedem exeHdr.EXE aus dem OS/2 Programmer`s
   Toolkit zu verwenden).

/W{+|-}
   Ein- (+) oder ausschalten (-) ob das Ergebnis des Packens auf die Platte
   geschrieben werden soll.   Standardmaessig ist es eingeschaltet (nona!),
   aber du  kannst  es  ausschalten falls du  die  Informationen  ueber /V+
   anschauen willst,  ohne die Datei neu zu packen und frisch zu schreiben.
   Diese Option kann auch fuer debugging der Optionen nuetzlich sein.

/X{+|-}
   e[X]pandieren   (+)  oder  Packen (-)  der uebergebenen Dateien.  Diesen
   Switch  verwendet man,  um  Dateien zu  entpacken.  lxLite  kann  sowohl
   Dateien, die es selbst komprimiert hat, als auch solche, die von anderen
   Programmen  mit  den  Standardmethoden  gepackt  wurden.  (i.e. Resource
   Compiler,  LINK386,  REPACK).  /X-  ist nicht identisch mit der /cUnpack
   Option.

/Z{#}
   Diese   Option  setzt   den   `threshold`  fuer  lxLite   und  hilft  so
   festzustellen,  ob eine Stub ein `dummy`  ist oder ob er  eine spezielle
   Funktion hat. Es gibt einige Programme (zum Beispiel, \os2\xdfloppy.exe)
   die sowohl unter DOS als auch unter OS/2  laufen - in solchen Programmen
   ist die DOS Executable in der   OS/2` LX als ein DOS stub implementiert.
   Standardmaessig (wenn man einfach /Z  benutzt)  lxLite haelt jeden Stubs
   der groesser als 1024 Bytes ist, fuer einen funktionellen, und daher hat
   die  /T{#} Option auf diese keinen Effekt.

/?,/H
   Zeigt eine  kurze Hilfe an.  Diese  ist ganz  brauchbar,  wenn man einen
   Switch aus der ganzen Liste vergessen hat:-)

---------------------------------------------------------------------------
Das .CFG Dateiformat ist so  simpel wie  moeglich:  Es ist eine reine ASCII
Textdatei,  welche mit jedem beliebigen Texteditor bearbeitet  werden kann.
Jedes Zeichen nach einem Strichpunkt ';' wird ignoriert, i.e. damit koennen
Kommentare in die Konfigurationsdatei eingesetzt werden:

; Diese Zeile ist ein Kommentar

Jede  Zeile,  die mit  einem  Wort  und  einem  Doppelpunkt  beginnt (z.B.:
"Wort:")  wird als einzelne Konfiguration behandelt. Das Wort identifiziert
die Konfiguration.

Das ist ein Beispiel fuer einen Konfigurationseintrag:

FAILSAFE: /APP /B- /G+ /R4 /MR2 /ML1 /P- /U+ /V-

Wie man sieht stehen nach dem Doppelpunkt beliebige Switches,  wie  man sie
auch in  der  Kommandozeile  nach  lxLite  schreiben  wuerde.  Rekursive /C
Optionen  werden  nicht  ignoriert,  so  dass  man  mehrere Konfigurationen
aneinander binden  kann,  aber die /C Option wird  als letztes verarbeitet,
das heisst von zwei  ueberlappenden  Optionen wird nur die  letzte effektiv
sein. Als Beispiel:

here: /app /b- /g+
da  : /ass /b+ /p+ /chere

"lxLite /cda "  ist also gleichbedeutend mit "lxLite /app /b- /p+ /g+". Man
beachte,  dass  lxLite  auch  weitere  Aufrufe  auf  dieselbe Konfiguration
ignoriert,  um unendliche  Schleifen zu  vermeiden.  Das  bedeutet, "lxLite
/cOne /" wird die `One` Konfiguration nur EINMAL laden.

5. Fehlermeldungen
------------------

   Wie  die  allermeisten  normalen  Programme   erzeugt   lxLite  manchmal
Fehlermeldungen :-)  Manche von Ihnen erscheinen  in aehnlichen Situationen
haben aber  unterschiedliche  Ausloeser.  Hier  ist  eine  kurze  Liste der
haeufigsten Fehler:

   * Invalid Konfiguration Datei format:
     Ungueltiges Format der Konfigurationsdatei. Selbsterklaerend:-)

   * Error reading Konfiguration Datei:
     Diese  Meldung wird  nur generiert,  wenn die Konfigurationsdatei phy-
     sisch nicht lesbar ist. Das Programm erzeugt keine Fehlermeldung falls
     die Konfigurationsdatei einfach fehlt.

   * Error writing Konfiguration Datei:
     Fehler beim Schreiben der Konfigurationsdatei. Selbsterklaerend:-)

   * Error reading executable
     Diese  Meldung wird  generiert,  wenn die Programmdatei physisch nicht
     lesbar ist.

   * error writing executable
     Diese Meldung wird  generiert,  wenn die Programmdatei  nicht mehr auf
     die Platte geschrieben werden kann.  Das kann dann passieren, wenn auf
     der Platte zuwenig Platz ist, lxLite selbst ueberprueft das nicht.

   * invalid executable file format
     Die Datei ist nicht vom Format [L]inear  E[x]ecutable. Bei EXE-Dateien
     kann  diese  Meldung  auftreten,  wenn  sie  im  alten,  '[N]ew  [E]xe
     (bwhahaha)' Format sind oder eine DOS-EXE-Datei oder eine WinDOS- EXE-
     Datei.

   * unsupported executable format revision
     Diese Meldung wird  generiert (vielleicht:-),  wenn  die Programmdatei
     eine andere Dateiformatrevision hat als 0.  Da OS/2 Warp normalerweise
     nur mit Revision 0  arbeitet,  duerfte dieser Fehler normalerweise nie
     auftreten.

   * invalid word/dword ordering in executable
     Die Datei verwendet die 'little-endian' Byte order. Wahrscheinlich ist
     sie nicht fuer eine Intel-Plattform-Maschine gedacht.

   * executable target ist an unsupported CPU type
     Das kann passieren,  falls die Ziel CPU eine andere als  286, 386, 486
     oder P5 ist.

   * executable target ist an unsupported OS
     Das  heisst,  dass die Programmdatei nicht  fuer  OS/2  ist. WinDOS 95
     verwendet ein aehnliches  Format,  aber  seine  Kennung  ist  nicht LX
     sondern  LE,  daher  sollte  es  normalerweise  eine  'invalid format'
     Meldung geben.

   * unknown entry bundle type in executable
   * unknown page flags in executable
   * invalid object page detected in executable
    Diese alle bedeuten, dass lxLite etwas ueber die interne Struktur nicht
     versteht.  Ich bitte um Benachrichtigung,  falls jemand Dateien findet
     bei denen diese Fehlermeldungen auftreten.

   * nicht enough memory to load executable
     Ich glaube nicht, dass dieser Fehler unter OS/2 auftreten kann:-) Eher
     wird  eine  'Kein Platz mehr  im SWAPPER.DAT'  Meldung auftauchen. Wie
     auch immer,  ich finde,  es war keine gute Idee  der IBM-Programmierer
     einen Fehler zu erzeugen,  statt auf die Speicheranfrage einfach einen
     NIL-Pointer zurueckzugeben:-(

6. To-do-Liste
--------------

   Das ist eine Liste aller Features,  die plane  in zukuenftigen Versionen
einzubauen.  Jede Anregung  ist willkommen,  wie  man mich  erreicht, siehe
letztes Kapitel.

 * Vielleicht eine  Moeglichkeit,  den  LX  Stub  in  VX-REXX Programmen zu
   packen; Ich weiss nur nicht obs wirklich gebraucht wird, der Unterschied
   in der Groesse macht gerade mal 18K aus - lxLite kann das echte Programm
   nicht packen,  da es   1.)  ausserhalb der LX-Struktur ist 2.) irgendwie
   verschluesselt ist und  solche  Daten  ueberhaupt  nicht  gepackt werden
   koennen, PKZIP nicht einmal PKZIP kann das.

 * Vielleicht eine  'extra-pack'-Option,  ich haette da eine  Idee, wie man
   Programmedateien  wirklich  klein kriegt (kleiner als  DOS-Packer jeden-
   falls:-);  diese  Programme  wuerden  dann  aber  nicht  so  wie ueblich
   arbeiten -  sie waeren immer 'unlocked'  (siehe auch das UNLOCK-Utility)
   i.e.  sie werden im Swapfile landen,  wenn nicht genaug Speicher da ist,
   sie werden nicht langsamer,  aber das Swapfile wuerde dramtisch wachsen,
   wenn so  ein Programm  gestartet wuerde.  Daher,  sagt mir ob  ihr sowas
   haben wollt, wenns genug Nachfrage gibt, mache ich es.

7. Bekannte Fehler und Einschraenkungen
--------------------------------------

   Hier ist eine Liste von Programmen, die sich aus irgendeinem Grund nicht
packen lassen, probieren sinnlos:

   * PMJPEG v1.5 bis 1.74. Wie auch immer, sogar IBM`s REPACK kann es nicht
packen,  ich denke,  dass  es  sich  entweder  um einen Bug  im Linker, der
benutzt  wurde,  um  es  zu  generieren  (die  ganze EXE hat  eine seltsame
Struktur) oder eine Art debug-Schutz (Pruefsummen?).

   * VX-REXX-Programme.   Der Hauptteil des  Programms  (der verschluesslte
REXX-Code)   wird  einfach  an  einen  kleinen  LX-Stub  angehaengt.  Diese
Programme  haben  eine  unbekannte  Struktur  und  wenn  lxLite   den  Stub
komprimiert, funktionieren sie ueberhaupt nicht mehr.

   * Watcom C & C++ v>=10.0. Schaut so aus als wuerde Watcom gerne Muell an
die Dateien anhaengen.  Diese Dateien sind dafuer gedacht, sowohl unter DOS
als auch unter OS/2 zu laufen und haben ebenfalls eine seltsame Struktur.

   * ZIPBRAND v1.11.  Es  ueberprueft,  ob sein .EXE-File veraendert wurde,
vermutet einen Virus und will dann nicht mehr laufen [Ergaenzung des Ueber-
setzers].

   *  InterCom.


8. Den Autor kontaktieren
-------------------------

Via Email bin unter folgenden Adressen erreichbar:

FIDOnet:  2:5030/84.5 (ist mir am Liebsten)
Internet: bit@freya.etu.ru

Enjoy,
 _\ndy

9. Der Uebersetzer
-----------------

Ich war von Andys Programm  so  begeistert,  dass ich ihm spontan angeboten
habe,  fuer ihn die Dokumentation der Version 1.01  ins Deutsche  zu ueber-
setzen.  Manches  klingt  etwas holprig,  aber  erstens mache  ich  das nur
hobbymaessig, zweitens bin ich kein professioneller Programmierer. Aber ich
hoffe,  es hilft trotzdem etwas.  Die Uebersetzung zu 1.1.5 ist bereits ein
kleines bisschen  weniger holprig und enthaelt  etwa  60 Tippfehler weniger
als die zu 1.0.1.

Via  Email bin unter folgenden  Adressen  erreichbar  (obwohl  das ziemlich
sinnlos ist, da ich ausser der Uebersetzung nichts beigesteuert habe):

FIDOnet:  Herwig Bauernfeind, 2:312/5.35 (ist auch mir am Liebsten)
InterNet: H_BFD@fidonet.at (funktioniert zur Zeit aber nicht so gut)

