I think I discovered a bug in fasm concerning the 16-bit 'and' instruction. when I remove the 'and ax, $100' everything works fine, but when it is un-commented 'CRASH'. see code below:

This probably should've been in the 'compiler internals' forum, so if the moderator would like to move this, thank you.

There might be better experts than me here in ... but I think this
code CANNOT work. System requirements ? DOS ? Windoze ?
"use16" will switch FASM to 16-bit,
but your PE-32 executable still runs in 32-bit PM ... and the INT
probably won't get decoded and even less executed at all



I would move it to Main. DOS vs Windoze, 16-bit vs 32-bit issue.

The code works just fine if I comment out the 'and ax, $100'. And as I look at the intel docs and try to hard code the instruction into the code, it still crashes at that instruction. So, I'm kind of wondering if it's really an fasm bug or not?

Oh, i see there some misunderstanding how code works under 32bit.

means create 32bit (PE) console (itself) program. 16bit coded code (use 16) will be treated by OS as 32bit anyway, but without/with 66h prefix.

First of all: interrupt functions like INT 2Fh you tried to use don't work in the PE programs, and they will crash your program (the exception are VxD calls by INT 20h in Win9x, but that's a really different story...). The only reason why it did not crash your program is because you have combined it with another serious mistake. I will try to explain in detail.

The USE16 makes assembler generate 16-bit code, however whether the code is interpreted by processor as 16-bit or 32-bit one, it is dependend on the settings of code segment. In Win32 code segment is 32-bit one, and even if you make fasm to generate some code as 16-bit one, the processor will interprete it as 32-bit one, most probably causing a serious trouble.

The 66h prefix switches the size of data on which instructions operators, from the default for current mode to the opposite one. In 16-bit mode the 16-bit size is default, and thus prefixing an instruction with 66h makes it work on 32-bit operands. Example:

In 16-bit mode:
B8 00 1A - MOV AX,1A00h
66 B8 00 1A 00 00 - MOV EAX,00001A00h

In 32-bit mode:
B8 00 1A 00 00 - MOV EAX,00001A00h
66 B8 00 1A - MOV AX,1A00h

So now when you tell fasm to generate code for 16-bit mode and put there a "mov ax,1A00h" instruction, it will generate the three bytes B8 00 1A. However in PE program the code is always executes as 32-bit. Thus when processor sees the B8 instruction opcode without any prefix, it takes it as "mov eax,..." instruction. However this instruction needs two bytes more for the 32-bit constant that has to be stored in EAX! And so it executes the instruction that takes five bytes in total, not three. And, by coincidence, the two bytes that follow the three bytes B8 00 1A in your code are CD 2F - the "int 2Fh" instruction. So processor executes the "mov eax,2FCD1A00h" instruction, and goes to what follows. Thus if you had only this in your USE16 block, there was nothing wrong with it, the interrupt wasn't just called at all.

But when you added another instruction encoded for 16-bit mode, it again are two more bytes when was executed in 32-bit mode, and this time it caused the instruction chain that follows to become completely broken. Thus this crash.

I hope I was able to explain it clearly, if you still don't understand something, please let me know.

Yeh, I think I do, when compiled, fasm compiled it correctly as 16-bit, but when exectuted, it still tried to run as 32-bit. So I guess I would have to make it a .com file wouldn't I?

Right. If you want to:

- Use DOS INT's
or
- Expose use16 FASM bugs (this is NOT one)

you have to use

- format MZ
or
- format binary as "COM"

And run it preferably in DOS ...

You can also disassemble your code with use32, and you'll
see the garbage the CPU has to execute, and no INT instruction at all