RtlCompressBuffer alternative gesucht!

[Bernhard Geyer]

Und was steht dort:

Version
Available starting in Windows XP.

[generic]

Zitat von Bernhard Geyer:

Und was steht dort:

Version
Available starting in Windows XP.

Ich verstehe euch heute nicht Ich glaub ich brauch mehr schlaf.

Zitat:

Jetzt frag ich mich, weil ja RtlCompressBuffer eine undokumentierte und möglicherweise nicht in jeder windows version zur verfügung stehende funktion ist

Also Funktion ist dokumentiert!

Zitat:

...mein produkt muss leider auch mit XP funktionieren...

Funktion ist in XP verfügbar.

Ist das nicht das, was Fukiszo wollte?

[Bernhard Geyer]

Zitat von generic:

Ich verstehe euch heute nicht Ich glaub ich brauch mehr schlaf.

...

Ist das nicht das, was Fukiszo wollte?

Genau. War ja auch für Fukiszo gedacht.
Du brauchst wirklich mehr schlaf

[himitsu]

Er hatte ja selber behauptet es sei nicht dokumentiert.

OK, abgesehn, dass diese Funktion eigentlich für das Windows Driver Kit gedacht ist, also z.B. für die Verwendung in Treibern und nicht direkt für User-Mode-Programme, ist sonst alles OK.

Natürlich könnte auch jemand noch fragen warum es unbedingt diese Komprimierungsfunktion sein muß und nicht Eine der vielen Anderen, oder gar die ZLib, welche direkt im Delphi vorhanden ist, und das schon seit mehreren Jahrzehnten.

[Fukiszo]

mit undokumentiert meinte ich, diese funktion ist nicht in delphi (version 7) nativ vorhanden und kennt auch keine hilfestellung zu diesem thema.
meine version der Win32.hlp datei schweigt sich darüber auch aus.
da die überschrift "alternative" heisst hoffte ich es gibt noch mehr funktionen die ab WindowsXP per WinAPI so etwas machen könnten und ich lediglich zu doof war sie zu entdecken.
zLib apLib ucl flexcompress 7zip und der gleichen wollte ich nicht wirklich einbinden, wobei mir zlib noch am liebsten ist wegen geschwindigkeit.

Vielen Dank für Euren feedback!

[himitsu]

Das kann Delphi 7 auch garnicht kennen.
1995 Delphi 7
2001 Windows XP

Außerdem sind nur ein paar WinAPIs im Delphi enthalten. Niemand hatte Lust sämtliche APIs nach Pascal zu übersetzen,
also gibt es nur die "Wichtigsten", vorallem Win32-API, GDI, COM/ActiveX usw.
Das WinDDK in Pascal gibt es aber von einigen Drittanbietern.

Wenn man mit C++ oder C++Builder arbeitet, dann kann man natürlich auch direkt gegen die API-Header des WinDDK kompilieren und braucht keine Headerübersetzungen zu suchen oder selber anzufertigen.

[Fukiszo]

Zitat von himitsu:

...und nicht Eine der vielen Anderen...

genau das versuch ich ja herauszufinden (siehe Titel -> "alternative")
wenn du mir bitte mit Api's weiterhelfen könntest, das wäre super!
"Eine der vielen" klingt klasse, bitte unterweise mich.

sollte halt eine funktion sein die XP versteht und auch aktuelle OS.

wenn da so viele vorhanden sind, könnt ich ja mein produkt auf verschiedene engines umrüsten.

himitsu besten dank schonmal!

alle anderen können sich gern mit-einklinken und mir weitere buffercompressions funktionen vorstellen,
je mehr je besser, haltet euch nicht zurück, egal ob code ur-alt ist oder erst in XE10 vorgestellt wurde.
Für mich gibt es kein "richtig/falsch" in diesem zusammenhang solange XP damit klar kommt bin ich total happy!

Es grüßt

[Der schöne Günther]

Wenn du einfach nur "irgendwas komprimieren" möchtest hat mir persönlich immer die mitgelieferte Unit System.Zip gereicht. Handelsübliche ZIP-Kompression in Dateien oder in den Speicher, Dateien rein und raus, alles ganz einfach.

Beispiel:

Delphi-Quellcode:

interface uses
   System.Classes,
   System.SysUtils,
   System.Zip,
   System.IoUtils;

procedure compressStuff();
const
   exampleData: TBytes = [1,2,3];
var
   inputStream: TStream;
   zipFile: TZipFile;
   outputStream: TBytesStream;
