MShell: cmd.exe/4os2.exe frontend

(DE) Projekte für OS/2, eCS und ArcaOS
(EN) OS/2, eCS and ArcaOS related projects
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

MShell: cmd.exe/4os2.exe frontend

Beitrag von Martin Vieregg »

Ich bin der Autor des ME Editors und anderer Editoren. ME kann schon von stdin einlesen:

ME Editor

dir /s | me in

Ich bin dabei, daraus ein vollständiges Frontend für cmd.exe / 4os2.exe zu erstellen, das nicht die ärgerliche 8192-Zeichen-Beschränkung hat. Alle Daten einer Sitzung kann man mit der Scrollbar dank Editorfunktionalität wieder herholen. Zwischenablage u.a. funktioniert wie bei einem richtigen Editor. Mein Programm, das ich vorläufig MShell nenne, startet von sich aus cmd.exe oder 4os2.exe, erzeugt entsprechende Pipes und leitet stdin, stderr und stdout entsprechend um.

Es laufen aber nur die Programme, die stdin/stdout unterstützen. Farben gehen mit ESC-Ansi-Sequenzen auch. Doch die wenigen Programme mit crt VIO Aufrufen gehen nicht und müssen dann über ein herkömmliches Kommandozeilenfenster ausgeführt werden, das ggfs. dann automatisch gestartet wird, wahrscheinlich mit Hilfe einer editierbaren Ausnahme-Liste.

Ich versuche erstmal, das look-and-feel der alten Kommandozeile nachzuprogrammieren und baue dann in einem zweiten Schritt die gewünschten "Goodies" ein.

Neben dem reinen Textin- und output werde ich zuerst die Cursor-rauf-runter Funktion zur Wiederherstellung alter Eingaben implementieren. Die Tab-Erweiterung wird es wie in 4os2.exe, Linux oder Windows auch geben. Dann werde ich mein Kommandozeilenprogramm cd-shortcut zum schnellen Springen in Verzeichnisse ebenfalls integrieren, weil es eines der wenigen Programme ist, das VIO Aufrufe nutzt und deswegen in der MShell nicht funktioniert. Evtl. baue ich noch in einem separaten PM-Fenster eine Liste der alten Befehle ein. Ich denke außerdem über ein mauscursor-nahes Dropdownfeld nach, das einem bei der Suche nach Verzeichnisnamen oder Dateinamen unterstützt (in Ergänzung zur Tab-Erweiterung).

Meine Frage an euch: Welche weitere Funktionalität wäre euch wichtig ?
Wo finde ich eine vollständige Liste der Tastenfunktionen von cmd.exe ?
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Martin Vieregg hat geschrieben: Mo 13. Jan 2020, 10:38 Ich bin der Autor des ME Editors ...
hat der etwas zu tun mit diesem Editor:
http://www.utopia-planitia.de/index.html
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

nein, MED ist ein Programmierereditor. ME ist ein Ersatz für den OS/2 Systemeditor und bewusst relativ einfach gehalten. Es gibt allerdings beispielsweise HTML-Syntax-Highlightning. Die ME Spezialität ist der Umgang mit verschiedenen Zeichensätzen und Betriebsssystemen (Dateiendungen, IBM und ANSI Zeichensatz), dann u.a. eine automatische Aktualiserung wenn sich die Datei geändert hat. Oder eine sehr praktische Suchfunktion mit Anleuchten der gefundenen Begriffe.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Martin Vieregg hat geschrieben:Mein Programm, das ich vorläufig MShell nenne...
Kein so gute Idee: https://ecsoft2.org/mshell-mini-pm-shell
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

>mshell

Danke für den Hinweis. Denkbar wäre aus meiner Sicht
cmdfront
mecmd
cmdme

Letzteres wäre ein nettes kleines Wortspiel: cmd-Martins-Editor und "befehle mir", doch es gibt ein paar andere Treffer bei Google, allerdings kein Computerprogramm.

Wer hat noch Vorschläge?
Zuletzt geändert von Martin Vieregg am Di 14. Jan 2020, 22:20, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Inzwischen habe ich mich erst einmal für "cmdme" entschieden.

Es dauert noch ein bißchen, bis ich etwas vorzeigen kann, ich werde es aber hier schreiben, wenn ich so weit bin.

Eine auf den ersten Blick banale Geschichte hat sich als extrem anspruchsvoll zu programmieren herausgestellt, ich werde gut in der "Programmers" section auf www.os2world.com/forum betreut und komme auch voran. Es geht um eine auf den ersten Blick Lapalie, von meinem PM Editor die Nutzereingabe von Ctrl-C in eine Exception für cmd.exe umzuwandeln, damit cmd.exe die Ausführung unterbricht, aber nicht beendet wird. Nach 4 Seiten Foren-Diskussion hat sich hausgestellt, dass ich eine helper exe benötige, die vom PM Editor aus in einer eigenen Session gestartet wird und die dann als child in derselben Session den Prozess cmd.exe startet. Zwischen dem PM Editor und dem Helper wird mit Event Semaphoren und Shared Memory kommuniziert, die Helper exe wandelt dann diese Information in exceptions um. Zwischen den unterschiedlichen Sessions muss man named pipes verwenden. Zwischen der helper exe und cmd.exe wird unter Verwendung von DosDupPipe stdin und stdout vererbt. Alles wird sowohl mit cmd.exe als auch mit 4os2.exe getestet.
Benutzeravatar
thorolf
Beiträge: 558
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Martin Vieregg hat geschrieben: Di 14. Jan 2020, 08:41 >mshell

