DLL einbinden Delphi7 vs Rad Studio 10.2

[diso]

Hallo,

nach langer Zeit möchte ich wieder was mit Delphi programmieren und verzweifle am neuen RAD Studio..

Ich möchte die ngspice.dll einbinden, Delphi 7 klappt ohne probleme.
Doch der selbe Code funktioniert nicht im RAD Studio, sobald ich eine Funktion aus der DLL aufrufe gibt es eine Zugriffsverletzung.

http://ngspice.sourceforge.net/ngspi...h_bin_win32.7z

Kann mir einer erklären warum es nicht auf der neuen Umgebung/Compiler nicht funktioniert?

Grüße

[KodeZwerg]

Wenn Du auch noch den Code zeigen könntest wie Du mit der dll umgehst... könnte hilfreich sein bei Fehlersuche.

[Luckie]

Glaskugel sagt: "Mutt du achten auf Ansi und Uniode."

[diso]

Sorry habe das bin Link geposted.. Sources: http://ngspice.sourceforge.net/ngspi..._src_delphi.7z

oder :

Code:

  ngspice_Init: function(ptrchar: Pointer; ptrstat: Pointer; ptrexit: Pointer;
                ptrdata: Pointer; ptrinitdata: Pointer; ptrnoruns: Pointer; userData: Pointer): integer; cdecl;
  ngspice_Com: function(ms: PChar): Integer; cdecl;
  ngspice_GetVec: function(ms: PChar): pVector_info; cdecl;
  ngspice_SendCirc: function(circarray: pcarray): Integer; cdecl;
  ngspice_GetCurPlot: function(): PChar; cdecl;
  ngspice_GetPlotNames: function(): ppansichararray; cdecl;
  ngspice_GetVecsFromPlot: function(plotname: PChar): ppansichararray; cdecl;
  ngspice_Running: function(): boolean; cdecl;
  ngspice_Init_Sync: function(ptrvsrcval: Pointer; ptrisrcval: Pointer; ptrsync: Pointer; ident: PInteger; userData: Pointer): integer; cdecl;
  ngspice_SetBkpt: function(simtime: double): boolean; cdecl;




// attach ngspice.dll and initialize ngspice
procedure TForm1.Button1Click(Sender: TObject);
var 
   init_test: integer;
   ng_ident: integer;

begin
   // load dll
   Hdll := LoadLibrary(PChar(StartIni.ReadString('ngspice.dll', 'Path', '')));
   if (Hdll = 0) then
      // try local directory
      Hdll := LoadLibrary('ngspice.dll');
   if (Hdll <> 0) then
   begin
      @ngspice_Init := GetProcAddress(Hdll, 'ngSpice_Init');
      @ngspice_Com := GetProcAddress(Hdll, 'ngSpice_Command');
      @ngspice_GetVec := GetProcAddress(Hdll, 'ngGet_Vec_Info');
      @ngspice_SendCirc := GetProcAddress(Hdll, 'ngSpice_Circ');
      @ngspice_GetCurPlot := GetProcAddress(Hdll, 'ngSpice_CurPlot');
      @ngspice_GetPlotNames := GetProcAddress(Hdll, 'ngSpice_AllPlots');
      @ngspice_GetVecsFromPlot := GetProcAddress(Hdll, 'ngSpice_AllVecs');
      @ngspice_Running := GetProcAddress(Hdll, 'ngSpice_running');
      @ngspice_Init_Sync := GetProcAddress(Hdll, 'ngSpice_Init_Sync');
      @ngspice_SetBkpt := GetProcAddress(Hdll, 'ngSpice_SetBkpt');
      // call initialization
      // send addresses of callback functions, and address of sending object
      init_test := ngspice_Init(@ng_getchar, @ng_getstat, @ng_exit, @ng_data,
                                @ng_initdata, @ng_thread_runs, self);
//       init_test := ngspice_Init(@ng_getchar, nil, @ng_exit, @ng_data,
//                                @ng_initdata, @ng_thread_runs, self);
      if (init_test = 1) then
      begin
        detach(coquit);
      end;
      ng_ident := 5;
      init_test := ngspice_Init_Sync(@ng_sendvsrc, @ng_sendisrc,
                                     @ng_sync {nil} , @ng_ident, self);
      if (init_test = 1) then
      begin
        detach(coquit);
        is_attached := false;
      end;
      will_detach := False;
      is_attached := True;
   end
   else
   begin
     MessageDlg('ngspice.dll not found', mtError, [mbAbort], 0);
     Form1.Close;
   end;
end;

[himitsu]

PChar durch PAnsiChar ersetzen!

Was du auch in nahtzu allen Tutorials und Beiträgen bezüglich Unicode-Umstellung nachlesen kannst.



Außerdem greift man NIEMALS auf diese hässlichen globalen Variablen zu,
welche genauso heißen, wie die Form, aus deren Events du das aber machst.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
     Form1.Close;

Wenn, dann

Delphi-Quellcode:

Self.Close

oder nur

Delphi-Quellcode:

Close

.

Und die Meldung "ngspice.dll not found" ist irreführend.
"not loaded" wäre passender, oder eben garnicht erst den Fehler verfälschen und den korrekten Fehler ausgeben,
also "ngspice.dll not loaded" + GetLastError + SysErrorMessage

[diso]

Zitat:

Zitat von Luckie (Beitrag 1404328)

Glaskugel sagt: "Mutt du achten auf Ansi und Uniode."

Auch wenn es schon 10 Jahre her ist, an deine Glaskugel erinnere ich mich noch.
Ich möchte hiermit ihre ordnungsgemäße Funktion bestätigen :lol:

Es lag an der Kodierung...


Vielen Dank Luckie!

[diso]

Das ist eine Beispiel/Test Anwendung für die ngspice dll, der Code stammt nicht von mir. (Auch wenn ich nicht wirklich fit bin hätte ich bestimmt nur Close verwendet :stupid: )

Danke auch dir himitsu =)

[KodeZwerg]

Ich las gerade das Du DLL mit einer CDECL Anweisung öffnest, da sollte dann immer der Memory Manager von Delphi an erster Stelle mitkompiliert werden, sonst kann es bei Daten-Übertragung (.exe <-> .dll) zu fehlern kommen.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1404356)

Ich las gerade das Du DLL mit einer CDECL Anweisung öffnest, da sollte dann immer der Memory Manager von Delphi an erster Stelle mitkompiliert werden, sonst kann es bei Daten-Übertragung (.exe <-> .dll) zu fehlern kommen.

oops.. Dann muss ich viele Fehler in meinen Anwendung haben denn ich verwende ihn nie.

gruss

[mkinzler]

Nur wenn man Delphi-Strings verwendet.

[KodeZwerg]

Zitat:

Zitat von mkinzler (Beitrag 1404362)

Nur wenn man Delphi-Strings verwendet.

Dann habe ich das falsch in Erinnerung, Text im allgemeinen dachte ich ist betroffen, ich nutz meist eh stdcall anstelle CDECL.

@EWeiss: Das war kein Angriff meinerseits, ich wollte damit nur sagen das es bei Übermittlung ohne den Manager zu fehlern kommen kann. Da es sich anscheinend nur um Konvention "String" handelt ist meine Aussage eh belangslos geworden.

Ps: Jetzt ist es mir wieder eingefallen bzw ich sehe es, ja das war so Delphi 6/7 rum als ich enorme Probleme hatte da Text immer fehlte/abgeschnitten war, stimmt total @mkinzler, String war damals auch der Übeltäter, ich habe erst jetzt das Projekt gefunden.

[EWeiss]

Zitat:

@EWeiss: Das war kein Angriff meinerseits, ich wollte damit nur sagen das es bei Übermittlung ohne den Manager zu fehlern kommen kann. Da es sich anscheinend nur um Konvention "String" handelt ist meine Aussage eh belangslos geworden.

Habe ich auch nicht so aufgefasst .. ;)

gruss

[himitsu]

Zitat:

Zitat von KodeZwerg (Beitrag 1404356)

Ich las gerade das Du DLL mit einer CDECL Anweisung öffnest, da sollte dann immer der Memory Manager von Delphi an erster Stelle mitkompiliert werden, sonst kann es bei Daten-Übertragung (.exe <-> .dll) zu fehlern kommen.

Wieso?
Die Aufrufkonvention hat absolut garnichts mit den Speichermanagern zu tun.

Die besagen ob Parameter auf dem Stack landen und/oder in den Registern und in welcher Reihenfolge
und wer den Stack am Ende aufräumt (der Aufrufer oder der Aufgerufene).

[KodeZwerg]

Zitat:

Zitat von himitsu (Beitrag 1404375)

Die Aufrufkonvention hat absolut garnichts mit den Speichermanagern zu tun.

Dann bastel Dir mal eine .dll mit Funktionen die Input/Output : String haben.
Nutze keinen Speichermanager.
Irgendwann wirst Du feststellen das die Strings fehlerhaft sind.
Bindest Du dann den Speichermanager in .dll und .exe ein, sind alle Strings auf magische Weise repariert. (<- objektive Aussage)
Vielleicht handhabt Delphi das jetzt mittlerweise anders (?), aber zu Delphi 6/7 war es ein arges Problem für mich gewesen!

[Luckie]

Und wo kommt bei dir jetzt die Aufrufkonvention ins Spiel?

Genau das wurde doch gesagt. Den Speichermanager brauchst du nur bei Delphi Strings. Unabhöngig von den Aurufkonventionen. Was die Aufrufkonventionen bewirken, wurde auch erklärt.

[KodeZwerg]

.dll

Delphi-Quellcode:

function abs(Input1, Input2, Input3: String): string; cdecl;
begin
  result := input1+#13#10+input2+#13#10+input3;
end

exports
 abs name 'abc',

.exe

Delphi-Quellcode:

function xyz(Input1, Input2, Input3: String): string; cdecl; external '123.dll' name 'abc';
Memo1.Lines.Add(xyz('Das ist ein Dll Test','der vielleicht in die Hose geht','wenn man keinen Speichermanager einbindet'));

meinst Du das?


edit: ok, erledigt.

[himitsu]

Und dann kommt noch etwas dazu.

Mit Delphi 2009 wurden die LongStrings erweitert. (nicht nur, dass der UnicodeString dazu kam)

Also, selbst mit SharedMemmory gibt es dann Probleme, wenn man AnsiString zwischen DLL und EXE austauscht, aber Einer mit Delphi 2007 oder älter und der Andere mit Delphi 2009 oder neuer kompiliert wurde.

Reine Lesezugriffe auf der Anderen Seite würden aber noch funktionieren, aber den String verändern und ein Lesezugriff auf einen String, aber mit concatinieren zweier/mehrerer String kann knallen.
Seit D2009 hat der AnsiString zwei Word (einen Integer) mehr in seiner Verwaltungsstruktur (CodePage und CharSize) ... vorher gab es nur Length und RefCount.