Delphi 7 DLL-Exports überladener Methoden?

[himitsu]

Moin, irgendwie funktioniert das bei mir nicht.

Delphi-Quellcode:

exports
//NSet(var A: IRational; const N: IInteger; const D: IInteger = nil) name 'NSetIInt',
  NSet(var A: IRational; const N: IInteger; const D: IInteger) name 'NSetIInt',
  NSet(var A: IRational; const N: Integer; const D: Integer) name 'NSetInt',
  NSet(var A: IRational; const N: Int64; const D: Int64) name 'NSetI64',
  NSet(var A: IRational; const B: IRational) name 'NSetIRat',
  NSet(var A: IRational; const B: Extended) name 'NSetExt',
  ...

Zitat:

[Fehler] Unit1.pas(39): Bezeichner 'NSet' kann nicht exportiert werden
[Fehler] Unit1.pas(39): '=' erwartet, aber ';' gefunden
[Fehler] Unit1.pas(39): ';' erwartet, aber ')' gefunden
[Fehler] Unit1.pas(39): ';' erwartet, aber ',' gefunden
[Fehler] Unit1.pas(40): '=' erwartet, aber '(' gefunden
...

Mit oder ohne DefaultParams, mit oder ohne CONST/VAR, ..... immer wird gemeckert, sobald es vom overload ist.

Wobei der zweite Folgefehler ... das = also der DefaultParam ist nicht beim N:IInteger, sondern erst beim D:IInteger. :stupid:

Ganz ohne Pamameterliste, kommt die erste Fehlermeldung erst nach dem Komma, was da ja auch OK ist.


Auch Overloaded über mehrere Units, wenn eine Unit nur eine der Überladungen hat, dann hilft auch kein Namespace.

Delphi-Quellcode:

exports 
  IDPrimes.NInt;

Am Liebsten hätte ich die DCU gern zur OBJ gemacht, um sie im Delphi 11 direkt linken zu können. (aber das geht nur aus einer PAS zu erzeugen)
Drum versuche ich das DECMath jetzt in eine DLL zu packen.

[Uwe Raabe]

Kannst du mal ein Minimalbeispiel machen? Ein schnell zusammengehackter Versuch zeigt keine Probleme.

[himitsu]

Delphi Encryption Compendium\5.2 (Unicode Version 2008)\Archive\D7\DECMath.dpr

Dat WinHelp zum Laufen gebracht
und die D7-Hilfe sagt, dass es damals auch schon gehen sollte.



PS: für https://www.delphipraxis.net/213644-...ml#post1526681

und https://entwickler-ecke.de/topic_Del...n_89408,0.html
Die Download-Links sind leider alle tot (eine Anmeldung für den Anhang hab ich nicht). Die beiden KB für Win8.1 x86 und x64 gibt es noch, unter neuen Link, aber im Win10 wollen sie sich nicht installieren lassen.

[jaenicke]

Da die Namen nach außen ohnehin anders lauten, warum benennst du die intern nicht einfach um? Dann kannst du exports ja nur mit den Namen selbst nutzen, so dass du das Problem gar nicht hast.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1526694)

und die D7-Hilfe sagt, dass es damals auch schon gehen sollte.

Also das compiliert hier unter D7:

Delphi-Quellcode:

library Project1;

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss sich in der
  ersten Unit der unit-Klausel der Bibliothek und des Projekts befinden (Projekt-
  Quelltext anzeigen), falls die DLL Prozeduren oder Funktionen exportiert, die
  Strings als Parameter oder Funktionsergebnisse übergeben. Das gilt für alle
  Strings, die von oder an die DLL übergeben werden -- sogar für diejenigen, die
  sich in Records und Klassen befinden. Sharemem ist die Schnittstellen-Unit zur
  Verwaltungs-DLL für gemeinsame Speicherzugriffe, BORLNDMM.DLL.
  Um die Verwendung von BORLNDMM.DLL zu vermeiden, können Sie String-
  Informationen als PChar- oder ShortString-Parameter übergeben. }
  

uses
  SysUtils,
  Classes;

{$R *.res}

type
  IRational = interface
  ['{4270A50C-2619-40F9-AAF8-2CCB6A67A423}']
  end;

  IInteger = interface
  ['{0E5936CA-C257-4820-86E4-3B192133E8D6}']
  end;

// procedure NSet(var A: IRational; const N: IInteger; const D: IInteger = nil);
procedure NSet(var A: IRational; const N: IInteger; const D: IInteger); overload;
begin
end;

procedure NSet(var A: IRational; const N: Integer; const D: Integer); overload;
begin
end;

procedure NSet(var A: IRational; const N: Int64; const D: Int64); overload;
begin
end;

procedure NSet(var A: IRational; const B: IRational); overload;
begin
end;

procedure NSet(var A: IRational; const B: Extended); overload;
begin
end;


