nach einem test mit einer messagebox, bin ich mir nun sicher, dass der mingw die funktion nicht aufruft(kann natürlich auch sein, dass messageboxen in entrpoints nicht gültig sind)

so sieht die funktion aus:

BOOL APIENTRY DllMain (HINSTANCE hInstance, DWORD reason,LPVOID){
	MessageBox (NULL,"aufruf","aufruf", MB_ICONERROR);
	if(reason==DLL_PROCESS_ATTACH){
		instance=hInstance;
	}
	return true;
}

wie gesagt, hab mit dlls nicht so die erfahrung, aber meine suche in der msdn/im forum und bei google hat mich nicht weitergebracht, deshalb muss ich doch wegen dieser trivialen sache fragen

rofl. 1 stunde mindestens nach dem dummen fehler gesucht, und hier gibts das nach 18minuten

ok, mein mousehook soll die MOUSEHOOKSTRUCT die es bei jedem mausklick doer bewegung bekommt an meine hauptapplication weiterleiten, das problem ist, das ding ist ein pointer, und wie ich schmerzlich in form eines systemfreezes erfahren musste, kann man nicht auf den speicher eines fremden prozesses zugreifen(irgendwie verständlich).

also hab ich mir folgenden kühnen plan überlegt:

HWND __attribute__((section ("shared"), shared)) window =0;
MOUSEHOOKSTRUCT __attribute__((section ("shared"), shared)) lastClick=MOUSEHOOKSTRUCT();//shared zwischen allen prozessen

//...
LRESULT CALLBACK MouseProc(int nCode,WPARAM wParam,LPARAM lParam){
	if(nCode==HC_ACTION){
		lastClick=*(MOUSEHOOKSTRUCT*)lParam;
		SendMessage(window,WM_USER+2,wParam,(LPARAM)&lastClick);
	}
	return CallNextHookEx(0,nCode,wParam,lParam);
}

ich dachte mir, dass, wenn ich die struct in shared memory packe, ich problemlos von meinem prozess aus drauf zugreifen könnte, da soweit ich das verstehe, die dll über loadlibrary ja auch einmal in meinen prozess integriert wurde.

also hab ichs probiert, und o wunder, solange ich auf meinem fenster mit der maus rumhämmer klappt das auch, aber wehe, ich komme auf ein fenster eines fremden prozesses, DANN wirds übel(systemfreeze und so)

weis jemand wieso das so ist, doer wie ich das umgehen kann?

HWND window=((MOUSEHOOKSTRUCT*)lParam)->hwnd;

dann ist ende(wenns nicht grad das fenster meines prozesses ist)

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...

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^^

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

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.