Externes Programm Teil 2

[Willie1]

Hallo Leute,
ich hatte berichtet, dass ein Programm von mir, welches Exiftool ausführt plötzlich nicht mehr funktionierte. Da habt ihr mir helfen könne!

Jetzt stelle ich fest, dass ein weiteres Programm von mir, plötzlich nicht mehr funktioniert. Hier führe ich das externe Programm z-zip32.dll aus, dazu benutrze ich die Unit Sevenzip.pas. Es lief prima von Vista bis vor dem letzten Windows Update. SevenZipExtractArchive liefert ohne Fehlermeldung nichts zurück. SevenZipCreateArchive erzeugt ein Datei mit der Lämge 0. Ich wiederhole noch mal: das Programm lief fast 10 Jahre fehlerfrei. Was ist da los, was zum Teufel hat Microsoft geändert?

Ich hänge Sevenzip.pas an, wie gesagt es greift auf 7-zp32.dll zu.

Gruß Willie.

[Fukiszo]

Vielleicht kann dir diese unit im anhang weiterhelfen.
Sie basiert auf 7za.dll und ist evtl etwas aktueller als deine 10 jahre alte unit.

Ich selbst hab mich damit leider noch nicht beschäftigt,
da ich faul war hab ich mir Abbrevia von http://tpabbrevia.sourceforge.net/ besorgt.

Für einsteiger ist es eine empfehlenswerte alternative da massig beispiel programme samt code beiliegen.

ps: hast du nach update evtl auch eine neue dll mitinstalliert? für mich hört sich an als ob der fehler ein konfilkt zwischen der unit und der dll ist.

[Willie1]

Hallo fukiszo,

die 7-zip32.dll ist von 2007, ich habe sie von einer japanischen Webseite, bei der ich nur Download lesen konnte. Ist dein Anhang von Torry.net, dann kenne ich sie, mal sehen.
Ich melde mich...
Willie.

[Fukiszo]

Meine Bezugsquelle war (auch schon lange her...) http://www.7-zip.de/links.html

Da nahm ich damals diesen Link: http://www.rg-software.de/

Ich hoff es hilft dir weiter,

Viel Erfolg dabei!


edit:
Hab grad mal nachgecheckt, also die unit in meinem anhang ist der letzte release, aber der download auf http://www.rg-software.de/ enthält alles was du dafür brauchst, auch wenn da steht "Visit SourceForge to get the dll", die ist im download enthalten.

Was, wenn du dich entscheiden solltest sie zu nutzen, auch noch einen vorteil haben könnte, du kannst eine vorgefertigte .res datei mit einbinden und bist dadurch von externer dll befreit, sprich egal was für 7zip dlls deine anwender (oder du selbst) haben, dein programm ist darauf nicht mehr angewiesen. Klingt für mich fantastisch, auch wenns bissl mehr speicher kosten mag.

[Willie1]

Kleine Zwischenfrage:
ich hab' seit Ewigkeit keine DLL mehr programmiert. Braucht man Borlndmm.dll nicht mehr, wenn mann Delphi strings verarbeiten will?

Die Komponente, die ich selbst gefunden hatte, entspricht deiner. Es ist ja ein Demo Programm dabei, das sieht sehr vielversprechend aus. Kann ich diese Komponente in Delphi Berlin einbauen? Wg meiner Augenprobleme bin ich mit allem sehr vorsichtig. Willie.
Willie.

[Fukiszo]

Wenn man den Borland Memory Manager einsetzt um unter anderem Zeichenketten an eine DLL zu senden bzw empfangen,
dann sollte im Programm sowie der DLL die FastMM/FastMM4 o.ä. unit an erster stelle eingebunden werden (soweit ich weiss)
Da ich aus der WinAPI Welt komme und Delphi 7 nutze, kenne ich mich damit leider nicht so gut aus, tut mir leid.
Meine IDE = Notepad++ und per WinAPI gibt es andere möglichkeiten mit DLLs zu kommunizieren.

Ich habe keine 7zip komponente getestet da die mir zuwenig bot.
Ob sie Delphi version XYZ kompatibel ist kann ich nicht beurteilen.
Man kann ja im Source nachschauen was der so alles anstellt.
Bei argen zweifel: [e-mail] anschreiben und nachfragen.

Ich fand die VCL Variante damals interessanter als all die anderen
und da sie vom 7zip Team beworben wurde vertraute ich mal dem Hersteller und lud sie mir runter.

Bei Abbrevia kann ich das hier Wiederholen was der Hersteller sagt:
Supports Delphi 6-XE2, C++Builder 2009-XE2, Kylix 3, and FreePascal, on Windows (32-bit and 64-bit), Linux, and OS X

