Kommandierung eines laufenden Programms - wie am besten?

[Bodenseematze]

Hallo,

ich würde gern in meine Programme einen irgendwie gearteten "Kommando-Server" einbauen - dem ich dann von außen (d.h. z.B. über ein Kommandozeilentool) Ausführungsbefehle geben kann - also z.B. "schalte den Datensatz mit der Nummer 12345 auf" oder "Drucke den aktuellen Datensatz" oder "öffne das Unterformular mit XYZ" oder "Erweitere das Logging auf Debug-Level".

Aber wie baue ich das so ein, dass es möglichst wenig Overhead hat (wenn er nicht benutzt wird) und einfach zu implementieren ist?

Das Grundprinzip des Kommandoservers sollte auf alle möglichen verschiedenen Programmen übertragbar sein, d.h. nur einmal implementiert werden müssen;
das, was dann an Kommandos akzeptiert / unterstützt wird, müsste in jedes Programm integriert werden.

Ich dachte da z.B. an einen Shared-Memory-Bereich, in den die Kommandos geschrieben werden - aber da müsste dann ein Thread ständig drauf "lauschen" und sich dann mit dem Rest des Programms synchronisieren.

Vielleicht gibt es da was fertiges? In das ich "nur" (z.B. per JSON/XML/RPC) meine Kommandos und deren Ziel-Aufrufe definieren müsste?

Ich denke auch, dass es reichen würde, auf dem gleichen Rechner zu funktionieren - einen ausgewachsenen TCP/IP-Server und Kommandos über Netzwerk bräuchte ich dafür nicht...

Im einfachsten Fall könnte es so funktionieren, dass beim Aufruf einer .exe die Kommandozeilenparameter an eine bereits laufende Programminstanz der selben .exe "weitergereicht" werden.

[fisipjm]

Aus deiner Fragestellung wird mir nicht ganz klar was dein eigentliches vorhaben ist. Aber in Delphi gäbe es da jetzt unterschiedliche Methoden das umzusetzen.

1.) REST Server
Das ist mittlerweile gar nicht mehr so kompliziert. Schau dir zum beispiel mal den Horse Webserver von Hashload an. https://github.com/HashLoad/horse
Vorteil hier, die könntest sogar direkt Rückmeldung geben ob der Befehl angenommen oder verarbeitet wurde. Außerdem bist du flexibel das später auch mal auf unterschiedlichen Maschinen laufen zu lassen

2.) Datei/Datenbank/Registry Austausch
Du hast irgendeinen Platz auf dem System, das in einer Dauerschleife von deinem Programm gelesen wird und dann reagiert wenn was entsprechendes drin steht.

3.) EXE mit Parameteraufruf
Du hast ein Programm das man mit Parametern starten kann z.B. MeinProgramm.exe -C "Mach das".
Vorteil ist hier wohl, dass es den kleinsten Footprint in Punkto Codingaufwand hat.

Gruß
PJM

[peterbelow]

Zitat von Bodenseematze:

Hallo,

ich würde gern in meine Programme einen irgendwie gearteten "Kommando-Server" einbauen - dem ich dann von außen (d.h. z.B. über ein Kommandozeilentool) Ausführungsbefehle geben kann - also z.B. "schalte den Datensatz mit der Nummer 12345 auf" oder "Drucke den aktuellen Datensatz" oder "öffne das Unterformular mit XYZ" oder "Erweitere das Logging auf Debug-Level".

Aber wie baue ich das so ein, dass es möglichst wenig Overhead hat (wenn er nicht benutzt wird) und einfach zu implementieren ist?

Das Grundprinzip des Kommandoservers sollte auf alle möglichen verschiedenen Programmen übertragbar sein, d.h. nur einmal implementiert werden müssen;
das, was dann an Kommandos akzeptiert / unterstützt wird, müsste in jedes Programm integriert werden.

