dll: entry point funktion wird nicht aufgerufen

otze

also, ich hab mir einen kleinen maushook nach vorbild des tastaturhooks in der faq zusammengebaut. das problem scheint im moment zu sein, dass der mingw den entry point nicht setzt(auch wenn ich mir sicher bin, dass die funktionsdeklaration richtig ist).

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

miller_m

du hast vermutlich eine cpp dll erstellt dann musst du dllmain mit extern "C" umklammern.

otze

danke, das wars, jetzt funzt auch alles.

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

otze

hmm neues problem,will dafür aber keinen neuen thread öffnen

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?

miller_m

bin mir nicht ganz sicher. aber ich denke das der handle des fensters von der anderen app überschrieben wird da diese ja dann auch zum prozess gehört.
könnte aber auch totaler schwachfug sein
versuch dieses mal zu testen.

otze

nein, daran liegts nicht,den handle setz ich in einer anderen funktion, die nachrichten kommen auch alle in meinem prozess an, aber wenn ich dann im prozess mit dem lParam der nachricht folgendes mach:

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

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

miller_m

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

otze

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

miller_m

zu drei, ich meine deine struct MOUSEHOOKSTRUCT

otze

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

miller_m

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 }

otze

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

otze

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

miller_m

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.

otze

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.

miller_m

sind drei / vier aufrufe pro file. find ich net so viel.