4. Zwischen Processen Kommunizieren

Zwischen Processen Kommunizieren

  • ?

    Gibt es im reinem C/C++ sowas ähnliches wie Interprocess Communication System? Oder nur mit hilfe einer Libary die in einer anderen Sprache geschrieben wurde?

    Oder kann man da auch was Manuell machen, also auf die Process Domäne von Windows zugreifen?

    0
  • C

    Dieser Thread wurde von Moderator/in volkard aus dem Forum C++ in das Forum WinAPI verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • ?

    LiGERWooD schrieb:

    Gibt es im reinem C/C++ sowas ähnliches wie Interprocess Communication System? Oder nur mit hilfe einer Libary die in einer anderen Sprache geschrieben wurde?

    Oder kann man da auch was Manuell machen, also auf die Process Domäne von Windows zugreifen?

    So etwas ist immer betriebssystemspezifisch und eine so allgemeine Sprache wie C oder C++ kann das unmöglich bieten, denn dadurch würden diese Sprachen nur auf Systemen einsatzbar sein die so etwas wie Prozesse überhaupt kennen (und dann muss auch noch IPC verfügbar sein).

    0
  • ?

    Habe ich mir schon gedacht. Deshalb redetete ich ja auch von Libarys für C/C++ die in entsprechender (Assembler) geschrieben wurde. Bzw. kann sie, denke ich mal, widerum doch auch in C/C++ geschrieben sein mit Verbindung von WinAPI. Denn normale Datei und Registrierungs Funktionen hat C/C++ ja auch. Und das was Windows da hat sind ja auch nur Dateien oder die Registrierungsdatenbank.

    Wie dem auch sei, der Obergrund für mein Alternative suchen ist, dass ich bei Interprocess Communication System mit Visual C++ cli/.net ein irrelavantes Problem Habe. Ich kann zwar per Instanz erstellen vom RemoteObject ein Call zum Server durchführen, aber ich kann der Bibliothek::Klasse (RemoteObject) mit der Instanzierung nichts übergeben und somit bekommt der Server immer nur dass was in der Bibliothek::Klasse steht. Tolle Funktion! Nein, wirklich!!! 😡 😡 😡

    0
  • A

    Ich hab deinen letzten Satz jetzt nicht ganz verstanden aber
    Processe können nur mittels SHARED MEMORY Daten austauschen.
    Versuchs mit Threads dann kannst globale Variablen benutzen.

    Unter Unix hab ich mal bei Prozessen mit shmget() gearbeitet. Da benötigst du aber noch ein paar funktionen. Insgesamt waren es glaub ich 4.

    0
  • ?

    Ja, da müsste ich auch selbst drauf kommen das mit der Instanzierung einer Klasse des Types System::MarshalByRefObject aus einer Bibliothek ein Call an den Server ausgeführt wird der ebenso die selbe Klasse eingebunden hat, ohne Instanzierung.

    Also die Klasse ist, das RemoteObject. Wobei dort im Beispiel dem Server nur etwas übergeben wird was inerhalb der Klasse generiert wird. Dann kam ich dahinter das mein einer Klasse auch Übergabeparameter defenieren kann im Konstruktor, was ich aufgrund meines Tut verpennt hatte.

    Nur gebe ich der RemoteObject Klasse Übergabeparameter im Konstruktor spuckt der Debuger folgendes aus, was natürlich zu cli gehöhrt aber zeige es trotzdem mal:

    Eine nicht behandelte Ausnahme des Typs "System.Runtime.Remoting.RemotingException" ist in mscorlib.dll aufgetreten.

