News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

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

Started by yoursonfather, April 18, 2014, 05:34:43 AM

Previous topic - Next topic

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


.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.
Well Microsoft, here's another nice mess you've gotten us into.

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

Quote from: FORTRANS on April 18, 2014, 11:07:16 PM
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,

Quote from: yoursonfather on April 19, 2014, 02:13:33 AM
does i5 cpu (or new) have 8bit register 16bit..32bit..64..in one cpu?

   Yes.  Current processors are backward compatible with older
processors.

Quoteso 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.
Well Microsoft, here's another nice mess you've gotten us into.

yoursonfather

Quote from: MichaelW on April 19, 2014, 02:50:21 PM
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

Quote from: MichaelW on April 19, 2014, 02:50:21 PM
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

Quote from: FORTRANS on April 20, 2014, 12:32:11 AM
Quote from: MichaelW on April 19, 2014, 02:50:21 PM
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.

.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

Well Microsoft, here's another nice mess you've gotten us into.

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.

.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

Well Microsoft, here's another nice mess you've gotten us into.

Gunther

Michael,

Quote from: MichaelW on April 20, 2014, 01:50:59 PM
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
You have to know the facts before you can distort them.

FORTRANS

Quote from: MichaelW on April 20, 2014, 01:50:59 PM
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.