KEYPRESS.COM

[Fauler Sagg (Gast)]

> d:\>keypress
> This version of C:\KEYPRESS.COM is not compatible with the version of
> Windows you're running. Check your computer's system information and then
> contact the software publisher.

Tja, hat mal einner Lust daraus ein 64 bit PE machen?
Vorzugsweise in (Flat-)Assembler.
Ich würd ja, hab aber keine Ahnung von 64 bit und so.

Sind ja nur 21 Byte...

Ein paar BIOS-Calls und eine DOS-Funktion sehe ich im Hexdump.

[Rufus Τ. F. (rufus)]

Und was soll das tolle DOS-Programm machen?

[Fauler Sagg (Gast)]

> Und was soll das tolle DOS-Programm machen?

Du bist ja noch fauler als ich.

Jedenfalls hat es jahrtausendelang gut funktioniert.

; File Name   :  KEYPRESS.COM
; Format      :  MS-DOS COM-file
; Base Address:  1000h Range: 10100h-10115h Loaded length: 15h

.686p
.mmx
.model tiny


; Segment type:  Pure code
seg000 segment byte public 'CODE' use16
assume cs:seg000
org 100h
assume es:nothing, ss:nothing, ds:seg000, fs:nothing, gs:nothing


; Attributes: noreturn

public start
start proc near
mov  ah, 1
int  16h    ; KEYBOARD - CHECK BUFFER, DO NOT CLEAR
      ; Return: ZF clear if character  in buffer
      ; AH = scan code, AL = character
      ; ZF set if no character in buffer
jnz  short loc_1010A
xor  al, al
jp  short loc_10110

loc_1010A:
mov  ah, 0
int  16h    ; KEYBOARD - READ CHAR FROM BUFFER, WAIT IF EMPTY
      ; Return: AH = scan code, AL = character
mov  al, ah

loc_10110:
mov  ah, 4Ch
int  21h    ; DOS -  2+ - QUIT WITH EXIT CODE (EXIT)
start endp    ; AL = exit code

retn
seg000 ends


end start

[Jim M. (turboj)]

Wozu braucht man sowas unter Windows?

CMD.exe kennt das "pause" Kommando von Haus aus.

Eine 64-Bit Windows PE Anwendung sähe deutlich anders aus, denn dort 
würden entsprechende Windows Funktionen aufgerufen. Int 21h gab es nur 
unter 16-Bit DOS.

[Rufus Τ. F. (rufus)]

Danke an Jim, damit hat sich das Thema offensichtlich erledigt.

[Fauler Sagg (Gast)]

> offensichtlich erledigt.

"pause" taugt als Ersatz micht.

Es geht um das Erkennen und Unterscheiden eines Tastendrucks im
laufenden Script.

"pause" kann das ja offensichtlich nicht.

Insoweit hat sich auch nichts erledigt.

[Niklas G. (erlkoenig)]

Fauler Sagg schrieb:
> Es geht um das Erkennen und Unterscheiden eines Tastendrucks im
> laufenden Script.

Was für ein Script denn? Ein .bat Script? Warum muss denn der 
KEYPRESS.COM-Ersatz in Assembler sein, kann deine Batch keine 
C-Programme aufrufen?

[Drückeberger (Gast)]

Fauler Sagg schrieb:
> Es geht um das Erkennen und Unterscheiden eines Tastendrucks im
> laufenden Script.

Dann nimm halt CHOICE.EXE, gehört auch unter aktuellem Windows noch zum 
Lieferumfang.

[Peter D. (peda)]

Fauler Sagg schrieb:
> Es geht um das Erkennen und Unterscheiden eines Tastendrucks im
> laufenden Script.

Tipp mal choice /? ein, damit kannst Du einzelne Tastendrücke auswerten.

[Fauler Sagg (Gast)]

> kann deine Batch keine C-Programme aufrufen?

Ja, können schon.
In einer unbekannten Umgebung kann das aber auch in einer fehlenden
Runtimeumgebung enden.

"choice" ist auch nur suboptimal, weil nur isalnums abgefragt
werden können.

"keypress" gibt einen Teil des Scancodes zurück.

[Niklas G. (erlkoenig)]

Fauler Sagg schrieb:
> In einer unbekannten Umgebung kann das aber auch in einer fehlenden
> Runtimeumgebung enden.

Dann kompiliert man sein C-Programm halt statisch, oder verzichtet auf 
C-Runtime-Funktionen. Sollte sich ja mit dem Win32-API machen lassen.

Assembler zu benutzen weil C nicht laufen könnte ist... spannend. Ein 
AMD64-Windows ist schon eine ziemlich gut definierte Umgebung. Das 
könnte man sogar in C# machen, .net ist ja vorinstalliert... Apropos, 
vielleicht geht das ja sogar in Powershell mit den entsprechenden 
.net-APIs - ganz ohne zusätzliche .exe .

Fauler Sagg schrieb:
> "keypress" gibt einen Teil des Scancodes zurück.
Die Frage ist natürlich, ob man für ein cmd.exe-Fenster überhaupt 
Scancodes abfragen kann!

[Rufus Τ. F. (rufus)]

Niklas G. schrieb:
> Die Frage ist natürlich, ob man für ein cmd.exe-Fenster überhaupt
> Scancodes abfragen kann!

Eine Konsolanwendung kann das, nur ist das eine Lösung eines Problemes, 
das nicht existieren würde, wenn ... die Anforderungen nicht 
scheibchenweise genannt werden würden.

Vielleicht kann man das ganze uralte ausgeklügelte Batchgeraffel, das 
der Threadstarter weiterverwenden will, auch einfach wegwerfen und 
stattdessen eine der sich in den vergangenen 30 Jahren möglich 
gewordenen anderen Lösungen verwenden ... aber dann müsste der 
Threadstarter sich halt bewegen und erklären, welches Problem er 
eigentlich lösen will.

Scancodes in Batchdateien sind ganz sicher nicht das eigentliche 
Problem.

[Niklas G. (erlkoenig)]

Rufus Τ. F. schrieb:
> Scancodes in Batchdateien sind ganz sicher nicht das eigentliche
> Problem.

Hab ich auch vermutet. Wahrscheinlich eine interaktive Anwendung als 
Batchprogramm, die sofort auf Tastendrücke reagieren muss. So etwas kann 
man z.B. mit C# als GUI-Anwendung fix besser neu bauen. Im Zweifelsfall 
ruft man (als Übergangslösung) die gewünschten Aktionen als 
Batch-Scripte auf...

[Peter D. (peda)]

Fauler Sagg schrieb:
> "choice" ist auch nur suboptimal, weil nur isalnums abgefragt
> werden können.

Ja so ist das halt, wenn man nicht damit rausrückt, was das ganze 
überhaupt soll.
In der Regel kommt man mit PAUSE, SET /P oder CHOICE recht weit.

[Marten Morten (Gast)]

Reden wir von diesem 
https://books.google.de/books?id=LRBokcwLB70C&pg=PA474 32 Jahre alten 
Programm?

Da starte ich ja noch lieber Windows Powershell ISE in Windows 10 als 
das. Tutorium gibt es bei 
https://docs.microsoft.com/de-de/powershell/scripting/components/ise/introducing-the-windows-powershell-ise?view=powershell-6

[DPA (Gast)]

Hier, ein Posix shellscript dafür:

#!/bin/sh

stty cbreak -echo # Disable tty line buffering & echo
input=$(dd bs=1 count=1 2>/dev/null)
stty -cbreak echo # enable tty line buffering & echo

i=0
while [ $# != 0 ] && [ "$1" != "$input" ]
do
  i=$(expr $i + 1)
  shift
done

if [ $# = 0 ]
  then exit 0
fi

exit $(expr $i + 1)

Speichere das unter C:\wsl\keypress.sh oder so. Aktiviere nun die WSL. 
Erstelle nun einen neuen Link über "Rechte Maustaste->Neu->Verknüpfung". 
Beim ersten Eingabefeld "bash" eingeben (oder wsl, sollte auch gehen), 
beim Zweiten auf der nächsten seite "keypress" eingeben. Dan rechte 
Maustaste auf den Link, Eigenschaften, und bei Ziel " 
/mnt/c/wsl/keypress.sh" hinzufügen, danach sollte da 
"C:\Windows\System32\bash.exe /mnt/c/wsl/keypress.sh" stehen. Nun den 
Link in den Path verschieben, (z.B. nach C:\Windows). Jetzt kannst du 
das Script verwenden, einfach eine CMD öffnen, und "keypress.lnk a b c" 
eingeben.

[Markus (Gast)]

Sicher, daß Du eine Konsolenanwendung benötigst? Das ganze klingt eher 
nach einem Fall für AutoHotKey.