Announcement

**Hagen Reddmann** · 15.11.2002, 00:20

Das heist Du hast eine Interprocesskomunikation �ber MMF's gemacht, gut. Was dir noch fehlt w�ren das Locking des MMF's und das Eventhandling. Neben dem MMF ben�tigst Du also noch global g�ltige Semaphore f�r's Locking und globale Event's, SetEvent(), CreateEvent() f�r die Benachrichtigungen. Die DLL erzeugt also ein benamtes globales Event, mit CreateEvent() zum MMF. Die Processes die nun die Daten aus dem MMF lesen sollen m�ssen einen Thread erzeugen der auf das Globale MMF-Event wartet. 
Der Thread wiederum k�nnte per Synchronization eine Callback im Context des Mainthreads deines Processes aufrufen. 
Allerdings rate ich von dieser Synchronization ab, falls es sich vermeiden l�sst, da z.B. mit Delphi's TThread's einigie schwerwiegende �nderung ab D6 vorgenommen wurden. 

Gru� Hage

**Markus Fuchs** · 15.11.2002, 01:12

Hi Hagen!
Danke f�r die klasse Antwort! 
Ich stelle mir nun nat�rlich die Frage, warum ich nicht gleich mit RegisterWindowMessage eine bzw. zwei globale Messages registriere (OperationSucceeded, OperationFailed) und diese dann von der DLL (aus dem fremden Kontext) zu meiner "MainForm" schicke. Klar, ich habe nach einer L�sung mir einer Callback procedure gefragt aber diese Frage ist nochmal zum Verst�ndnis und um die bestm�gliche L�sung in meine DLL implementieren zu k�nnen.
Viele Gr��e, 
Marku

**Hagen Reddmann** · 15.11.2002, 01:27

Weil der Weg �ber Events auch ohne Fenster funktioniert. Angenommen es soll ein Service Processs auf das MMF reagieren, dann hat der Service keinerlei GUI, kann nicht auf's User Interface zugreifen und somit existieren keienrlei Fensterhandles. 

Die Frage ist ganz einfach: soll der Aufwand nur einmal betrieben werden und Fensterhandles sind garantiert vorhanden, oder soll ein solches Processsharing auch in Zukunft f�r andere Dinge in eine komfortable Komponente ausgelagert werden. 
Nat�rlich ist der Weg �ber Messages einfacher, man mu� dann aber nicht unbedingt mit RegisterWindowMessage() arbeiten. 

Gru� Hage

**Markus Fuchs** · 15.11.2002, 14:34

Dankesch�n Hagen! 
Ich werde versuchen das in naher Zukunft umzusetzen (ohne TThread, pure Win32 API

).
Gru�, 
Marku

**Markus Fuchs** · 16.11.2002, 02:02

Ich habe gehofft, dass ich es alleine schaffe... Momentan sieht es aber eher nicht danach aus. 
Muss ich bei SetEvent und/oder CreateThread mit den SECURITY_ATTRIBUTES arbeiten? Falls ja, k�nnte mir das jemand n�her bringen? 
Ich arbeite mit Win2000.
Viele Gr��e, 
Markus<p&gt

**Markus Fuchs** · 16.11.2002, 02:07

Oh, die Fehlerbeschreibung fehlt: 
CreateEvent gibt ein korrektes Handle zur�ck. Der Thread in der DLL "steht". Ich "feuere" das Event aus dem fremden Prozesskontext, mein WaitForSingleObject scheint das aber nicht zu interessieren :

**Hagen Reddmann** · 16.11.2002, 13:34

Hi

Im dr MMF-DLL werden mit CreateFileMapping(.., 'MyMMF1234567') und mit CreateEvent(nil, False, False, 'MyMMFEvent1234567'); die beiden Handles erzeugt. Sie m�ssen einen Namen haben damit sie global verf�gbar sind. 

Dein Thread sollte so aussehen:

<pre>

var
FinishEvent: THandle = 0;
ThreadHandle: THandle = 0; 

procedure DoMMFChanged;
var
MMF: THandle;
MMFData: Pointer;
begin
MMF := OpenFileMapping(FILE_MAP_ALL_ACCESS, False, 'MyMMF1234567');
if MMF <> 0 then
begin
MMFData := MapViewOfFile(MMF, FILE_MAP_ALL_ACCESS, 0, 0, 0);
if MMFData <> nil then
begin
// Access to MMFData

UnmapViewOfFile(MMFData);
end;
CloseHandle(MMF);
end;
end; 

function MyThreadProc(Param: Pointer): DWord; stdcall;
var
Events: array[0..1] of THandle;
begin
FinishEvent := CreateEvent(nil, False, False, nil);
Events[0] := FinishEvent;
Events[1] := OpenEvent(SYNCHRONIZE, False, 'MyMMFEvent1234567');
if Events[1] <> 0 then
repeat
case WaitForMultipleObjects(2, @Events, False, INFINITE) of
WAIT_OBJECT_0: Break; // Thread soll terminieren
WAIT_OBJECT_0 +1: DoMMFChanged;
else
Break; // Abnormal termination
end;
until False;
CloseHandle(FinishEvent);
CloseHandle(ThreadHandle);
FinishEvent := 0;
ThreadHandle := 0;
end; 

function StartThread: Boolean;
var
ThreadID: DWord;
begin
if ThreadHandle = 0 then
ThreadHandle := CreateThread(nil, 0, @MyThreadProc, nil, 0, ThreadID);
Result := ThreadHandle <> 0;
end; 

