Delphi 7 DLL-Exports überladener Methoden?

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

Ja (und Anderes), aber liefert nichts verwertbares.

Zitat:

unknown unit file
Except command $96 at $A9, but $41 found.
Except ...
...

[edit]
nochmal ... jetzt geht's plötzlich

sieht aber genauso aus, wie in den offiziellen Headern.
[/edit]


Hab grade mal jenen angeschrieben (oder vielleicht seinen Sohn, weil Frederik anstatt Arvid), welcher damals von Hagen quasi die mehreren Gigabyte an Nachlass übernommen hatte.

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

[himitsu]

So, ich hab erstmal die alte/letzte ZIP des DECMath in ein GitRepo gepackt,
die verschiedenen Verzeichnisse aufgelöst und alles in den Root, mit versionsabhängigen Branches/Tags,
und dort nach zeitlichem Verlauf (Änderungsdatum) unter Angabe der originalen Bearbeiter mit rückdatierten Commits, den einen historischen Verlauf gebildet.

Der alte Aufbau liegt aktuell noch als erster Versuch im Branch main.old bei.

Wenn dann die DLL funktioniert, würde ich sie, inkl. neuer Import-PAS, noch hinzufügen.
Und dazu noch ein paar Links/Dokus, zu den wichtigsten Seite/Posts/Threads, bezüglich dieses Themas.

https://github.com/geheimniswelten/DECMath-Legacy

[himitsu]

Also so richtig versteh ich das irgendwie nicht.

Beispiel: NECBuild knallt sogar, wenn man keine Parameter angibt, obwohl diese Funktion eindeutig ist.
Komischer Weise knallte sie auch, als ich die Parameterliste dran ließ,
aber dann sah ich im Git (erste versuche), dass es doch mal ging, auch mit den Parametern ... wieder rein und nun geht es doch.

Dann ging der Export mit name 'xxx' nicht, aber später ging es plötzlich.
Ursprünglich hatte ich Eindeutiges nicht umbenannt, aber nun überall einheitlich mindestens den Unitname davor.



Ansonsten hab ich jetzt erstmal alle Funktionen als Exporte drin,
aber Zuvieles wieder auskommentiert, weil es nicht kompilieren wollte.

Aber nun noch rausbekommen, warum so Einiges immernoch einfach nicht will.

Ich mach jetzt nochmal bissl Pause und hab die VM ganz runtergefahren.
Aber falls wer Lust hat und schauen möchte, ob er/sie/es was findet ... siehe GitHub.



https://github.com/geheimniswelten/DECMath-Legacy
Branch: DLL

DLL-Projekt: \Part_II\DECMath.dpr bzw. GroupDECMath.bpg
Delphi7-DCU: \Archive\D7\*.dcu
PAS-Header: \Archive\Part_II\LibIntf\*.pas sowie \Archive\Part_II\*.pas

[add]
Zusammenfassung aller PAS-Headers: \Part_II\DECMath_Headers.txt aus \Archive\Part_II\LibIntf\*.pas
Zusammenfassung des DCU-Disassembly: \Part_II\DECMath_Disassemble.txt aus \Archive\D7\*.dcu
ohne DefaultParams und sortiert, aber vergleichbar ... braucht noch bissl
[/add]
[add2]
Mist, nach Abgleich sind die Parameter der DCU und Header-PAS praktisch identisch.
Bis auf ein nutzloses Overload, aber das sollte egal sein.
[/add2]


---

Branch: main = letzter/aktueller Stand nach Version+Datum
Branch: orginal-zip-content-by-date = alter ZIP-Inhalt nach Datum (Versionen als Unterverzeichnisse)

[himitsu]

Ahhhhhhhhhhhh, i werd' irre.


Hab die Gründe raus.

• einmal zwei Fehler beim Kopieren (falscher TypBezeichner)
• wenn bei einer Funktion kein overload deklariert ist, dann darf man keine Parameter angeben
• selbst wenn eine Funktion eindeutig ist, aber dennoch mit overload deklariert wurde, müssen Parameter angegeben werden (auch wenn es unmenschlich Viele sind, die man gern weglassen würde)
• typlose Var/Const-Parameter lassen sich nicht angeben ... also geht nur, wenn ohne overload und man sie weglassen kann

PS:

Zitat von Uwe Raabe:

Also das compiliert hier unter D7:

Delphi-Quellcode:

exports
  NSet(var A: IRational; const N: IInteger; const D: IInteger = nil),
  NSet(var A: IRational; const N: IInteger; const D: IInteger),
  NSet(var A: IRational; const N, D: IInteger);

Selbst das kompiliert anstandslos,
auch wenn so drei Mal die selbe Funktion mit dem gleichen Namen exportiert werden
und Delphi hier nichmal eine Warnung wirft, dass hier mehrmals der gleiche Name "NSet" in der Exports-Liste steht.

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