Ich dachte da z.B. an einen Shared-Memory-Bereich, in den die Kommandos geschrieben werden - aber da müsste dann ein Thread ständig drauf "lauschen" und sich dann mit dem Rest des Programms synchronisieren.

Vielleicht gibt es da was fertiges? In das ich "nur" (z.B. per JSON/XML/RPC) meine Kommandos und deren Ziel-Aufrufe definieren müsste?

Ich denke auch, dass es reichen würde, auf dem gleichen Rechner zu funktionieren - einen ausgewachsenen TCP/IP-Server und Kommandos über Netzwerk bräuchte ich dafür nicht...

Im einfachsten Fall könnte es so funktionieren, dass beim Aufruf einer .exe die Kommandozeilenparameter an eine bereits laufende Programminstanz der selben .exe "weitergereicht" werden.

Wenn Du nicht gerade einen kompletten out-of-process COM Server einbauen willst wäre vermutlich eine named pipe ein geeigneter Mechanismus zur notwendigen Kommunikation; das ist auch ein beliebter Weg, um Kommandozeilenparameter an eine schon laufende Instanz eines Programms weiterzuleiten. Allerdings Windows only. Durchsuch das Forum mal nach CreateNamedPipe, da findet sich sicher was. Dein "Server" würde die Pipe in einem sekundären Thread erzeugen und dort auf Daten warten.
Ein anderer Prozess muss nur den Namen der Pipe kennen um sie zu verwenden.

[jaenicke]

Ein großer Vorteil eines REST-Servers ist, dass er viele Möglichkeiten abdeckt. Aktuell würde es dir vielleicht auf dem gleichen PC reichen. Sicher, dass das immer so bleibt?

Außerdem könntest du damit sehr einfach eine Webseite drum herumbauen, die dann über die REST-Schnittstelle mit deinem Server spricht.

[dummzeuch]

Theoretisch ginge auch SendMessage oder sogar einfach eine Datei, in die man die Befehle schreibt und die das Programm dann liest.
Ach ja: Kommunikation via Memory Mapped File ginge auch.

SendMessage und Memory Mapped File funktioniert nur lokal auf demselben Rechner.

Was auch immer man nimmt: Es ist mehr Aufwand als man zunächst denkt.

[gubbe]

Ich habe es noch nicht ausprobiert, aber ist App-Tethering nicht dafür geeignet?

https://docwiki.embarcadero.com/RADS..._App-Tethering

Es gibt Beispielprojekte je nach Delphi-Version (ab XE6):
C:\Users\Public\Documents\Embarcadero\Studio\22.0\ Samples\Object Pascal\RTL\Tethering

Oder ganz klassisch per DDE (Dynamic Data Exchange), was genau für solche Fälle gedacht war. Ist schon etwas älter, sollte aber immer noch unter Windows funktionieren. In Delphi suchen nach TDdeClientConv bzw. TDdeServerConv

[Der schöne Günther]

Indy-Http-Server aufmachen, auf Http-Gets, Posts usw. reagieren und die entsprechenden Daten einlesen oder zurückgeben. Architektur- und Platform-Unabhängig, funktioniert über Rechnergrenzen hinweg und ist auch für das menschliche Auge super-leicht debugg-bar. Ich bin damit sehr glücklich geworden.

Gibt bestimmt mit "DataSnap" (?) und ähnlichen Dingen was noch weiter vorgekautes, aber die paar Minuten, Http und REST besser zu verstehen habe ich gerne investiert. War im Endeffekt deutlich einfacher als gedacht und funktioniert wirklich super.


