Externes Programm Teil 2

[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.