AW: Externes Programm Teil 2
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. |
AW: Externes Programm Teil 2
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/ |
AW: Externes Programm Teil 2
himitsu, also das habe ich jetzt so gemacht.
Delphi-Quellcode:
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.
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; 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) |
AW: Externes Programm Teil 2
Zitat:
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) |
AW: Externes Programm Teil 2
Zitat:
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:
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....!)
hier der delphi 7 dll export
exports ShowDLL Index 1; |
AW: Externes Programm Teil 2
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:
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:
, vorallem da in dem Except-Block sämtliche Exceptions "fahrlässig" vernichtet werden.
Application.NormalizeAllTopMosts;
try ... finally Application.RestoreTopMosts; end; Das kann doch nicht wirklich so gewollt sein? |
AW: Externes Programm Teil 2
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. |
AW: Externes Programm Teil 2
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:
Übergabe an das Memo mit Memo1.Lines.Text:=s und umgekehrt.
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; 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. |
AW: Externes Programm Teil 2
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 |
AW: Externes Programm Teil 2
Delphi-Quellcode:
Für Leute, die einfach so Fehlermeldungen/Ausnahmefälle rückstandslos vernichten, sollte der Pranger wieder eingefphrt werden.
except
Exit end;
Delphi-Quellcode:
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.
try
ff:=TFileStream.Create(TempPfad,fmCreate or fmShareDenyWrite); finally ff.Free end;
Delphi-Quellcode:
Ein OutOfMemory beim SetLength und schon gibt es ein Speicherleck.
try
ff:=TFileStream.Create(TempPfad,fmOpenRead or fmShareDenyWrite); except Result:=false; Exit end; SetLength(s,ff.Size); try finally ff.Free; end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz