PC Online 1997 October

home *** CD-ROM | disk | FTP | other *** search

/ PC Online 1997 October / PCO1097.ISO / FilesBBS / OS2 / LXLT121.ARJ / LXLT121.ZIP / lxLite / doc / lxLite_de.txt < prev next >

Wrap

Text File | 1996-12-01 | 31.7 KB | 619 lines

---------------------------------------------------- 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)