Message board for the users of flat assembler.
> DOS > 32-bit commands in DOS
alexa 21 Apr 2006, 21:25
How use 32-bit commands in DOS?
I used "use32" but programm work bad,
I delete "use32" programm work good.
FASM 1.65 under DOS.
|21 Apr 2006, 21:25||
daluca 23 Apr 2006, 06:37
what do you mean with 32-bit commands?
do you want to have access to 32 bit windows api like CreateWindow?
do you want to have access to all the memory like in protected mode?
or do you just want to use the 32-bit instructions?
well, must realise that DOS is a 16-bit OS so using or triyng to use
32 bit in 16 bit will lead to errors but you can use some 32-bit functionality
like the 32 bit registers :
as long as you ensure that the high word of eax is 0
is posible to use any general register for addressing
|23 Apr 2006, 06:37||
viki 23 Apr 2006, 07:05
Maybe try something like this:
with is the same like this:
I think you use td.exe so probably you know you can switch registry to be displayed as 32-bit regs.
|23 Apr 2006, 07:05||
Tomasz Grysztar 23 Apr 2006, 11:34
DOS itself executes 16-bit code only. To run the 32-bit code you need some extender and/or DPMI server.
To see how to use DPMI in order to execute some 32-bit code, see the USEDPMI example that comes in fasm package.
|23 Apr 2006, 11:34||
vid 23 Apr 2006, 12:00
but another thing is that in 16 bit code, you CAN use 32bit instructions, you just can't address memory with offsets greated than 0FFFFh
|23 Apr 2006, 12:00||
Borsuc 25 Apr 2006, 14:59
alexa: you have to understand that use32 does not change the processor's state. If it is executing in 16-bit mode, use32 will not change it. It will still be executing in 16-bit after that.
use32 only tells the assembler (fasm) that the following instructions should be encoded as 32-bit ones (instructions are just bytes, so by 'encoding' i mean a different set of rules for byte organization) --> thus, if the processor is still in 16-bit mode, and then 'executes' those bytes (which are 32-bit encoded instructions) it will most probably execute wrong.
Imagine as if you would execute 'data'. What's data? it's still bytes. Thus:
declares the 90h byte, which is the nop instruction. If you would execute this 'data', the processor would read it as nop.
now let's look at some encodings. Thus, if you tell the assembler to encode "xor ax, ax" in 16-bit mode (via use16), when it sees "xor ax, ax" it will generate the bytes: 31 C0
Now, if you told it to generate this in use32 mode, it would output: 66 31 C0
There's a '66' there! The cpu (on which state is in right now) will execute this fairly standard, it doesn't care about use32 or use16 (since these are not in the output), it only cares about the bytes and bits of the executable. The CPU is in 16-bit mode, but the following instruction is 66 31 C0, that means the instruction "xor eax, eax" in 16-bit mode.
Thus, use32 only tells the assembler how it should encode. It doesn't affect the generated code at all, nor the processor's state.
For further explanation, examine these:
use16 xor ax, ax ; compiles as 31 C0 bytes use32 xor eax, eax ; compiles as 31 C0 bytes (exactly the same)
Now, if the processor was in 16-bit mode upon entry, it will read these as:
xor ax, ax xor ax, ax
since, in it's 16-bit state, 31 C0 means xor ax, ax.
You could have also written data like:
data1 db 31h, 0C0h data2 db 31h, 0C0h
which will put these bytes in the output. IF the processor started executing here, he will read these as instructions (please, do not imagine instructions as something magical, they are JUST bytes and bits).
Apparentely 31 C0 means the xor ax, ax instructions, so the processor would execute that instruction, even if you wrote data there.
What's data? It's only bytes and bits, just like instructions. It's important how you 'encode' those bytes and bits (i.e following some rules) so that instructions are made.
For example, a rule would be that the set of 31 C0 means the 'xor ax, ax' instruction in 16-bit mode. In 32-bit mode, the same rule applies to the 'xor eax, eax' instruction. If you want 'xor ax, ax' in 32-bit mode, the 'rule' says we must put a '66' before it: 66 31 C0.
In conclusion, use32 does not affect the processor. It only gives the information to the assembler that the following piece of code should be encoded as 32-bit. The bytes and bits there will follow the 32-bit encoding rules. The processor may as well read data, which will make it random instructions (since data usually doesn't follow the instruction's rules, that's why it's data).
I tried to explain it as best as I could, hope it makes sense
|25 Apr 2006, 14:59||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.