Liste von textbasierten VIO-Programmen

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Hier scheint es wohl eher ein PM-Fenster zu sein.
Ja, ich nenne das PM-Fenster, in dem die VIO Anwendung (also cmd.exe) läuft, umgangssprachlich so.

Der Editor kann mit dem VIO-PM-Fenster kommunizieren (auf visible schalten, Titelzeilenbuttons manipulieren) und damit der (PM-)Editor mit cmd.exe kommunizieren kann, brauche ich die Helper exe. Der PM Editor startet die Helper exe in einer neuen Session und die Helper exe startet dann in derselben Session cmd.exe bzw. 4os2.exe. Da die Helper exe in derselben Session läuft wie cmd.exe, kann sie exceptions schicken, den VIO-Inhalt ansehen usw., was sonst der PM Editor nicht könnte.
Keine Ahnung woher diese Fehlbetrachtung kommt. Wie soll eine Tasteneingabe über Video-I/O (Vio) funktionieren?
Die keyboard Abfragen sind unter KBD calls gelistet. Dieser Input läuft unabhängig von stdin direkt ans VIO Subsystem. Es gibt somit Programme, die VIO bzw. KBD calls nutzen, aber keinen VIO Output generieren, weil sie nur VIO/KBD input verwenden. Mit diesen Aufrufen kann ein Programm einzelne keystrokes (Tastendrücke) abfragen. Wenn es nur stdin beherrscht, dann wird grundsätzlich ein Keyboard-Input mit einem Abschließen durch ein RETURN erwartet. Somit sind alle Programme, die einzelne Tastendrücke verwerten, also beispielsweise

---waiting------press any key--------

(wohlgemerkt "any key", nicht "press ENTER")

oder
press (Y) for Yes or (N) for No

ohne dass man noch ein ENTER dahinter schreiben muss, die für mich kritischen Kandidaten, solange nicht auch VIO Output verwendet wird.

Genau diese Programme machen mir Probleme, wenn vorher kein VIO Output stattgefunden hat und somit das VIO-PM-Fenster noch nicht automatisch sichtbar gemacht wurde.

Natürlich ist das kein Beinbruch, der Nutzer kann mit dem Button "VIO sichtbar" immer selbst eingreifen. Momentan habe ich nur das Original MORE von OS/2 gefunden, das dieses Problem erzeugt. Wenn es nicht '"press any key", sondern "press ENTER" wäre, dann wäre es auch kein Problem. Ich befürchte aber, dass es noch mehr Programme gibt.

