Question

我正在尝试编译来自九十年代后期的Visual Studio 2013中的一些代码。在大多数情况下，它非常直接但是有一些我不太确定的ASM块（我从未做过）任何x86 ASM，仅仅是单年前微控制器专用的奇怪的东西。）

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

错误1错误C2400：'opcode'中的内联汇编语法错误;找到'数据类型'

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”，则错误消失，但我担心我现在再次出现不匹配的大小，或许编译器因某些原因没有抱怨。

搜索“找到的数据类型”错误我没有遇到过这种语法，这对我来说看起来很奇怪，只是声明了一个int，好像在ASM中间什么都不做。

有谁能建议如何安全移植？解释为什么int甚至会有兴趣阅读...

由于

Answer 1

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

INT 0x60主要供用户/供应商使用，但已用于其他一些事项 - 请参阅http://www.delorie.com/djgpp/doc/rbinter/ix/60/。

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

在任何情况下，如果需要从用户模式进行硬件级访问，则可能还有其他几个问题移植到Win32，用户模式运行的权限级别低于内核模式驱动程序。

因此，虽然在从short块中删除_asm后，您的代码应该编译，但是当程序碰到该行时，程序很可能立即崩溃。

Answer 2

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

过去的TSR意味着“终止并保持居住”。在Windows成为多任务之前，程序可能会要求在退出后留在内存中。然后，它可以在生成特定中断时获得控制权 - 例如，通过int 60h指令。

在任何情况下，这都无法在32位Windows上运行，因此您将以某种方式解决它正在尝试做的事情，然后自己编程。

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

2 个答案: