I would appreciate it if someone were to tell me what is wrong with this code

.386
.model tiny
.stack
.data
.code
main proc
mov eax,2
mov ah,4ch
int 21h
main endp
end main

whether it is a .com or .exe seems to have no effect. This program compiles fine with MASM v6.14 but when i decompile it with turbo debugger or debug, the code for
mov eax,2
appears as
mov ax,0002
add ,al

i understand that what is happening is that the last 16 bits of the mov eax,2 command are being misinterpreted as add ,al, but i do not understand how to fix this problem. please help
Posted on 2001-11-18 10:46:32 by LOLTH
debug is unable to handle "66h prefix" instructions, such as those
generated when you use 32bit registers in 16bit mode. Debug
shows this the following way:


0C96:0100 66 DB 66
0C96:0101 B80200 MOV AX,0002
0C96:0104 0000 ADD [BX+SI],AL


When infact the instruction is



00000000 66B802000000 mov eax,02


Anyway... 16bit code... icky icky.
Posted on 2001-11-18 10:59:37 by f0dder
16bit mode? how do i use 32bit mode instead of 16bit? and in 32bit mode, can you still reference the 16bit registers like you would in 16bit mode?
Posted on 2001-11-18 11:06:53 by LOLTH
32bit mode? Not really hard. ".model flat, stdcall", for instance.
You don't need to set up a .stack.
Yes, you can still reference the registers as you are used to.
You'll have to use the win32 api instead of dos interrupts.

http://win32asm.cjb.net for the introductions iczelion has written,
and http://www.movsd.com for the masm32 package if you don't
already have it.
Posted on 2001-11-18 11:14:30 by f0dder
LOLTH,

The code you posted is a mix of 16 and 32 bit code that will not work.

.386 ; specifies 32 bit code
.model tiny : DOS com only
.stack ; not used in 32 bit code
.data
.code
main proc
mov eax,2
mov ah,4ch ; must not be used in 32 bit mode
int 21h ; " "
main endp
end main

Have a look at MASM32 as it has a mountain of example code that you can use and it does the very basic stuff correctly.

This is the bare minimum for a 32 bit PE file.



.386
.model flat, stdcall
option casemap :none ; case sensitive

; any include files here

.data
; initialised data here
.data?
; uninitialised data here

.code

start:

; your assembler code here

invoke ExitProcess,0 ; must exit program cleanly

end start


Regards,

hutch@movsd.com
Posted on 2001-11-18 16:01:02 by hutch--
Well, clearly he will not get a win32 PE out of the code snippet...
but isn't it perfectly legal syntax for a 16bit .com? Just wondering..
Posted on 2001-11-18 16:29:11 by f0dder
Possibly correct syntax is:



.286
.model tiny
.386
.stack
.data
.code
main proc
mov eax,2
mov ah,4ch
int 21h
main endp
end main
Posted on 2001-11-19 02:37:06 by japheth
Japeth,

wouldn't that still be illegal because you're using eax instead of ax? I thought you couldn't use 32-bit regs in a 16-bit prog.
Posted on 2001-11-19 15:28:18 by lackluster
But you can. You'll just cause one of them 66h or 67h prefixes.
I accessed 32bit memory space from 16bit apps by temporarily
switching to pmode and setting segment limits (!!!) to 4gb...
it's called "voodoo memory" or "unreal mode" or "big real mode"
or... a lot of other cute names ;). Of course it's only possible on
80386+ an later, and masm might try to restrain you from doing it
because it sometimes thinks it knows better than you ;).
Posted on 2001-11-19 19:17:48 by f0dder
But without switching to pmode or pulling some outrageous tricks, you generally can't (or shouldn't) attempt to use 32-bit regs in a 16-bit app?
Posted on 2001-11-19 21:37:24 by lackluster
There is no problem using 32-bit regs in 16-bit DOS programs unless your using those registers to access memory that you don't have access rights to.
Posted on 2001-11-19 22:19:13 by bitRAKE
Yup, I used the 32 bit regs in DOS programs for years with no problems. :)

PS - And instructions like MOVSD.
Posted on 2001-11-19 22:24:52 by S/390
bitrake said it pretty well. But to make it even clearer :), the only
thing you don't want to do is use 32bit registers to index memory,
except if you know they're valid (high part clear), or you use the
"unreal" hack (which is btw totally incompatibly with any memory
management above himem.sys... I think it works with himem.sys,
but not even sure about that... gosh I'm glad I left the dos world ;)
Posted on 2001-11-19 22:24:55 by f0dder