none
DLL Verständnisfragen RRS feed

  • Frage

  • Hallo zusammen

    Folgende Situation: Gebaut werden soll eine EXE, welche eine DLL A lädt. Diese EXE und die DLL nutzen jetzt Code einer weiteren DLL B (gemeinsam und diese DLL B baut auch Daten auf, welche in den Aufrufen der EXE und der DLL A gemeinsam genutzt werden sollen -> Bsp: EXE -> Call "store(x);" und DLL A -> Call "load(x)" -> so könnte EXE mit DLL A Daten austauschen).

    Zudem existieren von der DLL B zwei Varianten. Meine Fragen sind jetzt:

    a) Gibt's was zu beachten, dass die EXE und DLL A nicht andere "Instanzen" der DLL B nutzen und somit ein Datenaustausch per store/load nicht funktionieren würde?

    b) Wenn ich nur eine Version von B hätte, würde ich mal annehmen, dass ich in EXE und DLL A einfach die LIB von DLL B einbinden würde (mit passendem Header). Wenn jetzt aber mehrere Versionen davon existieren.. ginge das dann auch? Wie funktioniert der Mechanismus, der DLL-Einsprungmarken lädt?

    c) Wenn ich jetzt sogar eine C++ Klasse exportieren wollte aus DLL B, liesse sich das machen? Immer in der Annahme, dass die Anzahl und Aufrufkonvention der Funktionen in beiden DLL B Versionen immer die gleichen sind. Was, wenn ich für Version 1 von B einen anderen Compiler einsetze als für Version 2 von B? Ginge das gut? ... ich könnte den Export ja per DEF-File machen über Ordinals und ohne Namen...

    Fazit: ... gibt's irgendwo eine Falle, welche ich beachten muss bei so einem Szenario? Ich sehe schon, dass COM eine Alternative dazu wäre. Aber ich würde gerne das ganze System rund um DLLs besser verstehen und lieber ganz auf COM verzichten, wenn möglich.

    PS: Diesmal rede ich nicht von hypothetischen Dingen, diesmal will ich's wirklich bauen :-) ... aber ich will nicht in einem Jahr bei Version 2 rausfinden, dass ich früher massive Fehler gemacht habe.

     

    danke und Gruss

    Rudolf

    Mittwoch, 20. Oktober 2010 15:39

Antworten

  • Ganz grob kann man sagen:
    Wenn Du Compiler unabhängig sein willst, dann geht es nur wenn jede EXE/DLL seine eigene CRT verwendet und wenn Speicher in "DLL x" allokiert wurde, dann muss dieser auch in genau dieser DLL wieder freigegeben werden!

    Somit schlisst sich Folgendes aus:
    - C++ incl. STL
    - Alle anderen Datentypen auser PODs (also auch kein FILE* usw.)

    Wenn die DLL eine reine C-Schnittstelle hat und für Allokationen/Frees eine eigene Funktion hat, dann ist das alles kein Problem.

    Dann kannst Du auch eine import LIB machen und unterschiedliche DLL-Versionen, welche natürlich aufwärts kompatibel sein müssen.
     Das ist genaz das was Windows schon seit Jahrzenten macht. Die Version der DLL spielt keine Rolle... auch die LIBs vom PSDK sind immer entsprechend aufwärtskompatibel...


    Jochen Kalmbach (MVP VC++)
    Mittwoch, 20. Oktober 2010 17:57

Alle Antworten

  • Ganz grob kann man sagen:
    Wenn Du Compiler unabhängig sein willst, dann geht es nur wenn jede EXE/DLL seine eigene CRT verwendet und wenn Speicher in "DLL x" allokiert wurde, dann muss dieser auch in genau dieser DLL wieder freigegeben werden!

    Somit schlisst sich Folgendes aus:
    - C++ incl. STL
    - Alle anderen Datentypen auser PODs (also auch kein FILE* usw.)

    Wenn die DLL eine reine C-Schnittstelle hat und für Allokationen/Frees eine eigene Funktion hat, dann ist das alles kein Problem.

    Dann kannst Du auch eine import LIB machen und unterschiedliche DLL-Versionen, welche natürlich aufwärts kompatibel sein müssen.
     Das ist genaz das was Windows schon seit Jahrzenten macht. Die Version der DLL spielt keine Rolle... auch die LIBs vom PSDK sind immer entsprechend aufwärtskompatibel...


    Jochen Kalmbach (MVP VC++)
    Mittwoch, 20. Oktober 2010 17:57
  • Danke für die Info... ich denke, das werde ich so machen.

    Montag, 25. Oktober 2010 15:37
  • Hallo,

    ich muss eine in c++ erstellte dll in fortran einbinden und dort routinen callen. Um das vorab zu testen habe ich mir in Visual Studio eine c++ dll (Hello World) erstellt. Diese möchte ich in Fortran callen.

    Leider wird mir keine .lib datei erstellt. Daher schaffe ich es nicht, die dll in Fortran einzubinden. Woran könnte das liegen? Danke

    // test.h
    
    #define CALL __declspec(dllexport)
    
    namespace testfuncs{
    
    	class testfuncs extern "C" void CALL
    //	class testfuncs public void CALL
    	cschreiben_ ();
    }
    
    
    
    // testfuncs.cpp
    
    #include "test.h"
    #include <iostream>
    #include <stdexcept>
    
    using namespace std;
    namespace testfuncs
    {
    extern "C" void CALL cschreiben_ ();
    }

    Mittwoch, 4. April 2012 08:21
  • @markus: Ob ne .lib erstellt wird oder nicht stellt man irgendwo in den Projekt-Optionen ein (bei den linker-options)  - sollte aber standardmäßig geschehen, wenn ich mich nicht irre. Ansonsten mach mal nen eigenen Thread für die Frage auf.

    Samstag, 7. April 2012 04:17