Tastaturausgabe stark verzögert

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.

Nobuo T

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

Nobuo T

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

__asm**

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).

Nobuo T

__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.

Nobuo T

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.