Fehlermeldung nach ausführen von Dos Anwendung (Win98)

Hallo,

Nein das ist kein Scherz, ich habe eine VM mit Win98.

Zur Zeit arbeite ich mit BIOS Interrupts (Videomodus, Disketten usw..)

Nun erhalte ich nach dem Beenden mit

xor eax, eax
mov ah,4Ch
int 21h

die Meldung, das noch MS-Dos basierte Programme ausgführt werden.
Beenden Sie diese zuerst...blabla...

Ich reservierer keinen Speicher noch sonst irgendwas.. Lediglich einen String gebe ich aus, bevor das Programm beendet werden soll.

Erstellt wird eine .EXE im Modell SMALL mit Befehlssatz des 386.

Der PC stürzt zwar nicht ab, aber ich möchte schon gern die Meldung vermeiden.
Woran liegt das?

Nicky

supernicky schrieb:

xor eax, eax
mov ah,4Ch
int 21h

Ungewöhnliches DOS Programm!

supernicky schrieb:

Zur Zeit arbeite ich mit BIOS Interrupts (Videomodus, Disketten usw..)

Int 21h ist ein DOS Interrupt.

supernicky schrieb:

Woran liegt das?

Du brauchst einen Hellseher!?
Alternativ kannst du dein Programm ja mal in DOSBox (->google) laufen lassen - damit ersparst du dir dann auch Win98 (kein Scherz).

mov ah,4Ch
int 21h

ist zum beenden der Anwendung.

ja klar ist der int 21h ein Dos Interrupt.. nur mit den BIOS Interrupts
kann ich kein Programm beenden.
Ich hab ja gechrieben das ich eine .EXE erstellt habe. (Model SMALL und
386er Modus)

hier mal der ganze Code:

.model small
.386

daten segment

disk db "3,5 Zoll mit 1,44 MB",10,13,"$"

daten ends

stapel segment

dw 128 dup(?)

stapel ends

code segment

assume ds:daten,cs:code,ss:stapel,es:nothing

start:  

mov ax, daten
mov ds, ax

	xor edx, edx
        xor eax, eax
	mov ah, 08h
	int 13h

	cmp bl, 04h
	jne ende

	xor eax, eax
	xor edx, edx
	mov dx, offset disk
	mov ah, 09h
	int 21h

ende:

	xor eax, eax
        mov ah, 4Ch
        int 21h

code ends

end start

Nicky

Edit: Bitte code tags benutzen.

Nobuo T

Sowas

xor eax, eax
        mov ah, 4Ch

oder der Klassiker

mov al, 0
mov ah, 4Ch

tut schon ein bisschen weh. Bitte nicht.

Generell solltest du es vermeiden, in 16Bit-Programmen 32Bit-Register zu verwenden und umgekehrt.

Tritt das Problem nicht auf, wenn du dein Programm nicht startest? Oder wenn du den int 13h-Aufruf entfernst? Oder mit anderen DOS-Programmen?

Sehe da auf den ersten Blick kein weiteres Problem.
Viel Probieren - auch mit einem Debugger ist generell eine gute Idee. Falls du nicht gerade die Eigenheiten von Win98 untersuchen willst oder noch was Anderes mit win98 zu tun hast, wurde ja schon gesagt: DOSBox.

Hallo,

Die Meldung kommt auch ohne mein Zutun.

Sobald ich von Dos nach Windows wechseln will.. also kein Fehler im Programm.
Ich hatte ja lange kein Dos mehr

ich weiß das

xor ax, ax
mov ah, 09h
int 21h

nicht toll ist.. in den Büchern steht auch immer

mov ax, 0900h
int 21h

drin. Ich schreib ja nur für mich, da ist das glaub ich Wurscht

Nächste Woche kommen meine Disketten.. dann gehts mit Interrupt 13h weiter

Ich bleibe aber erstmal bei Win98.

Danke und Gruß

Nicky

nachtfeuer

Also, wenn ich mit fasm einen Code wie diesen:

org 100h
xor eax,eax
mov ah,09
mov dx,message
int 21h
mov ah,4ch
int 21h

message db "Hallo Test",24h

übersetze, gibt es keine Fehlermeldungen.