Noch ein nachwort zu Torry's seite, die ist ja an und für sich ganz nett und informativ,
aber oftmals fehlt vieles in den download Archiven, so das ich generell, egal bei was, immer zur Hersteller Seite geh.
Bei Torry was downloaden mache ich nur wenn es keine Hersteller Seite gibt bzw die Seite mittlerweile tot ist,
wobei ich dann erstmal Google ob's woanders auch angeboten wird.

[Willie1]

Delphi 7, ist das nicht von ca 2006? Ich habe Delphi 6 geschätzt, sehr stabil und schnell.

Ich muss mir den Hinweistext in der Dll-Objektdatei oben genau durch lesen. Die grüne Schrift kann ich extrem schlecht lesen, die Vorlesefunktion von Windows versagt in der Delphi IDE leider vollständig.

Das Schöne an SevenZip.pas war seine leichte Programmeinbindung, völlig unkompliziert. Werde es nochmal versuchen. Es ist doch komisch, dass ein Programm fast 10 Jahre funktioniert und dann plötzlich anfängt zu spinnen.

Willie.

[Fukiszo]

Schlechte Augen Problem -> evtl. Lösung :

1. drücke den Windows Start-Knopf
2. drücke auf "Ausführen"
3. Tipp " MAGNIFY " ein (ohne die Anführungszeichen! Groß-/Kleinschreibung ist egal.)
4. drück Eingabe Taste (Return)

Jetzt startet eine sogenannte Bildschirm-Lupe, im normalfall klinkt die sich im oberen Desktop-Bereich ein und vergrößert alles wo der Maus-Cursor ist.

Ja, meine Delphi Version ist alt, da mir 32bit reicht und ich keine 2 MegaByte Datei erzeugen möchte wenn auch 100 KiloByte (oftmals weniger, 15-30kb) das gleiche bewirken können.
Deshalb verweiger ich schon aus Prinzip mir privat soviel unnötigen Ballast zu Installieren.
Für VCL Programmierer ist natürlich eine aktuelle Version viel viel besser.
Auch die Installationsgröße von Delphi selbst ist ja ein Unterschied wie Tag und Nacht.
Meine Delphi Installation = 200/300 MegaByte,
aktuelles Delphi = unzählige MegaByte -> 20 GigaByte (?)

Grüße

[EWeiss]

Zitat:

Deshalb verweiger ich schon aus Prinzip mir privat soviel unnötigen Ballast zu Installieren.

Warum auch.
Wenn man mit der Win32Api programmiert benötigt man den Kram auch nicht.

GDI+ und Win32Api ist alles was du braucht.

gruss

[Willie1]

Hallo Fukiszo,

die Windows-Lupe benutze ich ständig mit 3-facher Vergrößerung, sonst könnte ich gar nicht programmieren. Auch die Vorlesefunktion von Windowas ist inzwischen sehr gut nur bei der Delphi-IDE geht nichts!

Aber jetzt mache ich mich an Arbeit und versuche das Problem zu lösen. Willie.

[Willie1]

Jetzt habe ich auch ein Problem mit meiner DLL.

1. Borlndmm.dll erreichbar ist,
2. In der DLL ShareMem als erstes...,
3. In dem Hostprogramm ShareMem in dier DPR-Datei als erstes eingetragen ist,

dann müsste doch die Übertragung von Delpi-Strings möglich sein?

Willie.

[himitsu]

Einfach SimpleShareMem als Erstes in EXE und DLL. (gibt es vermutlich seit Delphi 2006)
http://docwiki.embarcadero.com/RADSt...g_von_Speicher

Zu SimpleShareMem gibt es auch eine DEMO.
C:\Users\Public\Documents\Embarcadero\Studio\***.0\Samples\Object Pascal\RTL\SimpleShareMem
Die aktuellste Version der Embarcadero-Demos gibt es auf sourceforge.net
http://sourceforge.net/p/radstudiode...impleShareMem/

[Willie1]

himitsu, also das habe ich jetzt so gemacht.

Delphi-Quellcode:

function Verschluesseln(Passw: string; Ungerade: Boolean; Spiegeln: Boolean): string;
stdcall; external 'PasswSafeDLL.dll' Index 1;

function Entschluesseln(Passw: string; Ungerade: Boolean; Spiegeln: Boolean): string;
stdcall; external 'PasswSafeDLL.dll' Index 2;

procedure TForm1.Button3Click(Sender: TObject);
var
  s,Txt: string;
begin
  s:='ABCDEFGHIJKLMNOPQRSTUVWXYZ';
  Txt:=Verschluesseln(s,false,true);
  Label1.Caption:=Txt;
  Label2.Caption:= Entschluesseln(Txt,false,true);;
end;

