library project1;
{$mode objfpc}{$H+}
uses SysUtils;
type ZNumArray = array of Integer;
procedure test1( var num : ZNumArray );
begin
SetLength( num, 1 );
end;
exports test1;
begin
end.
Danke Dir für den Hinweis, wie binde ich denn sharemem ein? Ich habe Sharemem in dll nun verwendet. Wenn ich aber in gui app auch Sharemem verwende, bekomme ich sofort nach dem Starten. "Execution stopped with exit-code -1073741515", wenn ich sharemem in gui app nicht einbinde, funktioniert die Funktion Loadlibrary nicht, erhalte den Fehlercode 119.
library project1;
{$mode objfpc}{$H+}
uses ShareMem, SysUtils;
type ZNumArray = array of Integer;
procedure test1( var num : ZNumArray );
begin
SetLength( num, 1 );
end;
exports test1;
begin
end.
Auf was willst du hinaus ? Mit sharemem wird die Bibliothek fix an einen Memorymanger gebunden, der sehr spezifisch ist. Das ist normalerweise nicht wirklich gewünscht. Normalerweise überlegt sich, wer für den Speicher zuständig ist und wer den auch freigibt.
af0815 hat geschrieben: Do 31. Aug 2023, 10:38
Auf was willst du hinaus ? Mit sharemem wird die Bibliothek fix an einen Memorymanger gebunden, der sehr spezifisch ist. Das ist normalerweise nicht wirklich gewünscht. Normalerweise überlegt sich, wer für den Speicher zuständig ist und wer den auch freigibt.
Ich danke Dir für deine Hinweise, ich wollte viele Möglichkeiten kennenlernen, dann kann ich später noch die empfohlenen Variante verwenden. Daher würde ich gern auch die Möglichkeit mit Sharemem zu testen.
fliegermichl hat geschrieben: Do 31. Aug 2023, 09:39
sharemem muß auch in der App als ERSTE Unit eingebunden werden.
program Project1;
{$mode objfpc}{$H+}
uses
Sharemem,
{$IFDEF UNIX}
cthreads,
{$ENDIF}
{$IFDEF HASAMIGA}
athreads,
{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms, unit1
{ you can add units after this };
{$R *.res}
begin
RequireDerivedFormResource:=True;
Application.Scaled:=True;
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Run;
end.
program Project1;
{$mode objfpc}{$H+}
uses
Sharemem,
{$IFDEF UNIX}
cthreads,
{$ENDIF}
{$IFDEF HASAMIGA}
athreads,
{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms, unit1
{ you can add units after this };
{$R *.res}
begin
RequireDerivedFormResource:=True;
Application.Scaled:=True;
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Run;
end.
Leider weiter kein Erfolg
Beispiel-Crash.png (49.94 KiB) 5251 mal betrachtet
Ich bin auch kein Experte auf dem Gebiet.
Ich weiss nur, dass ich für die DLL/SO Schnittstellen immer möglichst einfache Typen bzw. C Kompatible Typen verwende (Auch PPChar etc.).
Was du da hast
Ich weiss nur, dass ich für die DLL/SO Schnittstellen immer möglichst einfache Typen bzw. C Kompatible Typen verwende (Auch PPChar etc.).
Dies würde ich auch machen, dann ist deine DLL auch kompatibel zu C und co.
Wen du es mit Pascal-Typen machst, wird ein C-Code fluchen, wen er die DLL verwenden will.
Und zu guter letzt nicht das cdecl vergessen.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Ich weiss nur, dass ich für die DLL/SO Schnittstellen immer möglichst einfache Typen bzw. C Kompatible Typen verwende (Auch PPChar etc.).
Dies würde ich auch machen, dann ist deine DLL auch kompatibel zu C und co.
Wen du es mit Pascal-Typen machst, wird ein C-Code fluchen, wen er die DLL verwenden will.
Und zu guter letzt nicht das cdecl vergessen.
theo hat geschrieben: Fr 1. Sep 2023, 09:38
Ich bin auch kein Experte auf dem Gebiet.
Ich weiss nur, dass ich für die DLL/SO Schnittstellen immer möglichst einfache Typen bzw. C Kompatible Typen verwende (Auch PPChar etc.).
Was du da hast
Danke danke, ich habe es mittlerweise nach hartnäckig Stunden geschafft mit Sharemem zum "sauberen" Start und Beenden.
Das ist schon wirklich heftig, sobald ich freePascal unit einbinde, muss ich schon Sharemem verwenden. Das wäre z.B. JwaTlHelp3 Unit, bei Windows unit ist es kein Problem auch ohne Sharemem zu verwenden.
Das Problem mit dem Absturz oder Fehler beim Starten ist es dass ich fpcmemdll.dll nicht kompiliert habe und in den Ordner neben exe Datei gelegt habe. Somit muss ich immer fpcmemdll.dll ausliefern, sofern pascal unit verwendet werden oder was. Das ist eher entmutigend. Dann wäre doch hier Dll in C++ zu schreiben.
Hi!
Warum möchtest du überhaupt eine DLL erstellen, wenn sie Pascal-spezifisch sein soll?
Wenn sie nur von deinen eigenen Programmen verwendet werden soll, kann man doch leichter die betreffenden Units ins Hauptprogramm mit einkompilieren.
Es ist doch ein riesiger Vorteil von Delphi+Lazarus, dass man monolithische Anwendungen ohne Abhängigkeiten erstellen kann.
Und wenn einen die vielen Units nerven, kann man sie im Editor einfach schließen.
Ich meine, das Erstellen von DLLs macht nur Sinn, wenn man sie ohne ein Hauptprogramm weitergeben möchte.
Jorg3000 hat geschrieben: Sa 2. Sep 2023, 07:59
Hi!
Warum möchtest du überhaupt eine DLL erstellen, wenn sie Pascal-spezifisch sein soll?
Wenn sie nur von deinen eigenen Programmen verwendet werden soll, kann man doch leichter die betreffenden Units ins Hauptprogramm mit einkompilieren.
Es ist doch ein riesiger Vorteil von Delphi+Lazarus, dass man monolithische Anwendungen ohne Abhängigkeiten erstellen kann.
Und wenn einen die vielen Units nerven, kann man sie im Editor einfach schließen.
Ich meine, das Erstellen von DLLs macht nur Sinn, wenn man sie ohne ein Hauptprogramm weitergeben möchte.
Das ganze ist nur für den Lernzwecke gedacht, ich wollte so ziemlich alle Möglichkeiten der Freepascal DLL kennenlernen, um mein Wissen in Pascal zu vertiefen. Bei manchen Sachen ist schon etwas schwierig zu analysieren, warum es plötzlich zu Crash kommt, z.B. habe ich Heaprtc in dll aktiviert und unter in gui app nach Schließen, gibt es wieder unknown exception : External. obwohl dort nur leere Prozedure und Funktion drin habe.