Windows CE Interprozess Kommunikation

ich hab das Windows CE Gerät momentan nicht da aber du hast recht, die 
Firewall geschichte könnte ich auch in der Debug Simulation starten.

Habe ich denn recht das es mit Messagequeues nicht geht sondern bei so 
einer Prozesskommunikation nur noch die Sockets bleiben? Oder gibt es 
eine alternative und welche Vor-/Nachteile hat dies?

Bei der Überlegung des Problems kamen mir auch noch ein paar Fragen.

Wo werden Globale Variablen gespeichert? Auch wenn sie Global heißen 
sind sie doch nur für die Prozesse verfügbar und ein anderes .exe 
Programm kann nicht auf die Globalenvariablen eines anderen Zugreifen, 
oder?

warum müssen es denn 2 Prozesse sein? Durch das IPC ist das ganze doch 
viel komplexer.

Unter windows könnte man das ganze aber über die normale Messageque 
machen. Sonst gibt es auch noch Shared Memory und eventuell kommt auch 
eine Pipe in frage.

Die Pipe würde sich vermutlich am einfachsten machen, weiss aber nicht 
ob sie in WindowsCE vorhanden ist.

Es müssen 2 Programme werden weil sich ein Programm mit der 
Datenbeschaffung und das andere mit der Verarbeitung befasst. Das 
Programm der Datenbeschaffung kann sich später auch ändern bzw. wird 
durch ein anderes ersetzt.

Du sagst das in Windows dies über normale Messageques machbar ist. 
Meinst du damit die Taskkommunikation oder wirklich die Kommunikation 
zwischen 2 Prozessen/Programmen. Wenn ja, wie geht dies?

Josef schrieb:
> Es müssen 2 Programme werden weil sich ein Programm mit der
> Datenbeschaffung und das andere mit der Verarbeitung befasst. Das
> Programm der Datenbeschaffung kann sich später auch ändern bzw. wird
> durch ein anderes ersetzt.

was ist denn das für ein Grund?

1. ein programm kann auch mehrere Dinge gleichzeitig machen
   (z.b. mit Threads)
2. Ist doch egal ob du nun das eine Programm austauschst oder nicht, 
warum
   sollte dann der Teil mit der Varbeitung nicht mit ausgetauscht 
werden?

dafür hättest du ein Programm was wesentlich besser zur Testen ist. 
Sonst passiert es dir früher oder später das beide Programm nicht 
zusammenpassen weil du etwas am Datenaustausch geändert hast.

Im Windows gibt es noch ein globale Message, darüber erfolgt z.b. die 
Benachrichtung wenn z.b. Windows in den Schlafmodus wechseln will, in 
diesen kann man auch Daten austauschen. Ob das sinnvoll ist hängt aber 
von der Menge und häufigkeit der Daten ab.

Ich möchte dies aber in 2 Programmen machen, da sich 1. später jemand 
anderes mit dem einen Teil beschäftigen soll und 2. ich später wirklich 
nur ein Programm anpassen/austauschen möchte ohne das andere anzupassen.

Klar das die Schnittstelle für den Datenaustausch fest geregelt sein 
muss damit es zu keinen Problemen führt.

Die Geschichte mit den globalen Messages klingt nicht Sinnvoll. Es 
werden sicher im sekunden Takt um die 256 Bytes abgefragt. Anscheinend 
könnte es am besten per Socketverbindung passieren. Oder einer 
"virtuellen Datei" aber da weiß ich noch nicht wie ich eine Dateianlege 
die nicht aufs Flashlaufwerk geschrieben werden soll sondern nur im RAM 
zur Verfügung steht.

In welcher Weise könnte man denn das ganze als DLL nutzen? Bei der DLL 
müsste ich dann eine Funktion für den Datenaustausch implementieren und 
das eine Programm ruft diese Funktion dann auf? Eventuell wäre das noch 
eine alternative. Dabei müsste ich aber noch eine Initfunktion 
erstellen, die in dem zweiten Programm immer aufgerufen wird.

Nachtrag:
DLL's sind auch kein Problem wenn die DLL in C/C++ geschrieben wird und 
das andere Programm in .net VB?

Zwie Blum schrieb:
> @Peter: "Teile und herrsche". Weil das unter Windows sooo schwierig ist,
> sind die Programme ja auch solche Wasserköpfe.