exports
//NSet(var A: IRational; const N: IInteger; const D: IInteger = nil) name 'NSetIInt',
  NSet(var A: IRational; const N: IInteger; const D: IInteger) name 'NSetIInt',
  NSet(var A: IRational; const N: Integer; const D: Integer) name 'NSetInt',
  NSet(var A: IRational; const N: Int64; const D: Int64) name 'NSetI64',
  NSet(var A: IRational; const B: IRational) name 'NSetIRat',
  NSet(var A: IRational; const B: Extended) name 'NSetExt';


begin
end.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1526695)

Da die Namen nach außen ohnehin anders lauten, warum benennst du die intern nicht einfach um? Dann kannst du exports ja nur mit den Namen selbst nutzen, so dass du das Problem gar nicht hast.

Weil es bisher nur diese uralten DCU gibt und ich sie nicht neu kompilieren kann? :zwinker:

Zitat:

Zitat von negaH (Beitrag 282158)

Dort findest du die Distributationen für D5,D6 und D7.
WICHTIG! willst du DECMath benutzen so musst du DEC part I "deinstallieren". D.h. Delphi darf zu keinem Zeitpunkt bei Benutzung von DECMath Zugriff auf die Sourcen vom DEC part I haben. DECMath benutzt eine andere Version vom DEC Part I und so könnte es zu Problemen komme n wenn beide Libraries installiert sind.

DECmath gibts nur als binäre Distributation, also nur Packages und DCU's. Allerdings sind viele DEMO Sourcen vollständig enthalten, man kann also uneingeschränkt damit arbeiten. Eine Veröffentlichung der Source vom DECmath ist nicht geplant. Ein individueller Verkauf der Sourcen wäre aber möglich.
Das ich hier in der DP diese Versionen exklusiv gepostet habe ist auch nur ein "riesen Glück". Eigentlich hatte ich nie geplant sie überhaupt zu veröffentlichen. Das hat primär ausschließlich mit dem anfallenden Support zu tun, denn wer DECMath benutzen möchte muß sich erstmal selber durchbeisen und mit relativ wenig Dokumentationen zurecht kommen.

Gruß Hagen

hab grade mal mich umgesehn

• Hier im Forum und bei Michael Puff lagen die letzten öffentlichen Versionen.
• Markus Humm (Markus) kümmert sich aktuell um DEC Part I (GitHub + GetIt)
• Arvid Winkelsdorf hatte vor Hagen Reddmann ableben den Rest übernommen (noch nicht mit gesprochen)
  • hmmm, seine Firma existiert seit 2014 nicht mehr (digivendo GmbH) und die Webseite/eMail ist auch tot
  • GitHub scheint ein Frederik Winkelsdorf übernommen zu haben

Viele Downloads sind dahin (auch die Webseite von Luckie)
Hab meine alte ZIP gestern als DEC-Legacy in einem GitRepo, mit zurückliegenden Commits, neu zusammengestellt.

Maaaaaaaaaaaa .... viele Namen, über die man Tagen immer wieder stolpert.
negaH, Luckie, Robert Marquardt, ... :cry:

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1526698)

Weil es bisher nur diese uralten DCU gibt und ich sie nicht neu kompilieren kann? :zwinker:

Du kannst doch eigene Wrapperfunktionen nutzen oder gleich ein Interface exportieren, das die verschiedenen Funktionen über ein Wrapperobjekt beinhaltet. Klar, ein zusätzlicher Call ist dann dazwischen.

[himitsu]

Jaaaaa, aber ich hoffte es geht auch ohne noch weitere zusätzliche Calls drumrum. :stupid:
Außerdem erstmal alle gefühlt 200.000 Wrapperfunktionen schreiben :freak:


Und boar eh, wie man Strg+# vermissen kann, auch wenn es jahrelang kaum nutzbar war, aber nun, wo es garnicht geht ....




Die meisten Funktionen dann, auf der anderen Seite (Delphi 10+) in einen/mehrere Custom-Records packen,
steht noch an ... zum Glück ist VAR fast immer der erste Parameter, so dass ich die Record-Methode direkt auf die passende DLL-Funktion als export definieren kann.

[Uwe Raabe]

Wie schon oben erwähnt funktionieren die reinen Deklarationen schon. Eventuell hat es etwas mit den Interfaces zu tun?

[himitsu]

Selbst ohne GUID kompiliert dein Code. :vernupft:

Delphi-Quellcode:

  IRational = interface
  end;

  IInteger = interface
  end;

Die genaue Deklaration kann ich nicht sehen.
Hab ja nur die DCU und das abgespeckte "so in etwa"-Interface der Unit,
aber im CodeInsight sieht es eigentlich OK aus.



Direkt nutzen und kompilieren lässt es sich aber.
https://www.delphipraxis.net/213644-...ml#post1526706