MASM32 application not executing?

[Benjamin1996]

Hi guys!
I'm pretty much new to Assembly in MASM, so it's very likely that this is just a stupid question, but here it goes:
My problem is that my program simply exits immediately, when I run it in the command prompt.
I wrote the source code in the MASM32 editor, and assembled it by going to Project->Assemble & Link.

Code Select Expand


.386
.model flat, stdcall
.stack 1024
.code
program proc
    mov ax, 0013h
    int 0010

    mov bx, 0a000h
    mov es, bx

    mov ebx, 0
    mov ax, 3501h
    mov ecx, 64000
draw:
    mov es:[ebx], ax
    inc ah
    loop draw

    mov ax, 0001h
    int 0021h

    mov ax, 4c00h
    int 0021h
program endp
end program


[clive]

You're trying to do 16-bit DOS/BIOS type interrupt calls, and direct screen memory access in a "FLAT" 32-bit executable. Isn't going to work. You need to build 16-bit applications ".MODEL SMALL/MEDIUM/COMPACT/LARGE/etc", or built 32-bit applications using the Win32 API calls.

[Benjamin1996]

You're trying to do 16-bit DOS/BIOS type interrupt calls, and direct screen memory access in a "FLAT" 32-bit executable. Isn't going to work. You need to build 16-bit applications ".MODEL SMALL/MEDIUM/COMPACT/LARGE/etc", or built 32-bit applications using the Win32 API calls.

Well, I already tried assembling a 16-bit DOS application, using ml.exe and link16.exe, but then I said that fullscreen mode was not supported, so I guess my only option is to build Win32 applications using the Win32 API..?

[dedndave]

hi Benjamin - welcome to the forum

i have written 16-bit apps that utilize fulls-screen
they seem to work ok under XP
you should know that some 16-bit functions are "emulated" under a win32 environment
for example, direct hardware I/O is not allowed under the security constructs of win32
direct I/O was allowed under Win95/98, though
but, in order to provide some backward compatibility and still allow a newer "more secure" operating system design, these functions are emulated

i have never tried these full-screen apps under vista or windows 7 - can't say how they are handled
also, 16-bit applications will generally not run under 64-bit OS's (well - not without a VM or something)

[redskull]

Full screen text mode is no more, as of Windows Vista.  It is my only real complaint  :'(

[hutch--]

Benjamin,

Unless you have very good reason to build 16 bit real mode applications do yourself a favour and write a console mode app in 32 bit code. Its faster, can do far more and easier to do most things. The characteristics of CMD.EXE are specific to the Windows version being used but you can normally set the console size that you run a console mode app with so it should not be any big deal. Due to the size of modern screens full screen text mode is probably no longer viable.

[dedndave]

there were some advantages to writing 16-bit apps, before the advent of Windows 7
but, as time goes on, Windows 7 will overtake XP as "the best 32-bit OS"
(this is mainly a matter of applications being updated for win7 compatibility)
notice how i skip over vista ? - lol

the advantages are mainly related to what you can and can't do with the video adapter
under win32, you can't directly access the hardware as easily
it will take a bit of a learning curve for me to figure out a new "right way" to do some things   :P