|
Anzeige
|
KEYPRESS.COM
Gast
#5774943
> 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. Und was soll das tolle DOS-Programm machen?
Gast
#5774961
> Und was soll das tolle DOS-Programm machen?
Du bist ja noch fauler als ich.
Jedenfalls hat es jahrtausendelang gut funktioniert.
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. Danke an Jim, damit hat sich das Thema offensichtlich erledigt.
Gast
#5775260
> 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.
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?
Gast
#5775356
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. 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.
Gast
#5775411
> 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.
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! 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. 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... 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.
Gast
#5775642
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
Gast
#5775735
Hier, ein Posix shellscript dafür:
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.
Gast
#5776321
Sicher, daß Du eine Konsolenanwendung benötigst? Das ganze klingt eher nach einem Fall für AutoHotKey. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
