Externes Programm Teil 2

[Willie1]

Hallo Himitsu,
ich sehe, du bist schon sehr lange dabei.

1. Mein Neffe geht lieber zu LAN-Spielpartys.
2. Dein Einwand ist für mich sehr theoretisch. Kann ich dieses Konstrukt benutzen oder wird es nach dem nächsten Windows Update wieder crashen. Wie gesagt, ich will die PIN's usw. verschlüsseln und zum Schluss mit einem Passwort versehen packen.

Was hältst du von der Idee, Rar.exe zu benutzen?

Willie.

[himitsu]

Zip, 7Zip und RAR erlauben es, die Daten auch mit Passwort zu verschlüsseln.

Seit einer Weile ist für ZIP direkt im Delphi eine Klasse enthalten, aber ich weiß nicht ob dort die Funktionalität für das Verschlüsseln mit eingebaut wurde.
7Zip hat gegenüber RAR aber den Vorteil, dass es quelloffen und kostenfrei ist. RAR dagegen ist ein propitäres Format und so weit ich weiß, ist dort nur das "entpacken" mit freien DLLs/Programmversionen legal möglich.

Zum Komprimieren und Verschlüsseln gibt es für Delphi auch Komponenten. ZLib ist seit Jahren in Delphi enthalten. (die hauptsächlich bei ZIP und GZIP verwendete Komprimierungsmethode)
Und Verschlüsselungsfunktionen gibt es mehrere Bibliotheken, also grundsätzlich kannst du dir selber sowas bauen, was ohne externe DLLs auskommt.


Aber das Hauptproblem mußt du dennoch erstmal lösen, also in welchem Format kommen deine Daten in den Stream.
z.B. einfach immer ANSI, Unicode oder z.B. UTF-8. Aber kein String/PChar, welches sich verändert, außer du speicherst in dem Stream auch wie er wieder ausgelesen werden muß und dann eine/mehrere Auslesefunktionen (bei Einer dann mit Fehlermeldung, wenn die Daten "unverständlich" sind)

TReader und TWriter sind auch ganz praktisch, denn deren String-Sunktionen speichern mit ab, wie sie die Strings gespeichert haben. Genauer speichern die das komplette Datenformat zu jedem einzelnen Teil.
PS: Darum können die vielen Property der DFMs im Delphi so schön deserialisiert werden, weil man beim Auslesen schauen kann, was für ein Format die nachfolgenden Daten haben. (original ist die DFM ein Binärformat ... das Textformat ist davon nur die menschenlesbare Version)

Zitat:

oder wird es nach dem nächsten Windows Update wieder crashen

Delphiprogramme haben per se recht wenige externe Abhängigkeiten, nicht so wie .NET oder JAVA.
Hier liegt das Problem in unterschiedlichen Compilern.
Ein "String" wird z.B. im Delphi 7 als AnsiString und in aktuellen Delphis als UnicodeString behandelt. "String" ist ein Alias, der je nach Compiler/Zielsystem auf unterschiedliche Typen zeigt.
Also mit einem Delphi 7-Programm speichert mit dem Code aus Kommentar #32 den Text als ANSI, aber versuchst du später das mit einem Delphi XE-Programm auszulesen, dann will das Unicode haben und liest somit nur Kauderwelsch aus, der ein bisschen an Chinesisch erinnern wird. (es gibt im Unicode sehr viele asiatische Zeichen, drum werden sie sehr wahrscheinlich getroffen)

[Willie1]

Du hast recht

Das Beispiel zum Laden von Strings knallt in der Zeile
SetLength(aTxt, aLen); mit Integer-Überlauf.
Bei einer kleinen Text-Datei fällt das nicht auf.
Über deinen Beitrag muss ich nachdenken.

Willie.

[EWeiss]

SetLength(aTxt, aLen + 1); ?

gruss

[Willie1]

Hallo

Zitat:

SetLength(aTxt, aLen + 1); ?

Das hilft leider nicht. Frage: aLen muss kleiner als MAXINT div 2 sein? Wg. 2 Byte pro Zeichen.

Windows erzeugt selbst Dateien mit dem Schema 2 Byte für die Länge des String und dann 1 Byte pro Zeichen! Mit Hexeditor überprüft.
Willie.

[EWeiss]

Zitat:

Das hilft leider nicht.

War auch nur eine frage.
Manchmal vergisst man das im Eifer des Gefechts.

gruss