Porting from Win16 to Win32 - ASM code block confusion

Question

I'm trying to compile some code from the late nineties in Visual Studio 2013. For the most part it's pretty straight forward but there are a small number of ASM blocks I'm not too sure about (I've never done any x86 ASM, only the odd bit of microcontroller specific stuff at uni years ago).

The function below generated compile errors relating to size mismatches, so I changed the ints to short int thinking it was written for 16 bit. That got rid of the size errors but now I have this error relating to the "short int 60h" line:

Error 1 error C2400: inline assembler syntax error in 'opcode'; found 'data type'

static unsigned int Read_TSR( unsigned short int b_offset )
{
  unsigned short int buffer;
  _asm {
    mov ax,899bh
        mov bx,2
        mov dx,b_offset
        short int 60h
    mov buffer,bx
  }
  return ( buffer );
}

So all the short ints above were just ints in the original code.

If I remove short and leave it as just "int 60h" the error disappears, but I worry I'd again be mismatching sizes only now perhaps the compiler isn't complaining for some reason.

Googling the "found data type" error I haven't come across this syntax, which looks very odd to me, just having an int declared as if to do nothing in the middle of the ASM.

Can anyone suggest how this can be safely ported? An explanation of why that int is even there would be read with interest too ...

Thanks

frasnian frasnian · Accepted Answer · 2015-01-22T09:34:31

The int in the _asm code block is the Intel x86 INT (interrupt) instruction - it does not mean a C integer. Delete the word "short" from in front of it, it's causing a syntax error because "short" there makes no sense to the assembler.

INT 0x60 is primarily reserved for user/vendor use, but has been used for a few other things - see http://www.delorie.com/djgpp/doc/rbinter/ix/60/.

Is this part of a hardware-level interface? The name of your function seems to hint that is. It's possible that this interrupt call was part of a vendor-provided interface to a device, so there probably isn't any equivalent Win32 function.

In any case, you may have several other problems porting to Win32 if hardware-level access is needed from user-mode, which runs at a lower privilege level than things like kernel-mode drivers.

So, although your code should compile after removing that short from the _asm block, in all likelihood the program will immediately crash when it hits that line.

Porting from Win16 to Win32 - ASM code block confusion

2 Answers