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

我试图在Visual Studio 2013中编译一些90年代后期的代码。在大多数情况下，这是非常直接的，但有一小部分ASM块我不太确定（我从来没有做过任何x86 ASM，只是几年前在uni做过一些微控制器特定的东西）

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

错误1错误C2400：“操作码”中的内联汇编程序语法错误；找到“数据类型”

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并将其保留为“int60h”，错误就会消失，但我担心我会再次出现大小不匹配的情况，直到现在，也许编译器不会因为某些原因而抱怨

< Google的“发现数据类型”错误，我没有遇到过这种语法，这对我来说很奇怪，只是在ATM的中间声明一个int好像什么也不做。 有人能建议如何安全地移植吗？一个解释为什么整数是偶数也会被感兴趣地阅读

---

感谢asm代码块中的

int

是英特尔x86

int

（中断）指令-它并不意味着C整数。从前面删除单词“short”，这会导致语法错误，因为“short”对汇编程序没有意义

INT 0x60主要保留供用户/供应商使用，但已用于其他一些用途-请参阅

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

在任何情况下，如果需要从用户模式进行硬件级访问，那么在移植到Win32时可能会遇到一些其他问题，用户模式的权限级别低于内核模式驱动程序

---

因此，尽管您的代码应该在从

\u asm

块中删除

short

后编译，但很可能程序在到达该行时会立即崩溃。

正如frasnian所说，

int 60h

是一个用户中断，其含义取决于用户定义的

ax

和

bx

。出现了一个简短的互联网搜索，这表明它被Agfa中一个名为TTSR.exe的程序使用。但它没有给出

bx=0002h

的定义

在过去，TSR的意思是“终止并保持居民身份”。在Windows变成多任务之前，程序仍然可以在退出后请求驻留在内存中。然后，它可以在生成特定中断时获得控制——例如，通过

int60h

指令

---

无论如何，这在32位Windows上是行不通的，所以你必须先弄清楚它想做什么，然后自己编程。

这仍然不太可能奏效。OP需要找出该中断在Win16上的作用，并找到一个匹配的Win32 API函数来调用。它是保留的（我的答案的更新与您的评论一起发布）。由于OP提到使用微控制器，这可能是供应商提供的接口的一部分，因此可能没有任何Win32等价物。在任何情况下，如果需要从用户模式（CPL3）进行硬件级访问（

Read\u TSR

），我想在移植到Win32时会出现其他几个问题。谢谢，我从来没有想到这是一个中断，应该是这样的。我正在编译的大部分内容是一个大型支持库，其中大部分可能不会被主应用程序使用，因此目前的目标是编译它。任何崩溃都可以在个人的基础上查看。@ WORD：如果这是一个更大的支持库的一部分，这个库中有一个这样的缺陷，你可能需要考虑包括<代码> <代码>，并使用<代码> uint 8xt ，<代码> uint 16t t < />代码>，而不是更冗长的<代码>无符号的短int >代码>等。当您必须处理这样的代码接口时。我已经更新了一些较旧的硬件级接口，显式大小的int类型在与C/C++和汇编接口时非常清晰。我认为TSR在这个上下文中是指“计时器服务寄存器”之类的东西，但我也简要回顾了DOS TSR（不太好）的旧时代：）