Man kann auf diese Weise auch "Protected Mode" Programme schreiben. Das Problem ist aber, wie Windows die Dos-Schnittstelle behandelt bzw. wie VMs das machen. Dazu kommt, dass unterschiedliche Windowsversionen unterschiedlich kompatibel sind. Spieleprogrammiere hatten früher, um mit 32Bit Registern zu arbeiten, Dos-Extender eingesetzt. Heute gibt es nur noch Directx.
Für den Prozessor gibt es das Problem, dass er wissen muss, ob er 16 Bit oder 32 Bit oder 64 Bit standardmäßig ausführt. Weil viele Befehle identisch sind, bekommen sie einen relativen Päfix.

Schauen wir uns mal an, was das Windows Programm Debug aus unserem Code herausliest:

C:\Users\nachtfeuer\FASMW>debug eaxtest.com
-d
1A9D:0100  66 31 C0 B4 09 BA 0E 01-CD 21 B4 4C CD 21 48 61   f1.......!.L.!Ha
1A9D:0110  6C 6C 6F 20 54 65 73 74-24 00 00 00 00 00 00 00   llo Test$.......
1A9D:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0130  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0140  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0150  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-u
1A9D:0100 66            DB      66
1A9D:0101 31C0          XOR     AX,AX
1A9D:0103 B409          MOV     AH,09
1A9D:0105 BA0E01        MOV     DX,010E
1A9D:0108 CD21          INT     21
1A9D:010A B44C          MOV     AH,4C
1A9D:010C CD21          INT     21
1A9D:010E 48            DEC     AX
1A9D:010F 61            DB      61
1A9D:0110 6C            DB      6C
1A9D:0111 6C            DB      6C
1A9D:0112 6F            DB      6F
1A9D:0113 205465        AND     [SI+65],DL
1A9D:0116 7374          JNB     018C
1A9D:0118 2400          AND     AL,00
1A9D:011A 0000          ADD     [BX+SI],AL
1A9D:011C 0000          ADD     [BX+SI],AL
1A9D:011E 0000          ADD     [BX+SI],AL
-

Aha! Debug - und damit auch Windows versteht wohl nur 16 Bit - Dos. Der Hexcode verrät hier viel mehr, als der dumme Disassembler. Der Hexwert 66 ist der Präfix für 16Bit Ausgangsposition. 16bit, ein Hinweis darauf, das Windows Dos-Programme über den Virtual Mode ausführt.

