Bin2Post / Binäre Daten gleich im Forumspost mitliefern

[ts-soft]

Die zLib.lib ist bei jeder PB Installation vorhanden. Die hat nichts mit der neuen libzip.lib zu tun, aus PB5.10.
Die zLib.lib ist z.B. für die ganzen ImagePlugins, sowie auch für Ogre usw. erforderlich. PB verwendet sich aber
nicht für seine Packroutinen, aber ich bin so frei

Geändert hat sich die Version vor kurzem, das ändert aber nichts an der Kompatibilität.

[Kurzer]

Die zLib.lib ist bei jeder PB Installation vorhanden. Die hat nichts mit der neuen libzip.lib zu tun, aus PB5.10.
Die zLib.lib ist z.B. für die ganzen ImagePlugins, sowie auch für Ogre usw. erforderlich. PB verwendet sich aber
nicht für seine Packroutinen, aber ich bin so frei

Alles klar, jetzt habe ichs auch geschnallt.
Das schau ich mir auf jeden Fall an.

[ts-soft]

Für Eure Allgemeinbildung: http://de.wikipedia.org/wiki/Zlib

Die lib wird fast überall verwendet, bzw. genutzt. OpenOffice, PNG und tausende weiterer Bibliotheken und Programme, sowie
auf allen Betriebssystemen (von Android bis Unix).

[Kurzer]

Hmm, ich komme gerade nicht weiter mit der Nutzung der gzWrite/gzOpen Funktionen

gzOpen gibt ein handle zurück, dessen Struktur mit nicht ganz klar ist.

Code: Alles auswählen

ZEXTERN gzFile ZEXPORT gzopen OF((const char *path, const char *mode));

Wenn ich das handle typenlos deklariere, dann gibt es bei der nächsten Verwendung (gzWrite) einen invalid memoryaccess error.

Bei meiner Recherche bin ich auf folgende Struktur für gzFile gekommen.

Code: Alles auswählen

    //C Code?
    struct gzFile_s {
    unsigned have;
    unsigned char *next;
    z_off64_t pos;
};

Falls das die richtige Struktur sein sollte, dann gekomme ich sie nicht nach PB übersetzt, zumindest nicht das dritte Element (z_off64_t pos).

Mein bisheriger (nicht funktionierender) Testcode sieht so aus:

Code: Alles auswählen

EnableExplicit

Global sOutFile.s, sFileMode.s, sText.s
Global *InBuffer
Global *Filehandle

Import "zlib.lib"
  gzclose(a.i) As "_gzclose"
  gzopen(a.i, b.i) As "_gzopen"
  gzwrite(a.i, b.i, c.i) As "_gzwrite"
EndImport

sOutFile = "F:\Out.txt"
sFileMode = "wb9"
sText = "01234567890123456789"

*InBuffer = @sText

*Filehandle = gzopen(@sOutFile, @sFileMode)
Debug *Filehandle
If *Filehandle <> 0
	Debug Str(gzwrite(*Filehandle, *InBuffer, 10))
	gzclose(*Filehandle) 
EndIf

Viellecht kann mir hier noch jemand unter die Arme greifen?

Gruß Kurzer

[ts-soft]

Was hast Du den jetzt vor?

Einfach die Resource im Speicher packen und dann mit Base64 encodieren, bzw. umgekehrt und den
Text speichern. Darum ging es doch in Deinem Projekt.

[Kurzer]

Hmm, stimmt. Ich könnte die Dateien alle hintereinander in einen Memoryblock laden (mit entsprechendem Header trennen) und sie dann dort packen.

Ich dachte mir halt, dass ich nicht so viel RAM verbrate, wenn ich das Packen der zig Einzeldateien in eine komprimierte Datei per gzWrite erledige.
Die resultierende, gepackte GZ-Datei hätte ich dann wiederum in den Speicher geladen und dort nach Base64 kodiert.

Vermutlich alles nonsense bei den heutigen RAM Speichergrößen.

Trotzdem würde ich mein Beispiel gern zum laufen bekommen. Bin nach Absenden meines posts nicht weiter am Rechner gewesen.

[ts-soft]

Datei laden, packen, encodieren, speichern, nächste Datei dasselbe Spiel. Am schluß noch einen Header schreiben, damit Du
alles wieder aufteilen kannst.
Header in den speicher lesen, dann Laden, decodieren, entpacken, speichern, nächter block aus dem Header.

Nur falls die Dateien doch grösser sind

Zu gzip kann ich Dir nichts sagen, ist auf jedem Fall nicht ohne und den Aufwand wahrscheinlich nicht wert.

[Kurzer]

Ganz so hoher Aufwand ist es nicht mit den gzFile Kommandos zu arbeiten, nur funktioniert das ganze nicht unter jeder PB Version.

Du hast es evtl. im englischen Forum schon gelesen, dass ich da nicht weiterkomme.

Kannst Du mir sagen, ob es ein PB internes bzw. ein Kompilerproblem ist, dass folgender Code unter PB 4.31 kompiliert wird aber unter höheren Versionen einen Linker Error erzeugt? Fehlen PB da irgendwelche Symbole so dass es nicht mit der aktuellen zLib zurecht kommt?

Ich hab leider zu wenig Ahnung davon was diesen Fehler auslöst. Meine Recherche hat lediglich ergeben, dass sich ab M$ VC++6 irgendwelche Bezeichnungen geändert haben und deswegen dort die oldname.lib eingeführt wurde. Nur hilft mir das unter PB leider nichts (ich bin auch kein C/C++ Coder).

Code: Alles auswählen

Structure gzFile_s
  iHave.i
  iNext.i
  iPos.i
EndStructure

Import "zlib.lib"
	gzopen.i(Filename.s, Mode.s)
EndImport

*Filehandle.gzFile_s = gzopen(GetTemporaryDirectory() + "test.txt", "wb9")

[ts-soft]

Code: Alles auswählen

Structure gzFile_s
  iHave.i
  iNext.i
  iPos.i
EndStructure

ImportC "oldnames.lib" : EndImport

ImportC "zlib.lib"
  gzopen.i(Filename.s, Mode.s)
EndImport

*Filehandle.gzFile_s = gzopen(GetTemporaryDirectory() + "test.txt", "wb9") 

[Kurzer]

Ich fange so langsam an ganz böse zu bereuen, dass dass ich mir 'linkende' Compiler und librarybasierende Entwicklungsumgebungen nie angetan habe und immer nur auf die 'flache Ebene' geschworen habe.

Vielen Dank ts-soft!