DEC: LHSS Komprimierung: Rückgabewerte unrbauchbar

[Muetze1]

Hallo negaH und alle anderen!

Da ich ja nun mal mit der DEC rumgespielt habe, habe ich auch mit der LHSS Komprimierung aus der DEC gespielt und hatte damit nur zwei kleinere Probleme - aber auch diese möchte ich gerne gelöst wissen.

1. Der Rückgabewert von LHEncode() und LHDecode() hast du ja gut dokumentiert, aber trotzdem bekomme ich recht zufällige Werte zurück. Ich kann daran nie ablesen ob die (De)komprimierung erfolgreich war oder nicht. Im Endeffekt macht er aber alles wie gewünscht.

2. Nach Benutzung der beiden Funktionen ist der Speichermanager recht benebelt und es hagelt AV's ohne Ende und ich habe bisher noch keinen Ansatzpunkt wieso. Die (de)Komprimierung läuft aber, wie schon erwähnt, problemlos durch.

Beide Fehler sind mit dem angehangenen Projekt nachvollziehbar.

Auch hierzu ein Beispielprojekt im Anhang. Dies mal reines Delphi, aber auch wieder mit RAD Studio 2007 erstellt.

Grüße,
Thomas

[Assertor]

Hi,

und genau das ist der Grund, warum LHSZ.pas in der DEC 5.2 nicht mehr enthalten ist. Ich hatte seinerzeit viel mit Hagen deswegen gemailt, aber es war selbst mit D2006 geschweige denn D2009 nicht zum Laufen zu bekommen. Die LHSZ Routinen sind aber ja nicht wirklich Bestandteil der DEC, sondern nur eine Beigabe - ich sah es als Anregung.

Lösung heißt also hier: Ausweichen und nicht verwenden bei > D7.

Gruß Assertor

[Muetze1]

Moin!

Aber eigentlich sollte es doch nur etwas findbares sein, schliesslich klappt die Komprimierung und Dekomprimierung einwandfrei. Nur halt (E)AX ist am Ende nicht mehr das was es mal war und das mit den Speicherproblem sollte ja wahrscheinlich nur ein falscher Schreibzugriff sein, vermutlich Pufferüber/unterlauf.

Also besteht soweit kein Interesse die Beigabe zu pflegen? Nun ja, vllt setze ich mich mal ran, wenn ich die Doku zu Hagen's AVR Bootloader Interface fertig habe.

Grüsse,
Thomas

[Assertor]

Hi,

Zitat:

Zitat von Muetze1

Aber eigentlich sollte es doch nur etwas findbares sein, schliesslich klappt die Komprimierung und Dekomprimierung einwandfrei. Nur halt (E)AX ist am Ende nicht mehr das was es mal war und das mit den Speicherproblem sollte ja wahrscheinlich nur ein falscher Schreibzugriff sein, vermutlich Pufferüber/unterlauf.

Ja, ich hatte einige Stellen schon gefixt und Probleme identifiziert (falsche Recordgrößen wenn ich mich recht erinnere). Ich hab meine Fassung im DEC 5.2 ins Archiv-Verzeichnis gepackt. Vergleich die sonst mal mit einem diff/merge mit der alten Fassung aus dem 5.1.

Meinen Testcode für die LHSZ hab ich aber leider nicht mehr aufgehoben.

Der asm Code macht mit > D7 definitiv auch Probleme. Wieder das gleiche Spiel mit dem Delphi-Compiler/Linker...

Gruß Assertor

[himitsu]

• Also, der Testcode läuft erstmal unter Delphi 7 und 2010.
• Es ist alles gemäß OOP in eine Klasse gewandert.
• Die Fehlerbehandlung wurde von Fehlercodes auf Exceptions umgestellt.
• Die Variante mit den Lese-/Schreibprozeduren wurde entfernt.
• Und dafür gibt es nun eine Variante mit Streams.
  
• Achtung: Ob die aktuell deaktivierten ASM-Codes auch zuverlässig arbeiten weiß ich nicht, denn diese habe ich fast im Originalzustand übernommen und noch nicht getestet.
  (Im Code aus'm DEC 5.2 waren sie aber auch schon deaktiviert.)

[add]
Die TestLHSS.dpr von Muetze1 läuft auch.
Ein Binärvergleich meinte jedenfalls daß die beide Dateien übereinstimmen. :-D

[edit]
'nen bissl Zeitmessung in die TestLHSS.dpr eingebaut.

Eine kleine 223 MB XML-Testdatei lieferte diese Werte:
lhmMax:

Code:

Encode()     result = 24757299 bytes     duration = 182.0 sec
Decode()     result = 233854130 bytes     duration = 8.9 sec

Zip und 7zip waren zwar bis zu 6 Mal schneller, aber von der Komprimierungsrate her bekamen sie die Datei auch nur auf 23 MB (zip) und 14 MB (7zip),
allerdings belegt die TLHCompress nur knapp 1,2 MB RAM.

lhmFastest:

Code:

Encode()     result = 31782658 bytes     duration = 18.56 sec
Decode()     result = 233854130 bytes     duration = 10.25 sec

[edit=Admin] Mfg, Daniel[/edit]

[negaH]

Hallo Himitsu,

Zitat:

* Es ist alles gemäß OOP in eine Klasse gewandert.
* Und dafür gibt es nun eine Variante mit Streams.
* Die Variante mit den Lese-/Schreibprozeduren wurde entfernt.
* Die Fehlerbehandlung wurde von Fehlercodes auf Exceptions umgestellt.

Das alles hatte ich absichtlich nicht so vorgesehen. Ziel war es diese Unit so kompakt wie möglich zu machen, möglichst keine Datensegemente=BSS benutzen (was jetzt bei deinen Änderungen wieder der Fall ist), keinerlei VCL wie Klassen oder TStreams oder Exceptions einzusetzen usw.

Diese Unit dient mir für meinen EXE-Packer-Stub, also als Bestandteil des Stubs für selbst entpackende Anwendungen. Alle deine Änderungen sind aus dieser Sicht sehr ungünstig. Das betrifft eben auch die bedingte Compilation für die einzelnen Bestandteile, sprich wenn man möchte kann man auch nur die LHDecode() alleine compilieren, eben für Entpcker die nicht packen können müssen.

Mit TStreams konnte man in meinem Original auch arbeiten indem man die Methoden TStream.ReadBuffer() und .WriteBuffer() der LHEncode() und LHDecode() Funktionen als Callbacks übergibt.

Und ändere bitte das Copyright folgendermaßen ab:

Original Authors: Hagen Reddmann, (c) 2000 HaReddmann [at] t-online [dot] de
Modifications: (c) 2008 Arvid Winkelsdorf, info [at] digivendo [dot] de
(c) 2010 himitsu, himitsu [at] fnse [dot] de

Ich weiß nicht was Heiko damit zutun haben sollte, oder bist du Heiko Behrens ? Auf alle Fälle wüsste ich nicht das Heiko der Initiator und Developer dieser Sourcen war, es sei denn ich habe eine gespaltene Persönlichkeit und weiß nichts davon das eine dieser Persönlichkeiten in mir drinnen Heiko heist ;)

Gruß Hagen

[edit]
PS: bitte nicht persönlich nehmen, aber mein Programmierstil in Punkto Sourceformatierungen gefällt mir weit besser. Warum schreibst du alle Bezeichner mit Großbuchstaben am Anfang, hast du dir mal die Borland Sourcen seit BP7 angeschaut ? Auch dieses elenede "Hochziehen" des begin ist eine echte Epedemie die um sich greift. Es zerstört komplett die schenlle visuelle Erfassbarkeit der Struktur der Source. Ne echte Unart ist das geworden.

Wenn ich ehrlich bin würde ich es nur ungern sehen das in diesem Source mein Name drinnen steht. Es geht ja auch um mein "Image" und so würde ich niemals einen Source formatieren.

Nichts für ungut, letzendlich zählt das es Anwender gibt die damit was anfangen können.

PPS: ;) ich kann's ja nicht lassen, einige der Bezeichner schreibst du mit Großbuchstaben wie Begin, End usw. aber Bezeichner wie xor,and,shr nicht. Das ist inkonsistent.

PPPS: Const lhModeValue: Array[TLHMode] of LongInt = (0, $01, $20, $40, $80, $FF);
Diese Zeile legt im BSS=vorinitialisierten Datensegement dieses array[] ab.
Desweiteren benötigen auch ResourceStrings Speicher im BSS.
Für zb. einen EXE/DLL Entpacker der seinen Code zb. in andere Prozesse injeziert bekommt sind solche BSS Datensegmente übel. Eben ein Grund warum im original keinerlei Datensegemente benutzt wurden.


PPPPS: durch die Kapselung in einer Klasse dürfte der ASM Code auch nicht mehr funktionieren, zumindest würde ich es nicht garantieren wollen. Der ASM Code geht von einem Record aus.
[/edit]

