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.
Einfache TCP Server/Client Anwendung : https://www.geeksforgeeks.org/tcp-server-client-implementation-in-c/ Das Beispiel kann für die eigenen Anförderungen modifizieren und erweitern. Vorteil, man geht von einem funktionierenden Beispiel aus.
:
Bearbeitet durch User
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.
Niklas G. schrieb: > Wie genau installiert man Windows völlig ohne IP-Stack? https://teckangaroo-com.cdn.ampproject.org/v/s/teckangaroo.com/tcpip-services-how-to-enable-tcp-ip-services-on-windows-10/?amp=1&usqp=mq331AQKKAFQArABIIACAw%3D%3D&_js_v=0.1#2
MaWin schrieb: > Niklas G. schrieb: > >> Wie genau installiert man Windows völlig ohne IP-Stack? > > https://teckangaroo-com.cdn.ampproject.org/v/s/teckangaroo.com/tcpip-services-how-to-enable-tcp-ip-services-on-windows-10/?amp=1&usqp=mq331AQKKAFQArABIIACAw%3D%3D&_js_v=0.1#2 Das deaktiviert nicht den IP-Stack, sondern nur eine Hand voll Applikatonsprotokolle: > Echo, Discard, Daytime, Character Generator, and Quota of the day Es benutzen so viele Programme Ip für lokale Kommunikation, da kann man nicht viel mit falsch machen...
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.
TCP/UDP mit localhost, named pipes, mqtt, shared memory
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.
Man auch die USB Schnittstelle zur Rechner/Rechner Kopplung verwenden: https://praxistipps.chip.de/zwei-computer-per-usb-verbinden-so-gehts_33035
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: > Alle anderen Verfahren sind unsicher. Welche "alle anderen Verfahren" denn? Bzw. was soll an Deinem Verfahren so sicher sein?
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?
:
Bearbeitet durch User
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".
:
Bearbeitet durch User
Walter T. schrieb: > Warum eigentlich? Was soll damit erreicht werden? Hier ist auch wirklich wieder jedes Klischee des Forenteilnehmers unterwegs, den so kennen. Hören wir doch einfach mal, was der Erfinder von dem Windows-Zeug zum Problem sagt: https://docs.microsoft.com/de-de/windows/win32/ipc/interprocess-communications
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?
:
Bearbeitet durch User
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: > Zur Kommunikation zwischen 2 Programmen können wir > einfach die windows Registry nutzen. Eine beeindruckend bescheuerte Idee.
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 :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.