der 1,3,5. Durchlauf des Click-Ereignis läuft wie gewünscht beim 2,4,6. ergibt es eine Zugriffsverletzung im DLL-Modul, wenn ich die Routinen innerhalb des Click-Ereignis mehrmals aufrufe, gibt es keine Zugriffsverletzung.

ich habe die Routinen aus der DLL in das Hostprogramm übertragen, dann läuft alles perfekt. Es kann also nicht falsch sein

Ich habe das Programm vor ca. 10 Jahren ohne eure Hilfe geschrieben, es lief gut und jetzt klappt plötzlich nichts mehr. (7-zip32.dll)

[himitsu]

Zitat:

Zitat von Willie1 (Beitrag 1391666)

Ich habe das Programm vor ca. 10 Jahren ohne eure Hilfe geschrieben, es lief gut und jetzt klappt plötzlich nichts mehr. (7-zip32.dll)

Beides wird neu kompilert? Wenn nicht, dann kann es schnell Probleme geben. (z.B. DLL aus Delphi 7 und nagelneue EXE passen nicht mehr zusammen)

Also bei externen Schnittstellen (z.B. EXE <> DLL) immer nur mit statischen Typen arbeiten. (z.B. AnsiString oder UnicodeString)
vor Delphi 2009 > String = AnsiString
seit Delphi 2009 > String = UnicodeString
Oder mit WideString.

WideString nutzt nicht den DelphiMM sondern den Speichermanager über OleAuth32.dll
und ist quasi eine Kapselung des BSTR vom C++. (SysAllocString)

[Fukiszo]

Zitat:

Zitat von himitsu (Beitrag 1391681)

z.B. DLL aus Delphi 7 und nagelneue EXE passen nicht mehr zusammen)

dürfte ich fragen wie das gemeint ist?

Code:

Function LinkAPI(Const Module, FunctionName: String; ShowError: Boolean): Pointer; StdCall;
var
  hLib: HMODULE;
begin
 Result := NIL;
 try
  hLib := GetModuleHandle(PChar(Module));
  if hLib = 0 then
   hLib := LoadLibrary(PChar(Module));
  if hLib <> 0 then
   Result := GetProcAddress(hLib, PChar(FunctionName))
  else
   Result := NIL;
  if ((Result = NIL) and (ShowError)) then
   raise Exception.Create('Unable'+' '+'to'+' '+'Load'+' '+ExtractFileName(Module));
 except
  Result := NIL;
  if (ShowError) then
   raise Exception.Create('Unable'+' '+'to'+' '+'Load'+' '+ExtractFileName(Module));
 end;
end;

procedure TTASKFORM.ModsMenu2Click(Sender: TObject);
var
 i : Integer;
begin
 if (LB_Mods.ItemIndex <> -1) then
 begin // start
  if not Assigned(_LoadPlugin) then @_LoadPlugin := LinkAPI(PChar(ChangeFileExt(Application.ExeName, '.dll')),'LoadPlugin', TRUE);
  if Assigned(_LoadPlugin) then
  begin
   try
    if SetEnvironmentVariable(PChar(ChangeFileExt(ExtractFileName(ParamStr(0)), '')), pChar(GetFileName(LB_Mods.Items[LB_Mods.ItemIndex]))) then
     if GetEnvironmentVariable(PChar(ChangeFileExt(ExtractFileName(ParamStr(0)), ''))) <> '' then
      begin
       Application.NormalizeAllTopMosts;
       i := _LoadPlugin(2);
       Application.RestoreTopMosts;
      end;
   except
    Application.RestoreTopMosts;
   end;
  end;
 end; // start
end;

Code:

hier der delphi 7 dll export

exports
  ShowDLL Index 1;

Klappt sowas mit aktuellem Delphi nicht (abgesehen von Unicode, verzeiht das ist falsch ja, bin ja schon beim aufarbeiten, aber der source war noch nicht drann....!)

[himitsu]

Da bei diesem Code Module/FunctionName nur gelesen und außerhalb der Funktion keine Referenzen darauf gespeichert werden, also Zugriff ausschließlich lesend innerhalb dieser Methode,
würde es hier auch ohne SharedMem keine Probleme geben, da keinerlei Zugriffe auf den/die SpeicherManager anfallen.

Zitat:

Zitat von Fukiszo (Beitrag 1391690)

dürfte ich fragen wie das gemeint ist?

Solcher Code ist immer böse. (Char PChar String)

Delphi-Quellcode:

Function LinkAPI(Const Module, FunctionName: String; ShowError: Boolean): Pointer; StdCall;

Mit Delphi 7 compiliert macht der Compiler das daraus

Delphi-Quellcode:

Function LinkAPI(Const Module, FunctionName: AnsiString; ShowError: Boolean): Pointer; StdCall;

aber in XE oder 10.x kompiliert kommt aber sowas aus dem Compiler

Delphi-Quellcode:

Function LinkAPI(Const Module, FunctionName: UnicodeString; ShowError: Boolean): Pointer; StdCall;

.

Also EXE mit dem Einem und DLL mit dem Anderen compiliert ... schon passt es nicht zusammen.
Ist das selbe Problem, wie wenn du das Eine mit STDCALL compilierst, aber das Andere nicht.

Und Delphi-Exceptions über DLL/EXE-Grenzen hinweg funktionieren auch nicht so gut, außer du arbeitest mit Laufzeitpackages und abeitest auf beiden Seiten mit den selben Exception-Klassen. (gemeinsame RTL, bzw. gemeinsamme RTTI)




Ach ja, bei

Zitat:

Delphi-Quellcode:

try
  Application.NormalizeAllTopMosts;
  ...
  Application.RestoreTopMosts;
except
  Application.RestoreTopMosts;
end;

meinst du doch bestimmt eher

Delphi-Quellcode:

Application.NormalizeAllTopMosts;
try
  ...
finally
  Application.RestoreTopMosts;
end;

, vorallem da in dem Except-Block sämtliche Exceptions "fahrlässig" vernichtet werden.
Das kann doch nicht wirklich so gewollt sein?

[Fukiszo]

von seiten des callers (programm) schon,
der brauch kein error handling, nur ob .dll existiert und ab gehts,
der dll export ruft eines von vielen modal-fenstern auf,
die im prinzip eigenständige programme OnTop sind,
jedes hat andere start parameter weswegen ich's mir einfach machte und per Environment der dll was flüster.

ich schrieb ja schon Unicode problem, aber der obere teil stammt aus XE4 was ich zu testzeiten mal drauf hatte.
ich kann gern die binaries zum testen hochladen, aber da selbst der main source nur für winXP war
zeigt das programm nicht viel an (ich nutzte da alte schnittstellen die unter 64bit anders angesprochen werden müssen.
war ein versuch eine art task manager mit paar extras zu basteln den ich auch nicht weiterentwickelt hab.)

also .exe ist XE4 und .dll ist d7



edit:
und des RestoreTop hab ich zweimal drinn als mein errorhandling ersatz

edit2:
starten und ausführen kann man es unter auch mit windows 7 64bit, aber zeigt nich viel an.

[Willie1]

Hallo, das Problem mit der DLL hat sich erledigt. Sorry!
Die neu kompilierte DLL wurde im Quelltext-Ordner abgelegt, die alte DLL lag im Debug-Ordner, das konnte natürlich nicht funktionieren. Das Host-Programm griff daher immer auf die alte DLL zu.

Mein Programm ist ein Passwort-Safe. Die Passworte und PIN's stehen in einem Memo-Feld, werden geladen, entschlüsselt und wieder verschlüsselt und abgespeichert. Zum Schluss wurden sie in ein mit Passwort gesichertes 7-zip-Archiv verpackt. Letzters geht leider nicht mehr.
Ich bin so vor gegangen:

Delphi-Quellcode:

      try
        ff:=TFileStream.Create(TempPfad,fmOpenRead or fmShareDenyWrite);
      except
        Result:=false;
        Exit
      end;
      SetLength(s,ff.Size);
      try
        ff.Read(s[1],Length(s));
      finally
        ff.Free;
      end;
      s:=Entschluesseln(s,true);//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Delphi-Quellcode:

    Buffer:=Verschluesseln(s,true);//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    try
      try
        ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite);
      except
        Exit
      end;
      ff.Write(Buffer[1],Length(Buffer));
    finally
      ff.Free
    end;

Übergabe an das Memo mit Memo1.Lines.Text:=s und umgekehrt.
Dieses Konstrukt läuft mit Delphi 2005 aber nicht mit Delphi Berlin. Ich hab's gerade nochmal ausprobiert. Auf meinem alten Vista-Notebook läuft das Programm fehlerfrei.
Was muss ich ändern, es ght mir darum die Datei nicht zeilenweise zu verschlüsseln sondern als Ganzes.

Alle Passwort-Programme, die in einen Browser integriert sind, laufen nach irgend einem Browser-Update oder in einem anderen Browser nicht (mehr). Deshalb das Memo-Feld:
Willie.

[Fukiszo]

Ich bin, wie desöfteren, verwirrt,

Im ersten Satz sagst du das sich das mit der .DLL erledigt hat und im zweiten sagst du das du keinen zugang zu der .DLL funktion hast, was denn nun? ;-)

zeig lieber den code wo die dll aufgerufen wird, da schlummert doch das problem oder überseh ich wiedermal etwas?