Je nachdem was deine separate Anwendung für eine Aufgabe hat finde ich ganz ehrlich Konsolenanwendung mit Tastatureingaben nicht abwegig. Kann man drüber lächeln, aber ist aus einer Delphi-Anwendung heraus auch super steuerbar (CreateProcess und stdIn/stdOut-Pipes umbiegen, denn nichts anderes ist die Tastatureingabe und Bildschirmausgabe einer Konsolenanwendung) und schon kann man alles fernsteuern und auslesen und als netten Nebeneffekt kannst du deine Konsolenanwendung unter Windows einfach doppelklicken und die entsprechenden Befehle und Daten über die Tastatur ins Konsolenfenster eingeben während die Anwendung standalone läuft. Hat irgendwie auch einen gewissen Charme...

[Bodenseematze]

Zitat von dummzeuch:

Was auch immer man nimmt: Es ist mehr Aufwand als man zunächst denkt.

Da hast Du wahrscheinlich recht.
Vor ewigen Zeiten hatte ich sowas mal in C/C++ gemacht - damals hatte ich in einer DLL über Linker-Optionen eine Shared-Section angelegt, die dann alle nutzen konnten, die die DLL verwendet haben; und dann über DLLMain und Process-Attach / Thread-Attach eine Verwaltung drüber gelegt.
Das war damals der einfache Teil - aufwändiger war dann eben, einen Thread aufzubauen, der auf diese Bereich "hört" und dann das Protokoll zu definieren / auszuwerten, damit sich Befehlssequenzen absetzen lassen und bestätigt werden können.

Aus dem damaligen "mach mal schnell" wurde dann schnell ein Großprojekt - die Protokollschnittstelle musste dann auch noch mit Versionsnummern versehen werden, so dass verschiedene Schnittstellenversionen miteinander kommunizieren konnten (damit die DLL ausgetauscht / erneuert werden konnte und je nach Schnittstellenversion des Gegenpartner unterschiedliche Möglichkeiten zur Verfügung gestellt hatte).

Das ganze hat dann zwar super funktioniert, war aber schlussendlich doch ein Riesenaufwand - da wäre ein REST- oder SOAP-Server nicht aufwändiger gewesen !

Und diesmal wollte ich es "einfacher" machen - aber ich denke, um den Grundaufwand, ein Protokoll zu definieren und zu implementieren komme ich nicht herum - egal welche Kommunikationsvariante ich wähle.
Gibt es eigentlich fertige REST-/SOAP-Bibliotheken (SOAP war mir immer sympathischer als REST, weil dort die Schnittstellendefinition "genauer" ist - allerdings braucht man da sinnvollerweise wieder einen Compiler für die Umwandlung der Schnittstellendefinition in Code) für Delphi (7), die mir in der Hinsicht Arbeit abnehmen würden?

[Bodenseematze]

Zitat von gubbe:

Ich habe es noch nicht ausprobiert, aber ist App-Tethering nicht dafür geeignet?

Davon hatte ich noch nie gehört - die verlinkten Klassen gibt's bei mir auf meinem System (D7) auf jeden Fall (noch) nicht

Zitat von gubbe:

Oder ganz klassisch per DDE (Dynamic Data Exchange), was genau für solche Fälle gedacht war.
Ist schon etwas älter, sollte aber immer noch unter Windows funktionieren. In Delphi suchen nach TDdeClientConv bzw. TDdeServerConv

Gibt's das immer noch?
Dachte, das wurde komplett von OLE (und damit OCX-Server) ersetzt/erweitert und dann nur noch als Altlast im Windows "beibehalten"...
Ich denke, das ist ein totes Pferd, auf das ich nicht unbedingt setzen möchte

[Uwe Raabe]

Zitat von Bodenseematze:

Davon hatte ich noch nie gehört - die verlinkten Klassen gibt's bei mir auf meinem System (D7) auf jeden Fall (noch) nicht

App-Tethering gibt es seit Delphi XE6. Obwohl es das also schon seit gut 10 Jahren gibt, ist es immer noch relativ unbekannt. Es hat allerdings den Charme, dass es nicht nur auf dem lokalen System, sondern auch innerhalb des lokalen Netzwerks und auch über Bluetooth arbeitet.