Seite 1 von 2
UnpackMemory - Zielspeichergröße
Verfasst: 19.10.2010 19:10
von STARGÅTE
Tachchen,
Triviale Frage:
Wenn ich eine gepackten Speicherbereich entpacke, die entpackte Größe aber nicht (nicht mehr) kenne, habe ich keine Chance diese herauszufinden oder ? Also bevor ich UnpackMemory anwende ...
Oder steht die im Header des gepackten Bereichs drin ?
Denn wenn ich doch mal zu zuwenig bereit halte, schreibt ja UnpackMemory einfach drüber weg und macht große Probleme ...
Muss ich also beim Anwenden von PackMemory() immer selber noch die Ursprungsgröße noch vorweg speichern?
Re: UnpackMemory - Zielspeichergröße
Verfasst: 19.10.2010 19:18
von GPI
Mir wäre nichts bekannt. Wäre übrigens keine Schlechte idee in PB das zu erweitern. Einfach einen zusätzlichen Header einfügen und PB sollte beim entpacken kontrollieren ob der Header da ist oder nicht und entsprechen reagieren.
Re: UnpackMemory - Zielspeichergröße
Verfasst: 19.10.2010 19:41
von Batze
Ist ja zum Glück nicht so schwer da mal eben ein int mit der Größe davor zu schreiben. Einbauen wäre natürlich auch nett.
Re: UnpackMemory - Zielspeichergröße
Verfasst: 19.10.2010 19:46
von GPI
Tip: Häng nicht nur ein long für die Größe davor. Mach ein "Header"
bspw.
das MyPC als kennung davor. Solltest du nämlich, aus welchen Gründen auch immer, mal erweitern müssen, kannst du einfach diesen Magiccode ändern und weitere Datenfelder einfügen. Es ist also leichter erweiterbar. (Wenn dir bspw. später einfällt, das es sinnvoll gewesen wäre, ein CRC-Prüfsumme einzufügen. Mit der Kennung kannst du dann sowohl die alten Daten als auch die neuen Daten laden).
Re: UnpackMemory - Zielspeichergröße
Verfasst: 19.10.2010 19:49
von Batze
GPI hat geschrieben:Tip: Häng nicht nur ein long für die Größe davor. Mach ein "Header"
bspw.
das MyPC als kennung davor. Solltest du nämlich, aus welchen Gründen auch immer, mal erweitern müssen, kannst du einfach diesen Magiccode ändern und weitere Datenfelder einfügen. Es ist also leichter erweiterbar. (Wenn dir bspw. später einfällt, das es sinnvoll gewesen wäre, ein CRC-Prüfsumme einzufügen. Mit der Kennung kannst du dann sowohl die alten Daten als auch die neuen Daten laden).
Würde sogar dazu tendieren noch sowas wie eine versionsnummer zu verwenden, sonst ist der schöne Magiccode verbraucht und man muss was anderes nutzten, obwohl vielleicht nur ein wenig dazugekommen ist.
Re: UnpackMemory - Zielspeichergröße
Verfasst: 21.10.2010 21:35
von HeX0R
Soviel ich weiß steht die Ursprungsgröße bei
Re: UnpackMemory - Zielspeichergröße
Verfasst: 22.10.2010 04:37
von GPI
HeX0R hat geschrieben:Soviel ich weiß steht die Ursprungsgröße bei
oh, mit sowas wär ich vorsichtig, da undokumentiert... Wäre nett, wenn das in die Dokumentation einfließen würde. Am besten als UnPackedLength()-Funktion.
Re: UnpackMemory - Zielspeichergröße
Verfasst: 22.10.2010 12:27
von Thorium
GPI hat geschrieben:HeX0R hat geschrieben:Soviel ich weiß steht die Ursprungsgröße bei
oh, mit sowas wär ich vorsichtig, da undokumentiert... Wäre nett, wenn das in die Dokumentation einfließen würde. Am besten als UnPackedLength()-Funktion.
Das ist auch falsch, da es nur für JCalG1 gild, welcher nur unter x86 verwendet wird. Unter x64 ist die Magic vom Header 3 Byte lang.
Dokumentiert ist es aber natürlich:
http://www.bitsum.com/jcalg1.htm
Re: UnpackMemory - Zielspeichergröße
Verfasst: 22.10.2010 12:53
von GPI
Das ist zwar dokumentiert, aber nicht für PureBasic. Großer Unterschied.
Re: UnpackMemory - Zielspeichergröße
Verfasst: 22.10.2010 14:32
von Thorium
GPI hat geschrieben:Das ist zwar dokumentiert, aber nicht für PureBasic. Großer Unterschied.
Wieso? PB nutzt die JCalG1 Lib für x86.