Grüße

[himitsu]

Delphi-Quellcode:

except
  Exit
end;

Für Leute, die einfach so Fehlermeldungen/Ausnahmefälle rückstandslos vernichten, sollte der Pranger wieder eingefphrt werden.

Delphi-Quellcode:

try

  ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite);

finally
  ff.Free
end;

Und ich hoffe hier bemerkt jemand die Compilerwarnung, denn wenn es im Create knallt, raucht es womöglich nochmal beim Free ab und schon wieder der ursprüngliche Fehler durch den Folgefehler versteckt/verdeckt.

Delphi-Quellcode:

try
  ff:=TFileStream.Create(TempPfad,fmOpenRead or fmShareDenyWrite);
except
  Result:=false;
  Exit
end;
SetLength(s,ff.Size);
try

finally
  ff.Free;
end;

Ein OutOfMemory beim SetLength und schon gibt es ein Speicherleck.

[Fukiszo]

aus sicht eines betrachters: danke für die aufklärung, so hab ich es auch noch nie verwendet, eine neue möglichkeit juchu!

[Willie1]

Hallo Fukiszo, Himitsu,

Verschluesseln und Entschluesseln kommen aus der DLL. Das funktioniert jetzt einwandfrei.
Txt:=Verschluesseln(Txt,true,true);
Txt:=Entschlusseln(Txt,true,true) liefert das korrekte Ergebnis. Die DLL läuft.

Bei der Speicherung von Memo1.Lines.Text geht etwas schief. Ist Memo1.Lines.Text Unicode? Wie würdet ihr denn einen unbekannt langen String speichern/laden. Seht euch bitte nochmal meinen Quelltext an. Try except/finnally end mal außen vor!
Memo1.Lines.SaveToFile kommt nicht in Frage. (Hab' ich begründet)

Willie.

[Fukiszo]

Ich stelle mich wiedermal zu doof an oder mein Browser ärgert mich aber ich finde keine Source Zeile die auf Memo1 verweist. Da ja der Inhalt anscheinend aus einer Memo-Box kommt ist es Inhalt mit bestimmter Länge, also definierbar/auslesbar. Bevor ich wiedermal irgendeinen code zeige (in diesem fall wie man eine datei erstellt und mit text füllt) wart ich mal ab und halte mich zurück.

Grüße

Ps.
Oder zeige nochmal wo in deinem code die Memo1 befüllt und dann gespeichert werden soll, ich finde es nicht.

[Fukiszo]

Ich hab hier noch eine gute LZMA Implementierung gefunden die auch auf 7z basiert.
Der Unterschied ist, es wird/kann momentan im Beispiel nur eine Datei bearbeitet werden.
Die entstandene Datei entspricht der eines 7z Archiv (Dateigröße) aber es ist kein Archiv!
Also die entstandene Datei ist nicht kompatibel zu irgendeinem normalen entpack Programm,
du wolltest ja auf sicherheit hinaus, die wäre damit erstmal gegeben.
Ich würde diese Units mit der zLib (die Delphi mit sich rumschleppt) kombinieren,
zLib's Archiv Funktionen mit der 7z LZMA Technik und schon hast du dein eigenes Format und bist total unabhängig von externen .dll Dateien, alles spielt sich in deinem Source ab.
In zLib wird super beschrieben wie man sowas anstellt. (zLib als Archiv Gerüst mit eigenem Kompressions-Motor)
Ansonsten kannst du ja mal in der LZMAalone.pas gucken ob dir da was mit deinem Problem weiterhelfen könnte.

Grüße und einen schönen Sonntag!

PS: Es handelt sich um 7z's LZMA v4.42b [LZMA (Pascal) 4.42 Copyright (c) 1999-2006 Igor Pavlov 2006-05-15]
Ich habe den Source lediglich um eine FreePascal deklaration erleichtert damit keine Fehler kommen.
(da war eine {$MODE DELPHI} direktive an der mein Compiler nicht vorbei kam.)

[Willie1]

Hallo, in einem Forum kann ich nur schreiben und wir können leider nicht mit einander reden.

Mein Programm ist fast 10 Jahre alt und ganz einfach gestrickt. In ein Memo-Feld schreibe ich meine Passwörter und PIN's, Memo.Lines.Text wird verschlüsselt, in ein mit Passwort gesichertes 7-Zip Archiv gepackt, gespeichert und umgekehr, das ist alles. Verschlüsseln und Entschlüsseln stehen in einer DLL.
Wenn ihr wollt, kann ich Exe und DLL hochladen, ihr könnt das Programm ausführen.

Willie.

[Fukiszo]

Delphi-Quellcode:

procedure TPasswords.PWSaveToFile(const s: string);
var
  ff: TFileStream;
  Dummy: array[0..2047] of Char;
  Buffer: string;
begin
  if not DLLFound then Exit;
  try
    Form1.Cursor:=crHourGlass;
    Form1.Memo1.Cursor:=crHourGlass;
    Buffer:=Verschluesseln(s,true);//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    try
      try
        ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite);
      except
        Exit
      end;
      ff.Write(Buffer[1],Length(Buffer));
    finally
      ff.Free
    end;
    if FileSetAttr(Self.Archivname,0) = 0 then RecycleFile(Self.Archivname,false,true);
    if SevenZipCreateArchive(Application.Handle,Archivname,'\',
                             TempPfad,4,true,false,GPw,false) <> 0 then beep;
    FillChar(Dummy,SizeOf(Dummy),'X');
    ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite);
    try
      ff.Write(Dummy,SizeOf(Dummy));
    finally
      ff.Free;
    end;
    RecycleFile(TempPfad,false,true);
  finally
    Form1.Memo1.Cursor:=crDefault;
    Form1.Cursor:=crDefault
  end
