Fragen zur API-Entwicklung

[blackdrake]

Die Lösungen haben leider doch nicht funktioniert.

Meine vorherige Lösung hatte den Schwachpunkt, dass man im Anwendungsfall "MyAPI.pas" (für Funktionen) UND "MyAPI_H" (für Typen) einbinden muss. Das ist eine Unit zu viel. Im Gegensatz zu C scheint Delphi sehr unflexibel zu sein, da die Implementierung immer an das Interface gekoppelt ist...

Die Include-Lösung ist noch katastrophaler. Delphi prüft nämlich zuerst die Funktionen und bindet danach erst die Include ein. Er sagt also, dass er "TMyRecord" bei "function x: TMyRecord" nicht kennt, obwohl der Typ in der Include-Datei drin steht. Schreibt man vor dem {$I} noch ein "type", kommt Delphi ebenfalls durcheinander weil es zu Syntaxfehlern kommt. (Die Include enthält types und consts)...

Ich habe nach extrem langer Zeit die Lösung gefunden:


Die Unit MyAPI.pas enthält alles was benötigt wird. Alle Typen sowie die DLL-Importe. Diese PAS wird im Anwendungsfall verwendet - logisch.

Für die DLL-Entwicklung wird MyAPI_Impl.pas entworfen. Es use'd die MyAPI.pas . Anschließend werden die Funktionen, die vorher aus der DLL importiert wurden nochmal definiert und implementiert. Aus irgendeinem Grund meckert Delphi NICHT wegen einer doppelten Deklaration!!! (Stand: Turbo Delphi, unbekannt ob Verhalten auch in Delphi 7)

Durch das Smart-Linking wird die DLL auch nicht sich selbst importieren (Import Table), da auf die Import-Funktionen nicht zugegriffen wird. Stattdessen werden die Funktionen exportiert, die implementiert wurden.

Kurz: Bei der API-Entwicklung importiert man die Funktionen _UND_ implementiert sie nochmal. Delphi "entscheidet" sich dann für die Implementierung und gibt keinen Konflikt aus; auch kein overload ist nötig.

Delphi-Quellcode:

unit MyAPI;

interface

type
  TMyRecord = record
    foo: PAnsiChar;
  end;

function myfunc: TMyRecord; stdcall;

implementation

// Die DLL importiert sich dank Smart-Linking nicht selbst
function myfunc: TMyRecord; stdcall; external 'MyDLL.dll' name 'myfunc';

end.

---

Delphi-Quellcode:

unit MyAPI_Impl;

interface

uses
  MyAPI;

// Seltsam, seltsam... Kein Namenskonflikt mit MyAPI.myfunc (imported)!
function myfunc: TMyRecord; stdcall;

implementation

function myfunc: TMyRecord;
begin
  result.foo := 'bar';
end;

end.

---

Delphi-Quellcode:

library MyDLL;

uses
  MyAPI_Impl in 'MyAPI_Impl.pas';

exports
  myfunc;

begin
end.

---

Delphi-Quellcode:

program MyProg;

uses
  MyAPI in 'MyAPI.pas';

var
  x: TMyRecord;

begin
  x := myfunc;
end.

Es ist seltsam, dass dieses merkwürdige Verhalten (Symbolkonflikt, der keiner ist) nicht dokumentiert ist. Auch ist es seltsam, dass noch niemand zuvor das Problem der Coderedundanz bei DLL-Entwicklung mit gleichzeitiger Nutzung gestoßen ist.


===> Kann bitte jemand bestätigen, dass dieses Verhalten auch in Delphi 6 und 7 existiert? Ich möchte den Code wegen OpenSource gerne bis mindestens D6 kompatibel halten.






Offen sind noch meine Fragen 2 und 3. Weiß denn niemand Rat?


Gruß
Daniel Marschall

[sx2008]

Jeder einigermassen moderne Compiler kann heutzutage COM/ActiveX-Bibliotheken einbinden.
Wenn du eine Schnittstelle (API) als Typbibliothek auslieferst, dann sind sämtliche Metadaten bekannt.
Ein fremder Compiler/IDE liest einfach nur die Typbibliothek ein und kennt anschliesend alle Funktionen, Parameter, Konstanten, Strukturen und Schnittstellen.

COM/ActiveX ist ab Delphi 5 aufwärts sinnvoll einsetzbar (mit Einschränkungen D4).

[blackdrake]

Was hat der Einsatz von COM/ActiveX konkret mit dem Problem der mangelhaften Delphi-Quelltextstruktur im Gegensatz zu C-Sprachen zu tun? Ich habe COM schnmal recherchiert und habe es nicht wirklich begriffen, auch habe ich nie eine Schulung diesbezüglich gehabt. Was ist böse daran, eine DLL-Funktion mit primitiven Datentypen (PAnsiChar, Cardinal, ...) zu deklarieren die einfach nur funktioniert, ohne Microsoft-abhängige Technologien zu nutzen, die das ganze mit Client/Server ver-kompliziert?

[sx2008]

Zitat von blackdrake:

Was hat der Einsatz von COM/ActiveX konkret mit dem Problem der mangelhaften Delphi-Quelltextstruktur im Gegensatz zu C-Sprachen zu tun?

Na es ist einfach die Lösung der Probleme zwischen verschiedenen Prog.-sprachen eine gemeinsame Basis zu finden.
Gerade beim Schreiben von Plugins kann COM helfen.
Man definiert einfach ein Interface ohne konkret angeben zu müssen, welche DLL dieses Interface implementieren muss.

Zitat von blackdrake:

Ich habe COM schnmal recherchiert und habe es nicht wirklich begriffen, auch habe ich nie eine Schulung diesbezüglich gehabt.

Das ist leider ein Schwachpunkt von COM. Man braucht relativ lange, bis man es verstanden hat.

Zitat von blackdrake:

Was ist böse daran, eine DLL-Funktion mit primitiven Datentypen (PAnsiChar, Cardinal, ...) zu deklarieren die einfach nur funktioniert, ohne Microsoft-abhängige Technologien zu nutzen, die das ganze mit Client/Server ver-kompliziert?

Es ist nicht "böse" sondern eher Zeitverschwendung.
Ich versuch's mal mit einem Beispiel:
X86 Assembler mag vielleicht ganz interessant sein, aber mit einer höheren Programmiersprache kann man wesentlich mehr Dinge in kürzerer Zeit programmieren.
Gleichfalls kann man mit einer Objektorientierten Programmiersprache mehr erreichen als mit einer Programmiersprache die auf strukturierte Programmierung setzt.

Normale DLLs kennen nur ganz normale Funktionen während COM objektorientiert ist.
Es ist gut zu wissen, wie ganz normale DLLs funktionieren, aber damit arbeiten möchte man eigentlich nicht mehr.

Oder anderst gesagt: mach' es so wie du es für richtig hältst, aber jetzt weisst du ja wie man es besser machen kann.

[omata]

Zitat von blackdrake:

... mit dem Problem der mangelhaften Delphi-Quelltextstruktur im Gegensatz zu C-Sprachen zu tun?

Delphi hat halt keinen PreProzessor, dafür hat Delphi eben andere Vorteile.

[Sherlock]

COM macht genau das, was du willst, und sogar einfach und hübsch verpackt. Erste schritte findest Du bei about.com.

Und nur weil etwas anders als bei C gelöst ist, heisst es nicht, daß es mangelhaft ist. Oder ist Pascal als Programmiersprache etwa mangelhaft?

Sherlock