begin
   inputStream := nil; zipFile := nil; outputStream := nil;
   try
      inputStream := TBytesStream.Create(exampleData);
      outputStream := TBytesStream.Create();

      zipFile := TZipFile.Create();
      zipFile.Open(outputStream, TZipMode.zmWrite);
      zipFile.Add(inputStream, 'compressedInput.dat');

      TFile.WriteAllBytes('x:\myZipfile.zip', outputStream.Bytes);
   finally
      inputStream.Free(); zipFile.Free(); outputStream.Free();
   end;
end;

[himitsu]

Sonst kenn ich keine API im Windows.

ZLib ist im Delphi enthalten (gleichnamige Unit).
Das ist eine Wörterbuchkomprimierung mit anschließender Entropiekodierung. (wird z.B. in ZIP- und GZ/GZIP-Dateien verwendet oder bei der komprimierten Übertragung von HTTP-Servern)
http://docwiki.embarcadero.com/Libra...en/System.ZLib
https://de.wikipedia.org/wiki/Zlib

ZipMaster / ZipMaster
Abbrevia
ZipForge, FlexCompress, KaZip, UnRAR, SynZip, ....
und sogar in der JCL verstecken sich einige Komprimierungsfunktionen.

TZipFile ist neu und gibt es in Delphi 7 noch nicht, aber nutzt ja intern auch wieder die ZLib.
Wobei ZipFile natürlich nicht nur die Kompimierung, sondern auch das ganze Management/Overhead zur Behandlung von mehreren verschlüsselten Datenstreams in einer ZIP-Datei hat.

7-Zip ist offen. Das kann als DLL genutzt oder via vorkompilierter OBJ direkt in die EXE gelinkt werden.
(OBJ: siehe ZLip, TJPEGImage, TRegEx ... das kommt alles von Fremden und wird im Delphi nur wiederverwendet)
www.7-zip.de/sdk.html

LeseTipp: http://www.delphipraxis.net/152933-k...-geht-das.html

[Fukiszo]

Ah schade, nach der vorfreude "die vielen anderen" nun die ernüchterung.
Na wenn RtlCompressBuffer eh die einzige schnittstelle für puffer kompression mit windowsXP per WinAPI ist,
kann ich ja dennoch stolz auf mich sein das ich sie fand, auch wenn die eigentliche funktion für einen anderen zweck erdacht/bereitgestellt wurde.

ps:
wen es interessiert, mein produkt bearbeitet eine selfmade datenbank auf nicht konventionelle art und weise,
bei mir fangen die datensätze mit einem nicht-komprimierten DIB/BMP an,
da es immer die gleiche dimension hat (ist gleichzustellen mit einer festen offset position/kleines thumbnail)
fängt der eigentliche inhalt erst danach strukturiert an,
bei anzeige/bearbeitung eines datensatzen, wird der per LZMA dekomprimierung in den speicher geladen.
im speicher wiederum geht eine on-the-fly komprimierung vor sich damit der speicher nicht zu voll wird.
nur partielle bereiche sind kurzzeitig komplett entpackt im speicher.
nach bearbeitung wird der komplette datensatz erstmal nur auf hdd ausgelagert (auch on-the-fly komprimiert) bis das programm entweder den befehl erhält, eine bestimmte uhrzeit ist, das system gebootet wird oder zu guter letzt eine gewisse system inaktivität festgestellt wird, dann wird das bearbeite wieder per LZMA in die hauptdatenbank eingepflegt.
in den datensätzen selbst ist meist ellenlanger TEXT/RTF/HTML/PDF inhalt mit ein paar bilder oder video's.
Es funktioniert ja auch alles tadellos, aber da schon ewig meinerseits keine echten erneuerungen damit gemacht wurden (letztes update ersetzte LZSS mit LZMA), dacht ich mir ich widme mich mal dem thema "on-the-fly" und ob profi's mir eine andere schnittstelle die microsoft zur verfügung stellt verraten könnten. (zu dem zeitpunkt der erschaffung gab es auch im MSDN wenig bis garnichts über diese funktion zu lesen, damals hieß es noch "function will be used intern").
Ich geb zu ich war seit ewigkeiten nicht mehr im MSDN und mir fielen da glatt die augen raus als ich eure links verfolgte. Ich bin ja ein liebhaber von WinAPI und was da so alles ans tageslich kommt.... mann-o-mann, find ich echt klasse das MS einen derart weiterhilft, sorry offtopic aber ich kanns immernoch kaum glauben.
als ich kurzzeitig mal einen abstecher in die welt von VB machte war MSDN unerläßlich aber sobald ich da mal was mit delphi oder asm fragte wurd ich immer wieder enttäuscht.

In diesem Sinne, danke für eure meinungen auch wenn mir selbst nicht wirklich weitergeholfen werden konnte, danke danke dankeschön!