erst einmal Gratulation - MWconn ist wirklich eine super Sache.
Wir entwickeln aktuell eine verteilte Anwendung. Die (MWconn spezifischen) Anforderungen:
a.) Die "Aussenstelle" muss sich bei bestimmten Vorgängen (Ereignis, Zeit) in der Zentrale melden
b.) Die "Zentrale" muss jederzeit in der Lage sein, eine "Aussenstelle" anzufragen
c.) Das System muss sowohl mit fixer Internetverbindung (kein Problem) als auch mit "temprärer" bzw. Dialup-Verbindung laufen
d.) Die "Aussenstellen" müssen "leistbar" bleiben.
Der erste Gedanke war ein intelligentes "Serielles Modem".
So Dinger gibt's - kosten richtig Geld und können dann
a.) Zeitgesteuert
b.) Ereignisgesteuert (es ist was passiert bzw. es ist lange nix passiert)
c.) Gepollt (SMS bzw. call)
die Verbindung aufbauen.
Wenn ich von "richtig Geld" rede, dann meine ich um die 800 Teuros rum.
Dafür gibt's aber auch 2 Barebones - bzw. ich krieg um den halben Preis einen Barebone.
Auf / mit dem kann ich dann machen was ich will - bin also weit flexibler

Nun zum Kern der Sache. Ich habe Dein Teil gestern irgendwie beim rumsuchen gefunden, habs mir runtergeladen und installiert.
HUAWEI E220 - und das Dashboard des Providers haten PC UI Treiber nicht installiert.
Damit gings dann "nur halb" (SMS Empfang ging - aber Verbindung war keine möglich weil das Modem ja belegt war).
Dank der (deiner) super Doku war der Fehler gleich lokalisiert.
Neues Dashboard gezogen - kurz ruminstalliert - PC UI wurde installiert - und MWconn machte sofort was es sollte -- WAR NUR BEGEISTERT!!!
Die Fileschnittstelle wäre eine Option für unsere Anwendung - ABER es ist einfach schöner, wenn man direkt (aus der eigenen Applikation) mit dem Teil reden kann.
In der Doku habe ich dann die Geschichte mit dem Shared Memory gefunden.
Folgende Sachen sind mir aufgefallen:
Die Schnittstelle (um Infos zu bekommen) ist für reines Polling (Beispiel mit Timer) ausgelegt.
Weiters geht versucht das Beispiel WRITE Access zu bekommen - wenn das nicht geht wird READ Access versucht.
Ich gehe mal leise davon aus, dass der WRITE Zugriff immer dann nicht geht, wenn MWconn gerade im Memory rumschreibt.
Was mir hier fehlt ist irgendeine Synchronisation (Mutex, Semaphore, Event oder so).
Gibt es so was nicht? Oder wird es nur im Beispiel nicht erwähnt?
Mein Wunsch / Vorschlag - wie wäre es mit Message Kommunikation?
Ein üblicher Pattern dazu ist REGISTER / WM_COPYDATA.
Mal kurz erklärt:
Der "Server" (MWconn) registriert zwei Messages (RegisterWindowsMessage) und hört eine davon dann ab.
--ich nenne die mal MSG_REGISTER_CLIENT und MSG_NOTIFY_CLIENT
Der Client (also z.B. meine Anwendung) registriert die selben Messages.
Bei Start postet der Client dann MSG_REGISTER_CLIENT mit seinem WindowHandle als Parameter. Als zweiter Parameter dann noch, WAS den Client interessiert (optional) - MWconn merkt sich den Handle und reagiert mit MSG_NOTIY_CLIENT und dem Fensterhandle sowie "OK" (irgend ein nummerischer Wert halt) als Ergebnis.
Wenn WMconn was neues hat (aktuell wird process_counter inkrementiert) sendet es eine WM_COPYDATA Nachricht an die registrierten Clients.
Dabei wird einfach der "hintere Teil" (ohne Command) der aktuellen Struktur an den Client übergeben.
Wenn der Client was von MWconn will geht er den selben Weg - er sendet WM_COPYDATA mit dem Command als Daten.
MWconn kann sofort (return value) OK oder "falsches Command" melden.
Der Vorteil so einer Implementierung:
a.) Message driven -- nicht sinnlos rumpollen, wenn eh grad nix los ist
b.) Kein manuelles Synchronisieren (der oben erwähnte nicht gefundene Mutex

c.) Super erweiterbar um z.B. eine "SMS Erhalten" "Verbindung hergestellt" usw. Info an den Client zu senden.
d.) Auch leicht erweiterbar im Sinne von "neue Funktionalität".
-- hier fällt mir das eine "Missing Feature" ein - SMS Senden via "API" (habe in den Commands beim Beispiel nix dafür gefunden).
CONCLUSIO (ich weiß, dass ich ein Vielschreiber bin

a.) Gibt es bei der aktuellen Shared Memory Implementation einen Synchronisierungsmechanismus (Mutex, Semaphore, Event)?
b.) Vorschlag / Wunsch: statt (zusätzlich zu) Shared Memory eine Message orientierte Kommunikation ermöglichen
c.) Wunsch: SMS Senden via API (u.U. habe ich da was übersehen)
Nochmal Gratulation zu der wirklich gelungenen Software
lg
Manfred