4. DLL Problem mit Globalen Variablen

DLL Problem mit Globalen Variablen

  • C

    Unter Linux habe ich es viel folgt gemacht:

    Im Binary wir mittels

    dlopen(...)
    die ".so" Datei geladen.
    Weiterhin liegt im Binary auch eine Sigleton Klasse, welche ich mittels Klasse::GetExemplar()->Insert(function) eine Funktion übergeben kann.

    In der ".so" Datei habe ich dann eine Klasse Proxy p, welche ich nutze um auf die Sigleton Klasse zuzugreifen und das Insert auszuführen. Anschliessend erzeuge ich mir eine Instanz des Proxys im Globalen bereich der ".so" Datei. Unter Linux und Mac haben somit Binary und die ".so" oder "dylib" die möglichkeit aufeinander zuzugreifen und Werte zwischen ihnen auszutauschen.

    Ich hatte nur die Erfahrung gemacht das unter Mac Compiler Flags nötig waren um dieses Verhalten zu ermöglichen.

    Ist dieses denn Windows auch von nöten und wenn ja, welche Flags muss ich denn setzen.

    Oder ist der Adressbereich unter Windows für die Geladene DLL unerreichbar?

    0
  • J

    Meinst Du sowas?

    #pragma data_seg( "shared" ) 
int g_dllVarS = 0; // shared var 
#pragma data_seg() 
#pragma comment( linker, "/SECTION:shared,RWS" )

    Siehe auch:
    http://msdn.microsoft.com/en-us/library/h90dkhs0
    http://msdn.microsoft.com/en-us/library/ms686958

    Damit kannst Du von *verschiedenen* Prozesses auf die gleichen Daten (Prozessübergreifend) zugreifen.

    Oder was willst Du genau?

    ADD: Ich hab es glaube ich falsch verstanden... Du willst nur eine Variable im "Main-Prozess" von der DLL heraus ansprechen, oder?
    Dann mach am besten eine "Init(...)" Funktion in Deiner DLL, wo Du alles nötige übergibst....

    Alternativ könntest Du noch "GetProcAddress" auf die HINSTANCE der EXE ausführen, wenn Du den Namen kennst und in der EXE diesen exportiert hast...

    0
  • B

    Unter Windows sind die Datenbereiche von Prozessen (eine dll ist auch ein solcher) strikt gegeneinander abgeschottet. Der Vorschlag mit einem 'shared data segment' ist nicht bei allen Compilern verfügbar, sonst gut. Geht es nur um wenige Informationen, übergibt man diese aus der rufenden Anwendung mit einer DLL-Funktion. Darüberhinaus gibt es noch verschiedene Verfahren der 'inter process communinication ipc', die auch unter dem Begriff 'file sharing' zu finden sind.

    0
  • J

    So wie ich es verstanden hab, will er doch *innerhalb eines Prozesses* auf Daten der DLL/EXE zugreifen. Das geht natürlich...

    0
  • B

    Jochen Kalmbach schrieb:

    So wie ich es verstanden hab, will er doch *innerhalb eines Prozesses* auf Daten der DLL/EXE zugreifen. Das geht natürlich...

    Habe ich auch so verstanden wie du. Meine Borland-Compiler machen da leider nicht alles mit, WinMain und DllMain sind da schon nahezu getrennte Prozesse. Deswegen mein Hinweis.

    0
  • J

    Das sind aber keine getrennten *Prozesse* sondern Funktionen...
    Du kannst aber trotzdem aus der DLL auf die EXE zugreifen... alles teilt sich den gleichen Adressraum!

    0

  • Die Übliche Lösung wäre wohl die Variable mit in die DLL zu packen, dann kann man auch einfach aus der .EXE und der .DLL darauf zugerifen.

    Natürlich kann auch die .DLL Symbole aus der .EXE importieren, aber das ist umständlicher, und bei weitem unüblicher.

    0
  • C

    Danke für die vielen Konstruktiven antworten.
    Also soweit ich das überblicken kann, schirmt Windows die Exe und die DLL voneinander ab. Als wären es zwei Prozesse. Die Möglichkeit aus der Exe über eine DLL Funktion die Variablen bekannt zu machen ist für mich nicht praktikabel genug und leider ein viel zu statisches Verfahren.

    Ich hatte mir überlegt, mittels boost Shared Memory geteilten Speicherbereich zu erzeugen und diese dem DLL Prozess bekannt zu geben.

    Ich hätte jetzt mal nur Frage ob jemand mal ausprobiert hat, ob die Erzeugung einer DLL mittels des MingWing Compilers eine Linux ähnliches Verhalten ermöglicht.

    Denn irgendwie finde ich das Verhalten von .so Dateien natürlicher als die von Windows DLLs.

    Ich glaube ich verstehe jetzt warum, DLLs und .so Bibliotheken doch was ganz unterschiedliches sind.

    Schade nur, das man jetzt wieder um Portablen Code zu schreiben sehr tief in die Trickkisten des großen Betriebssystem Herstellers gehen muss.

    0
  • J

    Warum machst Du es nicht so wie ich es beschrieben habe:
    Exportiere die Variable in der EXE und hole diese in der DLL via GetProcAddress...

    Es wird keineswegs die EXE und DLL irgendwie voneinander abgeschirmt. Nur die natürliche abhängigkeit ist EXE von DLL und nicht anders herum (so wie Du es willst)...

    Der Weg über Shared-Memory ist ja min. genauso wie eine Init-Methode aufzurufen... da hast Du ja wieder das gleiche Problem, dass Du den Shared-Memory bekannt machen musst.

    Also einfach nur so in der EXE:

    extern "C" {
__declspec(dllexport) int MyVar;
}

    Und in der DLL brauchst Du einfach nur

    HMODULE hModExe = GetModuleHandle(NULL);
  int* pMyVar = (int*)GetProcAddress(hModExe, "MyVar");
  printf("%p", pMyVar);

    zu machen.... schon fertig...

    Oder was ist Dein Problem???

    0

  • Oder was ist Dein Problem???

    Er klingt für mich ein wenig so, als ob sein Problem wäre, dass er SOs kennt, und jetzt alles ablehnt was anders ist ("nicht praktikabel genug" "leider ein viel zu statisches Verfahren").

    0
Anmelden zum Antworten