Announcement

**Hagen Reddmann** · 08.03.2003, 22:12

Grundsätzlich musst du sowieso berücksichtigen das ein Prozess alleine den Exklusivzugriff auf ein MMF haben kann. Dieser Fall tritt ein wenn das MMF kopiert oder angelegt oder hineingeschrieben wird. MMF's werden vom OS eben NICHT zwischen den Prozessen synchronisiert. D.h. normalerweise wird ein globales MMF immer mit einem globalen Event + Semaphore geschützt. 
Ich würde ein globales MMF mit fester Größe benutzen. In diesem MMF stehen die Namen und die Handles von Child-MMF's, deren Processe und Thread's. Wird ein neues MMF benötigt so wird es mit der neuen Größe angelegt, dann die Daten des alten MMF's hineinkopiert, die zusätzlichen Daten rangehängt. Danach wird das alte MMF Handle/Name im globalen MMF mit dem neuen ersetzt. 
Für diese Operationen sollte aber der Ownerprozess des globalen MMF's zuständig sein. 
D.h. über ein festes Array in einem MMF werden die eigentlichen Daten-MMF's verwaltet und global zur Verfügung gestellt. 

Gruß Hage

**Markus Fuchs** · 09.03.2003, 17:38

Hi Hagen!
Hört sich gut an. 
Ich habe dann 2 MMFs. Das "alte" und ein neues, in dem das dyn. Array abgelegt wird. Im alten speichere ich eine Referenz auf das neue, das bei Bedarf angelegt wird.
Habe ich das grundsätzlich richtig verstanden? ;-)
Gruß, 
Marku

**Hagen Reddmann** · 15.03.2003, 14:13

nicht ganz, ich habe mich da ein bißchen diffus ausgedrückt. 
Ein MMF dient zur Verwaltung der gerade gültigen Daten-MMF's. Dieses Index-MMF hat immer feste Größe und verwaltet die Handles/Namen der gerade gültigen Daten-MMFs. Will ein Process auf ein Daten MMF zugreifen dann tut es dies indem über das Index-MMF über den Index in dieses Array direkt den Namen des Daten-MMF's in Erfahrung bringt. Somit kann der Name der Daten-MMF's beliebig sein. 
z.b.

<pre>

type
TMMFIndex = array[0..15] of packed record
Handle: THandle; // Handle des MMF's
Size: DWord; // Größe des MMF's
Lock: TRTLCriticalSection; // globale RTL zum Sperren des MMF's
ProcessID: DWord; // Owner Process des MMF's, rein informativ
ThreadID: DWord; // Owner Thread des MMF's
Name: array[0..127] of Char; // Name des MMF's
end;

</pre>

Obiges TMMFIndex ist die Struktur die per MMF mit fester Größe zur Verfügung gestellt wird. Nun kannste in die DLL funktionen schreiben die über dieses Array[] per festen Index auf die einzelenen Daten-MMF's zugreifen. Soll nun eines dieser Daten-MMF's vergrößert werden so gibts dafür eine Funktion in dieser DLL. 

Gruß Hage

**Markus Fuchs** · 18.03.2003, 01:19

Hi Hagen!
Danke für die Antwort. Nun verstehe ich die Sache schon mehr, auch wenn ich so ein Gewurschtel eigentlich vermeiden wollte ;-) 
Ich muss momentan mal wieder etwas kürzer treten beim Programmieren, aber ich halte Dich auf dem Laufenden wie es funktioniert. Eine (blöde) Frage habe ich aber dennoch: Wieso verwenden wir diesmal nicht eine Semaphore (siehe meine Callback-Frage), sondern eine TRTLCriticalSection?
Danke, Du weißt wie sehr ich Deine Hilfe schätze!
Viele Grüße, 
Marku

**Hagen Reddmann** · 27.03.2003, 14:46

CS könnte man wie ein Sempahore betrachten, es ist sogar so das das OS intern CS per Semaphoren umsetzt. Der wesentlichste Unterschied ist der das Semaphoren die Möglichkeit bieten die Anzahl der Threads die diese "Schranke" passieren dürfen auf mehr als 1 Thread zu beschränken. Eine CS ist also eine Semaphore die nur EINEN Thread durchlässt und die anderen blockiert. ABER, genau diese Blockierung ist ein wesentlicher Unterschied zwischen Semaphoren und CS. Eine CS implementiert einen Mechanismus der den anderen, blockierten Threads, mitteilt das der blockierende Thread (der der die CS passiert hat und sie sperrt) nun fertig ist. Danach lässt die nun entsperrte CS den nächten wartenden Thread durch, und zwar NUR diesen, alle anderen wartenden Thread bleiben weiterhin blockiert und warten anständig. Die Entscheidung welcher Thread der nächste ist wird an hand dessen Priorität und Aufrufreihenfolge festgemacht. So, all diese Features bestitzen Semahore NICHT. Man muß also die alles selber coden. Im Normalfalle wird bei Semaphoren, bei nicht Erfolg, einfach die Funktion mit einem Fehler verlassen. D.h. der Thread WARTET NICHT. 