ja aber wenn der code für eine Seriellen Schnittstelle kleiner ist, also 
der code für IPC dann fragt man sich schon nach dem sinn.
Dazu kommen dann noch solche Probleme wie, wer startet denn das 
2.Programm? wer beendet es wieder. Was passiert wenn das 
auswerteprogramm zwei mal gestartet wird?
sinvollerweise müsste man den seriellen Teil in einen Dienst auslagern 
der vom System gestartet wird. (keine ahnung ob das bei CE auch geht).

@Josef
Aber eine DLL ist hat erstmal wenig mit IPC zu tun. Wenn du es mit einer 
DLL machen willst dann geht es auch ohne IPC. eine C (nicht C++) dll 
kannst du ohne PRobleme von .net ansprechen.

vielen dank für eure diskussionsbeiträge.

Das die ganzen Fehler abgefangen werden müssen ist mir schon klar und 
ist auch ein großer Aufwand, trotzdem soll der Teil ausgelagert werden.

Meine Frage bezüglich der DLL Geschichte ist noch: Kann ich die DLL auf 
dem Gerät tauschen und mit einer neuen DLL die z.B. dann über TCP/IP 
arbeitet ersetzen und das Programm läuft weiter? Also wird die DLL zur 
Laufzeit eingebunden oder beim Kompilieren?

Beide Programme werden im Autostart gestartet, das sollte Windows CE 
doch noch schaffen....hoffentlich.

Das Programm, welches im moment die Serielle Schnittstelle bedient muss 
später auch Realtimefähig sein. Das andere Programm wird in .net 
Programmiert und ist somit schon nicht mehr Echtzeitfähig. Das ist auch 
ein Grund, weswegen es 2 Programme sein müssen.

Einfacher für das spätere Handling wird somit eine IPC anstatt die DLL 
Variante.

Josef schrieb:
> Meine Frage bezüglich der DLL Geschichte ist noch: Kann ich die DLL auf
> dem Gerät tauschen und mit einer neuen DLL die z.B. dann über TCP/IP
> arbeitet ersetzen und das Programm läuft weiter? Also wird die DLL zur
> Laufzeit eingebunden oder beim Kompilieren?
das kannst du machen wie du willst. Aber wenn du sie zur laufzeit 
tauschen willst dann musst du im program die möglichkeit vorsehen die 
dll zu entladen. Ob es aus .net geht weiss ich nicht. Windows bietet es 
aber grundsätzlich an.

> Das Programm, welches im moment die Serielle Schnittstelle bedient muss
> später auch Realtimefähig sein.
nur mal aus neugier - warum?
Geht es dir nur darum um keine Daten zu verlieren oder müssen die daten 
in einer gewissen zeit angenommen und bestätigt werden?

ok. die dll geschichte klingt doch nicht so simpel wie gedacht. ich 
hätte erwartet das ich sie 1:1 an die Stelle kopiere und alles gut ist.

Das Programm welches die Serielle Schnittstelle bedient wird später 
durch ein Programm ersetzt welches Echtzeitfähig arbeiten muss. Es 
werden dort Programme mit genauem Zeitverhalten abgearbeitet. Bei der 
Seriellenschnittstelle lassen sich auch Timeouts definieren, diese 
müssen auch exakt arbeiten. Ich weiß nicht 100% ob sie das bei .net 
tuen. Ich weiß zwar auch nicht ob sie das in C/C++ machen aber dort gehe 
ich einfach davon aus.

Josef schrieb:
> Es
> werden dort Programme mit genauem Zeitverhalten abgearbeitet. Bei der
> Seriellenschnittstelle lassen sich auch Timeouts definieren, diese
> müssen auch exakt arbeiten.

wenn du sich bei der Schnittelle einrichtest dann ist es egal ob du es 
von .net oder c++ machst, es wird jeweil dem Betriebssystem übergeben. 
Um welche genaue zeitverhalten geht es denn? Millisekunden, Sekunden? 
.net ist erstmal nicht wirklich langsamer als mit c geschrieben 
programme. Und wenn es wirklich nur um ein paar byte gehen die von der 
Schnittstelle kommen wird es kein unterschied machen.
Meist sind sogar schlecht geschriebene C++ Programme langsamer als 
welche in C#, weil viele gar nicht bewusst ist das Objekte kopiert 
werden.

