Delphi 7 DLL-Exports überladener Methoden?

[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.

[himitsu]

Zitat von 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.

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

Zitat von negaH:

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, ...

[jaenicke]

Zitat von himitsu:

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

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.
Außerdem erstmal alle gefühlt 200.000 Wrapperfunktionen schreiben


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.

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

[mytbo]

Zitat von himitsu:

Die genaue Deklaration kann ich nicht sehen.
Hab ja nur die DCU und das abgespeckte "so in etwa"-Interface der Unit, ...

Hast du es schon mit DCU32INT versucht?

Bis bald...
Thomas

[himitsu]

Mist, dachte schon ich hab den Grund, aber war's leider nicht.

Hatte mir ja eine VM mit Delphi 7 neu aufgesetzt und da drin dann das "falsche" Verzeichnis erwischt.
Die Header aus der 5.1c kopiert und mit den DCU der 5.2 versucht zu kompilieren.

Aber egal, denn es gibt keinen Unterschied.

[Kas Ob.]

I am sorry if missunderstand the context of this thread.

What i got is you need a way to declare and use functions from a library, and prefer to save on jumps (branching) as much as you can for performance.

If that is the case then i would suggest to drop the whole Delphi default export/import system and use your own:
1) Make your library have a table of pointers to the needed functions (your exports), it is better of that table is simple global record or an global defined array.
2) DLL on loading will fill that table with the addresses of the functions you need to export, this might be ditched if you can manage to declare that table as constant and the compiler manage to full the addresses automatically.
3) Export one function and one only is enough, GetExportTable.
4) well the rest is easy.. i think you got it out from here, as it is easy as it sound for the import part.

See, Delphi compiler generate ugly/slow code for the static imported functions, the calling code will do be like this
.dpr.97: MessageBeep(10);
004D882A 6A0A push $0a
004D882C E847A0F3FF call MessageBeep // <-- this a call to the same EXE

the called MessageBeep inside the EXE is doing such jump, again !!!!!!
:function MessageBeep; external user32 name 'MessageBeep';
00412878 FF2560344E00 jmp dword ptr [$004e3460]

Where the address $004e3460 holds the actual address to MessageBeep the function in user32.dll, and had being resolved by the OS.

So two branching per API call, while if you used my suggestion above (or any other way you see fit), you can save on a jmp/branch, relieving the CPU cache, while allowing any sort of naming you might need.