why can not run in 32bit window7 but can run in dos-box

[yoursonfather]

in window7 Only "window" appears ,notthing happen


does masm can use 16bit register ,32bit register ,64bit register in same program?

same program in different os not same happen ? cpu same


i know this is 16bit program

Code Select Expand


.MODEL SMALL
.STACK
.CODE
MAIN:
MOV AX,@DATA
MOV DS,AX
MOV AX,0B800H
MOV ES,AX
MOV DI,00H
MOV CX,1000H
MOV AX,8F04H
REP STOSW
MOV AH,4CH
INT 21H
END MAIN


[dedndave]

well - i know 16-bit code won't run under 64-bit versions
but, i thought it would run under 32-bit versions

it may be that direct memory accesses are not allowed (i would think you'd get an error message)
or it may be that the display buffer is at a different base address (try 0A000h or 0B000h maybe?)

[MichaelW]

The code works as it should when run from an MS-DOS 6.22 boot diskette, but running under Windows XP it does not display, and I cannot find any PIF settings that will allow it to display. So it looks like NTVDM does not allow direct access to the display memory for the alphanumeric modes.

[FORTRANS]

Hi,

   Here the code assembles and runs as intended.  In both full
screen and windowed sessions.  On both Windows 2000 and
Windows XP.  More tests can be made if wanted, but seem
unnecessary.

HTH,

Steve

[yoursonfather]

Hi,

   Here the code assembles and runs as intended.  In both full
screen and windowed sessions.  On both Windows 2000 and
Windows XP.  More tests can be made if wanted, but seem
unnecessary.

HTH,

Steve

does i5 cpu (or new) have 8bit register 16bit..32bit..64..in one cpu?

so can i write a program have 16bit 32bit 64bit ?

[FORTRANS]

Hi,

does i5 cpu (or new) have 8bit register 16bit..32bit..64..in one cpu?

   Yes.  Current processors are backward compatible with older
processors.

so can i write a program have 16bit 32bit 64bit ?

   Not really.  If I understand correctly, you cannot mix 16-bit code
with 64-bit code.  And the current operating systems are not going
to allow you to switch CPU modes into and out of 64-bit easily.

Regards,

Steve N.

[MichaelW]

The problem under Windows XP could be a service-pack issue that affects the alphanumeric modes only. The system is running SP3 with all available updates, and I have no problem writing directly to the display memory in the graphics modes 12h and 13h.

[yoursonfather]

The problem under Windows XP could be a service-pack issue that affects the alphanumeric modes only. The system is running SP3 with all available updates, and I have no problem writing directly to the display memory in the graphics modes 12h and 13h.

so all thing just os problem? QQ   writing in the dos-box is useful..but can emptiness

IF  computer does not have copliler ,so computer science leg was broken ?

[FORTRANS]

The problem under Windows XP could be a service-pack issue that affects the alphanumeric modes only. The system is running SP3 with all available updates, and I have no problem writing directly to the display memory in the graphics modes 12h and 13h.

Hi,

   Well, here is what I have on that machine.

Intel(R) Pentium(R) M processor 1.70GHz

Version   5.1.2600 Service Pack 3 Build 2600

How does that compare to yours?  I'll try it on some other
machines with XP later today.

Regards,

Steve N.

[yoursonfather]

The problem under Windows XP could be a service-pack issue that affects the alphanumeric modes only. The system is running SP3 with all available updates, and I have no problem writing directly to the display memory in the graphics modes 12h and 13h.

Hi,

   Well, here is what I have on that machine.

Intel(R) Pentium(R) M processor 1.70GHz

Version   5.1.2600 Service Pack 3 Build 2600

How does that compare to yours?  I'll try it on some other
machines with XP later today.

Regards,

Steve N.

cpu:Intel® Core™i5
os: window 7 32bit

[MichaelW]

At this point I have no idea why the original code cannot display on either of my Windows XP systems, both Version 5.1.2600 Service Pack 3 Build 2600, with all available updates (and MSE). This code does a direct read and a direct write of the alphanumeric display memory and it works as expected on both systems, windowed or full screen.

Code Select Expand


.model small,c
.386
.stack
.data
.code
;----------------------------------------------------------------------------
; Calls the BIOS Set Cursor Position function to set the cursor position for
; display page 0 to <row>,<col> (upper left corner is position 0,0).
;----------------------------------------------------------------------------
locate proc uses eax ebx edx row:BYTE, col:BYTE
    mov ah, 2
    mov bh, 0
    mov dh, row
    mov dl, col
    int 10h
    ret
locate endp
;----------------------------------------------------------------------------
; Clears the screen by calling the BIOS Scroll Current Page Up function with
; a scroll (row) count of zero, and sets the cursor position to the upper
; left corner of the screen. An 80x25 alphanumeric mode screen is assumed.
;----------------------------------------------------------------------------
cls proc uses eax ebx ecx edx
    mov ah, 6
    mov al, 0
    mov bh, 7
    mov ch, 0
    mov cl, 0
    mov dh, 24
    mov dl, 79
    int 10h
    invoke locate, 0, 0
    ret
cls endp
;==============================================================================


.startup

    invoke cls

    ; Expected output is "XXY"

    mov ah, 0eh
    mov al, 'X'
    xor bh, bh      ; verify page 0 as current
    int 10h

    push 0b800h
    pop es

    ; The character code byte precedes the character attribute byte in memory,
    ; so the character codes are at even addresses and the attributes at odd
    ; addresses.

    mov al, es:[0]
    mov ah, 0eh
    xor bh, bh
    int 10h

    mov BYTE PTR es:[4], 'Y'

    xor ah, ah
    int 16h

.exit
end


[MichaelW]

Mystery solved, I think. On my XP systems, without first executing a CLS the direct memory writes, and probably also the reads, do not work. After executing a CLS they both work. This would appear to be a security measure.

Code Select Expand


.model small,c
.386
.stack
.data
.code
;----------------------------------------------------------------------------
; Calls the BIOS Set Cursor Position function to set the cursor position for
; display page 0 to <row>,<col> (upper left corner is position 0,0).
;----------------------------------------------------------------------------
locate proc uses eax ebx edx row:BYTE, col:BYTE
    mov ah, 2
    mov bh, 0
    mov dh, row
    mov dl, col
    int 10h
    ret
locate endp
;----------------------------------------------------------------------------
; Clears the screen by calling the BIOS Scroll Current Page Up function with
; a scroll (row) count of zero, and sets the cursor position to the upper
; left corner of the screen. An 80x25 alphanumeric mode screen is assumed.
;----------------------------------------------------------------------------
cls proc uses eax ebx ecx edx
    mov ah, 6
    mov al, 0
    mov bh, 7
    mov ch, 0
    mov cl, 0
    mov dh, 24
    mov dl, 79
    int 10h
    invoke locate, 0, 0
    ret
cls endp
.startup
    push 0b800h
    pop es
    mov BYTE PTR es:[0], 'X'
    mov BYTE PTR es:[2], 'Y'
    mov BYTE PTR es:[4], 'Z'
    mov al, es:[0]
    mov es:[6], al
    xor ah, ah
    int 16h
    invoke cls
    push 0b800h
    pop es
    mov BYTE PTR es:[8], 'X'
    mov BYTE PTR es:[10], 'Y'
    mov BYTE PTR es:[12], 'Z'
    mov al, es:[8]
    mov es:[14], al
    xor ah, ah
    int 16h
.exit
end


[Gunther]

Michael,

Mystery solved, I think. On my XP systems, without first executing a CLS the direct memory writes, and probably also the reads, do not work. After executing a CLS they both work. This would appear to be a security measure.

that's a strange comportment. Seems to be another nice MS feature.

Gunther

[FORTRANS]

Mystery solved, I think. On my XP systems, without first executing a CLS the direct memory writes, and probably also the reads, do not work. After executing a CLS they both work. This would appear to be a security measure.

Hi Michael,

   Congratulations on finding out what was going on.  I doubt I
would have thought of that.  Though I was using CLS and MODE
80,25 to muck about with the screen format at times.  Looks
like a nice test program to verify things.

   I ran the code on two more XP SP3 systems, and they worked
normally.  One is running a different anti-malware product that my
brother used to clean up Mom's computer.  And the other is a another
laptop of mine.  That, while it has MSE on it, has it currently disabled
due to the thing being very, very slow.

   I also ran your FP code from the other thread on each if you
want some Celeron results.

Regards,

Steve N.