Es geht dabei um Millisekunden. Betriebssystem ist Windows CE 6.0 R2.

Windows garantiert ein 1ms Taskzyklus mit einem Glitch von max. ca. 
100µs. Bei .net Programmen räumt Windows zwischendurch den Cache auf und 
zerstört damit die Echtzeit, bei C/C++ Programmen ist dies aber nicht 
der Fall und bleibt weiterhin im 1ms Takt.

Die größe der Datenmenge wird sich im Bereich von 256Bytes abspielen, 
also nicht wenig aber auch keine riesen Mengen.

Das Echzeitfähigeprogramm muss später mit genauen Taskzeiten arbeiten 
und da darf es keine Toleranz von mehren ms geben. Einzelne Tasks werden 
mit 10ms oder 100ms arbeiten.

"Meist sind sogar schlecht geschriebene C++ Programme langsamer als
welche in C#..." gibt es da auch mehr Informationen drüber? Was zeichnet 
denn ein schlecht geschriebenes C++ Programm aus? Gibt es 
Funktionen/Algorithmen/Methoden/Arbeitsweisen die man defintiv vermeiden 
sollte?

Josef schrieb:
> gibt es da auch mehr Informationen drüber? Was zeichnet
> denn ein schlecht geschriebenes C++ Programm aus? Gibt es
> Funktionen/Algorithmen/Methoden/Arbeitsweisen die man defintiv vermeiden
> sollte?

class data
{
   char p[100];
};

langsam
void test1( const data d ) { /* mach was mit d /* };


schneller
void test2( const data& d ) { /* mach was /* };


das sind halt die Feinheiten.

Ich war auch immer der Meinung das Java/#c langsam ist, aber nach ein 
paar Tests hat sich gezeigt das kaum Anwendungen gibt wo man es 
wirklicht merkt. Meist kommt die langsamkeit nicht von der Sprache 
sondern sondern von einer falschen/ungünstigen Umsetzung der Aufgabe.

Also der Aufruf per Namensreferenz ist schneller als ein direkter 
zugriff auf eine variable/klasse?

gibts dafür eine sinnvolle erklärung? kann der compilier referenzen 
sinnvoll zwischenspeichern und bei wenigen somit schneller arbeiten und 
bei mehreren macht es kein unterschied mehr?

ahja klar. die namensreferenz ist ja wie ein pointer auf die variable 
und somit erstellt er die variable nicht neu sondern kann direkt 
reinschreiben.
ich bin kein großer freund von diesen referenzen weil mir genau die 
information fehlt, dass ich direkt immer in der gleichen variable 
arbeite.

somit ist das oben aufgeführte beispiel doch auch eine komplett andere 
sache. in dem einen programm arbeite ich mit der beim aufruf erstellten 
kopie der variable und in der anderen arbeite ich in der aktuellen 
variable die sich auch zur laufzeit (bei mehreren tasks) ändern könnte.

also bei der referenz geschichte muss man auch gut aufpassen was man 
macht.

Verhindert das const beim Funktionsparameter das die Funktion die 
Variable beschreiben kann? Aber es verhindert nicht, dass die Variable 
in einer anderen Task manipuliert wird, oder?

Vielen Dank für eure ganzen Tips.

Ich hab mir dieses Buch bestellte: 
http://www.amazon.de/Programming-Windows%C2%AE-Developer-Reference-PRO-Developer/dp/0735624178/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1276070917&sr=8-1

Dauert aber noch bis es ankommt.

Ich habe vorher nut mit Pointer gearbeitet und nicht mit Referenzen.

CreateMsgQueue gibt mir jeweils den gleichen Handler zurück wenn ich den 
gleichen Namen in 2 Programmen aufrufe? Das wäre ja klasse.

So wie es aussieht wirds nun die Socketverbindung. Im moment mit einer 
Localenverbidnung und später könnte diese Leicht durch eine externe 
socket verbindung ersetzt werden. Diese Variante klang auch sehr 
interessant. Wobei mich bei der Socketverbindung der Overhead etwas 
stört.

Sachen wie Semaphoren/Mutex und andere Spermechanismen sind mir schon 
ein Begriff und habe ich in kleineren Programmen auf einem Unixsystem 
genutzt, doch die Windowswelt ist neu für mich.