Zusätzliche Informationen: Ein nicht standardmäßiger Konstruktor kann nicht ausgeführt werden, wenn die Verbindung mit bekannten Objekten hergestellt wird.

    Und genau deshalb such ich nach einer Alternative. Mann kann auch mit dem Visual C++ reines C verwenden.

    Hier mein Urgrund

    0
  • T

    Ey, nur weil Du den Durchblick nicht hast, was ich aus deinen Post schliesse, heisst das nicht, dass man mit Spache / Library oder Toolkit xy dies und jenes nicht machen kann.

    Mit C++, C sowie den .NET Sprachen (ja, darunter fällt auch C++/CLI) lassen sich auf jeweils ihre Weise Daten über Prozessgrenzen hinweg austauschen. Dabei benutzen alle jeweils die Funktionalität die das OS dafür zur Verfügung stellt (der Zugriff erfolgt via C API). Assembler hat damit (in erster Linie) gar nichts zu tun damit.

    .NET bietet darüber hinaus sehr komfortable "Networking" Möglichkeiten, von Pipes, Sockets, Remoting (WCF ist die Weiterentwicklung) und WebServices bis zu WCF.

    Dein Schluss also, dass Du eine Exception in deiner Applikation mit Sprache der C++/CLI hast und desshalb die Lösung in der Sprache C oder C++ suchst ist hier wirklich nicht angebracht.

    Bei deinem Code und den bisher erwähnten Artefakten schliesse ich daraus, dass Du .NET Remoting (mit C++/CLI) benutzt um die Objekte auszutauschen. Löse das Problem dort. Lies ein Buch oder Tutorial zum Thema.

    Nur so am Rande: Ich halte ich C++/CLI für die falsche Sprache wenn es darum geht Applikationen zu entwickeln. Diese Sprache und ihre Features sind dafür gemacht die Managed und die Unmanaged Welt zu verbinden (als Integrationsschicht). Und ich würde die Gründe für diese Verbindung kritisch betrachten, denn sowas kostet (Know- How, mehr Fehlerquellen, Performance, ...).

    Simon

    0
  • ?

    Ach nein man!!!

    Komm ich mir den hier beklopt vohr? Im Forum cli sagte man mir Ipc sei das Richtige, nun dann bin ich da hin auf msdn und da muss ich sagen dass, das doch eine recht magere Beschreibung wahr. Dort wurde nie erwehnt das per Instanzierung der Klasse ein Call an den Server durchgeführt wird. Aber nun gut das ist jetzt Geschichte.

    Natürlich habe ich auch schon ganz einfach drann gedacht in der Client Routine/Funktionen eine Datei zu schreiben die, die Server Routine wiederum einliest.

    Aber ich habe gleich zu beginn im cli Forum erwehnt dass es mit nur darum geht die args von dem gestarteten Process zum bereits gestarteten Process zu übergeben.

    Nur wie sol dass gehen wenn ich der RemoteObject-Klasse bei der Instanzierung nichts übergeben kann? Ich kann doch schlieslich nicht von der RemoteObjekt-Klasse aus, auf das zurückgreifen von dem es Instanziert wurde.

    Ich sage es mal so, ich habe nicht den Durchblick, weil ich mir nicht jedes Objekt aus der .Net angeguckt habe und damit herumexperimentiert habe, was sehr sehr viel zeit kosten würde. Wiederum bei den Controls wird mit Beschreibung übertreiben. Dabei ist dass immer nur die User Schnitstelle und nicht das eigentliche.

    0
  • T

    LiGERWooD schrieb:

    Ach nein man!!!

    😕

    LiGERWooD schrieb:

    Im Forum cli sagte man mir Ipc sei das Richtige

    Das kann gut sein, dass mit IPC dein Problem gelöst werden kann. Es scheint mir aber, dass Du IPC (Inter Porcess Communication) mit konkreten Mechanismen verwechselst.

    LiGERWooD schrieb:

    nun dann bin ich da hin auf msdn und da muss ich sagen dass, das doch eine recht magere Beschreibung wahr. Dort wurde nie erwehnt das per Instanzierung der Klasse ein Call an den Server durchgeführt wird.

    Ob ein Objekt per Call oder als Singleton aktiviert wird, ist konfigurierbar.
    (Zumindest bei .NET Remoting und WCF)

    LiGERWooD schrieb:

    Natürlich habe ich auch schon ganz einfach drann gedacht in der Client Routine/Funktionen eine Datei zu schreiben die, die Server Routine wiederum einliest.

    Empfinde ich als "unsschön", aber wenn es dein Problem löst ist das super.

    LiGERWooD schrieb:

    Aber ich habe gleich zu beginn im cli Forum erwehnt dass es mit nur darum geht die args von dem gestarteten Process zum bereits gestarteten Process zu übergeben.

    Es heisst erwähnt.
    Schön dass Du das erwähnt hast. Das ist auch nicht unmöglich.

    LiGERWooD schrieb:

    Nur wie sol dass gehen wenn ich der RemoteObject-Klasse bei der Instanzierung nichts übergeben kann? Ich kann doch schlieslich nicht von der RemoteObjekt-Klasse aus, auf das zurückgreifen von dem es Instanziert wurde.

    Z.B. indem Du ein Interface machst das eine Methode Start(..) hat, welches die gewünschten Argumente nimmt.

    LiGERWooD schrieb:

    Ich sage es mal so, ich habe nicht den Durchblick, weil ich mir nicht jedes Objekt aus der .Net angeguckt habe und damit herumexperimentiert habe, was sehr sehr viel zeit kosten würde. Wiederum bei den Controls wird mit Beschreibung übertreiben. Dabei ist dass immer nur die User Schnitstelle und nicht das eigentliche.

    Du sollst Dir einfach die Doku lesen, die Du für dein Problem benötigst. Zudem solltest Du die Sprache beherrschen (wenigstens ansatzweise..).

    Simon

    0
  • ?
     

    Eine nicht behandelte Ausnahme des Typs "System.Runtime.Remoting.RemotingException" ist in mscorlib.dll aufgetreten.

