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

Liste von textbasierten VIO-Programmen

Beitrag von Martin Vieregg »

Für mein Projekt einer neuen Kommandozeilenshell für cmd.exe und 4os2.exe (siehe Post unter Projekte) muss ich herausbekommen, wenn ein textbasiertes Programm mit VIO-Aufrufen in der Kommandozeile vom Nutzer aufgerufen wird, weil sie nicht in der neuen PM-basierten Shell ausgeführt werden können. Also die Programme, die keine PM-Programme sind, aber auch nicht bzw. nicht nur stdout und stderr Ausgaben produzieren. Ein Beispiel wäre dfsee oder der ted Editor mit seiner sagenhaften Dateigröße von 7 kB, aber es gibt vereinzelt auch kleine Utilities, die über die reine stdout/stderr Ausgabe hinausgehen. Bitte helft mir, eine Liste derartiger Programme anzulegen. Ich hoffe dann durch Binärvergleich ein regelmäßiges Muster zu finden, um derartige Programme grundsätzlich erkennen zu können. Schließlich wird immer dieselbe Bibliothek bzw. werden dieselben Funktionsaufrufe verwendet. Diese Programme sollen dann künftig automatisch von meinem Programm erkannt und in einem separten Cmd-Fenster geöffnet werden.

Wenn man nach "VIOCALLS" in den Binaries sucht, dann kommen auch einige Programme, die meines Erachtens diese gar nicht nutzen, z. B. xcopy

Damit kann man suchen:

[C:\] do search *.exe VIOCALLS

Wer das DO Utility noch nicht hat: DO Download
(Bislang kann man mit DO nicht nach Sonderzeichen suchen.)

Gibt es Programme zum Analysieren von Binaries? Ich habe nur Hexedit-2 zum Anschauen der Binaries.
Zuletzt geändert von Martin Vieregg am Mi 12. Feb 2020, 08:54, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ich habe mich jetzt entschlossen, beim Aufrufen eines Executables die ersten 64kB zu durchsuchen, ob VIOCALLS vorkommt - das steht wirklich so in der EXE. Wenn dann nach einer bestimmten Zeit (wahrscheinlich einstellbar), standardmäßig 0,5 Sekunden, kein STDOUT ankommt, wird automatisch das VIO Fenster aktiviert. Es gibt einen Schalter, wo man jederzeit zwischen VIO-Fenster und dem PM Editor-Stdout Fenster hin- und herschalten kann. Komischerweise ist nämlich in manchen Stdout-Programmen, wo man es nicht erwartet, auch VIOCALLS enthalten, so etwa XCOPY oder SORT. Oft ist das dann nur ggfs. eine Fehlermeldung, die im VIO-Fenster erscheint statt im STDOUT. Durch das Warten, ob nicht doch STDOUT kommt, wird dann bei diesen Programmen das VIO-Fenster nicht automatisch aktiviert. Ich kann allerdings nicht sehen, ob cmd.exe etwas ins VIO Fenster schreibt.

Mit dieser Strategie wird es nicht erforderlich sein, eine Ausnahmeliste von VIO-Programme anzulegen.

Komplizierter wird es mit CMD-Dateien, wo auch VIO Executables enthalten sein können. Hier werde ich, wenn der Nutzer .cmd anhängt, den Inhalt der Datei Zeile für Zeile an cmd.exe schicken. Dann kann mein Programm wieder analysieren, ob ein VIO Programm dabei ist.

Die Komplexität des Projektes ist doch höher als ich usprünglich gedacht habe - wer Lust hat, kann mal die englischen Programmiererdiskussionen unter dem englischsprachigen os2world.com Programmers Forum verfolgen (mehrere Threads zu verschiedenen Unterthemen). Ich habe aber trotz verbleibender Probleme und Aufgaben schon eine Menge Sachen erfolgreich lösen und programmieren können und werde dort super unterstützt. Der ganze Bereich Threads, Semaphoren, Sessions, Exceptions und Pipes läuft schon super.

Es hat sich herausgestellt, dass der komplizierteste Aspekt am neuen cmd-Frontend die Unterscheidung in cmd.exe zwischen stdout und VIO Ausgaben ist. Das ist einem sonst gar nicht klar, wenn man einfach cmd.exe benutzt. Das ist wahrscheinlich der DOS-Historie geschuldet, wo der Bildschirm noch langsam war und man (bei VIO) direkt in den Bildschirmspeicher geschrieben hat.

Weiß jemand eigentlich ein Programm, das in der Kommandozeile läuft, nicht in das VIO-Fenster schreibt und trotzdem Cursor-Sprung-Befehle (etwa Menüführung) über ESC-Sequenzen nutzt ? Ich kenne momentan keines. (DOS-Programme werden ja in meiner Shell nicht laufen.) Ich habe zwar bei den ESC-Sequenzen Farben umgesetzt, aber keine Cursor-Sprungbefehle.
Benutzeravatar
Wimpie
Beiträge: 54
Registriert: Sa 10. Jan 2015, 21:58
Wohnort: Uithoorn
Kontaktdaten:

Beitrag von Wimpie »

Gibt es Programme zum Analysieren von Binaries? Ich habe nur Hexedit-2 zum Anschauen der Binaries.
What you could use is the Executable File Header Utility [EXEHDR] which you will find in the OS/2 2.45 toolkit.

When you type "exehdr /v xcopy.exe" then for VIOCALLS it shows:
    PTR     4b69  imp VIOCALLS.19
This means xcopy.exe imports only VIOCALLS.19 which is Vio16WrtTty().

I tried and used the following rexx code to inspect some executables:

Code: Alles auswählen

/* analyse executable import viocalls */
parse upper arg efn SuperfluousArguments
if (efn == '') then return

ifn = 'exehdr.txt'

'@e:\os2ddk\base32\tools\os2.386\bin\exehdr /v 'efn' > 'ifn

needle = ' imp '
do while lines(ifn) <> 0
  haystack = linein(ifn)
  there = pos(needle,haystack)
  if (there > 0) then do
    line = substr(haystack,there+length(needle))
    if (left(line,8)=='VIOCALLS') then say line
    end
  end

return
Which resulted into:

[E:\WIM\PROJECT\EXEHDR]viocalls h:\os2\xcopy.exe
VIOCALLS.19

[E:\WIM\PROJECT\EXEHDR]viocalls h:\os2\sort.exe
VIOCALLS.19

[E:\WIM\PROJECT\EXEHDR]viocalls h:\os2\tedit.exe
VIOCALLS.9 alias
VIOCALLS.15 alias
VIOCALLS.21 alias
VIOCALLS.24 alias
VIOCALLS.27 alias
VIOCALLS.32 alias
VIOCALLS.48 alias
VIOCALLS.52 alias
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Of course, with the LX format spec which comes with the OS/2 toolkit and a few toolkit header files (like exe386.h) you can also scan the import table of the executable without having to start an external application. Which also means you do not need to scan arbitrary parts of the executable. No guesswork needed.
Zuletzt geändert von erdmann am Sa 22. Feb 2020, 17:54, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

It would be a great step to know the specific vio calls. How can I make this analysis of the header of an exe binary via C code and OS/2 API calls?
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: So 23. Feb 2020, 13:25 It would be a great step to know the specific vio calls. How can I make this analysis of the header of an exe binary via C code and OS/2 API calls?
EXEHDR, welches für NE und LX geeignet ist, wurde ja bereits schon erwähnt. Es gibt genügend frei verfügbare Programme wie z.B. OS2Trace und OS2Call, um die Nutzung von APIs bzw, Subsystemen nachzuvollziehen. Als interaktive Werkzeuge können alternativ auch FileSpy oder Typ dienen. Eine Betrachtung von oftmals aufwendigeren Analyselösungen würde an dieser Stelle wohl den Rahmen sprengen. Es kann generell empfohlen werden, sich mit dem Prozeßmodell von OS/2 vertraut zu machen, um nicht den Überblick zu verlieren.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Martin Vieregg hat geschrieben: So 23. Feb 2020, 13:25 It would be a great step to know the specific vio calls. How can I make this analysis of the header of an exe binary via C code and OS/2 API calls?
As I said: read the LX spec,then look at the header files that come with the toolkit,in particular,exe386.h,exe.h and newexe.h.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

If I ever find the time I can create some sample code in C.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Danke Lars für Dein Angebot. Ich bräuchte letztlich ein paar Zeilen C Code, wo ich eine Liste der in der EXE verwendeten VIO-Calls erhalte. Ich würde mir tatsächlich eine Menge Arbeit sparen, weil ich mich erst einarbeiten müsste. Das EXEHDR Programm habe ich zwar gefunden, nicht jedoch den Quelltext dazu.

Komisch ist, dass bei XCOPY oder bei SORT mit 19 "VIOWRTTTY" vermeintlich eine VIO-Textausgabe unterstellt wird. Doch das VIO-Fenster bleibt leer, es geht alles über STDOUT, auch wenn es eine Y/N Frage gibt. Besser wäre es natürlich, wenn ich die tatsächlichen VIO calls beobachten könnte, aber das dürfte nicht gehen. Wenn ich Compiler und Linker richtig verstehe, werden die aufgeführten Calls auch wirklich genutzt, weil ja der Linker alles Unbenutzte eigentlich aus dem Binarycode werfen sollte.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Ja,wenn eine DLL in der Importtabelle auftaucht, dann wird sie auch genutzt.
Es gibt auch tatsächlich Programme die für Teile ihrer Textausgabe STDOUT und/oder STDERR nutzen und für andere Teile die direkte Bildschirmausgabe.
In C stellt sich das so dar: bindet der Quelltext conio.h ein,dann erfolgt die direkte Bildschirmausgabe,wird hingegen stdio.h eingebunden,dann erfolgt die Ausgabe über die (umleitbaren) standard streams.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Tatsächliche calls beobachten: das würde gehen wenn du dir eine DLL schreibst,die als Forwarder für alle Routinen in VIOCALLS dient. Diese DLL muss die gleiche Dateinamenlänge haben,kann aber ansonsten beliebig heissen. Dann müssen mittels eines renaming tools ( z.B. dllrname.exe aus dem VAC toolkit) alle Referenzen auf VIOCALLS im executable auf deine DLL umbenannt werden. Hat nun deine DLL die nötige Funktionalität um z.B. jeden Routinen Aufruf zu tracen kannst du sehen was genau wann aufgerufen wird. Das Problem ist,dass hierzu das Executable modifiziert werden muss.
Übrigens funktioniert das OS2TRACE Tool genau so. Es erlaubt auch die "Rückbenennung" um den Originalzustand wieder herstellen zu können. Das ist also eine temporäre Lösung zur Analyse und keine dauerhafte Lösung.
Benutzeravatar
Wimpie
Beiträge: 54
Registriert: Sa 10. Jan 2015, 21:58
Wohnort: Uithoorn
Kontaktdaten:

Beitrag von Wimpie »

Besser wäre es natürlich, wenn ich die tatsächlichen VIO calls beobachten könnte, aber das dürfte nicht gehen.
Perhaps you could try and use OS/2 API Trace by Dave Blaschke.
Benutzeravatar
efbe
Beiträge: 69
Registriert: Do 11. Sep 2014, 19:33
Wohnort: Dortmund

Beitrag von efbe »

Falls dir die Information der aufgerufenen VIOCALLS je Programm reicht, also ohne Modifikation des Programms und Aufruf mit OS2trace, gibt es OS2Call ( bei Hobbes, ebenfalls von Dave Blaschke).
Damit ist eine Analyse für mehr als ein Pgm auf einmal möglich.
MfG
Frank
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

I have moved the discussion to OS/2 World Programmers forum
Da das Thema jetzt für "OS/2 Apps" zu technisch geworden ist, habe ich das Thema nun umgezogen in das OS/2 World Programmers forum (englisch).
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Inzwischen geht im englischen Programmiererforum die Diskussion weiter und es hat sich herausgestellt, dass es mit Hilfe des API Aufrufs VioGetCurPos möglich ist, Output im VIO Fenster feststellen zu können, in dem man die VIO Cursorposition beobachtet und Änderungen feststellt. Ich werde also nun eine sichere Lösung für das Umschalten auf VIO Fenster realisieren können und muss auf keine "Frickellösung" zurückgreifen, mit Ausnahme dass dann quasi zwei Ausgabefenster gibt. (Die bisherige Lösung mit nur einem Fenster fand ich aber auch "frickelig", weil VIO den alten stdout Output überschreiben konnte, was ein ganz schönes Chaos im Kommandozeilenfenster anrichten konnte.) Ich verfüge ohnehin schon über ein Helper Programm, das der Kommunikation zwischen meinem PM Editor und cmd.exe dient, und zumindest der Helper kann sich das VIO Fenster ansehen und ggfs. dann dem PM Programm eine Botschaft schicken. Damit dürfte das Problem tatsächlich gelöst sein. Soweit ich das überblicke, war das der letzte Knackpunkt, der die Nutzbarkeit des neuen Kommandozeilen-Frontends hätte einschränken können.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

VIO-Ausgaben sind auch möglich, ohne die Cursorposition zu ändern. Und das Verfahren des Pollings der Cursorposition kann durch "geschicktes" Timing auf Seiten der Clientapplikation in die Irre geführt werden. Sorry, aber das Problem ist nicht umfassend und korrekt lösbar, ohne das gesamte Konsolensubsystem zu erneuern. Was aber ohne Sourcecode schwer fallen dürfte...
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Ist es nicht so, dass im VIO Fenster immer die Cursorposition hinter dem letzten ausgegebenen Buchstaben liegt? Dann würde nur ein Überschreiben eines schon vorhandenen VIO Outputs die Cursorposition nicht ändern. Das ist aber für meinen Fall nicht interessant, weil mich nur die erste Änderung der Cursorposition interessiert, um daraus den Schluss zu ziehen, dass überhaupt etwas im VIO-Fenster passiert ist. Dann poppt das Fenster automatisch hoch und der User übernimmit die Steuerung. Wenn mein Editor tatsächlich einmal eine Aktivität im VIO-Fenster verpasst und der User das bemerkt, kann er ja immer noch mit Drücken auf den "VIO Visible" Button das Fenster anzeigen lassen. Es geht nur um die Automatik, die natürlich möglichst perfekt sein sollte. Das Verschwinden des VIO-Fensters geschieht grundsätzlich immer durch den User. Prinzipiell könnte ich aber auch noch weitere VioGet... Aufrufe nutzen, um die Veränderung von anderen Eigenschaften zu beobachten. Der User hat auch die Möglichkeit, das VIO Fenster offen zu lassen und neben dem PM Fenster anzuordnen.
Zuletzt geändert von Martin Vieregg am Fr 28. Feb 2020, 11:02, insgesamt 1-mal geändert.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

Wenn ich mich recht erinnere, beeinflußt nur VioWrtTTY die Cursorposition. Alle anderen VioWrtXXX lassen den Cursor in Ruhe. Was auch Sinn macht, denn wenn ich z.B. in der rechten oberen Ecke die Uhrzeit einblenden möchte, der Cursor nicht jedes mal dahin springen sollte. Auf jeden Fall sollte es möglich sein, daß ein Programm so zu konstruieren, daß es den vorgeschlagenen Erkennungsmechanismus austrickst. Und damit ist es keine allgemeingültige Lösung. Schon die Vorgehensweise des Pollens der Verhaltensweise des Childprozesses ist aus Sicht eines Systemprogrammierers zumindest grenzwertig...

Irgendwie fühle ich mich um Jahrzehnte zurückversetzt: Als ich damals von DOS/Windows auf OS/2 umgestiegen bin, war das eine Offenbarung. Alle Dinge, die unter den alten Betriebssystemen fragwürdige Hacks benötigten, waren plötzlich mit sauberen API-Funktionen realisierbar. Seit geraumer Zeit ist es allerdings so, daß das damals so tolle OS/2 inzwischen das Hemmnis darstellt und die fragwürdigen Hacks benötigt. Daher bin ich weg davon...
Zuletzt geändert von ehemaliger am Sa 29. Feb 2020, 22:09, insgesamt 1-mal geändert.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Sinnvoll wäre natürlich das Neuprogrammieren des gesamten VIO-Bereichs. Ich denke das wäre schon mal längerfristig möglich. Mein "Hack" funktioniert jetzt schon ganz gut, ich habe bislang ein Programm gefunden (TED.EXE Editor), das nicht erkannt wird. Ich werde noch einen weiteren vom User zuschaltbaren Mechanismus einbauen, dass der gesamte Screenbuffer verglichen wird und nicht nur die Cursorposition. Der Editor muss sich das nicht ständig ansehen, er weiß um die kritischen Momente. Also ein Befehl wird mit ENTER abgeschickt und es kommt trotzdem kein Stdout, den er anzeigen könnte. Dann auch noch wenn der Befehl beendet ist und ein neuer Prompt erscheint, checkt er nochmal den VIO Inhalt. Das läuft jetzt schon recht gut. Der Screenbuffer ist ja auf 8192 Zeichen beschränkt, d.h. es müssen nur 8192 Bytes beobachtet werden. Das ist mit den heutigen Rechnern kein Thema mehr.

Sicherlich wird mein Programm am Anfang noch Haken und Ösen haben, ich muss einige Spezialfälle von Hand abfangen. Ich brauche dann das Userfeedback von euch, dann sollte es schon klappen. Ich finde das Konzept VIO und Stdout gemischt wie in allen DOS-Windows-OS/2 Kommandozeilen auch keine wirklich saubere Lösung. Es kann immer mal passieren, dass VIO Output und Stdout im Fenster durcheinandergerät. Bei mir ist es getrennt, das ist nicht nur ein Nachteil, solange alles sauber auf- und zuploppt. Der User kann jederzeit das VIO Fenster herholen und wieder verdecken.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Nachdem ich mich mit den VIO API Aufrufen etwas beschäftigt habe, musste ich feststellen, dass an zahlreichen Stellen die Variablen zum Zugriff auf den VIO Buffer USHORT sind. Das 8192 Zeichen Limit des VIO Buffers erklärt sich so: Um in True Color ein Zeichen darzustellen, braucht man 3 Bytes für die Vordergrund- und 3 Bytes für die Hintergrundfarbe, dann die Attributes (1 Byte) und das eigentliche Ascii-Zeichen (1 Byte). Macht 8 Bytes. 8 x 8192 = maxushort. In der Regel werden 2 Bytes für ein Zeichen verwendet (ASCII-Zeichen und kombiniertes Attribute/Color Byte). Um das Limit aufzuheben, bräuchte man also eine neue VIO32 API und neue VIO Programme und einen Kompatibilitätsmodus, um die alten VIO Programme ausführen zu können. Ich vermute mal, dass man bei Windows NT den Schritt zum VIO32 gemacht hat (?).
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Di 3. Mär 2020, 09:24 Nachdem ich mich mit den VIO API Aufrufen etwas beschäftigt habe, musste ich feststellen, dass an zahlreichen Stellen die Variablen zum Zugriff auf den VIO Buffer USHORT sind.
Aus den im Toolkit enthaltenen Kopfdateien und der enthaltenen Dokumentation geht dies nicht hervor.
Das 8192 Zeichen Limit des VIO Buffers erklärt sich so: Um in True Color ein Zeichen darzustellen, braucht man 3 Bytes für die Vordergrund- und 3 Bytes für die Hintergrundfarbe,
Diese Darstellung entspricht leider nicht der Realität.
dann die Attributes (1 Byte) und das eigentliche Ascii-Zeichen (1 Byte). Macht 8 Bytes. 8 x 8192 = maxushort.
Selbst wenn es in der Phantasie ein solches Konzept geben würde, wäre es doch äußerst ineffizient. Zudem wäre auch nur weitverbreitete Sonderfall einfarbiger Zeichen abgedeckt.
In der Regel werden 2 Bytes für ein Zeichen verwendet (ASCII-Zeichen und kombiniertes Attribute/Color Byte).
Das möchte ich bezweifeln. Vio unterstützt Zellen zu 2 oder 4 Byte - mit Zeichen kann man es so nicht vergleichen. Von ASCII sollte auch nur die Rede sein, wenn eine entsprechend verträgliche Zeichentabelle zur Vorbedingung gemacht wurde.
Um das Limit aufzuheben, bräuchte man also eine neue VIO32 API und neue VIO Programme und einen Kompatibilitätsmodus, um die alten VIO Programme ausführen zu können.
Fragt sich nur wozu? Die API ist doch vorhanden und die Subsysteme sind modular und austauschbar.
Ich vermute mal, dass man bei Windows NT den Schritt zum VIO32 gemacht hat (?).
Nein, alle Windows-NT-Versionen inklusive Windows 2000 unterstützen nur das 16-bit OS/2-Subsystem. Die unterstützte API kann man dem Ressource Kit entnehmen.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Aus den im Toolkit enthaltenen Kopfdateien und der enthaltenen Dokumentation geht dies nicht hervor.
Wir haben eine entsprechende Diskussion im englischsprachigen Forum:

Es scheint so zu sein, dass das Toolkit zum Teil die neuere VIO32 Schnittstelle beschreibt, die es aber nie ins Serien-OS/2 - ArcaOS geschafft hat.

