Moin, Problem: Ein Programm läuft in einer DOS-Box (Win7/XP) und wickelt selbstständig den Mailverkehr ab. Leider nur bis einer draufschaut und in die DOS-Box klickt. Dann steht es. Kann man das irgendwie abschalten ?
Du meinst keine "DOS-Box", sondern ein Kommandozeilenfenster. Das Programm sollte auf Mausevents in der Konsole reagieren, siehe dazu https://docs.microsoft.com/en-us/windows/console/reading-input-buffer-events Für Programme, die zuverlässig im Hintergrund arbeiten sollen und keine Benutzerinteraktion vorsehen, ist seit über zwei Jahrzehnten unter ernstgemeinten Windows-Versionen das Konzept des Dienstes (Service) vorgesehen, solche Programme laufen auch dann, wenn kein Benutzer angemeldet ist. Was macht das Programm besonderes, daß nicht ein herkömmlicher Mailserver verwendet werden kann, der das Dienst-Konzept umsetzt? (Ein Beispiel für einen guten, freien und stabilen Mailserver, der unter Windows läuft, ist hmailserver)
Gast
#5435625
Sicher das das Programm stehenbliebt und nicht nur die Meldungen aufhören selbständig zu scrollen? Prinzipiell hat der Vorposter Recht, so etwas sollte ein Service sein. Aber man hat ja nicht immer Einfluss darauf. Ich erinnere mich mal ein Tool von Microsoft genutzt zu haben was es ermöglicht jedes Programm als Service laufen zu lassen. Wenn das auch heutzutage noch funktioniert wäre das evtl. auch ein Versuch Wert. Dann könnte das Problem unter einem eigenen Nutzer ungestört ablaufen. Allerdings könnte man dann die Konsolenausgaben nicht mehr sehen.
Das Programm steht als man-in-the-middle und archiviert die durchgehenden Mails. Abgesichert mit OpenSSL. Danke für den Link - ich denke da komme ich weiter ;)
nur zufällig hier schrieb: > Ich erinnere mich mal ein Tool von Microsoft genutzt zu haben was es > ermöglicht jedes Programm als Service laufen zu lassen. > Wenn das auch heutzutage noch funktioniert wäre das evtl. auch ein > Versuch Wert. Das gibt es nach wie vor (srvany.exe), aber es gibt auch viele andere Alternativen dazu. Man kann das betreffende Programm auch mit dem Windows-Taskplaner in einem anderen Benutzerkontext laufen lassen, dann bekommt man auch nichts davon mit. Das Problem bei solchen Ansätzen ist aber immer das Beenden, da kein sauberer Weg zur Signalisierung eines Beenden-Wunsches vorhanden ist. Dienste sind mit dem SCM (service control manager) verbunden und können über diese Schnittstelle Steuerereignisse empfangen (die z.B. mit "net stop servicename" ausgelöst werden können). Interaktive Programme beendet man mit Mausklicks oder Tastatureingaben, wenn aber das interaktive Programm in einer nicht zugänglichen alternativen Benutzersitzung läuft, lassen sich Mausklicks und Tastatureingaben logischerweise nicht verwenden. Am sinnvollsten dürfte für das betreffende Programm tatsächlich die Implementierung der Dienst-Schnittstelle sein; je nach verwendeter Programmierschnittstelle gibt es dafür auch einfach zu nutzende fertige Werkzeuge, so daß die Interaktion mit dem SCM nicht unbedingt über die Win32-API erfolgen muss.
Gast
#5435660
Mit sx kann man einen cmd ohne Fenster starten: B Start application without creating a new window. Oder mit cmdow das Fenster "verstecken"...
Gast
#5435665
P.S.: sx heisst eigentlich StartX
Gast
#5435671
Beim Kompilieren der Anwendung kann man ein Flag setzen welches die .exe als Windows-Anwendung markiert (-mwindows bei MinGW) was letztendlich nur ein Bit im PE Header setzt. Dann öffnet Windows kein Konsolen-Fenster für das Programm, und es läuft unsichtbar. Als Dienst wäre allerdings deutlich sauberer.
Ich möchte beobachten was das Programm so treibt. Bei einem Service dürfte das nicht so einfach gehen. Deshalb ist "unsichtbar" nicht so das gelbe vom Ei. Die Chose läuft später eh auf einem eigenen Rechner, draufschalten kann man sich mit VNC (kicken, reinklicken und unser BWLer merkt nich was er da angerichtet hat ;)
Gast
#5435685
Joachim D. schrieb: > Bei einem Service dürfte das nicht so einfach gehen. Im simpelsten Fall einfach die Ausgaben in eine Datei schreiben. Windows bietet ja selber auch Logging Funktionen auch für Services...
Gast
#5435739
nur zufällig hier schrieb: > Prinzipiell hat der Vorposter Recht, so etwas sollte ein Service sein. > Aber man hat ja nicht immer Einfluss darauf. Doch hat man. Auf jeden Fall, wenn es ein "reines" Konsolenprogramm ist, denn dann kann man daraus mit absoluter Sicherheit unter Verwendung von srvany einen Dienst machen. > Ich erinnere mich mal ein Tool von Microsoft genutzt zu haben was es > ermöglicht jedes Programm als Service laufen zu lassen. Das isses. Nur leider stimmt es nicht, dass man wirklich jedes Programm damit als Dienst laufen lassen kann. Nur für reine Konsolenprogramme kann das garantiert werden und auch MS garantiert das nur eben genau dafür. Für alle anderen Programme KANN es funktionieren (das ist sogar relativ wahrscheinlich), muss aber eben nicht und ist deswegen auch nicht garantiert. Das Problem ist nur: es ist für einen Laien garnicht so einfach zu erkennen, ob man es mit einem "reinen" Kommandozeilenprogramm zu tun hat. Die Tatsache, das es kein sichbares Fenster anzeigt und sich über die Konsole starten läßt und auch Ausgaben dort tätigt, ist leider kein auch nur annähernd hinreichendes Kriterium...
c-hater schrieb: > Das Problem ist nur: es ist für einen Laien garnicht so einfach zu > erkennen, ob man es mit einem "reinen" Kommandozeilenprogramm zu tun > hat. Es ist definitv ein reines Konsolenprogramm, ich hab's ja selbst geschrieben ... ;)
Gast
#5435758
Tja, dann kannst du doch auch nen Service draus machen und ein korrektes Logging implementieren.
Gast
#5435809
Joachim D. schrieb: > Ich möchte beobachten was das Programm so treibt. > Bei einem Service dürfte das nicht so einfach gehen Joachim D. schrieb: > Es ist definitv ein reines Konsolenprogramm, ich hab's ja > selbst geschrieben ... ;) Dann ist das ja kein Problem. Am saubersten ist, die Arbeit als Service zu programmieren und dazu ein Frontend als Windowsprogramm, dass die Tätigkeiten anzeigt und Befehle für Start und Stop an den Service senden kann. Dieses Frontend kann man beenden, wenn man es nicht braucht, während der Service weiterläuft. Joachim D. schrieb: > Ich möchte beobachten was das Programm so treibt. Und das musst du wirklich ununterbrochen 24 Stunden am Tag?? Georg
Gast
#5436452
Hängt das Stoppen mit dem Markierungsmodus zusammen? Bei Powershellskripten hab ich das Problem beim Reinklicken auch. Da steht dann "Markieren" oder "Auswahl" in der Titielleiste. Mit Enter (Kopieren) geht es dann weiter. Zumindest für das normale Eingabefenster sollte sich das in den Einstellungen deaktivieren lassen. Markieren muss man dann via Kontextmenü manuell aktivieren.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.