dll Erstellung unter Windows

[dr.disk]

Hallo zusammen,

für ein Programmpaket, welches aus vielen kleinen Einzelprogrammen besteht, will ich die gemeinsamen Funktionen in eine dll packen (unter Linux soll's dann natürlich eine so werden).

Zum Testen habe ich eine einfach dll mit einer "Hallo Welt"-Funktion gebaut. Diese lässt sich auch aufrufen, jedoch erhalte ich nach deren Aufruf sofort einen SIGSEGV.

Leider habe ich im Internet noch nichts gefunden. Hat jemand für mich ein einfaches Beispiel bzw. ein Link zu einem Tutorial/HowTo wie man dynamische Bibliotheken "richtig" programmiert?

Vielen Dank,
Steffen

[Socke]

Zum Testen habe ich eine einfach dll mit einer "Hallo Welt"-Funktion gebaut. Diese lässt sich auch aufrufen, jedoch erhalte ich nach deren Aufruf sofort einen SIGSEGV.

Wenn du referenzgezählten Strings zwischen Bibliothek und Anwendung austauschen möchtest musst du die Units sharemem (Windows) oder cmem (*nix) als erstes deine Anwendung und Bibliothek aufnehmen.

Diese beiden Units implementieren andere Speichermanager, sodass Anwendung und Bibliothek auf den Speicher des jeweils anderen zugreifen dürfen.

Die Alternative: Du verwendest ausschließlich PChar (bzw. PWideChar/PUnicodeChar für Widestring bzw. UnicodeString).

[marcov]

Hallo zusammen,

für ein Programmpaket, welches aus vielen kleinen Einzelprogrammen besteht, will ich die gemeinsamen Funktionen in eine dll packen (unter Linux soll's dann natürlich eine so werden).

Wurde ich nicht tun. Gibt momentan mit FPC nur Ärger.

[dr.disk]

Wurde ich nicht tun. Gibt momentan mit FPC nur Ärger.

Wegen? Bzw. wo liegen da (derzeit?) die Probleme mit FPC?

[carli]

Grundsätzlich sollte man nur abkapselbare Bibliotheken, die ein C-Interface haben, in DLLs auslagern.
Komplette Klassen, so wie es mit MS-C++ geht, geht bei FPC nicht (ist auch nirgends spezifiziert, wie es denn gehen sollte, dazu hat das FPC-Sprachdesign zu viele Seiteneffekte)

Wie sieht denn der Code deiner Hello World aus?
Welche Aufrufkonvention verwendest du?

[dr.disk]

Morgen!

Ich will da im wesentlichen nur eine "Funktionssammlung" auslagern. Also mehr oder weniger nur Funktionen welche ich in den unterschiedlichen Modulen immer wieder mal brauche.

Als Aufrufkonvention verwende ich cdecl.

Code: Alles auswählen

function hello (lname: string): string; cdecl;
begin
  result := 'Hallo ' + lname;
end;

[theo]

Ich würde das für den Gebrauch innerhalb Freepascal nicht machen.
Wenn du die Funktionen aus C etc, benutzen willst, ergibt sich das Interface so:

function hello (lname: PChar): PChar; cdecl;

[carli]

Ich würde das für den Gebrauch innerhalb Freepascal nicht machen.
Wenn du die Funktionen aus C etc, benutzen willst, ergibt sich das Interface so:

function hello (lname: PChar): PChar; cdecl;

Nicht wirklich.

Code: Alles auswählen

procedure hello(lname: PChar; outtext: PChar; maxlen: integer); cdecl;

[marcov]

Wurde ich nicht tun. Gibt momentan mit FPC nur Ärger.

Wegen? Bzw. wo liegen da (derzeit?) die Probleme mit FPC?

Keine Unterstützung? FPC hat kein Packages Konzept wie Delphi um darum zu arbeiten, und keine Flache namespace wie C.

Für ein Idee wo die Problemen liegen, siehe http://wiki.freepascal.org/packages" onclick="window.open(this.href);return false;

[marcov]

Komplette Klassen, so wie es mit MS-C++ geht, geht bei FPC nicht (

"Wie" gehts mit MS C++? Irgendwelche URL, oder kannst du das hier kurz Erklären?

ist auch nirgends spezifiziert, wie es denn gehen sollte, dazu hat das FPC-Sprachdesign zu viele Seiteneffekte)

Unsinn. Gleich an Delphi, und Delphi hat Packages. Aber weil die schoen sind (sehr automatisiert), sind die aufwendig, und brauchen viel Kontrolle über den Linker.

[marcov]

Ich würde das für den Gebrauch innerhalb Freepascal nicht machen.
Wenn du die Funktionen aus C etc, benutzen willst, ergibt sich das Interface so:

function hello (lname: PChar): PChar; cdecl;

In Zukunft vielleicht nicht, weil char,pchar und String dann entweder ansi- oder unicode- sein können, von Kompiler-modus abhaengig.

Man soll anfangen sich daran zu gewöhnen um externe Interfaces mit pansichar ansichar usw, zu spezifizieren.

[theo]

In Zukunft vielleicht nicht, weil char,pchar und String dann entweder ansi- oder unicode- sein können, von Kompiler-modus abhaengig.

Man soll anfangen sich daran zu gewöhnen um externe Interfaces mit pansichar ansichar usw, zu spezifizieren.

Da sehe ich den Sinn nicht wirklich. Bei Char meinetwegen, aber PChar sollte doch immer char * und nicht wchar_t * entsprechen.

[marcov]

In Zukunft vielleicht nicht, weil char,pchar und String dann entweder ansi- oder unicode- sein können, von Kompiler-modus abhaengig.

Man soll anfangen sich daran zu gewöhnen um externe Interfaces mit pansichar ansichar usw, zu spezifizieren.

Da sehe ich den Sinn nicht wirklich. Bei Char meinetwegen, aber PChar sollte doch immer char * und nicht wchar_t * entsprechen.

Weil?

In Delphi ist das seit D2009 so. (pchar=punicodechar)

[theo]

Weil?

Wie gesagt, weil PChar doch meistens in der Schnittstelle zu C Libraries verwendet wird, und char * afaik auch nicht "magisch" zu wchar_t * wird, wie Byte auch nicht plötzlich zu Word wird, nur weil es eine neue Delphi Version gibt.

[marcov]

Wie gesagt, weil PChar doch meistens in der Schnittstelle zu C Libraries verwendet wird,

Nein. C libraries sind überhaupt da nicht im Frage. Delphi ist entworfen um mit winapi zu arbeiten, und winapi hat ein variabler CHAR typ. (variabler abhaengig vom "unicode" define)

Aber, wichtiger, ins FPC/Delphi dialect sind char und pchar erzwingend äquivalent zu "string". Das ist eben häufiger als C Schnittstellen. Also wenn "string" sich ändert, sollen (p)char mit ändern.

Und mindestens in D2009+ kompatiblen(*) Modi wird "string" sich ändern

(*) wie und ob das getan wird ist eine andere Diskussion