Danke für den Hinweis. Denkbar wäre aus meiner Sicht
cmdfront
mecmd
cmdme
finde ich alle nicht sooo toll, denn es ist kein "Kommando", sondern eine Shell oder Terminal oder Kommando-Zeile.
Wer hat noch Vorschläge?
Irgendwas mit Shell fände ich am besten, "mvshell", "mvsh" oder "msh" wenn Du Deinen Namen drin haben willst, sonst vielleicht das "Linux-übliche" wie "yash" ("yet another...) , "os2sh" oder sowas eben.

Im Grunde ist das fehlen einer brauchbaren Shell, neben dem Fehlen eines aktuellen Web-Browsers und der allgemeinen Instabilität und Inkompatibilität, seit sehr vielen Jahren für mich eines der größten Mankos unter OS/2.

Ein Terminal mit einer ordentlichen History, die auch Neustarts überlebt, TAB-Vervollständigung von Befehlen, mit anständigen Maus-markier-/kopier-Funktionen, mit Registern/TABs, bequem konfigurierbar und frei in der Fenstergröße veränderbar sind seit Jahren Standard bei richtigen Betriebssystemen. Nur unter OS/2 gab's sowas leider nie :-(
Grüße,

Thorolf
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Das Problem ist, daß eigentlich das gesamte VIO-Subsystem hätte überarbeitet werden müssen. Ansätze dazu gab es wohl in OS/2 für PowerPC, die aber - Gegensatz zu GRADD - nicht in das "normale" OS/2 zurückgeflossen sind. Somit läuft es auf solche Frickellösungen wie die hier besprochene hinaus, die nie alle Fälle sicher abdecken können.
MKH
Beiträge: 117
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Ein Terminal mit einer ordentlichen History, die auch Neustarts überlebt, TAB-Vervollständigung von Befehlen, mit anständigen Maus-markier-/kopier-Funktionen, mit Registern/TABs, bequem konfigurierbar und frei in der Fenstergröße veränderbar sind seit Jahren Standard bei richtigen Betriebssystemen.
Nur mal aus Neugierde: Welches PC-Betriebssystem bringt das mit? Ich glaube Windows eher nicht. Und für den Mac war die Kommandozeile lange ein Fremdwort, soweit ich weiß.
Aber natürlich wäre hier mehr Komfort wünschenswert.
Benutzeravatar
Sandra Asja Eickel
Beiträge: 43
Registriert: Sa 30. Dez 2017, 01:00

Beitrag von Sandra Asja Eickel »

Unixoide Betriebssysteme können das schon sehr lange, inklusive der Befehlshistorie.
Es gibt dort auch nur verhältnismäßig wenige Programme, die nicht nur einfach Ein- und Ausgabe über STDIN und STDOUT machen, da es üblich ist, mehrere Programme miteinander zu verketten. Das zweite Programm nimmt die Ausgaben des ersten Programms entgegen und schickt seine Ausgaben als Eingabe an ein drittes Programm weiter.
Aber auch die anderen Programme wie Editoren können sich an geänderte Fenstergrößen problemlos anpassen. Maussteuerung in Konsolenfenstern geht außer für Copy&Paste so gut wie nie (bzw. wird es zumindest nicht verwendet).

Bei Windows 10 hat M$ die normale Kommandozeile komplett überarbeitet, freie Größenänderung geht jetzt auch - solange kein MODE-Befehl erfolgt, dann ist die Größe fest.

Die Konsolen merken sich, welche Ausgaben erfolgt sind, insbesondere, wo sich echte Zeilenumbrüche befinden und wo einfach nur das alte Fenster zu schmal war - dementsprechend werden die Inhalte bei einer Breitenänderung passend neu ausgegeben.

Sandra Asja
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Die heiklen OS/2-nahen Programmierungen habe ich nun tatsächlich auch hinbekommen. Das meiste in den letzten Posts erwähnten Punkte bekomme ich tatsächlich auch hin. Die Einschränkungen beziehen sich auf ein paar spezielle Dinge. Das wichtigste ist, dass ich noch die VIO-Programme, also die Programme, die nicht (nur) stdout und stderr verwenden, sondern direkt in den Bildschirmspeicher schreiben (das sind die Programme, die den Cursor beliebig positionieren können, z. B. dfsee), sicher erkennen muss. Diese werden dann in einer eigenen cmd Sitzung gestartet. Ich habe schon im englischen Forum angefragt, ich müsste das Binary analysieren und das am Code erkennen. Eine wesentlich schlechtere Variante wäre es, wenn man eine Ausnahmeliste anlegen würde.

Dann gibt es noch ein Thema, wenn cmd.exe eine cmd-Datei ausführt. Befehle wie "mode" oder "cls" bekommt dann der Editor nicht mit. Ich werde das das so lösen, dass wenn der Benutzer eine Datei mit explizitem Dateiende .cmd übergibt, der Editor dann die Datei (ggfs. rekursive bei "call") liest und Zeile für Zeile cmd.exe zusendet. Die Grenze ist dann bei REXX-Programmen, diese kann ich nicht zeilenweise an den Editor schieben. Wenn in REXX-Programmen "mode" oder "cls" steht, wird das der Editor nicht mitbekommen.

Farben gehen auch, 4os2 wird auch unterstützt. Man kann nachträglich die Fenstergröße ändern und die bisherigen Eingaben werden dann auch korrekt wieder umgebrochen (das geht jetzt schon mit ME, mit dem man auch den Output von anderen Programmen einfangen kann), denn der Editor unterscheidet zwischen Zeilen mit weichen und harten Zeilenumbrüchen.

Code: Alles auswählen

[C:\]dir /s | me in
Das einzige, was ich lassen werde, ist dass wenn man die Bildschirmbreite ändert, die Farben gelöscht werden (ist mir zu frickelig das zu programmieren, es ginge schon, wäre aber relativ viel Arbeit.).

Inzwischen habe ich das Basisprogramm fertig, noch vollkommen spartanisch bzgl. der Goodies, die dann den Unterschied zu cmd.exe ausmachen werden. Ich teile es hier mit, wenn ihr die erste Version einmal testen könnt. Ich werde aber erst noch ein bißchen Features einbauen. Die Goodies zu programmieren, wird dann einfacher sein, weil ich viel ja im ME Editor schon implementiert habe und nur Code freigeben bzw. kopieren muss. Ich möchte das Programm aber erst mit eiiner gewissen Reife herausgeben, um unnötigen Mailverkehr zu vermeiden.
Benutzeravatar
thorolf
Beiträge: 558
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

MKH hat geschrieben: Sa 8. Feb 2020, 09:44
Ein Terminal mit einer ordentlichen History, die auch Neustarts überlebt, TAB-Vervollständigung von Befehlen, mit anständigen Maus-markier-/kopier-Funktionen, mit Registern/TABs, bequem konfigurierbar und frei in der Fenstergröße veränderbar sind seit Jahren Standard bei richtigen Betriebssystemen.
Nur mal aus Neugierde: Welches PC-Betriebssystem bringt das mit? Ich glaube Windows eher nicht. Und für den Mac war die Kommandozeile lange ein Fremdwort, soweit ich weiß.
Aber natürlich wäre hier mehr Komfort wünschenswert.
alles was nicht Windows ist (und selbst da ist es besser geworden), v.a. natürlich alles was Bash hat, jedes Linux, BSD und Unix aber selbstverständlich auch Mac OS X von Anfang an, was ja eine gewisse Nähe zu BSD hat(te).

Für mich war u.a. das Fehlen einer brauchbaren Kommandozeile ein Grund nicht mehr mit OS/2 zu arbeiten, der Komfortgewinn mit Terminal&Co. war einfach gigantisch.
Grüße,

Thorolf
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich mache Fortschritte mit meinem Kommandozeilen-Frontend.

Nochmal zurück zu den Namensgebungen. Thorolf hat geschrieben:
Irgendwas mit Shell fände ich am besten, "mvshell", "mvsh" oder "msh" wenn Du Deinen Namen drin haben willst, sonst vielleicht das "Linux-übliche" wie "yash" ("yet another...) , "os2sh" oder sowas eben.
Ein hübscher Name wäre "meshell", weil sich das, wenn man es sauber englisch ausspricht, wie der französische Mädchenname "Michelle" anhört. Doch es gibt schon eine Musikerin mit dem Künstlernamen "me'shell". Ob das ein Problem sein könnte? Auf jeden Fall gehen Google-Suchanfragen dann ziemlich unter.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Das wär mir egal. Neben meshell fallen mir noch ein:

mecmdshell
meos2shell

Interessant ist die Verwechslung mit cmd's hell, die mich stören würde. Beim EPM heißen die virtuellen Dateien .command_shell_#, aber das hat sicherlich den Grund, dass E2 ein DOS-Programm war.
Zuletzt geändert von aschn am So 16. Feb 2020, 22:37, insgesamt 1-mal geändert.
Andreas Schnellbacher
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

@Martin: WM_UPDATEFRAME sollte gegen "Löcher" in Titelbalken helfen...
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: So 16. Feb 2020, 21:24 Ein hübscher Name wäre "meshell", weil sich das, wenn man es sauber englisch ausspricht, wie der französische Mädchenname "Michelle" anhört.
Ich kann selbst mit viel Phantasie keine Ähnlichkeit in der Phonetik feststellen. Selbst für Worte romanischer Herkunft ist die Aussprache in der englischen Sprache nicht unbedingt identisch. Die Unterschiede von Takt und Versmaß könnten noch angeführt werden.

Wenn es unbedingt eine Masche sein soll, geht es doch mit # deutlich kürzer.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

aber meshell wäre doch OK, oder? Für mich käme jetzt cmdme oder meshell in Frage. Ich möchte kein OS/2 im Namen, weil ich das Programm später evtl. auch noch auf andere OS portiere. Den ME gibt es ja für OS/2, Windows, Mac und Linux. Sofort werde ich das aber sicher nicht machen, weil unter den anderen OS der Leidensdruck nicht so groß ist. Und es ist diesmal viel proprtetärer Code enthalten (viele OS/2 API-Aufrufe), der relativ aufwendig portiert werden müsste.
Benutzeravatar
thorolf
Beiträge: 558
Registriert: Mi 25. Dez 2013, 16:14
Wohnort: Rhein-Main

Beitrag von thorolf »

Martin Vieregg hat geschrieben: Fr 21. Feb 2020, 09:43 aber meshell wäre doch OK, oder? Für mich käme jetzt cmdme oder meshell in Frage. Ich möchte kein OS/2 im Namen, weil ich das Programm später evtl. auch noch auf andere OS portiere. Den ME gibt es ja für OS/2, Windows, Mac und Linux. Sofort werde ich das aber sicher nicht machen, weil unter den anderen OS der Leidensdruck nicht so groß ist. Und es ist diesmal viel proprtetärer Code enthalten (viele OS/2 API-Aufrufe), der relativ aufwendig portiert werden müsste.
meshell wäre okay, mshell gab es wohl schon mal (wobei das Projekt wohl tot ist) und msh ist auch schonmal genutzt worden, könnte man aber trotzdem als verwenden. cmdme finde ich weniger gut, weil es aus dem Rahmen "fällt".

Kommandozeilen haben i.A. was mit Shell oder Terminal im Namen.
Grüße,

Thorolf
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich habe jetzt eine erste Version MeShell 0.5 fertiggestellt. Wer im Englischen nicht komplett fitt ist, wartet bitte auf die nächste Version. Diese wird dann eine deutsche Doku enthalten. Es wird erst ein Native Speaker die englische Doku überarbeiten, dann werde ich sie ins Deutsche übersetzen. Die Benutzeroberfläche ist jetzt schon englisch und deutsch. Es ist wichtig, die Doku (vor allem Kapitel 1 und 3) zu lesen und zu verstehen, um das Programm sinnvoll nutzen zu können.

Hier kann man MeShell.zip (500 kB) downloaden.

Ich bitte um die Sammlung von Fehlern und Kommentaren und die Übersenung per E-Mail. Danke. Bitte nicht für jeden Punkt eine einzelne E-Mail senden.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Beeindruckend.

BTW: Auch nach CUA fangen Texte, Parameter usw. in Kontrollelementen immer mit einem Großbuchstaben an. Das gilt jedenfalls für eng und deu.
Andreas Schnellbacher
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich habe jetzt selbst den ganzen Thread hier nochmal überflogen und möchte resummieren, dass die, mit viel Mithilfe von Experten aus dem englischen OS/2-Forum, gefundenen Lösungen nicht mehr viel "Gefrickel" enthalten und gerade das Thema Erkennen eines VIO Programms besser gelungen ist als ich mir es am Anfang erhofft hatte. Auch manche ursprünglich gesehenen Probleme wie dass ich eine cmd-Datei Zeile für Zeile mitinterpretieren müsste, haben sich gottseidank in Luft aufgelöst. Der Schwerpunkt der Version 0.5 liegt in der Basisfunktionalität und der Kommunikation zwischen dem Editor und cmd.exe. Jetzt kommt noch der für den Nutzer interessantere Teil mit den "Goodies", die aber weitgehend vollständig im Editor ablaufen und deshalb nicht mehr so schwierig zu programmieren sind:

- Ich möchte noch für alle meine Editoren ein schnelleres Scrollen (direkt über den Bildschirmspeicher) umsetzen, das sollte bei MeShell in der klassischen "full scroll" Einstellung einen erheblichen Geschwindigkeitsgewinn bringen bzw. die Prozessorlast senken
- Befehls-Vervollständigung mit Tab-Taste und optional mit fly-over Dropdown Auswahlfeld
- WPS Integration (ein bißchen geht jetzt schon: markieren und drag and drop in einen Ordner erzeugt eine Textdatei). Vor allem möchte ich, dass ein Doppeklick auf einen Dateinamen aus einem "dir" Befehl und Ähnlichem die Datei über WPS Standardzuordnung öffnet
- eigenes Fenster mit Navigationsbaum, mit zwei Sortierebenen 1 aktuelles Verzeichnis 2 verwendete Befehle
- dann noch zuschaltbar ein Bottom Panel mit einer Anzeige, welche Verzeichnisse bei welchen Laufwerksbuchstaben gerade angemeldet sind, damit man den Überblick behält, wenn man ein Copy dateiname x: ausführt.

Längerfristig könnte ich einzelne Befehle wahlweise auch direkt von MeShell ausführen lassen, z. B. ein neues Copy mit einer im Bottom Panel eingebauten Fortschrittsanzeige. In meinem DO Kommandozeilentool habe ich schon ein neues Copy programmiert, allerdings mit abweichender Syntax.

Alle neuen Funktionen wird man im Einstellungen-Buch wahlweise zuschalten können.

Bzgl. Eurer Mitarbeit würde ich mich über Buglisten freuen. Bitte teilt mir VIO-Programme mit, die MeShell noch nicht automatisch hochpoppt. Wenn ich den Erkennungsmechanismus verbessern soll, brauche ich Beispiele, wo er bislang noch nichts bemerkt.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Die Eingabe von "exit" hängt bei mir das ganze System auf. Ansonsten aber würde ich auch sagen: ein Zugewinn.

Ein Nörgler muss ja den Anfang machen :lol:

Gruß,
Lars
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

erdmann hat geschrieben: Mo 6. Apr 2020, 13:00 Die Eingabe von "exit" hängt bei mir das ganze System auf. Ansonsten aber würde ich auch sagen: ein Zugewinn.

Ein Nörgler muss ja den Anfang machen :lol:

Gruß,
Lars
Komisch, das scheint nicht immer zu passieren. Wenn ich das jetzt direkt eingebe schließt sich nur (erwartungsgemäß) das Programm. Ich muß beim letzten Mal irgendwas gemacht haben, Text ausgewählt, eine Kommandozele aus einer anderen gestartet haben oder so.
Wenn ich Genaueres weiss melde ich mich eben wieder .
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Wenn ich das Programm starte und dann die "Pfeil oben" Taste drücke kommt direkt eine Schutzverletzung bei Addresse 5b:103a6
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Es ist für mich nicht völlig verwunderlich, weil ich das Programm bislang nur auf zwei hardwaremäßig identischen Rechnern entwickelt habe. Es sind mehrere Threads und heikle API-Aufrufe, die Threads müssen in kritischen Momenten aufeinander warten.

cmd.exe beendet sich mit dem Empfang von "exit" selbst, der Helper spannt das, schließt noch Pipes und einen Thread, schickt vorher dann noch ein "tschüß" an den Editor und der Editor bemerkt dann, dass die Session beendet wurde. Dann schließt er seine Threads und gibt die Resourcen frei. Da kann eine Menge schiefgehen.

Wenn man den Schließen Button in der Titelzeile klickt, wird auch ein EXIT geschrieben und an cmd.exe über stdin gesendet. Dann müsste es eigentlich mit Schließen auch abstürzen? Ich bitte um eine Ausführung mit -log als Parameter und Zusendung der drei *.log Dateien im Verzeichnis der EXE-Datei und Zusendung E-Mail-Adresse siehe HLP-Datei letzte Seite.
Antworten