Gruß Hage

**Markus Fuchs** · 13.04.2003, 15:26

Hi Hagen,
kannst Du mir bitte, bitte nochmals ein paar Infos geben? Ich komm' nicht weiter

1. Muss ich nun für alle 3 MMFs (Index, "HookRec", "dynArrayRec") eine map und eine MMF anlegen? Boah, das bläht die DLL mächtig auf... 
2. Wie greife ich über das IndexMMF auf meine HookRec (Index 0) zu?
-> z.B. MMFIndex^[0].Handle.oldProc ???
Hm, sorry, dass ich mich so "dappig" anstelle...
Viele Grüße, 
Marku

**Hagen Reddmann** · 13.04.2003, 23:23

Was meinst du mit HookRec ?? 

Du benötigst ein MMF das die Liste aller Daten MMF's speichert. D.h. im Grunde kannst du 2,3,4 sogar 1000 MMF's in diesem Index-MMF verwalten. 

Da MMF's nicht in der Größe verändert werden können muß das MMF in ein neues größeres kopiert werden. Dazu wird über das "Index" MMF das Daten MMF gesperrt. Dann ein neues, größeres MMF alloziert, der Inhalt hineinkopiert, die Einträge im Index MMF die auf das Source MMF zeigen durch das neue ersetzt, und das alte Source MMF gelöscht. 

Das neue MMF hat dann auch einen anderen Namen. Um nun denoch das richtige MMF auswählen zu können, wird es über den Absoluten Index in das Index MMF Array angesprochen. Also nicht per globalen Namen, sondern per fester ID oder Index. 

Gruß Hagen

PS: ein anderer Name für das Index-MMF wäre zb. "Handle-Tabelle" auf MMF's. Ich würde aber pro MMF einen Record speichern der noch zusätzliche Info's zum MMF speichert. Sprich Handle, Name, Size, Owner, RTL-CS, Events usw. 
&#10

**Markus Fuchs** · 13.04.2003, 23:46

Hi Hagen!
>> Was meinst du mit HookRec ??
Ja, das kommt mal wieder davon, wenn man noch schnell einen Post schreiben will... Sorry! 
HookRec ist einfach das record meiner MMF, in dem ich das Hook Handle, die alte Window Proc usw. speichere. Das andere MMF (record) soll mein dynamisches Array enthalten (und beide sollen wiederum im Index enthalten sein, klar). Saudumm von mir geschrieben, nochmals Entschuldigung dafür.
Meine Frage ging in diese Richtung:
<pre><code>
type
THookRec = packed record
Hook: hHook;
//...
oldProc: Integer;
end;
</code>
<code>
//...
</code>
<code>
var
HookRec: ^THookRec;
</code>
<code>
// ...
</code></pre>
Wie komme ich nun auf die Variable Hook (z.B.) unter Verwendung des angelegten Index? 
Wie schütze ich den Zugriff auf das Index MMF? Auch mit CriticalSections oder lieber mit Semaphoren?
Gruß, 
Markus
PS: Ich glaube, meine Auszeit in diesem Projekt war einfach zu lange, sorry für die laufenden dummen Fragen... :

**Hagen Reddmann** · 14.04.2003, 13:04

So nun mal Klartext: Du willst in der DLL bestimmte Fenster subclassen ?! richtig ? 

Dann geht das ohne MMF's, ohne solche Tricks wie Semaphores, usw. 

Je nachdem ob du nur 1 oder 2 Fenster "hooken" oder sehr viele hooken möchtest gibt es zwei Wege.
<li>globaler Fensterhook über SetWindowHookEx() 
<li>gezieltes SubClassing über SetWindowLong(gwl_WndProc, ..) 

Normalerweise wird in der zweiten Methode alle notwendigen Daten, wie alte Fensterprocedure usw. IM Fenstser selber gespeichert. Jedes Fensterhandle hat dyn. erweiterbare Speicherbereiche. Diese werden mit SetProp() und Konsorten gelesen, geschrieben, gelöscht. Solche Prop's arbeiten Prozessübergreifend. 

Gruß Hage

**Markus Fuchs** · 14.04.2003, 13:35

>> Du willst in der DLL bestimmte Fenster subclassen ?! richtig ?
Yep, richtig.
>> Dann geht das ohne MMF's, ohne solche Tricks wie Semaphores, usw.
Ja, auch richtig. Es gibt natürlich mehrere Möglichkeiten... 
Naja, jedenfalls habe ich den Spleen bei Hooks mit MMFs zu arbeiten von Madshi. Ich dachte der Großmeister des Hookings gab mir da einen Profitip :/
Also, wieder zum "Klartext": Ich misbrauche (bis jetzt noch) SetWindowsHookEx() um in den target process zu kommen, danach subclasse ich das Fenster mit SetWindowsLong(). Mein Ziel ist es meiner injezierten DLL Informationen zukommen zu lassen (per Funktion in der DLL). Da die Funktion in der DLL, die vom Anwenderprogramm aufgerufen wird, jedoch in einem anderen (meinem) Speicherkontext läuft muss ich etwas tricksen. Also, aber diese Informationen (window handles, window classes und deren Captions) sollen in ihrer Anzahl nicht beschränkt sein, deshalb dynamisch und hier fängt mein Problem mit dem MMF an. Wichtig ist, dass ich diese Fenster nicht subclassen möchte. Ich benötige sie nur um in der gesubclassten window proc (1 Fenster!) messages abzufangen (und eben Messages mit diesen Infos als Parametern werden abgefangen und verändert)...
Ich werde mir die Sache mit SetProp() etwas näher ansehen.
Viele Grüße, 
Marku

**Hagen Reddmann** · 15.04.2003, 15:08

Dann mißbrauche doch das subclassed Fenster als Message-Handler zwischen den Prozessen. Dies ist einfacher als über MMF's zu gehen. Normalerweise sind MMF's eher statisch, d.h. jeder interessierte Prozess ist selber dafür verantwortlich Änderungen am MMF zu erkennen. Normalerweise spaltet dafür jeder Prozess einen Thread ab der auf Änderungen eines Events wartet. Diese Event wird gepulst wenn irgendeine eine Änderung am MMF gemacht hat. Im Grunde übernimmt die teilweise das OS, da man auch das Handle des MMF's statt eines Events so nutzen kann. Siehe WaitForSingleObject(). 

ABER: du willst mehr dynamic, heist gezielt Änderungen vermelden, bzw. gezielt Nachrichten absetzen. 

Überlege dir mal ob es vielleicht günstiger ist in der DLL einen kleinen TCP/IP Server zu integrieren. Dann könnte die Steuerungssoftware auch übers Netz/WEB mit der DLL kommunizieren. 
Der Aufwand ist so oder so rel. hoch, besonders um es bugfree und flüssig zum laufen zu bekommen. Mit dem TCP/IP hättest du zumindestens das Synchronisationsproblem beseitigt. RPC=remote procedure calls arbeiten ähnlich. 

Gruß Hage

**Markus Fuchs** · 15.04.2003, 15:17

>> Dann mißbrauche doch das subclassed Fenster als Message-Handler zwischen den Prozessen.
Oh nein, ich De..! Das ist wirklich ein Weg, der sogar mir hätte einfallen müssen

Danke, das wird funktionieren.
Bzgl. RPC, TCP/IP: Ich habe mich darüber schon oft schlau gemacht und bemerkt, dass viele Profis diese Methode verwenden (wenn's wirklich zur Sache geht ;-). Aber davon halte ich mich bis jetzt noch fern, ich will ja nicht gleich über's Ziel hinausschießen.
Nochmals Danke für Deine Hilfe und Deine guten Nerven

Gruß, 
Markus
PS: Das mit dem MMF werde ich trotzdem (bei gegebener Zeit) versuchen, aus reinen Lehrzwecken ;

**Hagen Reddmann** · 15.04.2003, 22:56

Oder übers COM, da MS COM ja auch prozessüberreifend arbeiten kann. Allerdings ist hier Andreas Kosch fitter als ich.
Ich weiß nicht ob bei Injekt-DLL's COM noch arbeitet.

Gruß Hage

Announcement

Größe von MMF ändern

Größe von MMF ändern

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment