从 Win16 移植到 Win32 - ASM 代码块混淆

Question

我正在尝试编译 2013 年 Visual Studio 九十年代末的一些代码。在大多数情况下，它非常简单，但有一小部分 ASM 块我不太确定（我从来没有做过任何 x86 ASM，几年前在 uni 只做过一些微控制器特定的东西。

下面的函数生成了与大小不匹配相关的编译错误，因此我将 int 更改为 short int，认为它是为 16 位编写的。这消除了大小错误，但现在我有与 "short int 60h" 行相关的错误：

错误 1 错误 C2400：'opcode' 中的内联汇编程序语法错误；找到 '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 );
}

所以上面所有的短整数在原始代码中都是整数。

如果我删除 short 并将其保留为 "int 60h"，错误就会消失，但我担心我现在再次出现大小不匹配，也许编译器出于某种原因没有抱怨。

谷歌搜索 "found data type" 错误我没有遇到这种语法，我觉得它很奇怪，只是声明了一个 int 就好像在 ASM 中间什么都不做。

谁能建议如何安全移植？关于为什么 int 甚至在那里的解释也会引起兴趣...

谢谢

Answer 1

_asm代码块中的int是Intel x86 INT（中断）指令——它并不意味着C整数。删除前面的单词 "short"，它会导致语法错误，因为 "short" 对汇编程序没有意义。

INT 0x60 主要保留供 user/vendor 使用，但已用于其他一些用途 - 请参阅 http://www.delorie.com/djgpp/doc/rbinter/ix/60/。

这部分是硬件级接口吗？您的函数名称似乎暗示了这一点。此中断调用可能是供应商提供的设备接口的一部分，因此可能没有任何等效的 Win32 函数。

无论如何，如果需要从用户模式进行硬件级访问，则移植到 Win32 时可能会遇到其他几个问题，因为用户模式运行的权限级别低于内核模式驱动程序。

因此，虽然您的代码应该在从 _asm 块中删除 short 之后编译，但很可能程序会在它命中时立即崩溃那条线。

Answer 2

正如frasnian所说，int 60h是用户中断，其含义以用户定义的方式取决于ax和bx。一个简短的互联网搜索出现了 this page，这表明它被用于 Agfa 的一个名为 TTSR.exe 的程序中。但它没有给出 bx=0002h.

的定义

以前的TSR就是"Terminate and Stay Resident"。在 Windows 成为多任务之前，程序仍然可以在退出后请求驻留在内存中。然后它可以在生成特定中断时获得控制权——例如，通过 int 60h 指令。

无论如何，这不适用于 32 位 Windows，因此您将不得不弄清楚它要做什么，然后自己编程。

从 Win16 移植到 Win32 - ASM 代码块混淆

Porting from Win16 to Win32 - ASM code block confusion

c++

assembly