- Die Klasse hält (privat) die ID und das Handle zum DispatcherThread
- Dadurch kann mit PostThreadMessage() der Dispatcher kommandiert werden
- Der Disptacher kümmert sich intern um die Geschäfte mit allen anderen
  Threads, inklusive deren Steuerung, Beendigung etc pp.
- Der Dispatcher reicht einen Pointer zu der Liste mit den Rechnern an
  jeden Thread weiter, der was tun soll (GUI, MAC, Workers). So wissen
  diese ab dem Start, wo sie gucken können, wenn sie in der Liste stöbern
  müssen. Dieser Pointer muß von den Threads als Readonly behandelt werden.
- Update der Daten kommt sowieso nur von den Workers! Diese müssen ein
  Update anmelden, indem sie per PostMessage den Pointer zu den Daten für
  die eingeloggten User sowie den Index des Records zurückgeben.
- Der Dispatcher macht das Update, sobald keiner der Threads mehr gerade
  diesen Record liest! Will heißen, NUR der Dispatcher bestimmt, wann er
  die Records tauscht ... weshalb es NICHT ERLAUBT ist, daß ein anderer
  Thread (zB Hauptthread) die Adresse des Records zwischenspeichert!
- Der vorige Punkt sollte klarer werden, sobald man weiß, daß der GUI-
  Thread nur per PostThreadMessage() vom Dispatcher den Befehl für ein
  Update erhalten kann.
- Critical Sections werden gebraucht für:
  + Update der Liste mit den Rechnern im Netzwerk
  + Schreiben/Lesen der Daten welcher User wo eingeloggt ist.

Ich hoffe, daß ich dadurch, daß die Verwaltung der anderen Threads nur
noch dem Dispatcher obliegt, es schaffen kann die Konflikte auszuräumen.
Unter anderem sollte es dann möglich sein auf einige (vielleicht sogar
mehr als geplant) Critical Sections zu verzichten, da die Abarbeitung
ja allein durch die Benutzung von Message-Loops in den Threads einger-
maßen serialisiert worden sein sollte.