I've noticed FASM assembles int 03h differently from other assemblers/compilers. I've noticed it when I was debugging. Surprisingly, Windows dissassembler (Dr. Watson logger) disassembles them differently too:
FAULT ->0040416f cc               int     3

00404170 cd03 int 03

The first int 3 (assembled as CC) I made manually using db 0CCh, but second one FASM assembled from int 3h.
Posted on 2003-04-21 22:40:33 by comrade
I took liberty to fix it with some other minor adjustments to resources. :)


lods byte [esi]
call get_size_operator
cmp ah,1
ja invalid_operand_size
cmp al,'('
jne invalid_operand
call get_byte_value
cmp al, 03
je .int03
mov ah,al
mov al,0CDh
stos word [edi]
jmp instruction_assembled
.int03: mov al, 0CCh
stos byte [edi]
jmp instruction_assembled
Posted on 2003-04-21 22:58:46 by comrade
Hmm, just looked at source-code and found you can do int3 for short form. :) Damn!
Posted on 2003-04-21 23:01:02 by comrade
int3 and int <space> 03 are diferent instructions at all. int3 is special one byte instruction for debug purposes (break points) but int 03h is usual software interrupt with number 3 (same as int 21h). It's strange that FASM assemble int<space>3 as int3 IMHO.
Posted on 2003-04-22 00:49:17 by JohnFound
It doesn't, but I modified it to. But then why does MASM assemble int<space>03 as CC, software breakpoint?
Posted on 2003-04-22 07:23:05 by comrade
But then why does MASM assemble int<space>03 as CC, software breakpoint?

Because MASM is buggy :grin:
Posted on 2003-04-22 08:58:59 by JohnFound
because 0xCC is usually what you want when you write "int 3". I personally prefer int3=0xCC and int<space>3=0xCD,0x03 , though.
Posted on 2003-04-22 09:15:34 by f0dder