dll: entry point funktion wird nicht aufgerufen
-
There are restrictions to consider before using a shared data segment:
* Any variables in a shared data segment must be statically initialized. In the above example, i is initialized to 0 and a is 32 characters initialized to hello world.
* All shared variables are placed in the compiled DLL in the specified data segment. Very large arrays can result in very large DLLs. This is true of all initialized global variables.
* Never store process-specific information in a shared data segment. Most Win32 data structures or values (such as HANDLEs) are really valid only within the context of a single process.
* Each process will get its own address space. It is very important that pointers are never stored in a variable contained in a shared data segment. A pointer may be perfectly valid in one application but not in another.
* It is possible that the DLL itself could get loaded at a different address in the virtual address spaces of each process. It is not safe to have pointers to functions in the DLL or to other shared variables.Note that these last three points apply to memory-mapped files and shared data segments.
erfüllst du das alles, insbesondere punkt 3.
[edit] tollen msdn tag wieder geändert
-
* Any variables in a shared data segment must be statically initialized. In the above example, i is initialized to 0 and a is 32 characters initialized to hello world.
Erfüll ich
* All shared variables are placed in the compiled DLL in the specified data segment. Very large arrays can result in very large DLLs. This is true of all initialized global variables.
k, kein problem
* Never store process-specific information in a shared data segment. Most Win32 data structures or values (such as HANDLEs) are really valid only within the context of a single process.
mein HWND ist solange konstant, wie mein fenster existiert, und wenn mein fenster gekillt wird, wird die dll entladen
* Each process will get its own address space. It is very important that pointers are never stored in a variable contained in a shared data segment. A pointer may be perfectly valid in one application but not in another.
hier net wichtig
* It is possible that the DLL itself could get loaded at a different address in the virtual address spaces of each process. It is not safe to have pointers to functions in the DLL or to other shared variables.
hmmm liegt hierdran das problem? ich weis nicht...
-
zu drei, ich meine deine struct MOUSEHOOKSTRUCT
-
nein, daran liegts sicher nicht, weil mir mein debugger inzwischen durch zufall einen segmention fault geliefert hat, dh der zeiger den mein prozess auswertet zeigt auf einen bereich, auf den er nicht zeigen soll

-
raten wir weiter. den es interessiert mich da ich selber noch nicht mit shared memory zu tun hatte und somit schon mal von vornherein ein paar fehler vermeiden
kann.
punkt1:
initialier mal lastClick mit = { 0 }
-
raten wir weiter
jo, is ja auch nur mein pc, den ich neustarten muss

(nein brachte nichts)
//edit2: wenns net klappt, komm ich halt mit dem hammer und mach filemapping an, das funzt bestimmt, nur is es etwas klobig^^
-
hab die lösung, ist mir auf dem weg zur schule eingefallen^^
und zwar geht es um die virtuellen addressräume, wenn in der geladenen dll a die sharedvariable an position 0x01F liegt, ist nicht garantiert, dass sie in einer dll b an derselben position liegt,dh bei meinem prozess greif ich auf die richtige position zu, und beim anderen..naja...schlecht

mit anderen worten: auch wenn die variablen physikalisch am selben platz liegen, heisst das nicht, dass sie das im auch virtuellen addressraum sind.
und nun teste ich das mal

mit ner getter funktion klappt das

-
hab mich heute auch mal dran versucht
mit ner shared section bekomme ich es gar nicht hin (hab auch das eine oder andere mal neubooten müssen
)
speicher kopieren auch negativ.mit ner einfachen get funktion hab ich hinbekommen. alle werte in die dll speichern. nachricht an app schicken diese ruft dann die get funktion auf.
mit mapped files funktioniert es super.
-
das es mit mapped files funzt war klar, ich wollte sie hier aber nich verwenden, da es doch ne ganze ecke code ist, und sich meiner meinung nach der aufwand für sone kleine sache nicht lohnt.
-
sind drei / vier aufrufe pro file. find ich net so viel.