Letztlich müssen wir abwarten, bis ich meine erste Betaversion Euch zur Verfügung stelle, dann bitte ich um entsprechende Berichte von Programmen, wo es noch hakt, und dann überlege ich, wie man am besten damit umgeht. Aber dafür brauche ich eben erst einige Beispiele, die ich jetzt noch nicht kenne. In ein bis zwei Wochen bin ich soweit. Es gibt dann schon eine weitghend vollständige Version, aber noch ohne Completion Funktionalität. Die wird dann technisch eher einfach umzusetzen sein, weil sie komplett im Editor stattfindet.
Zuletzt geändert von Martin Vieregg am Do 12. Mär 2020, 16:14, insgesamt 1-mal geändert.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Do 12. Mär 2020, 16:04
Hier scheint es wohl eher ein PM-Fenster zu sein.
Ja, ich nenne das PM-Fenster, in dem die VIO Anwendung (also cmd.exe) läuft, umgangssprachlich so.
Es ist zumindest nicht ausgeschlossen, daß eine Untermenge an Sonderfällen bei dieser Betrachtungsweise abgedeckt sein könnte,
Der Editor kann mit dem VIO-PM-Fenster kommunizieren (auf visible schalten, Titelzeilenbuttons manipulieren) und damit der (PM-)Editor mit cmd.exe kommunizieren kann, brauche ich die Helper exe.
Da wäre ich mir nicht so sicher. Wie sieht es aus, wenn mehrere Instanzen (ob nun beabsichtigt oder nicht) gestartet wurden.
Der PM Editor startet die Helper exe in einer neuen Session und die Helper exe startet dann in derselben Session cmd.exe bzw. 4os2.exe. Da die Helper exe in derselben Session läuft wie cmd.exe, kann sie exceptions schicken, den VIO-Inhalt ansehen usw., was sonst der PM Editor nicht könnte.
Solange der PM nicht verlassen wird, man nehme einen Prozeßmonitor, kann ich dieses Verhalten nicht nachvollziehen.
Die keyboard Abfragen sind unter KBD calls gelistet. Dieser Input läuft unabhängig von stdin direkt ans VIO Subsystem. Es gibt somit Programme, die VIO bzw. KBD calls nutzen, aber keinen VIO Output generieren, weil sie nur VIO/KBD input verwenden. Mit diesen Aufrufen kann ein Programm einzelne keystrokes (Tastendrücke) abfragen. Wenn es nur stdin beherrscht, dann wird grundsätzlich ein Keyboard-Input mit einem Abschließen durch ein RETURN erwartet. Somit sind alle Programme, die einzelne Tastendrücke verwerten, also beispielsweise
So direkt, wie hier behauptet läuft es unter dem PM nun auch nicht ab. Außer der Möglichkeit mittels VioRegister/KbdRegister bzw. VioDeRegister/KbdDeRegister das BVS zu umgehen, gibt es bei AVIO deutlich mehr Eingriffsmöglichkeiten. Wenn es nicht aus dem Referenzhandbuch hervorgehen sollte, würde ich die Beispiele aus der Developer Connection (Volume 6) empfehlen. Oder eventuell eines der Beispiele, wie die Zwischenablage bzw. der dynamische Datenaustausch aus der Befehlszeile heraus nutzbar gemacht werden kann.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Da wäre ich mir nicht so sicher. Wie sieht es aus, wenn mehrere Instanzen (ob nun beabsichtigt oder nicht) gestartet wurden.
Das ist natürlich berücksichtigt. Der PM Editor hat ja die Session mit der Helper exe gestartet, wo dann cmd.exe läuft. Ich muss auch wegen den Named Pipes die Sessions durchnumerieren. Zusätzlich zu mehreren Instanzen wird man wie schon bei ME mehrere PM-Fenster derselben Sitzung starten können, um mit einem Fenster hochscrollen und Editorinhalte außerhalb des sichtbaren Editorfensters vergleichen zu können. Nur das aktive Fenster scrollt weiter, wenn man neue Befehle eingibt, und die weiteren Fenster bleiben stehen.
(PM Editor kann über den Helper mit cmd.exe kommunizieren)
Solange der PM nicht verlassen wird, man nehme einen Prozeßmonitor, kann ich dieses Verhalten nicht nachvollziehen.
Das geht tatsächlich, aber nur immer indirekt über den Helper. Der Helper empfängt Semaphoren vom PM Editor und schaut dann im Shared Memory nach, was er tun soll. Dann schickt er Exceptions an cmd.exe oder schaut sich den VIO Speicher an und schickt die Antwort dann wieder über Semaphoren zurück an den PM Editor. Das läuft tatsächlich alles schon prima !

Es war nur ein Einziger im englischen os2.world.com Programmiererforum, der von Anfang an wußte, wie das geht (Wim Brul), selbst andere bekanntermaßen fitte OS/2-Programmier wußten es nicht. Komischerweise muss man wirklich den Helper und cmd.exe in einer separaten Session laufen lassen. Alle Versuche, alles in derselben Session laufen zu lassen, schlugen fehl. Weil es zwei Sessions sind, musste ich dann Named Pipes und nicht Unnamed Pipes verwenden. Unnamed Sempapohres gehen aber schon. Die Speicheradressen der Semaphoren und des Shared Memory gibt der PM Editor über Kommandozeilenparamter an die Helper exe weiter, außerdem die Instance-Number, die dann Auswirkung auf den Namen der Named Pipes hat. Um den richtigen Window Handle des PM-VIO-Fensters zu finden, geht der PM Editor die Switchentry Liste durch und schaut, welches Fenster die richtige Session ID hat. Letztlich war es nicht wirklich viel Programmieraufwand, aber die Diskussionen im Forum erstreckten sich über 2 Monate.
So direkt, wie hier behauptet läuft es unter dem PM nun auch nicht ab. Außer der Möglichkeit mittels VioRegister/KbdRegister bzw. VioDeRegister/KbdDeRegister das BVS zu umgehen, gibt es bei AVIO deutlich mehr Eingriffsmöglichkeiten. Wenn es nicht aus dem Referenzhandbuch hervorgehen sollte, würde ich die Beispiele aus der Developer Connection (Volume 6) empfehlen. Oder eventuell eines der Beispiele, wie die Zwischenablage bzw. der dynamische Datenaustausch aus der Befehlszeile heraus nutzbar gemacht werden kann.
Ich komme momentan mit der helper exe ja gut klar, mit Ausnahme der Frage, ob man nicht vielleicht doch herausbekommen könnte, ob das VIO Subsystem auf einen Keyboard Input wartet oder nicht. Ich mache jetzt wie gesagt erstmal den PM Editor soweit fertig, dass ihr ihn testen könnt. Es fehlt noch das Einstellungen-Buch mit Nutzereinstellungen, und bei der Multiwindow-Funktionalität sind noch Bugs, also alles reine PM Editor Geschichten, die keine größeren Schwierigkeiten erwarten lassen. Dann müssen wir alle gemeinsam noch überlegen, was noch möglich ist und was nicht.
Antworten