Guten Abend,
ich möchte gerne auf einem PC (Windows 10) zwei Programme (in C)
miteinander kommunizieren lassen. Diese möchte ich parallel starten.
Programm A schickt was nach Programm B, welches die Daten bearbeitet und
etwas wieder zurückschickt.
Welche Möglichkeiten gibt es dazu?
Unter Linux gäbe es einen socketCAN, mit den ich virtuelle CAN
Nachrichten verschicken kann (und vom zweiten Programm empfangen kann).
Gibt es ähnliches auch unter Windows?
Was genau ist jetzt die Frage? Suchst du eine fertige
Kommunikationslibrary? Weil, eine Ethernetschnittstelle hat wohl jeder
PC, und darauf ein Socket zu öffnen dürfte aus jeder Programmiersprache
kein großes Problem sein.
Oliver
Felix schrieb:> Welche Möglichkeiten gibt es dazu?
Wie in Linux auch bieten Pipes (etc.) eine einfache
Kommunikation zwischen Prozessen. In Windows werden
dazu "named Pipes" verwendet, der Name dient der
Identifikation bzw. zum auffinden der Pipes auf
beiden Seiten.
Felix schrieb:> Welche Möglichkeiten
Ich kenne ein System, wo mehrere Programme auf eine Datenbank zugreifen,
die natürlich Mehrbenutzerfähig ist. Die Kernkomponente sieht, dass ein
neuer Eintrag erfolgt ist, führt diesen aus und schreibt Erfolg /
Mißerfolg zurück.
Eine simple Variante sind zwei Dateien, wo A zyklisch guckt, ob sich das
Datum erhöht hat, nämlich weil B reingeschrieben hat.
So ähnlich lief doch früher DOS-Software fürs FIDO-Netz in Batches ab:
Der Mailer schreibt eine Datei "fertig" und beendet sich. Der Tosser
bearbeitet die Daten, löscht die Datei und schreibt eine weitere, auf
die der nächste Prozess schaut. (Lange ist's her, bekomme ich nur noch
rudimentär erklärt).
Gerald K. schrieb:> Einfache TCP Server/Client Anwendung :
Geil, damit das simple Programm nicht mehr funktioniert, wenn man bei
der Installation den Netzwerksupport weglässt, weil der Rechner
vielleicht gar nicht im Netzwerk hängt.
Und der Benutzer wundert sich, warum das Scheiss-Programm nicht
funktioniert.
MaWin schrieb:> Geil, damit das simple Programm nicht mehr funktioniert, wenn man bei> der Installation den Netzwerksupport weglässt,
Wie genau installiert man Windows völlig ohne IP-Stack? Die
Netzwerk-Fähigkeit integriert zu haben ist gar nicht so verkehrt.
Das Suchwort ist übrigens IPC, Inter-Process Communication. Damit findet
man:
https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications
MaWin schrieb:> Gerald K. schrieb:>> Einfache TCP Server/Client Anwendung :>> Geil, damit das simple Programm nicht mehr funktioniert, wenn man bei> der Installation den Netzwerksupport weglässt, weil der Rechner> vielleicht gar nicht im Netzwerk hängt.>> Und der Benutzer wundert sich, warum das Scheiss-Programm nicht> funktioniert.
Mit welcher vorsintflutlicher Windows-Version arbeitest Du denn noch,
daß dies vorkommen könnte? Windows 95? Ja, da musste man sogar noch den
localhost-Support extra installieren.
MaWin schrieb:> Und der Benutzer wundert sich, warum das Scheiss-Programm nicht> funktioniert.
Der wird sich dann vermutlich eher wundern, warum das
Scheiss-Betriebssystem nicht funktioniert, denn vermutlich werden die
meisten Komponenten dann streiken.
MaWin schrieb:> Geil, damit das simple Programm nicht mehr funktioniert, wenn man bei> der Installation den Netzwerksupport weglässt, weil der Rechner> vielleicht gar nicht im Netzwerk hängt.> Und der Benutzer wundert sich, warum das Scheiss-Programm nicht> funktioniert.
Ohne Wissen über Netzwerke wird's schwirig. Darum sollte man auf eine
erprobte TCP/UDP Server/Client Software aufsetzen.
https://www.geeksforgeeks.org/udp-server-client-implementation-c/
Hat bei mir zwischen PC (Server) und Raspberry (Client) auf Anhieb
funktioniert.
Ansonsten wäre vielleicht noch com0com eine Möglichkeit.
Das emuliert zwei RS233-Schnittstellen, die miteinaner gekoppelt sind:
Was auf der einen Seite reingeht, geht auf der anderen wieder raus.
Ist zwar eine etwas exotische Lösung, sollte aber funktionieren.
Wühlhase schrieb:> Das emuliert zwei RS233-Schnittstellen, die miteinaner gekoppelt sind:
Warum sollte man eine Hardware-Schnittstelle simulieren wenn man eine
reine Software-Lösung braucht? Gilt auch für:
Felix schrieb:> Unter Linux gäbe es einen socketCAN
Da doch lieber TCP oder eine der anderen Möglichkeiten von Windows wie
z.B. COM+ oder named pipes. Da muss man dann auch nichts zusätzlich
installieren.
Felix schrieb:> Programm A schickt was nach Programm B, welches die Daten bearbeitet und> etwas wieder zurückschickt.
Die Frage die sich stellt ist. Auf den selben Rechner oder nicht. !!
Wenn auf den selben Rechner wäre eine schnelle Möglichkeit die
Zwischenablage. Dies ist aber keine sichere Methode. !!!
Eine sicherer Möglichkeit wäre das man 2 Verzeichnisse nutzt.
Prg 1 : schreib in das Verzeichnis die Datei : Prg 2: liest aus den
Verzeichnis. (um Fehler zu vermeiden muss man einfach die Dateigröße
abfragen).
Wenn PRG 2 was mitzuteilen hat, legt es eine Datei an mit
Datum-und-Timecode.
PRG 1 : liest einfach das Verz. aus, und wenn eine Datei drin ist, die
Größe abfragen, um zu verhindern das Prg. 2 noch schreibt. Danach die
Datei lesen, die Daten verarbeiten und dann wird die Datei gelöscht.
Das ganze geht logoweis auch anders herum. Dazu muss PRG1 dann nur in
ein Verzeichnis schreiben in den PRG 2 schreibt.
Alle anderen Verfahren sind unsicher.
Jedenfalls mache ich das so, wenn ich die Zwischenablage nicht sicher
kontrollieren kann, was meistens der Fall ist.
Gerald K. schrieb:> Man auch die USB Schnittstelle zur Rechner/Rechner Kopplung verwenden:
Es geht aber nur um einen Rechner. Und das ist auch eine ziemlich
exotische Lösung. Wenn es um mehrere Rechner geht, kann man auch einfach
Netzwerktechnologie benutzen, und damit dann eben wieder TCP oder UDP.
Wenn es unbedingt USB sein muss - 2 USB-Netzwerkkarten verbinden.
Schlaumaier schrieb:> Alle anderen Verfahren sind unsicher.
Was ist an Dateien so sicher? Auf die kann auch jedes andere Programm
zugreifen. Außerdem ist es nicht so einfach eine
Synchronisation/Nachrichtenaustausch aufzubauen. Außerdem macht es nicht
unbedingt so viel Sinn, temporäre Daten erstmal zur Festplatte zu
schicken.
Sockets mit SSL sind da doch sicherer (hier aber wenig sinnvoll), oder
wie gesagt Named pipes die mit den entsprechenden Sicherheitsattributen
versehen sind.
Niklas G. schrieb:> Was ist an Dateien so sicher? Auf die kann auch jedes andere Programm> zugreifen.
Na und. ?!?
1. Ich kann die Verschlüsseln.
2. Auf meinen eigenen Rechner ist das völlig egal.
3. Temporäre Dateien legt jedes Rotz-Prg. an. Also wieso nicht auch
meine eigenen.
4.) Wenn der TO das nur für sich selbst nutzt, kann er ja eine RAM-Disk
anlegen. Dann wird nicht einmal die Platte belastet. PAssende Free-Ware
Treiber gibt es im Netz. Habe ich sogar mal benutzt (vor SSD-Zeiten),
aber nicht für so was. ;)
Schlaumaier schrieb:> 1. Ich kann die Verschlüsseln.
Kannst du die Übertragung über Pipes, TCP o.ä. auch. Ist bei lokaler
Kommunikation halt unnötig.
Schlaumaier schrieb:> 2. Auf meinen eigenen Rechner ist das völlig egal.
Gilt für die anderen lokalen Kommunikationsmechanismen genauso. Nur dass
halt nichtmal andere Programme dran kommen.
Schlaumaier schrieb:> 3. Temporäre Dateien legt jedes Rotz-Prg. an. Also wieso nicht auch> meine eigenen.
Jedes Rotz-Programm nutzt auch Tcp, Pipes, DDE, warum nicht auch deins?
Dateien für IPC zu nutzen ist doch eher unüblich; höchstens als "Marker"
oder für PID-Dateien, was aber eher aus der Unix-Welt kommt. Und auch da
geht man dazu über D-Bus o.ä. zu verwenden.
Schlaumaier schrieb:> 4.) Wenn der TO das nur für sich selbst nutzt, kann er ja eine RAM-Disk> anlegen.
Warum einfach wenn's auch kompliziert geht, oder wie? Warum einen der
vielen dedizierten IPC-Mechanismen exakt genau dafür einsetzen wofür sie
gemacht sind, wenn man auch das Dateisystem zweckentfremden kann?
Felix schrieb:> ich möchte gerne auf einem PC (Windows 10) zwei Programme (in C)> miteinander kommunizieren lassen.
Warum eigentlich? Was soll damit erreicht werden?
Es ist ein funktionierende Verfahren.
Und mit 2 Zeilen mehr an Code hat man sogar noch LOG-Dateien ;)
Davon abgesehen sind interne Pipes viel schwerer anzusteuern als ein
normales File-Write-Read Befehle. Und was auch nicht zu verachten ist.
Es treten keinen Timing-Probleme auf. Weil es egal ist, wann ich die
Dateien ein-/auslese.
Bei den anderen Möglichkeiten muss ich regelmäßig auslesen, sonst habe
ich Timing-Probleme.
Und bei meiner Methode können die 2 Prg. sogar unabhängig von einander
laufen.
Klar gehen andere Sachen auch. Aber ich mag Methoden die Stressfrei
sind.
Walter T. schrieb:> Felix schrieb:>> ich möchte gerne auf einem PC (Windows 10) zwei Programme (in C)>> miteinander kommunizieren lassen.>> Warum eigentlich? Was soll damit erreicht werden?
(Nicht, dass hier ein typischer Fall vorliegt, bei dem "Dynamisches
Linken" anstelle "Inter-Process-Kommunikation" gefragt ist.)
Schlaumaier schrieb:> Und mit 2 Zeilen mehr an Code hat man sogar noch LOG-Dateien ;)
Die im Zweifelsfall riesig werden...
Schlaumaier schrieb:> Davon abgesehen sind interne Pipes viel schwerer anzusteuern als ein> normales File-Write-Read Befehle.
Inwiefern? Die verwenden die gleichen WriteFile/ReadFile-Befehle.
Schlaumaier schrieb:> Es treten keinen Timing-Probleme auf. Weil es egal ist, wann ich die> Dateien ein-/auslese.
Eben nicht, Dateisysteme sind nicht perfekt synchron. Wenn ein Programm
3 Operationen am Dateisystem macht, können die für andere Programme oder
sogar das selbe Programm in anderer Reihenfolge sichtbar sein. Klassisch
bei NTFS: Gelöschte Dateien erscheinen für andere Programme noch kurz
als existent!
Schlaumaier schrieb:> Bei den anderen Möglichkeiten muss ich regelmäßig auslesen, sonst habe> ich Timing-Probleme.
Nein, die anderen Lösungen haben auch Puffer bzw. fügen sich in das
asynchrone I/O von Win32-API ein.
Schlaumaier schrieb:> Und bei meiner Methode können die 2 Prg. sogar unabhängig von einander> laufen.
Können die bei anderen Methoden selbstverständlich auch. Ein Browser
läuft auch ohne dass ein Server läuft, und umgekehrt.
Schlaumaier schrieb:> Klar gehen andere Sachen auch. Aber ich mag Methoden die Stressfrei> sind.
Ein ungeeignetes Werkzeug zweckentfremden ist stressfreier als ein genau
dafür konzipiertes? Scheint mir eher ein Fall von "was der Bauer nicht
kennt".
MaWin schrieb:> Hören wir doch einfach mal, was der Erfinder von dem Windows-Zeug zum> Problem sagt:
OK. Und bei jeder neuen Windows-Version hat MS was dran geändert und ich
muss neu Programmieren.
NE DANKE.
Die Software die ich schreibe würde unter Win 3.1 genau so laufen wie
unter Win-11. Und das ohne das ich auch nur eine Programmzeile ändere.
Schlaumaier schrieb:> OK. Und bei jeder neuen Windows-Version hat MS was dran geändert und ich> muss neu Programmieren.>> NE DANKE.>> Die Software die ich schreibe würde unter Win 3.1 genau so laufen wie> unter Win-11. Und das ohne das ich auch nur eine Programmzeile ändere.
Warum sollte MS ausgerechnet an den IPC-APIs was ändern, aber an den
Filesystem-APIs nicht? Die sind beide Teil des Win32-APIs. MS ist nicht
bekannt dafür, die Win32-APIs plötzlich inkompatibel zu ändern.
Schlaumaier schrieb:> Die Software die ich schreibe würde unter Win 3.1 genau so laufen wie> unter Win-11. Und das ohne das ich auch nur eine Programmzeile ändere.
Unter Win 3.1 hat man aber ganz andere Verzeichnisse, auf die man
zugreifen kann, als Win-11. Das Timing-Verhalten der Dateisysteme hat
sich sicherlich ebenso geändert. Named Pipes gibt es z.B. seit Win2k.
Alt genug?
Schlaumaier schrieb:> Die Software die ich schreibe würde unter Win 3.1 genau so laufen wie> unter Win-11.
Mit mehreren Prozessen auf dieselbe Datei zugreifen ?
Kann mächtig in die Hose gehen.
Read-only gemountete Drives, Floppylaufwerke unter Win3.11, ein SSD was
zerschlissen wird durch ständiges schreiben, ein Antivirenprogramm was
bei jeder Dateimodifikation die Datei nach Schädlingen durchsucht und
damit das System ausbremst, eine Einstellung im sharing, die Programme
blockiert die gleichzeitig auf dieselbe Datei zugreifen, ein redirect
des Verzeichnisses auf einen anderen Rechner (NAS) mit hohem Overhead.
Was hab ich noch vergessen ?
Schlaumaier schrieb:> Und bei jeder neuen Windows-Version hat MS was dran geändert und ich> muss neu Programmieren.
Blödsinn.
Du präsentierst hier nur mal wieder Deine Inkompetenz,
Alexander/Schlaumaier/Pucki. Du findest genau das am besten, was Du
kannst, und das ist nicht viel.
Schlaumaier schrieb:> Die Software die ich schreibe würde unter Win 3.1 genau so laufen wie> unter Win-11.
DDE gab es zu Win16-Zeiten z.B. auch schon.
MaWin schrieb:> Mit mehreren Prozessen auf dieselbe Datei zugreifen ?>> Kann mächtig in die Hose gehen.
Stimmt mache ich auch nicht.
PRG1 legt die Datei an, schreibt und schließt sie. Dann hat sie eine
Größe > 0 und das erkennt PRG-2.
Prg-1 legt einfach eine neue Datei an und schreibt munter weiter.
MaWin schrieb:> ein SSD was> zerschlissen wird durch ständiges schreiben
Absoluter Schwachsinn. JEDES Windows nutzt die Auslagerungsdatei. Und
die schreibt mehr aus 1000 meiner Programmen.
MaWin schrieb:> ein Antivirenprogramm was> bei jeder Dateimodifikation die Datei nach Schädlingen durchsucht und> damit das System ausbremst
Die erkennen eine Text-Datei am Header und machen garnix.
Lerne mal wie AV-Programme funktionieren. Oder glaubst du ernsthaft die
könnten Dateien so schnell lesen und Analysieren beim Scannen. Und zwar
um den Faktor 100 Gegenüber ein Dateikopieren. löl.
Und mir dann was von Schlangenöl erzählen. Du musst dich mal mit die
selbst einigen, was für eine Meinung du vertrittst.
Davon abgesehen habe ich nur den TO eine funktionsfähige Lösung
angeboten. Ob er die Nutzt oder eine aus den MS-Link ist mir absolut
egal.
Schlaumaier schrieb:> PRG1 legt die Datei an, schreibt und schließt sie. Dann hat sie eine> Größe > 0 und das erkennt PRG-2.
Versuch das mal mit NTFS statt FAT.
Schlaumaier schrieb:> Absoluter Schwachsinn. JEDES Windows nutzt die Auslagerungsdatei. Und> die schreibt mehr aus 1000 meiner Programmen.
Und wer sagt, dass der TO so wenige Daten austauschen will wie Dein
Zeug?
Schlaumaier schrieb:> Davon abgesehen habe ich nur den TO eine funktionsfähige Lösung> angeboten.
Eine schlechte, in Deiner üblichen Dunning-Kruger-Überheblichkeit
garniert mit "Alle anderen Verfahren sind unsicher".
Schlaumaier schrieb:> Ob er die Nutzt oder eine aus den MS-Link ist mir absolut egal.
Sobald deutlich wird, dass Dein Vorschlag Mist ist, kommt immer etwas
wie "Ist mir egal".
Warum äusserst Du Dich dann überhaupt? Dass Du von nichts wirklich
Ahnung hast, ist eh bekannt.
Schlaumaier schrieb:> Die erkennen eine Text-Datei am Header und machen garnix.
Was für einen Header haben Textdateien? Was wenn man größere Mengen
Binärdaten austauscht? Einfach ein bisschen ACII-Text davor schreiben?
Mann, warum kommen Malware-Autoren nicht auf solche Ideen um ihren Code
zu verstecken...
Schlaumaier schrieb:> Oder glaubst du ernsthaft die> könnten Dateien so schnell lesen und Analysieren beim Scannen. Und zwar> um den Faktor 100 Gegenüber ein Dateikopieren. löl.
AV-Programme scannen während des Zugriffs, d.h. sie verlangsamen jeden
normalen Zugriff. Kann man super am Windows Defender sehen.
Schlaumaier schrieb:> Ob er die Nutzt oder eine aus den MS-Link ist mir absolut> egal.
Warum verteidigst du die dann wie das Beste seit geschnitten Brot? Warum
möchtest du offensichtliche Anfänger desinformieren?
Bei Pipes & Co kann man in dem Moment, in der eine Nachricht abgeschickt
wurde, darauf reagieren, und wenn man möchte, den Thread/Programm bis
dahin blockieren (WaitForMultipleObjects), d.h. man verschwendet nicht
unnötig Rechenzeit.
Wenn man auf das Anlegen von Dateien warten möchte, muss man regelmäßig
prüfen (busy wait). Das hat eine längere Reaktionszeit UND wacht ständig
den Prozess(or) auf (schlecht für Notebooks). Es sei denn man verwendet
Directory Change Notifications, was die Sache aber noch komplizierter
macht.
Ich habe Alternative: Zur Kommunikation zwischen 2 Programmen können wir
einfach die windows Registry nutzen. Einfach einen Registryzweig
festlegen wo die beiden Prg A+B Status und Daten auszutauschen können.
That's all. Zum Testen kann man einen Wert mit regedit.exe ändern, und
schauen ob das Programm auf diesen Wert korrekt reagiert.
Deafie schrieb:> Ich habe Alternative: Zur Kommunikation zwischen 2 Programmen können wir> einfach die windows Registry nutzen.
Das klingt nach der russischen Variante.
Ob Dein Pfusch den Felix (Gast) nach knapp einem Jahr noch
interessiert, bezweifele ich.
Ich kenne Anwendungen, die eine Mehrbenutzer-Datenbank wie interbase
bzw. firebird nutzen, aufwendig. Da hängen mehrere Anwendungen drauf,
wenn sie geändert wird, bekommen es alle mit.
Die einfachere Variante ist eine (Text-)Datei, auf die beide Seiten
zugreifen und das Änderungsdatum überwachen. Da muß eine gegenseitige
Sperre eingebaut werden, dass nicht beide zeitgleich schreiben und die
Daten inkonsistent werden.
DerEinzigeBernd schrieb:> Eine beeindruckend bescheuerte Idee.
Du warst schneller :-)