function StopThread: Boolean;
begin
Result := FinishEvent <> 0;
if Result then
begin
SetEvent(FinishEvent);
// evntl.
WaitForSingleObject(ThreadHandle, INFINITE);
// oder
MsgWaitForSingleObject();
end;
end;

</pre>

Gru� Hage

**Hagen Reddmann** · 16.11.2002, 13:37

Jetzt m�sste noch in DoMMFChanged() per Locking das MMF gesch�tzt werden. 
Beachte das DoMMFChanged() im Context unseres Threads ausgef�hrt wird. Meistens ist dies sinnvoll da dadurch ein Hintergrundprocessing m�glich wird. Ich mache es immer so das ich bei �nderungen eine globale Variable MMFChanged := True setze. In meiner Application polle ich MMFChanged in der Messageschleife, oder per Timer, oder per ApplicationEvents.OnIdle(); 
Oder der Thread setzt einfach MMFChanged := True, und die Application die MMFChanged pollt ruft DoMMFChanged() auf um die daten im Mainthread zu lesen. 
Je nachdem was man erreichen m�chte.

Gru� Hage

**Markus Fuchs** · 16.11.2002, 17:53

Danke! 
Es scheint zu funktionieren!

Wer kein OpenEvent() benutzt, muss sich eben nicht wundern, wenn die verschiedenen Prozesse nicht auf die Events reagieren...
Viele Gr��e, 
Marku

**Hagen Reddmann** · 16.11.2002, 22:05

�brigens Markus, der Thread mu� auch nicht unbedingt sein. Das ge�ffnete Event h�lt solange seinen Status bis es abgefragt wird. D.h. man kann auch den Thread verzichten, und mit WaitForSingleObject(Event, 10) innerhalb des Haupthreades pollen. Es h�ngt halt davon ab was man haben m�chte. Soll das ge�nderte MMF nicht im Hintergrund parallel im Process bearbeitet werden, dann kann man auch auf den Thread verzichten und gleich das Event pollen.

Gru� Hage

**Markus Fuchs** · 20.11.2002, 19:06

Hi Hagen!
Kaum zu glauben, heute habe ich das 1. Mal wieder Zeit zu antworten

Nochmals Danke f�r Deinen nachtr�glichen Tip! 
Ich habe mich entschieden jetzt erstmal alles soweit fertig zu machen wie ich es angefangen habe. Sp�ter werde ich dann Tests machen wie es ohne den Thread l�uft. 
Ich bin momentan eben nur am �berlegen wie sich die DLL verh�lt bzw. verhalten sollte, wenn zwei Applicationen gleichzeitig auf sie zugreifen. Ich glaube das wird die n�chste Nuss, die es zu knacken gilt...
So long. Gru�, 
Marku

**Hagen Reddmann** · 23.11.2002, 13:46

Betrachte die DLL wie jeden anderen Client der auf das MMF zugreifen will. Deshalb das globale Semaphore-Handle. Am besten du codest dieses Locking in der DLL und exportierst diese Funktion. Alle anderen Client's der DLL, und das k�nnen sehr viele sein, m�ssen dann diese Funktion nutzen bevor sie auf das MMF zugreifen. 
Wichtig ist dabei folgendes begriffen zu haben: 
Ein globaler Hook sitzt in einer DLL damit Windows bei der Installation des Hook's diese DLL automatische in jeden laufenden und vom Hook betroffenen Prozess laden kann. D.h. angenommen 10 Prozesse laufen inkulsive Deiner Anwendung. Diese l�dt die DLL und die DLL installiert ihren systemweiten Hook. In diesem Moment, oder aber sp�testens wenn der Hook in einem anderen Prozess greifen muss, wird die die DLL zus�tzlich in die anderen Prozesse geladen. Damit existieren in unserem Falle 10 eigene DLL-Datensegment im System. ALLE Zugriffe auf's MMF, egal aus welchem Prozesscontext heraus, m�ssen nun geblockt ablaufen. So wie du das globale Event erzeugt hast sollte nun eine globale Semaphore bei der Installation des Hook's erzeugt werden. In der exportierten Locking-Funktion wird nun mit OpenSemaphore diese Semaphore ge�ffent. Eine andere M�glichkeit ist es eine globale Variable anzulegen in der das Semaphorehandle gespeichert wird. Da die DLL zu jedem Prozerss ihr eigenes Datensegemnt zugeordnet bekommt, w�rde diese globale variable also 10 mal im System vorkommen, und jeder process sein eigenes Semaphorehandle besitzen. Wird nun diese Var als Threadvar deklariert w�re das Locking sogar innerhalb der Prozesse Threadsafe. 
Den Code musst du aber nur einmal in der DLL coden. 
ich w�rde auch mit den Event's so verfahren, und die Pollingfunktion in die DLL verlagern. 

gru� Hage

**Markus Fuchs** · 13.12.2002, 23:00

Und wieder mal kr�ftig dazugelernt! 
Nach langem und ausgiebigem Testen kann ich nun behaupten, dass die Variante ohne Thread definitiv die bessere ist in meinem Fall. Die DLL l�uft wie geschmiert. ;-)
Nochmals vielen herzlichen Dank, Hagen!
Gru�, 
Marku

Announcement

DLL in fremden Kontext; Callback procedure

DLL in fremden Kontext; Callback procedure

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment