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
Posts: 241
Joined: Tue 19. Aug 2014, 09:30

Liste von textbasierten VIO-Programmen

Post by Martin Vieregg » Wed 12. Feb 2020, 08:37

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 Wed 12. Feb 2020, 08:54, insgesamt 1-mal geändert.

Martin Vieregg
Posts: 241
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Fri 21. Feb 2020, 23:39

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.

User avatar
Wimpie
Posts: 53
Joined: Sat 10. Jan 2015, 21:58
Location: Uithoorn

Post by Wimpie » Sat 22. Feb 2020, 16:47

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: Select all

/* 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
Posts: 300
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann » Sat 22. Feb 2020, 17:51

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 Sat 22. Feb 2020, 17:54, insgesamt 1-mal geändert.

Martin Vieregg
Posts: 241
Joined: Tue 19. Aug 2014, 09:30

Post by Martin Vieregg » Sun 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?

User avatar
ak120
Posts: 981
Joined: Thu 8. May 2014, 12:50
Location: Demmin

Post by ak120 » Mon 24. Feb 2020, 01:15

Martin Vieregg wrote:
Sun 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
Posts: 300
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann » Mon 24. Feb 2020, 09:50

Martin Vieregg wrote:
Sun 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
Posts: 300
Joined: Mon 4. Jan 2016, 14:36

Post by erdmann » Mon 24. Feb 2020, 09:52

If I ever find the time I can create some sample code in C.