[himitsu]

Keine Ahnung was was Heiko darin will, aber der stand da schon vorher drin. :gruebel:

Ich kann es leider nicht editieren, aber ein lieber Mod ändert das bestimmt gerne. :stupid:

Zitat:

Wenn ich ehrlich bin würde ich es nur ungern sehen das in diesem Source mein Name drinnen steht. Es geht ja auch um mein "Image" und so würde ich niemals einen Source formatieren.

Wenn der Mod schon dabei ist, könnte er dich ja notfalls rauslöschen. :lol:

Zitat:

Nichts für ungut, letzendlich zählt das es Anwender gibt die damit was anfangen können.

Schon OK, immerhin kann sich ja jeder das Passendere.


PS: Das mit dem Hochziehen mache ich schon immer so und ich find es persönlich so übersichtlicher.
Nja, zum Glück kann man ja nur (in D2010) einfach Strg+G machen und schon isses umformatiert. :)

zu PPPPS: Theoretisch könnte es dennoch Funktionieren, denn im Prinzip hat sich das Offset der Fehler nur um 4 Byte verschoben.
> vorher ein Zeiger auf einen Record
> jetzt ein Zeiger auf das Objekt - dort gibt es am Anfang blos noch den Zeiger auf den Klassentypen und gleich danach die Felder

zu PPS: Das ist inkonsistent. Och, ich bin wenigstens konsequent inkonsistent. (wobei XOR und Co. für mich operatoren sind und Begin/Then nicht ... ist also was ganz Anderes :mrgreen: )

zu PPPS: Gut, ich wollte es eh direkt in einem eigenem Programm nutzen, da stört das nicht so sehr. :angel2:

[negaH]

Zitat:

zu PPPPS: Theoretisch könnte es dennoch Funktionieren, denn im Prinzip hat sich das Offset der Fehler nur um 4 Byte verschoben.
> vorher ein Zeiger auf einen Record
> jetzt ein Zeiger auf das Objekt - dort gibt es am Anfang blos noch den Zeiger auf den Klassentypen und gleich danach die Felder

Das ist korrekt, denoch würde ich nicht meine Hand in's Feuer legen wollen. Ich kenne mich und trickse eben auch oft in Assembler, gerade wenn es um die Ausrichtung der Felder geht um mehr Performance etcpp. raus zu holen.

Übrigens: der erste 4 Bytes Zeiger in einem Objekt zeigt auf die VMT=virtuelle Methoden Tabelle. Diese befindet sich im Codesegment mitten innerhalb der Klassenstruktur=RTTI der Klasse. Borland hat mit der Zeit diese Klassenstruktur immer weiter ausgebaut und um kompatibel mit den alten TObject zu sein einfach diese Strutur nach hinten und vorne im Speicher ausgebaut. Früher war es also schon so das dieser 4 Bytes Zeiger an den Anfang der Klasse gezeigt hat und dort began dann die VMT.

Übrigens: schaue dir mal im originalen Source die Funktion LH_Check() an und wie ich dort auf die ResourceStrings zugreife. Dieser Weg optimiert einiges am Codesegment Verbrauch, sprich Programmgröße des Kompilates.

Wo hast du denn deinen Source her ?

Gruß Hagen

[himitsu]

Zitat:

Zitat von negaH

Wo hast du denn deinen Source her ?

Gute Frage.

Also aus dem Post #1 hier schonmal nicht.
Ich kann mich nur drann erinnern das DEC mal vor langer Zeit bei Luckie gedownloadet zu haben,
aber ob diese Datei hier wirklich von dort war, kann ich nicht mit Sicherheit sagen.

Delphi-Quellcode:

Raise ELHInflate.CreateRes(@sLHSZInflate);

Delphi-Quellcode:

Raise ELHInflate.Create(sLHSZInflate);

Das Delphi bei Letzerem Code eine Tabelle der ResourceStrings anlegt und die Strings dann in einer "Cache"/Liste geladen läßt (oder irgendwie so) hab ich schon vor langem mal mitbekommen.
Ersteres geht intern über LoadStr.

@Mods: Bitte mal mit dem Anhang meine Datei da ganz oben in #5 ersetzen.

[Daniel]

Zitat:

Zitat von himitsu

@Mods: Bitte mal mit dem Anhang meine Datei da ganz oben in #5 ersetzen.

Bin zwar kein Mod, habe es aber dennoch erledigt.