end; {TPasswords.PWSaveToFile}

du schreibst die datei nicht auf festplatte?

Code:

    try
      try
        ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite); // <<-- hier versuchst du eine datei zu erstellen
      except
        Exit; // <<-- bei fehler komplett raus und alle fehler ignorieren
      end;
      ff.Write(Buffer[1],Length(Buffer)); // <<-- hier fängst du die datei zu füttern
    finally
      ff.Free; // <<-- hier machst du die datei zu ohne geschrieben zu haben
    end;

// also in meinem delphi müsste das hier dazwischen

    finally
      ff.Close; // <<-- das könnte helfen die datei auf festplatte zu bekommen
      ff.Free;
    end;

// falls das der fehler ist, wiederholst du den danach

[Willie1]

Hallo,
TFileStream.Close gibt bei meinem Delphi nicht.

Das Problem muss woanders liegen:

Delphi-Quellcode:

var
  Txt: AnsiString;
begin  
if SDialog.Execute then begin
//    Txt:=Verschluesseln1(Memo1.Lines.Text,true,true); //Zeile A
    Txt:=Memo1.Lines.Text;                              //Zeile B
    FS:=TFilestream.Create(SDialog.FileName,fmCreate);
    FS.Write(txt[1],Length(txt));
    FS.Free;
  end;
end;

Nur wenn TxT: AnsiString funktioniert dieses Konstrukt!!! Bei Txt: string werden 2 Bytes pro Zeichen auf die Festplatte geschrieben, (mit einem Hexeitor überprüft). Sobald ich Zeile B durch Zeile A ersetze geht es auch dann nicht mehr.
Kannst du mit diesem Wissen etwas anfangen? Bei der Konvertierung der Strings geht was schief?!.
Willie.

[Fukiszo]

mein tipp wäre das die memo box etwas mit deinem text anstellt (Umcodiert/Umformatiert)
wenn du etwas verschlüsselt hast, besteht die verschlüsselung aus lesbaren zeichen?
falls dort nicht lesbare zeichen vorkommen kann es sein das die memo box sie verschluckt (inkompatibel)
evtl vorher noch mit base64 en-/dekodieren, da kommen nur zahlen raus die jede memobox drucken kann/du problemlos weiternutzen kannst.

also:

Code:

var
  Txt: String;
begin
if SDialog.Execute then
 begin
   txt:=Verschluesseln1(Memo1.Lines.Text,true,true); // hier ist dein text jetzt in txt verschlüsselt
   txt:=Base64Enc(Txt); // hier wird daraus ein lesbarer string
   Memo1.Lines.Clear; // memo leeren
   Memo1.Lines.Text := Txt; // memo füllen
   Memo1.SaveToFile(); // <<-- da es lesbare zeichen sind, kannst du diesen befehl nutzen
  end;
end; 

andersrum:
 Memo1.LoadFromFile(); // <<-- da es lesbare zeichen sind, kannst du diesen befehl nutzen (dein delphi kann anderen befehl haben)
 txt:=Memo1.Lines.Text; // <<-- hier memo in txt speichern
 txt:=Base64Dec(Txt); // hier wird daraus dein verschlüsselter string
 txt:=Entschluesseln1(txt,true,true); // <-- aufruf überprüfen, hab nur dein verschluesseln1 umbenannt
 Memo1.Lines.Clear; Memo1.Lines.Text := txt; // hier müsste nun dein verschlüsselter string wieder lesbar sein

