Tastaturausgabe stark verzögert
-
Hallo zusammen,
Ich fange gerade mit Assembler an. Ich habe mir ein Buch angeschafft und die ersten Programme geschrieben. Zum Beispiel dieses:
.MODEL SMALL .CODE MOV AH,01H L: INT 21H JMP L END
Nun habe ich es in der Konsole aufgerufen und im Prinzip funktioniert es auch...
ABER: Bei der Eingabe merkt man schon, das die Zeichen verzögert ausgegeben werden. Hält man eine Taste gedrückt, so wird das Eingegebene nur noch sekundenweise in 10-Zeichen-Blöcken angezeigt. Wirft man einen Blick auf den Task-Manager: die CPU-Auslastung klebt an der Decke!
Ich schätze, dass ich irgendetwas übersehen habe. Nur was?
Ein anderes Problem, das erst nach dem Ausführen auftritt: Ich kann die .exe nicht mehr löschen. Die Fehlermeldung:
PROGRAMM kann nicht gelöscht werden: Die Datei wird von einer anderen Person bzw. einem anderen Programm verwendet...
Mit Unlocker kann ich das Programm zwar von dem Prozess befreien (nämlich Explorer.EXE) aber das ist natürlich keine schöne Lösung. Wie behebe ich dieses Problem?
Danke schon mal im Voraus für Antworten.
MfG Tobi
-
Eventuell musst du den Eingabepuffer löschen: int21,ax=0c01h.
Zudem empfiehlt es sich DOSBox zu benutzen.
-
ganz vergessen: Dir ist schon klar das das Prog. unendlich läuft ... kann also nie Beendet werden.
-
Ja. Das mit dem Endloscode weiß ich. Aber was genau ist der Eingabepuffer?
Also noch mal zum Verständnis: Ich müsste den Code nur inCode: .MODEL SMALL .CODE MOV AX,0C01H MOV AH,01H L: INT 21H JMP L END
Was genau bewirkt das denn? Dann habe ich doch bloß 01 in AL und 0C in AH gespeichert, oder?
-
das hast du Flasch verstanden:
... mov ax,0c01h ; Funktion 0ch --> google int 21 mov ah,1 int 21
-
Funktioniert leider nicht...
-
Wie gesagt, benutze DOSBox oder irgendeinen anderen Emulator - Weiter kann ich dir leider nicht helfen.
BTW: Das sich das Prog. nicht löschen lässt, liegt daran, dass es noch läuft...
-
Aber ich hab am Schluss doch "END" geschrieben...
Und normalerweise benutze ich auch noch die Funktion 4CH des Interrupts 21H. Also eine definierte Rückkehr ins System.
Ich habe auch schon mal am Schluss die Direktive .EXIT verwendet. Ohne Erfolg.
-
du musst aus der Schleife Ausbrechen - z.B:
next: mov ah,1 int 21 cmp al,'q' ; wenn 'q' gedrückt wird Schleife Verlassen. jne next ; "jump not equal" mov ah,04ch int 21
-
Ich habe folgendes Programm geschrieben und ausgeführt:
;**************************** ; Funktion: Testprogramm * ; Name: Programm.asm * ;**************************** .MODEL SMALL .STACK 256 .RADIX 16 .CODE START: MOV DL, 42 MOV AH, 02 INT 21 MOV AH, 4C INT 21 .EXIT END START
Aber auch dieses kann ich nicht löschen, obwohl ich an alles gedacht habe:
- int 21h, ah=4ch
- .exit
- end start
-
Ich hab jetzt mal gegooglet(!): Zum Beenden des Prog. musst du Funktion 0 des int 21 benutzen. Ansonsten: DOSBox bunutzen!!
"END start" sagt masm nur, dass der Quelltext hier endet und der Eintrittspunkt beim Lable „start“ liegt.
-
IRQ schrieb:
Wie gesagt, benutze DOSBox oder irgendeinen anderen Emulator - Weiter kann ich dir leider nicht helfen.
Ack. Die in Windows integrierte virtuelle DOS-Maschine ist ein Haufen Mist.
Dass alles ruckelt und die CPU voll ausgelastet wird, ist bei dem Ding noch als erfreulich problemloser Normalbetrieb ein zu schaetzen.
Entweder findest du dich bei diesen einfachen Testprogrammen damit ab oder holst dir einen vernuenftigen DOS-Emulator oder gleich eine richtige VM mit DOS.IRQ schrieb:
BTW: Das sich das Prog. nicht löschen lässt, liegt daran, dass es noch läuft...
Gewagte Vermutung... Das kann an allem moeglichen liegen. Am wahrscheinlichsten ist irgend ein Bug im Explorer, bzw. eine Extension, Virenscanner o.Ae. der sich an den DOS-Programmen verhakt. -> Ordner, der das Programm enthaelt, nicht im explorer oeffnen, sondern nur in der Konsole.
Und das mit dem Loeschen des Eingabepuffers bringt praktisch wahrscheinlich auch nicht mehr als Verwirrung.
Tobi schrieb:
Aber ich hab am Schluss doch "END" geschrieben...
Das sagt dem Assembler nur, dass nach diesem Schluesselwort, gefolgt vom Label des Eintrittspunktes, nichts weiter im Quelltext steht.
Rennt dein Programm beim Ausfuehren in diesen Punkt rein, folgen undefinierte Daten -> undefiniertes Verhalten.
Um Programme zu beenden, musst du Funktionen des Betriebssystems nutzen (bei DOS zB. int 21h mit ah=4ch)
.exit ist AFAIR ein Macro, das aufgeloest auch nichts anderes macht als og. DOS-Funktion aufzurufen.
-
Nobuo T schrieb:
Gewagte Vermutung... Das kann an allem moeglichen liegen. Am wahrscheinlichsten ist irgend ein Bug im Explorer, bzw. eine Extension, Virenscanner o.Ae. der sich an den DOS-Programmen verhakt. -> Ordner, der das Programm enthaelt, nicht im explorer oeffnen, sondern nur in der Konsole.
Stimmt. Ich hab da mal ein wenig rumprobiert: Solange ich nicht versuche die Datei über den Explorer zu löschen funktioniert alles (also löschen per del oder erase).
Dann hab ich noch mit ein paar kleinen Programmen experimentiert. Also die Ausgabe funktioniert fabelhaft. Sofort nach Starten des Testprogramms das AL mit dem Inhalt 42H wiederholt anzeigt ist das Konsolenfenster mit 'B' gefüllt.
Aber sobald ich die Funktion 08H oder direkt 01H zum Einlesen der Tastatur benutze stottert das Programm. Was mich verwundert ist halt, dass das Eingegebene ja sonst immer sofort angezeigt wird. Also beim ganz normalen Arbeiten mit der Eingabeaufforderung zum Beispiel. Gibt es etwa eine schnellere (bzw. überhaupt eine) andere Möglichkeit die Tastatur zu lesen?
Doch ich dachte das so ein Interrupt recht schnell funktioniert.
Danke schon mal für die Tipps bis hier hin
MfG Tobi
-
Das Problem ist der Windows-Eigene DOS-Emulator. Sobald du DOS-Programme startest, laufen diese in einer virtuellen Maschine. Dabei wird so ziemlich ein kompletter zweiter PC auf deinem Rechner simuliert. Die Eingabeaufforderung selbst ist ein 100%iges Windows-Programm (zumindest ab win2k), das direkt ohne Weiteres auf deinem PC laufen kann, und deshalb auch wesentlich schneller.
Siehe auch Unterschied: DOS / MS-DOS und Windows32-Konsole
-
Ach so... Dann läuft also nicht nur mein Assemblercode, sondern jener in einem anderen Programm!?!
Ich hab mich schon gewundert, dass dasselbe C#-Programm schneller läuft als in Assembler.
Danke!
MfG Tobi
-
Das die ntvdm Probleme macht ist wirklich nichts neues - aber mit AV's, dem Explorer oder anderen Programmen hat das sicher nichts tun (32Bit<>16Bit). Ich kann auch nur DOSBox empfehlen - hatte bis jetzt noch nie Probleme damit. Einziges Manko ist die Tastatureinstellung (US).
-
__asm{} schrieb:
Das die ntvdm Probleme macht ist wirklich nichts neues - aber mit AV's, dem Explorer oder anderen Programmen hat das sicher nichts tun (32Bit<>16Bit).
Um das noch einmal klar zu stellen:
Die mangelhafte Performance und die Sache mit dem Datei-Lock sind 2 unabhaengige Probleme:
1. Problem hat mit der Notwendigkeit einer Emulation und damit der ntvdm zu tun und
2. Problem scheinbar "mit AV's, dem Explorer oder anderen Programmen".Tobi schrieb:
Ach so... Dann läuft also nicht nur mein Assemblercode, sondern jener in einem anderen Programm!?!
Ich bin mir nicht sicher, was du meinst.
Wenn du ein DOS-Programm startest, wird zunaechst ein Programm namens ntvdm gestartet. Das ist eine Virtuelle Maschine. Diese fuehrt dann erst deinen Code aus.
Oft sieht es also so aus, dass dein Asm-Code in DOS-Programmen dann gar nicht direkt auf der CPU deines PCs ausgefuehrt wird, im Gegensatz zu compiliertem C#-Code.
-
Also schreibe ich im Moment Programme für DOS. Das wusste ich noch nicht mal. Würde ich diese auf einem Computer mit DOS ausführen würden sie doch so laufen wie alle anderen Programme dort auch, oder?
Und wenn ich nun ein Assemblerprogramm für Windows schreibe, so würde es wohl auch flüssiger laufen?
Ich dachte Assemblersprache sei nur prozessorspezifisch.
-
Ja. Startest du deine DOS-Programme auf einem PC mit DOS (oder Windows < WinME), laufen die Programme "nativ" auf dem System, dh. ohne komplizierte VM direkt auf der CPU.
Windows-Programme laufen unter Windows naturgemaess am fluessigsten.
Assembler ist genau so systemspezifisch wie jede andere direkt lauffaehige binaere Programme erzeugende Programmiersprache (zB. C, C++, Basic) auch. Schliesslich hat jedes Betriebssystem seine eigene API.
Bei Assembler kommt dann aber zusaetzlich noch die Prozessorabhaengigkeit dazu, da hier nicht wie bei Hochsprachen von den Maschinenbefehlen abstrahiert wird. Diese fehlende Abstraktion ist so gesehen vom Prinzip her auch das Einzige, was Assembler von og. Hochsprachen unterscheidet.