Zusätzliche Informationen: Ein nicht standardmäßiger Konstruktor kann nicht ausgeführt werden, wenn die Verbindung mit bekannten Objekten hergestellt wird.

    Jetzt weiß ich nciht was mit Interface gemeint ist. Methode ist doch die Im Konstruktor der Klasse oder?

    0
  • T

    Jetzt weiß ich nciht was mit Interface gemeint ist.

    Dann google danach oder guck bei MSDN.

    Methode ist doch die Im Konstruktor der Klasse oder?

    Ich verstehe die Frage nicht. Sie ist etwas wirr.
    Eine Methode ist eine Methode und ein Konstruktor ist ein Konstruktor.

    Simon

    0
  • ?

    Die WinApi bietet zwei Möglichkeiten zur InterProcessCommununication (IPC):
    1. FileSharing, z.B. NamedPipes
    2. Direkte Nachrichten via SendMessage über die FensterHandles
    Besondere Libraries sind dazu nicht erforderlich.
    In Netzwerken braucht man ggfs. Sockets.

    0
  • ?

    daddeldu schrieb:

    Die WinApi bietet zwei Möglichkeiten zur InterProcessCommununication (IPC):
    1. FileSharing, z.B. NamedPipes
    2. Direkte Nachrichten via SendMessage über die FensterHandles
    Besondere Libraries sind dazu nicht erforderlich.
    In Netzwerken braucht man ggfs. Sockets.

    Wo oder wie finde ich eine Doku für Ipc in WinAPI? Die Visual C++ IDE bietet auch die möglichkeit mit Win32-Projekt und keinem vorkompilierten Header in reinem C zu Schreiben und dieser Compiler übersetzt es auch. Oder ist das weniger geignet um in C zu schreiben? Gegebenenfalss wegen dem Compiler?

    0
  • T

    Wo oder wie finde ich eine Doku für Ipc in WinAPI?

    Bei MSDN: http://www.msdn.com

    Die Visual C++ IDE bietet auch die möglichkeit mit Win32-Projekt und keinem vorkompilierten Header in reinem C zu Schreiben und dieser Compiler übersetzt es auch.

    Schön - nur hat das nichts, aber auch gar nichts mir deinem Problem zu tun.

    Oder ist das weniger geignet um in C zu schreiben? Gegebenenfalss wegen dem Compiler?

    Der C - Compiler von Visual Studio ist eher dürftig.
    Jedoch: Warum in aller Welt möchtest Du auf einmal C benutzen?

    Entscheide dich für C oder C++ (wobei da die C API's des OS benutzt werden) oder für .NET (am besten C# und nicht C++/CLI, wie schon vorher mal erwähnt).

    Simon

    0
  • ?

    Das erste mal wo ich ins Programmieren eingestiegen bin da habe ich mit QBasic begonnen wobei dass für MS-DOS ist und ich daher schnell an die Grenzen gestosen bin, ebenso mit QuickBasic. Aber dadurch habe ich Visual Studio Basic (Visual Basic) endeckt und da war die Syntax ziemlich wie QBasic. Nur mit der Zeit merkte ich dann den entscheidenen Punkt: VB ist langsam! Gleiches erzählt man mir bei Visual C#. Daher wolte ich auf Visual C++ umsteigen. Dazu habe ich von vorne angefangen und Reines C gelernt, dazu habe ich ein prima OpenBook im web gefunden.

    Wie dem auch sei dass mit OpenGL war mir dann doch zu anstregend und von der WinAPI wuste ich so noch nichts bzw. habe ich mir dummerweise nicht angeschaut. Aber jetzt habe ich es und ich denke vielleicht solte ich dass doch mal lieber machen als Objektorientiert mit .Net. Denn wenn bei .Net so viele Probleme auftretten. Auserdem wil ich ja gerade diese C/C++ Spezialitäten nutzen, das eben nicht gereade alles Mangament ist.

    Dass andere ist duch Visual Studio habe ich keine Ahnung von Make files oder Compilier anweisungen, z.B. die, die per Übergabeparameter am Aufruf des Compiliers angehängt werden.

    Also was ich suche ist wirklich die Beispiele wie ich WinAPI in Reinem C/C++ anspreche. Auf msdn bekomme ich immer für cli C++/C+/VB/...

    0
  • T

    Ich fasse zuammen:
    Du willst (aus obskuren Gründen) Programme mit nativem C++ schreiben und dabei die WinAPI benutzen.

    Hier findest Du den Einstieg in die WinAPI Doku:
    http://msdn.microsoft.com/en-us/library/aa139672.aspx

    Und hier ein Bsp. einer Seite, welche die Funktion WSASocket(..) dokumentiert:
    http://msdn.microsoft.com/en-us/library/ms742212(VS.85).aspx

    Simon

    0
  • M

    LiGERWooD schrieb:

    C/C++

    C und C++ sind zwei eigenständige Dinge. Nur weil ein Teil von C eine Teilmenge von C++ ist, muss man nicht immer C/C++ sagen.

    Der Grund, Visual C# sei langsam, ist auch kein wirklicher.

    0
  • ?

    mad_martin schrieb:

    LiGERWooD schrieb:

    C/C++

    C und C++ sind zwei eigenständige Dinge. Nur weil ein Teil von C eine Teilmenge von C++ ist, muss man nicht immer C/C++ sagen.

    Der Grund, Visual C# sei langsam, ist auch kein wirklicher.

    Schön. Aber was ergibt das für einen sinn wegen solchen Problemen die Sprache zu wechseln? Jetzt kann ich C. Und dann noch mal C# zu lernen um dan wieder ins Visual ab zu tauchen nur um die gleichen Probleme noch mal zu bekommen - nein Danke! Es ist ja dann nämlich immer noch .Net und da ist ja die Quelle meines Problems. Und ich glaube das ich auch deshalb mit solchen fehlern nicht klar komme weil, weil ich an sich nicht die ganze Funktion kenne die hinter den Klassen der Ipc steckt, geschweige denn .Net

    0
  • B

    LiGERWooD schrieb:

    Schön. Aber was ergibt das für einen sinn wegen solchen Problemen die Sprache zu wechseln? Jetzt kann ich C. ...

    Für den Einsatz der WinApi reicht C völlig aus. Obwohl man natürlich schnell auch die Vorteile von C++ nutzen möchte. Sage mal konkret, was in welchem Umfang Du kommunizieren möchtest. Für einfache Dinge (integer oder kleine Byte-Folgen) ist SendMessage ausreichend und sehr effektiv. Für mehr FileSharing oder Sockets. Aber das wurde Dir schon gesagt.
    Wer programmiert, sollte auch wissen wo er die Dokus findet. Bei mir liefert die der Compiler (Borland).

    0
  • ?

    berniebutt schrieb:

    LiGERWooD schrieb:

    Schön. Aber was ergibt das für einen sinn wegen solchen Problemen die Sprache zu wechseln? Jetzt kann ich C. ...

    Für den Einsatz der WinApi reicht C völlig aus. Obwohl man natürlich schnell auch die Vorteile von C++ nutzen möchte. Sage mal konkret, was in welchem Umfang Du kommunizieren möchtest. Für einfache Dinge (integer oder kleine Byte-Folgen) ist SendMessage ausreichend und sehr effektiv. Für mehr FileSharing oder Sockets. Aber das wurde Dir schon gesagt.
    Wer programmiert, sollte auch wissen wo er die Dokus findet. Bei mir liefert die der Compiler (Borland).

    Danke. Ich wil wirklich nur einen char array der eine größe von bis zu 256 Zeichen(1. Byte) (char[255]) einem anderen Process übergeben.

    Das mit der Doku, ich hatte ja den Visual Studio und das ja msdn und da ist dass für cli und die objekte kommen auserdem aus .Net

    Gut also SendMessage ist in WinAPI enthalten?

    0
Anmelden zum Antworten