hier siehst du einen meiner erster startversuche um lizenzinformationen zu verschlüsseln.
wie du vielleicht erkennst, nutz ich alles nur intern und gut verschachtelt.
mir war damals lediglich bewusst das ich nicht alle zeichen ($00 - $FF) als text schreiben und lesen kann, deswegen der umweg per Base64.
tja, so fing ich mal an....

Delphi-Quellcode:

procedure TRegUnit.btnApplyClick(Sender: TObject);
var
 Ini: TIniFile;
begin
{
 MessageBox(GetDesktopWindow,'Registration Data is correct. Please Restart.','Success! Please Restart.',MB_ICONINFORMATION);
 MessageBox(GetDesktopWindow,'Wrong Key!','Error!',MB_ICONHAND);
}
// only continue if some data is present
 if Length(edUser.Text+edCompany.Text) > 0 then
// check for valid DES
 TRY
  if ( (DESEncrypt(edUser.Text+edCompany.Text,GiveIt(PassKey)) = edKey.Text) and (edValid.Text = GiveIt(edKey.Text)) ) then
  begin
   Ini := TIniFile.Create(ChangeFileExt(Application.ExeName,'.ini'));
// Save Userdata Base64 scrambled and DES protected
   Ini.WriteString('Registration','Name',DESEncrypt(Base64Enc(edUser.Text),GiveIt(PassKey)));
   Ini.WriteString('Registration','Company',DESEncrypt(Base64Enc(edCompany.Text),GiveIt(PassKey)));
   Ini.WriteString('Registration','Serial',DESEncrypt(Base64Enc(edKey.Text),GiveIt(PassKey)));
   Ini.WriteString('Registration','Key',DESEncrypt(Base64Enc(edValid.Text),GiveIt(PassKey)));
   Ini.WriteString('Registration','CRC',DESEncrypt(Base64Enc(MD5Print(MD5StringA(edUser.Text+edCompany.Text+edKey.Text+edValid.Text))),GiveIt(PassKey)));
   Ini.Free;
  end;
 EXCEPT // bei irgendeiner unstimmigkeit oben einfach weitermachen, so macht man es cracker etwas schwerer da null rückmeldung kommt
 END;
{
  edKey.Text := DESEncrypt(edUser.Text+edCompany.Text,GiveIt(PassKey));
  edValid.Text := GiveIt(edKey.Text);
}
// clean up, no later usage wanted
 edUser.Text := '';
 edCompany.Text := '';
 edKey.Text := '';
 edValid.Text := '';
 RegUnit.Close;
//  RegUnit.CloseModal;
end;

[Willie1]

Zitat:

mein tipp wäre das die memo box etwas mit deinem text anstellt (Umcodiert/Umformatiert)

Genau das vermute ich auch. Passt ja, dass es mit Delphi 2005 ohne Fehler lief.
var Txt: string, Txt = '1234567890' gespeichert wird 31003200330034003500 (Hexeitor)! (unverschlüsselt)
var Txt: ansistring Txt = '1234567890' dann geht's. Aber sobald ein Zeilenumbruch erfolgt, geht's wieder schief.


txt:=Base64Enc(Txt); zu welcher Bibliothek gehört das.

Ich habe gelesen bei 32-Bit-Compiler ist string Unicode.

[Fukiszo]

Zitat:

Zitat von Willie1 (Beitrag 1392307)

var Txt: string, Txt = '1234567890' gespeichert wird 31003200330034003500 (Hexeitor)! (unverschlüsselt)

also 31003200330034003500 ist 1234etc als hexadezimalstring mit nullen (terminator) dazwischen soweit ich weiß, aber was weiß ich schon im vergleich zu den profi's hier.

Zitat:

Zitat von Willie1 (Beitrag 1392307)

txt:=Base64Enc(Txt); zu welcher Bibliothek gehört das.

Das gehört zu der Base64.7z von meinem obrigen anhang.
Du kannst auch jede andere Base64 unit benutzen, vielleicht ist so etwas in deinem Delphi sogar von Hause aus dabei ?!?!
Ich hab die nur rangehangen damit du überhaupt etwas hast.

Zitat:

Zitat von Willie1 (Beitrag 1392307)

Ich habe gelesen bei 32-Bit-Compiler ist string Unicode.

Das ist Delphi Versions abhängig, bei mir ist string eben kein unicode (altes Delphi 7)

Aber wenn du mein Beispiel mit der Base64 nimmst, sollte alles klappen, unicode hin oder her.

Grüße


ps: ansonsten erstell ein rar/zip/7z archiv mit komplett source + dll und ich überarbeite es so das es funktioniert. momentan les ich nur was du da probierst aber kann's selbst nicht testen.
Falls du das so machst, bearbeite im vorfeld deine passwörter.... ersetz die mit irgendwas, mir ist's egal.

[Willie1]