http://www.edm2.com/index.php/VioReadCharStr_%28FAPI%29
http://www.edm2.com/index.php/VioReadCharStr

Dort sieht man den Unterschied, gerade bei den USHORT/ULONG Variablen. FAPI ist die alte 16 bit Version, die wir alle nutzen. Die EDM2 Doku muss aber an einigen Stellen überarbeitet werden, es gibt keine Querverweise zwischen der FAPI- und der 32-Bit Version.
Das 8192 Zeichen Limit des VIO Buffers erklärt sich so: Um in True Color ein Zeichen darzustellen, braucht man 3 Bytes für die Vordergrund- und 3 Bytes für die Hintergrundfarbe,

Diese Darstellung entspricht leider nicht der Realität.
Es gibt real kein True Color in VIO Fenstern, aber die API sieht das tatsächlich vor. Siehe VIOMODEINFO, dort ist tatsächlich True Color erwähnt.
Nein, alle Windows-NT-Versionen inklusive Windows 2000 unterstützen nur das 16-bit OS/2-Subsystem.
Ich meine natürlich, ob es für Windows Kommandozeilenprogramme ein 32-bit VIO Subsystem gibt.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Do 5. Mär 2020, 18:51
Aus den im Toolkit enthaltenen Kopfdateien und der enthaltenen Dokumentation geht dies nicht hervor.
Wir haben eine entsprechende Diskussion im englischsprachigen Forum:

Es scheint so zu sein, dass das Toolkit zum Teil die neuere VIO32 Schnittstelle beschreibt, die es aber nie ins Serien-OS/2 - ArcaOS geschafft hat.

http://www.edm2.com/index.php/VioReadCharStr_%28FAPI%29
http://www.edm2.com/index.php/VioReadCharStr
Ein 32-bit Vio-Subsystem gab es nur für die OS/2-PowerPC-Variante. Systemseitig ist bei den ausgelieferten Intel-Varianten alles weiterhin 16-bit. Analog dazu auch die entsprechend genutzten Datenstrukturen.

Leider wurde ohne Sinn und Verstand ziemlich viel unreflektiert und teilweise zusammenhanglos in EDM/2 hineinkopiert. Berichtigungen sind dort auch eher unerwünscht. Die Kopfdateien für die Definitionen der Subsysteme (\toolkit\h\bsesub.h bzw. \toolkit\inc\bsesub.inc) sollten deutlich aussagekräftiger und näher an der Realität sein.
Dort sieht man den Unterschied, gerade bei den USHORT/ULONG Variablen. FAPI ist die alte 16 bit Version, die wir alle nutzen. Die EDM2 Doku muss aber an einigen Stellen überarbeitet werden, es gibt keine Querverweise zwischen der FAPI- und der 32-Bit Version.
Nicht jeder VioXXX-Aufruf gehört zwingend zur Family-API. Weiterhin sollte bei den zugehörigen Funktionen das unterschiedliche Verhalten unter DOS und die Abhängigkeiten von der Ausführungsumgebung beachtet werden.

Tatsache ist, daß einfach alles blind aus unterschiedlichen Online-Dokumenten der CP-Referenz dort hinüberkopiert wurde, bzw. aus zuvor nach HTML gewandelten Dokumenten, was die Fehlerhaftigkeit noch weiter erhöht.
Das 8192 Zeichen Limit des VIO Buffers erklärt sich so: Um in True Color ein Zeichen darzustellen, braucht man 3 Bytes für die Vordergrund- und 3 Bytes für die Hintergrundfarbe,

Diese Darstellung entspricht leider nicht der Realität.
Es gibt real kein True Color in VIO Fenstern, aber die API sieht das tatsächlich vor. Siehe VIOMODEINFO, dort ist tatsächlich True Color erwähnt.
Der Begriff "True colour" ist dort nirgends zu finden. Sicherlich kann das Feld "color" in der Struktur Werte von 0 bis 255 aufweisen. Aber es ist von der Implementierung des entsprechenden Adaptertreibers abhängig, welche Betriebsarten auch tatsächlich mit den gängigen Mitteln nutzbar sind.
Nein, alle Windows-NT-Versionen inklusive Windows 2000 unterstützen nur das 16-bit OS/2-Subsystem.
Ich meine natürlich, ob es für Windows Kommandozeilenprogramme ein 32-bit VIO Subsystem gibt.
[/quote]
Ein Vio-Subsystem kann es konstruktionsbedingt nur für OS/2-Programme geben und auch nur für die x86-Editionen von Windows NT. Erst in späteren Windows-Versionen wurde die Windows Console API mit erweiterten Möglichkeiten eingeführt.

