Zwei DLLs statisch laden

[dummzeuch]

Ich tippe genau wie Uwe ganz stark darauf, dass die Deklarationen sich irgendwie geändert haben. Ob eine oder zwei DLLs ist dabei völlig egal.

Überprüfe mal anhand der C-Header:

• Parameter-Typen
• Parameter-Reihenfolge
• Calling Convention

Mögliche Ursache:

In C/C++ bastlen sich die Leute bei Interface-Änderungen gerne einen "Compatibility-Layer" mit #define-Makros. Wenn man da nicht genau hinschaut, sucht man sich dumm und dusselig.

[Sinspin]

Ist die API so extrem Geheim dass Du nichtmal die Header Dateien oder das C/C++ Beispielprojekt mit uns teilen kannst? Denn aktuell ist es nur Rätselraten.

[TSchnuckenbock]

Ja, die ist so geheim. Das verlangt der Hersteller. Da es eine ganz kleine Nische ist, werden es auch nur ganz wenige Kunden sein (eine Hand voll?), die das SDK überhaupt bekommen. Der Hersteller läßt sich das auch üppigst bezahlen.

Wenn ich die Deklaration der Funktionen aus den C++-Headern 1:1 neu gegen alt in einem Texteditor untereinander packe, dann ist da absolut kein Unterschied.

Es ist auch so, daß alle Funktionen aus der zweiten DLL nicht gehen.

Ich werd mir morgen mal das C++-Demo-Projekt zu Gemüte führen und gucken, ob ich das zum Laufen krieg. Da sind aber meiner Erinnerung nach die *.lib eingebunden und nicht die DLLs.

[Sinspin]

Wenn das so teuer ist dann sollten die mal Sourcecode rausrücken der die DLLs verwendet. Der kann ja auch in C/C++ sein. Aber dann kann man sehen was zu machen ist.
Allerdings, ich habe auch schon *.lib direkt in Delphi (32 Bit) eingebunden und verwendet. Mal gucken wo das Programm ist. Ist nicht Geheim, kann ich also Posten

[TSchnuckenbock]

Ich habe inzwischen die Vermutung, daß der Fehler nicht beim Laden der DLLs liegt, sondern daß intern in den Funktionen ein Check gemacht wird, aus welcher API sie sind. Das geht dann an den Simulator und der sagt "Nein", will ich nicht und haut den Fehler "falsches ClientHandle" raus.
Sowas in der Art. Das würde erklären, daß mit meinem Konstrukt und Laden aller Funktion aus der alten DLL alles geht, aber wenn ich die aufgespaltenen nutze, dann gehen die Funktionen aus der Lib_A, aber die Funktionen aus Lib_B nicht, weil der Programmierer der DLLs z.B. den Fehler gemacht hat, in LIB_B den API-Versions-Code nicht richtig angepasst zu haben auf die neue API.

Ich könnte mir vorstellen, daß ich eventuell sogar der einzige bin, für den es die DLLs gibt....die anderen Nutzer/Kunden schreiben ihren Krams vermutlich auch in C++ und nutzen die *lib.

Ich werd' mich wohl mal an den Hersteller wenden und dem das Problem schildern. Mal sehen wie ich das Problem rüber kriege....english for me and the manufactura is foreign.

@Sinspin: Aber ein Beispiel-Code mit *lib fände ich trotzdem gut, falls du finden solltest.

[shebang]

Hast du dir die DLLs mal mit dem Dependency Walker angeschaut? Vielleicht gibt der irgendwelche hilfreichen Hinweise auf die Ursache deines Problems.

[Sinspin]

Hallo,

ich finde meine alten Delphi Quelltexte nicht.
Was ich aber gefunden habe ist ein wrapper. Via MS Visual Studio habe ich mir selber eine DLL aus der .lib gemacht.

Wenn Du jetzt zwei .lib hast wäre es eventuell eine Idee die wieder in eine dll draus zu machen.

Allerdings, bei dem von dir beschriebenen Preis würde ich erstmal beim Hersteller anklopfen und fragen ob der helfen kann.

[TSchnuckenbock]

Mit dem Dependency Walker hatte ich schon geschaut.

Ich denke, ich bau dem Hersteller morgen mal ein kleines Demonstrationsprojekt mit Lazarus (in Delphi hab' ich das ja schon).
Dann soll der sich mal äußern.

Ich vermute, der Fehler bzw. das Problem steckt in den DLLs.

Erstmal Danke.

Vielleicht führe ich mir auch mal Rudy Velthuis Seite etwas intensiver zu Gemüte:

http://rvelthuis.de/articles/articles-cobjs.html