Hallo,
ich bin nur Hobby-Programmierer, da fehlen mir manchmal die Grundlagen. Ich erkenne, das der String offensichtlich 2 Bytes pro Zeichen groß ist AnsiString nur 1 Byte. Diese Erkenntnis bringt mich nicht weiter. Ich muss mein Programm von Anfang an über arbeiten, flicken geht nicht. Ich werde deine Ratschläge mit ein beziehen.

Ich gehe mir schon selbst auf due Nerven aber ich habe das Programm gestern Abend auf meinem neuen Laptop mit Windows 10 vor dem großen Update laufen lassen, alles in Ordnung. Das gibt Frust!!!

Frage an Fukiszo: Läuft Delphi 7 unter Windows 10? Ich hatte meinem Neffen Delhi 7 PE (Buch mit CD) geschenkt, er sagt, es läuft mit W10 nicht.


Eine gute Woche für euch alle
Willie

[Gollum]

Hallo Willie,

wenn Du mit Strings statt AnsiStrings arbeitest, musst Du Deine Speicher- und Leseroutine ändern:

Delphi-Quellcode:

var
  aText:String;
  aLen :Integer;
begin 
  if SDialog.Execute then begin
  // aText:=Verschluesseln1(Memo1.Lines.Text,true,true); //Zeile A
    aText:=Memo1.Lines.Text; //Zeile B
    aLen:=Length(aText);
    FS:=TFilestream.Create(SDialog.FileName,fmCreate);
    FS.Write(aLen, SizeOf(Integer));
    FS.Write(Pointer(aText)^, aLen*SizeOf(Char));
    FS.Free;
  end;
end;

Und nun, die umgekehrte Richtung:

Delphi-Quellcode:

var
  aText:String;
  aLen :Integer;
begin
  FS:=TFilestream.Create(SDialog.FileName, fmOpenRead);
  aLen:=FS.Read(aLen, SizeOf(Integer));
  SetLength(aText, aLen);
  FS.Read(Pointer(aText)^, aLen*SizeOf(Char));
  FS.Close();
end;

[Willie1]

Hallo Gollum,
ich glaube, das ist fast die Lösung.
Mein Testbeispiel: '1234567890'
Schreiben geht in Ordnung. erst 4 Bytes für die Länge xA,0,0,0, dann 2 Bytes pro Zeichen.
Lesen noch nicht, aLen=4 Es steht '1234' da.

Willie.

[Fukiszo]

Delphi 7 Professional (32bit) schnurrt unter Windows 10 64bit, Delphi 7 Personal Edition kenn ich leider nicht.
Gollum's tipp ist sehr gut, damit sollt es auch ohne Base64 umweg klappen.

Grüße

[Gollum]

Hallo Willie,

eigentlich sollte mein Beispiel funktionieren.

Ich habe dir die Routinen als Unit angehängt.

[Willie1]

Hallo Gollum,

ich verstehe, wie es geht aber selbst wäre ich nicht darauf gekommen!
Willie.

[Gollum]

Hallo Willie,

ich habe es auch nicht selber erfunden.
Das Beispiel ist sogar aus der Delphi-Hilfe bzgl. Unicode-Umstellung.

Wichtig ist, dass Dir geholfen wurde.

[Willie1]

Hallo!
Ausgangspunkt für mein Problem war, dass 7-zip32.dll nicht mehr funktioniert. Ich habe eine Lizenz für Winrar und da gibt das Programm Rar.exe. Ein Konsolen-Programm zum Packen und Entpacken, genau was ich brauche.. Ich sehe, es ist hier im Forum schon Thema gewesen und ich werde mal stöbern, um 7-zip durch rar zu ersetzen.

Gruß Willie.

[himitsu]

Zitat:

Zitat von Willie1 (Beitrag 1392440)

Frage an Fukiszo: Läuft Delphi 7 unter Windows 10? Ich hatte meinem Neffen Delhi 7 PE (Buch mit CD) geschenkt, er sagt, es läuft mit W10 nicht.

http://www.delphipraxis.net/184041-d...0-preview.html
https://www.entwickler-ecke.de/topic...n_89408,0.html

[himitsu]

Zitat:

Zitat von Gollum (Beitrag 1392570)

Ich habe dir die Routinen als Unit angehängt.

Das Problem ist hier, dass sich dein Code zwar an den Compiler anpasst, aber genau das ist das Problem, denn du hast im Stream keine Informationen darüber gepsiechert welches Format dieser Text hat.

Entweder sollten sich Daten die das Programm im Format nicht einfach so verändern, oder es sollte darin enthalten sein welches Format das ist und das auslesende Programm muß dann auch alle Formate kennen und und den Text dann in sein Format notfalls umwandeln können.