Moin Robert,
Wir haben also hier eine betriebssystemspezifische Schnittstelle zwischen verschiedenen Programmmodulen, die nicht auf jedem System überhaupt existieren muss und die auf einem gegebenen System (Linux, Windows) auch nicht von der verwendeten Programmiersprache C/C++ abhängig ist. Eine in Assembler/Delphi/VB geschriebene DLL hätte die gleiche Schnittstelle.
Inwiefern spielt denn an dieser Stelle die sogenannte Calling-Convention eine Rolle?
Sie spielt eine große Rolle für die Kompatibilität verschiedener Module untereinander, hat aber nichts mit den _Namen_ der Funktionen zu tun. Für ein gegebenes System muss aber diese "Calling Convention" ebenso eingehalten werden, logisch.
Aus meinen Tagen der Windows-Programmierung sowohl mit C als auch Delphi kenne ich, dass C-Funktionen standardmäßig als „cdecl“ betrachtet werden, d.h. die Argumente an die Funktion werden in einer bestimmten Reihenfolge auf den Stack gelegt, so dass C-Funktionen eine variable Anzahl an Argumenten entgegennehmen können. Außerdem ist die C-Funktion selbst dafür verantwortlich, beim Rücksprung den Stack in einem ordentlichen Zustand zu hinterlassen.
Nee, gerade andersrum: Nach cdecl ist die _übergeordnete_ Funktion für das Abräumen des Stacks nach dem Funktionsaufruf zuständig. Die aufgerufene Funktion kann dies nicht, da sie nicht "weiß", wieviele Argumente ihr übergeben wurden. Mit "pascal" deklarierte Funktionen tun das selber.
Der andere wichtige Unterschied ist die Reihenfolge der Parameter, wie du richtig bemerkt hast: Bei "cdecl" wird die Parameterliste von rechts nach links abgearbeitet, der erste Parameter kommt also zuletzt auf den Stack; bei "pascal" dagegen von links nach rechts, in normaler Leserichtung.
Schönen Tag noch,
Martin
Wichtig ist, was hinten rauskommt.
(Helmut Kohl, 16 Jahre Bundeskanzler)