Nächster Versuch: Wir schauen uns das ganze in einem 32bit Debug Klone an, hier eines von Paul Vojta ( http://math.berkeley.edu/~vojta/ )

(um 32bit Register zu benutzten, gibt man rx ein:)

-rx
386 regs on
-r
EAX=00000000 EBX=00000000 ECX=00000019 EDX=00000000 ESP=0000FFFE EBP=00000000
ESI=00000000 EDI=00000000 NV UP EI NG NZ NA PO NC
DS=1BC2 ES=1BC2 SS=1BC2 CS=1BC2 FS=0000 GS=0000 EIP=00000100
1BC2:0100 6631C0            XOR     EAX,EAX
-d
1BC2:0100  66 31 C0 B4 09 BA 0E 01-CD 21 B4 4C CD 21 48 61 f1.......!.L.!Ha
1BC2:0110  6C 6C 6F 20 54 65 73 74-24 00 00 00 00 00 00 00 llo Test$.......
1BC2:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0130  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0140  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0150  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
-u
1BC2:0100 6631C0            XOR     EAX,EAX
1BC2:0103 B409              MOV     AH,09
1BC2:0105 BA0E01            MOV     DX,010E
1BC2:0108 CD21              INT     21
1BC2:010A B44C              MOV     AH,4C
1BC2:010C CD21              INT     21
1BC2:010E 48                DEC     AX
1BC2:010F 61                POPA
1BC2:0110 6C                INSB
1BC2:0111 6C                INSB
1BC2:0112 6F                OUTSW
1BC2:0113 205465            AND     [SI+65],DL
1BC2:0116 7374              JAE     018C
1BC2:0118 2400              AND     AL,00
1BC2:011A 0000              ADD     [BX+SI],AL
1BC2:011C 0000              ADD     [BX+SI],AL
1BC2:011E 0000              ADD     [BX+SI],AL
-g
DPMI entry hooked, new entry=1449:2C2F
Hallo Test
Program terminated normally (0024)
-

http://de.wikipedia.org/wiki/DOS_Protected_Mode_Interface
http://wiki.osdev.org/Unreal_Mode

Und der Vollständigkeit halber gucken wir uns auch nochmal an, was IDA macht:

seg000:0100 ;
seg000:0100 ; +-------------------------------------------------------------------------+
seg000:0100 ; ¦     This file is generated by The Interactive Disassembler (IDA)        ¦
seg000:0100 ; ¦     Copyright (c) 2010 by Hex-Rays SA, <support@hex-rays.com>           ¦
seg000:0100 ; ¦                      Licensed to: Freeware version                      ¦
seg000:0100 ; +-------------------------------------------------------------------------+
seg000:0100 ;
seg000:0100 ; 
seg000:0100
seg000:0100 ; File Name   : C:\Users\nachtfeuer\FASMW\eaxtest.COM
seg000:0100 ; Format      : MS-DOS COM-file
seg000:0100 ; Base Address: 0h Range: 100h-119h Loaded length: 19h
seg000:0100
seg000:0100                 .386
seg000:0100                 .model tiny
seg000:0100
seg000:0100 ; ---------------------------------------------------------------------------
seg000:0100
seg000:0100 ; Segment type: Pure code
seg000:0100 seg000          segment byte public 'CODE' use16
seg000:0100                 assume cs:seg000
seg000:0100                 org 100h
seg000:0100                 assume es:nothing, ss:nothing, ds:seg000, fs:nothing, gs:nothing
seg000:0100
seg000:0100 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
seg000:0100
seg000:0100
seg000:0100                 public start
seg000:0100 start           proc near
seg000:0100                 xor     eax, eax
seg000:0103                 mov     ah, 9
seg000:0105                 mov     dx, 10Eh
seg000:0108                 int     21h             ; DOS - PRINT STRING
seg000:0108                                         ; DS:DX -> string terminated by "$"
seg000:010A                 mov     ah, 4Ch
seg000:010C                 int     21h             ; DOS - 2+ - QUIT WITH EXIT CODE (EXIT)
seg000:010C start           endp                    ; AL = exit code
seg000:010C
seg000:010C ; ---------------------------------------------------------------------------
seg000:010E                 db  48h ; H
seg000:010F                 db  61h ; a
seg000:0110                 db  6Ch ; l
seg000:0111                 db  6Ch ; l
seg000:0112                 db  6Fh ; o
seg000:0113                 db  20h
seg000:0114                 db  54h ; T
seg000:0115                 db  65h ; e
seg000:0116                 db  73h ; s
seg000:0117                 db  74h ; t
seg000:0118                 db  24h ; $
seg000:0118 seg000          ends
seg000:0118
seg000:0118
seg000:0118                 end start

Nobuo T

Das scheint mir alles etwas zu verwirrend, um es so unkommentiert stehen zu lassen. Also der Reihe nach...

nachtfeuer schrieb:

Man kann auf diese Weise auch "Protected Mode" Programme schreiben.

Auf welche Weise? Zusammenhang?

nachtfeuer schrieb:

Das Problem ist aber, wie Windows die Dos-Schnittstelle behandelt bzw. wie VMs das machen. Dazu kommt, dass unterschiedliche Windowsversionen unterschiedlich kompatibel sind.

Welches Problem? Welche "Dos-Schnittstelle"?

nachtfeuer schrieb:

Spieleprogrammiere hatten früher, um mit 32Bit Registern zu arbeiten, Dos-Extender eingesetzt. Heute gibt es nur noch Directx.

Unsinn.

nachtfeuer schrieb:

Für den Prozessor gibt es das Problem, dass er wissen muss, ob er 16 Bit oder 32 Bit oder 64 Bit standardmäßig ausführt. Weil viele Befehle identisch sind, bekommen sie einen relativen Päfix.

Grbl? Koenntest das Richtige meinen, liest sich aber wie Quatsch.

nachtfeuer schrieb:

Schauen wir uns mal an, was das Windows Programm Debug aus unserem Code herausliest:

C:\Users\nachtfeuer\FASMW>debug eaxtest.com
-d
1A9D:0100  66 31 C0 B4 09 BA 0E 01-CD 21 B4 4C CD 21 48 61   f1.......!.L.!Ha
1A9D:0110  6C 6C 6F 20 54 65 73 74-24 00 00 00 00 00 00 00   llo Test$.......
1A9D:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0130  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0140  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0150  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A9D:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-u
1A9D:0100 66            DB      66
1A9D:0101 31C0          XOR     AX,AX
1A9D:0103 B409          MOV     AH,09
1A9D:0105 BA0E01        MOV     DX,010E
1A9D:0108 CD21          INT     21
1A9D:010A B44C          MOV     AH,4C
1A9D:010C CD21          INT     21
1A9D:010E 48            DEC     AX
1A9D:010F 61            DB      61
1A9D:0110 6C            DB      6C
1A9D:0111 6C            DB      6C
1A9D:0112 6F            DB      6F
1A9D:0113 205465        AND     [SI+65],DL
1A9D:0116 7374          JNB     018C
1A9D:0118 2400          AND     AL,00
1A9D:011A 0000          ADD     [BX+SI],AL
1A9D:011C 0000          ADD     [BX+SI],AL
1A9D:011E 0000          ADD     [BX+SI],AL
-

Aha! Debug - und damit auch Windows versteht wohl nur 16 Bit - Dos. Der Hexcode verrät hier viel mehr, als der dumme Disassembler. Der Hexwert 66 ist der Präfix für 16Bit Ausgangsposition. 16bit, ein Hinweis darauf, das Windows Dos-Programme über den Virtual Mode ausführt.

Unsinn.
MS Debug ist eine Mumie, ein Relikt aus DOS 1.0- und 8086-Zeiten. Entsprechend begrenzt ist es auch, was den Befehlssatz angeht. So fehlt in diesem Programm u.A. schlicht eine Unterstuetzung fuer 32Bit-Register. Etwas Anderes laesst sich davon nicht ableiten.
Uebrigens bewirkt der Instruktionspraefix 66h in 16-bit-Programmmen nichts anderes, als dass der nachfolgende Befehl 32Bit- statt 16Bit-Register verwendet.
So ist folgendes in einem 16Bit-Modus aequivalent

db 66h
xor ax, ax
; ist das Gleiche wie
xor eax, eax
; beides wird zur Bytefolge 66 33 c0 codiert.

nachtfeuer schrieb:

Nächster Versuch: Wir schauen uns das ganze in einem 32bit Debug Klone an, hier eines von Paul Vojta ( http://math.berkeley.edu/~vojta/ )

(um 32bit Register zu benutzten, gibt man rx ein:)

-rx
386 regs on
-r
EAX=00000000 EBX=00000000 ECX=00000019 EDX=00000000 ESP=0000FFFE EBP=00000000
ESI=00000000 EDI=00000000 NV UP EI NG NZ NA PO NC
DS=1BC2 ES=1BC2 SS=1BC2 CS=1BC2 FS=0000 GS=0000 EIP=00000100
1BC2:0100 6631C0            XOR     EAX,EAX
-d
1BC2:0100  66 31 C0 B4 09 BA 0E 01-CD 21 B4 4C CD 21 48 61 f1.......!.L.!Ha
1BC2:0110  6C 6C 6F 20 54 65 73 74-24 00 00 00 00 00 00 00 llo Test$.......
1BC2:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0130  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0140  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0150  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1BC2:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
-u
1BC2:0100 6631C0            XOR     EAX,EAX
1BC2:0103 B409              MOV     AH,09
1BC2:0105 BA0E01            MOV     DX,010E
1BC2:0108 CD21              INT     21
1BC2:010A B44C              MOV     AH,4C
1BC2:010C CD21              INT     21
1BC2:010E 48                DEC     AX
1BC2:010F 61                POPA
1BC2:0110 6C                INSB
1BC2:0111 6C                INSB
1BC2:0112 6F                OUTSW
1BC2:0113 205465            AND     [SI+65],DL
1BC2:0116 7374              JAE     018C
1BC2:0118 2400              AND     AL,00
1BC2:011A 0000              ADD     [BX+SI],AL
1BC2:011C 0000              ADD     [BX+SI],AL
1BC2:011E 0000              ADD     [BX+SI],AL
-g
DPMI entry hooked, new entry=1449:2C2F
Hallo Test
Program terminated normally (0024)
-

http://de.wikipedia.org/wiki/DOS_Protected_Mode_Interface
http://wiki.osdev.org/Unreal_Mode

Das soll jetzt genau was zeigen?