Assembly 64位Windows上的16位程序集？

不久前我决定开始学习汇编，所以我开始使用FASMW进行16位汇编。 然而，我最近得到了一台运行64位Windows7的全新计算机，现在该程序汇编的编译的.COM文件都不能再工作了。他们会给出一条错误消息，指出.COM与64位windows不兼容。 32位程序集仍然可以工作，但是我宁愿从16位开始，然后逐步升级。。。

---

可以在windows 7上运行16位程序吗？或者有没有具体的方法来编译它们？或者我应该放弃并跳到32位吗？

您不能使用16位汇编的原因是因为所有64位版本的Windows都使用了16位汇编

解决这个问题的唯一方法是安装DOSBox之类的东西，或者安装VirtualBox之类的虚拟机包，然后将FreeDOS安装到其中。这样，你就得到了真正的DOS。（）

就我个人而言，我会鼓励为DOS编写16位汇编吗？不，我会使用32位甚至64位汇编，原因是不同的操作系统有不同的函数调用集（称为ABI）。因此，64位linux应用程序的ABI不同于32位应用程序。不确定Windows是否是这样。但是，我保证中断的含义可能不同

---

也有16种程序集需要考虑的事情，比如使用的内存模型。我可能错了，但我相信DOS会给你64K的内存来玩“就是这样”。据我所知，所有东西，你的整个堆和堆栈以及代码都必须适合这个空间，这让你想知道任何东西是如何工作的。

我的建议是只编写32位代码。虽然一开始似乎学习如何编写16位代码，然后“毕业”到32位代码是有意义的，但实际上情况恰恰相反：编写32位代码实际上更容易，因为有很多任意的体系结构约束（例如，关于可以用作基寄存器的内容）基本上都是32位代码

对于这件事，我会考虑是否有真正的理由来编写16位x86代码。在大多数实际应用中，它是一个死气沉沉的平台——对于台式机来说，它已经严重过时，而对于嵌入式机器，你更可能看到ARMs或微芯片图片之类的东西。除非您心中有一个特定的目标，并且确信它将是一个16位x86，否则我可能会忘记它的存在，就像世界上大多数其他地方一样。

在64位Windows（或任何其他64位操作系统）上，您需要模拟器或完全虚拟化

长模式的内核不能使用vm86模式来提供虚拟8086实模式环境。这是AMD64/x86-64体系结构的一个限制

在64位内核运行的情况下，CPU在16位模式下本机运行的唯一方法是16位保护模式（是的，这是存在的；不是，没有人使用它，而且AFAIK主流操作系统不提供使用它的方法）。或者内核将CPU从长模式切换回传统模式，但64位内核不这样做

但实际上，通过硬件虚拟化（VirtualBox、Hyper-V或任何使用Intel VT-x或AMD SVM的产品），一个64位内核可以作为整个虚拟机的虚拟机监控程序，无论该虚拟机是以16位实模式运行还是运行32位操作系统（如Windows 98或2000）它又可以使用vm86模式运行16位实模式可执行文件

---

尤其是在64位内核上，通常更容易完全模拟16位PC（就像DOSBOX那样），而不是使用硬件虚拟化以本机方式运行正常指令，但捕获直接硬件访问（

输入

/

输出

，加载/存储到VGA内存等）和

int

进行DOS系统调用/BIOS调用/任何操作的指令。

您始终可以为目标环境运行VM。程序集是特定于处理器的。你用的是什么处理器？你用的是什么处理器？像Windows虚拟PC这样的虚拟机。但这个问题无论如何都是误导性的，因为16位不能工作。64位模式简单得多，与32位模式非常相似，您也不需要专门学习后者。更多位！=harderRelated：对于在kernel32.dll中调用WinAPI函数的32位示例，如果您认为64K内存足够，您应该查看demoscene->Increct（但不是您的错）。它已被删除，因为它在长模式下无法正常工作。有趣的是，我没有意识到这是它被移除的原因，我只知道它被微软抛弃了。就我而言，这是一个不错的举措，我们真的不应该再使用WOW64了。那么，像基于DOS的交叉编译器这样的东西会不再工作吗？听起来是个不使用64位的好理由。我想知道为什么微软没有为DOS提供仿真层？即使进行每指令模拟，它仍然可以让DOS软件在新机器上运行得比它在为其编写的机器上运行得更快。+1，我要提到嵌入式，但我从汇编的角度对它了解得不够。说得好，r.e.学习曲线也不错。