something strange with a far call in 16bit

[TheClue/Nash of Subsystems]

i've a trouble in completing the very very very last code for my thesis in computer science. I'm playing with interrupt hooking in 16 bit DOS mode, but my code acts strange:
-------------------------

; old int21h
mov ax, 0x3521
int 0x21
; save it
mov [OLDINT], bx
mov [OLDINT+2], es
lea di, [OLDINT]

; simulate 'exit to dos' int21h service using a far call
mov ax, 0x4C00
pushf
call far dword [cs:di]

OLDINT dd 0x00
-----------------------

well it crashes at location 011E. Debugging it i can see:

2048:011D 9C pushf
2048:011E 2E CS:
2048:011F 66 DB 66
2048:0120 .... call far [DI+0]
..........

from NASM manual i read:

"When NASM is in BITS 16 mode, instructions which use 32-bit data are prefixed with an 0x66 byte, and those referring to 32-bit addresses have an 0x67 prefix. In BITS 32 mode, the reverse is true: 32-bit instructions require no prefixes, whereas instructions using 16-bit data need an 0x66 and those working on 16-bit addresses need an 0x67."

but why does the program crash?

[nobody]

'Cause you haven't got 32-bit data, you've got two items of 16-bit data. Use dword for a 32-bit call (plus segment), word here.

Best,
Frank

[TheClue/Nash of Subsystems]

uhm, im not sure i understood what u mean

can u pls post a line of code? tnx!! :)

gabrio

[nobody]

call far word [cs:di]

for example...

I doubt if you need the cs override - "call far word [di]" ought to do it, since you just loaded OLDINT without an override. If ds isn't equal to cs, you're going to miss it! (probably won't hurt in a .com file) As your disassembly shows, you've persuaded Nasm to insert two override bytes into your code, and you don't need any at all. "far" tells Nasm to expect 16 bits of segment, following 16 or 32 bits of offset. You've told Nasm to expect a "dword" offset, and only provided 16 bits of data, so you're way off in the weeds...

Best,
Frank