Mir scheint, daß die ganze Diskussion in eine nicht zielführende Richtung verläuft. Wenn ich das Ansinnen richtig verstanden habe, ging es doch ursprünglich darum, eine Art Kommunikation zwischen einem PM-Programm und einem anderen Prozeß, welcher Vio-Aurufe nutzt zu bewerkstelligen bzw. umzuleiten. Es gibt genügend praktische Beispiele, welche verschiedene Möglichkeiten verwenden. Am ehesten würde man zu einem Verfahren wie es DCAF verwendet greifen. Eine Ebene drunter könnte man den Gemeinsamen Speicher anzapfen.
Martin Vieregg
Beiträge: 459
Registriert: Di 19. Aug 2014, 09:30

Beitrag von Martin Vieregg »

Zwischenzeitlich habe ich meine Programmieraufgabe für mein Kommandozeilen-Frontend recht gut lösen können. Es gibt ja schon eine sog. cmdhelper.exe, die in der cmd.exe session läuft und für die Kommunikation zwischen meinem Editor und cmd.exe zuständig ist. Angefangen hat es damit, dass ich ein Ctrl-C des Users im Editor als Exception an cmd.exe senden wollte. Wenn der Editor eine VIO-Aktivität vermutet, weil kein stdin ankommt und auch kein Prompt erscheint, dann sendet er die Frage an den Helper. Der Helper vergleicht dann mit VioReadCharStr den Textspeicher-Inhalt mit dem letzten Inhalt (bei 80x25 sind das gerade einmal 2000 Bytes) und so kann er herausbekommen, ob zwischenzeitlich ein VIO Output stattgefunden hat. Wenn ja, sendet er eine Botschaft an den Editor zurück und der Editor schaltet das VIO Fenster auf Visible und in den Vordergrund. Das klappt recht gut. Es gibt dann noch einen Spezialfall mit "| more", weil "more" einen VIO-Tastaturinput erwartet, ohne dass vorher ein VIO Output passiert ist. Der Stdout Output bleibt dann stehen, ohne dass das VIO fenster hochpoppt. Dieser Fall ist noch nicht abgefangen. Aber letztlich hat "more" und seine Derivate in meinem Programm nicht mehr viel verloren, weil ja der Editor die "more" Funktionalität viel besser abdeckt. Wie ich mit solchen Eingaben umgehe und diese zuverlässig erkenne, muss ich mir noch überlegen. Der Editor wird wie mein ME Editor eine wahlweise Funktionalität haben, dass der stdout von cmd.exe nicht sofort weiter angezeigt wird, sondern nur wenn man mit PgDn herunterblättert. Dass noch ein stdout ankommt, sieht man an einer roten LED (= keine Prompt-Eingabe momentan möglich) und am kleiner werdenden Scrollbalken. Mit ESC kann man immer zum aktuellen Prompt bzw. zum Ende des Outputs springen. Die Überlegung am Anfang des Threads, eine Ausnahmenliste mit VIO-Programmen anzuelgen, wird also verzichtbar sein.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Martin Vieregg hat geschrieben: Di 10. Mär 2020, 21:20 Wenn ja, sendet er eine Botschaft an den Editor zurück und der Editor schaltet das VIO Fenster auf Visible und in den Vordergrund.
Hier scheint es wohl eher ein PM-Fenster zu sein.
Das klappt recht gut. Es gibt dann noch einen Spezialfall mit "| more", weil "more" einen VIO-Tastaturinput erwartet, ohne dass vorher ein VIO Output passiert ist.
Keine Ahnung woher diese Fehlbetrachtung kommt. Wie soll eine Tasteneingabe über Video-I/O (Vio) funktionieren? Selbst im Sonderfall eines Tastbildschirms wäre statt Vio das zusätzliche Tou-Subsystem zuständig.
Der Stdout Output bleibt dann stehen, ohne dass das VIO fenster hochpoppt.
Ist hier wirklich ein Vio-Fenster oder nicht eher ein PM-Fenster gemeint? Es höchstwahrscheinlich wahrscheinlicher, daß eine System-Semaphore nicht wieder freigegeben wurde.
Antworten