spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »nubi007«

Ja und diese funktionieren lediglich mit C++.
Ich möchte die DLL jedoch auch mit anderen Sprachen nutzen können, die keine .lib includieren können.

Diese dll, die du da hast, ist aber nur für die Verwendung in C++ vorgesehen. Genaugenommen sogar nur für eine ganz bestimmte Version eines ganz bestimmten Compilers eines ganz bestimmten Herstellers. Selbst mit einem anderen C++ Compiler, ließe sich diese dll bereits nicht mehr benutzen...

Zitat von »nubi007«

Und der dependencywalker zeigt logischerweise nur die direkt exportierte funktion an, und nicht die dahintersteckenden.

Die "direkt exportierten Funktionen" sind rein prinzipiell auch schonmal die einzigen, auf die du überhaupt von außen zugreifen kannst. Nur weil im Source Code der Engine eine bestimmte Funktion existiert, heißt das noch lange nicht, dass diese im fertigen Kompilat auch tatsächlich als Funktion abgebildet ist...

Zitat von »nubi007«

also müsste ich eine dll erstellen die die funktionen der lib zur verfügung stellt.

Du müsstest eine dll bauen, die ein prozedurales Interface zu dieser Engine implementiert. Das ist wesentlich mehr Aufwand, als einfach nur ein paar Funktionen weiterzuleiten...

Wieso muss es denn unbedingt genau diese eine Engine sein? Hast du nur die libs und Header, oder auch Zugang zum Source Code der Engine? Wenn du C++ beherrschst, wieso benutzt du sie dann nicht einfach in C++? Wenn du C++ nicht beherrschst, wirst du nicht drumherumkommen, es zu lernen, denn ohne solide C++ Kenntnisse, wirst du so eine dll, wie sie dir vorschwebt, nicht zustande bringen (mal ganz davon abgesehen, dass das imo ein mehr als sinnloses Unterfangen wäre)...

Zitat von »dot«

Genaugenommen sogar nur für eine ganz bestimmte Version eines ganz bestimmten Compilers eines ganz bestimmten Herstellers. Selbst mit einem anderen C++ Compiler, ließe sich diese dll bereits nicht mehr benutzen...

Naja, nicht wirklich. Man muss sich bei uebergeben der Daten einfach nur an das erforderliche Format halten. Bei einer Klassenmethode ist der Unterschied ja auch nur, das noch ein Pointer auf eine bestimmte Datenstruktur als weiterer Parameter hinzukommt. Alles in allem kein Hexenwerk.

Beachte: Wir reden hier nicht von einem einfachen C-style Interface. Natürlich muss man sich am Ende immer nur "an das erforderliche Format halten". Wenn du deine dll aber nicht gerade in einem Hexeditor schreiben willst, ist diese Aussage allerdings leider nicht sehr hilfreich. C++ ist viel zu komplex, als dass es ohne Metainformation auf ein dermaßen rudimentäres ABI, wie dlls es darstellen, abgebildet werden könnte. Schon beim Namemangling ist in der Regel Schluss, was Interoperabilität mit anderen Compilern angeht. Selbst wenn du für alles die selbe Version von MSVC verwendest, gibt es immer noch alle möglichen Dinge zu beachten, damit das auch tatsächlich funktioniert. Je nachdem, was genau dein Code tut, spielen z.B. die verwendeten Runtime Libraries eine Rolle, alle Module müssen natürlich mit kompatiblem Objektlayout arbeiten, ...

Natürlich ist kaum etwas jemals wirklich unter allen Umständen ganz und gar unmöglich, irgendeinen Hack gibt's fast immer. Aber kein ernstzunehmender Entwickler würde so eine Lösung in Erwägung ziehen und jemandem, der offenbar über keinerlei Erfahrung in diesen Dingen verfügt, kann man nur davon abraten...

Zitat von »dot«

Wenn du deine dll aber nicht gerade in einem Hexeditor schreiben willst, ist diese Aussage allerdings leider nicht sehr hilfreich.

Die dll ist doch schon geschrieben?

Zitat von »dot«

Je nachdem, was genau dein Code tut, spielen z.B. die verwendeten Runtime Libraries eine Rolle, alle Module müssen natürlich mit kompatiblem Objektlayout arbeiten, ...

Das sagte ich ja: man muss eine bestimmte Datenstruktur haben. Das wars dann aber auch schon.

Waere auch recht sinnloses Konzept, wenn z.b. jeder seine eigene d3d11.dll mitliefern muss, weil die von MS ja nur mit einem ganz bestimmten C++ Compiler zusammenarbeiten kann.

Zitat von »TGGC«

Zitat von »dot«

Wenn du deine dll aber nicht gerade in einem Hexeditor schreiben willst, ist diese Aussage allerdings leider nicht sehr hilfreich.

Die dll ist doch schon geschrieben?

Das Problem hier ist, dass die dll nicht dem passenden ABI folgt...

Zitat von »TGGC«

Zitat von »dot«

Je nachdem, was genau dein Code tut, spielen z.B. die verwendeten Runtime Libraries eine Rolle, alle Module müssen natürlich mit kompatiblem Objektlayout arbeiten, ...

Das sagte ich ja: man muss eine bestimmte Datenstruktur haben. Das wars dann aber auch schon.

...und diese "bestimmte Datenstruktur" liefert dir in dem Fall nur eine ganz bestimmte Version eines ganz bestimmten C++ Compilers von einem ganz bestimmten Hersteller mit ganz bestimmten Compilerflags...

Zitat von »TGGC«

Waere auch recht sinnloses Konzept, wenn z.b. jeder seine eigene d3d11.dll mitliefern muss, weil die von MS ja nur mit einem ganz bestimmten C++ Compiler zusammenarbeiten kann.

Eben genau darum basiert D3D auf COM. COM ist ein ABI Standard; die dll, um die es hier geht, folgt dagegen völlig undokumentierten Konventionen...

Also ich habe das so verstanden, dass hier eine DLL und eine statische Bibliothek vorliegen.
Der OP möchte die Funktionen, die er in der statischen Bibliothek zur Verfügung hat und deshalb auch in der DLL vermutet, nun in einem Basic Projekt benutzen. Die DLL liegt dabei nicht in einem speziellen Format vor, sondern der OP benutzt in C++ einfach die statische Bibliothek. Ich bin der Meinung der OP sollte einfach die entsprechenden Funktionen in einer DLL selbst exportieren (wie er ja auch schon selbst vorgeschlagen hat).

Oh, ich ging davon aus, dass es sich um in eine dll exportierte C++ Klassen handelt...