为什么 32 位驱动程序不能在 64 位上运行
从过去的阅读来看，大多数 32 位驱动程序似乎无法在 64 位上运行。
在纯粹的概念层面上，我认为 64 位机器在使用 32 位驱动程序时有额外的“空间”，因此我试图确定为什么它们通常无法工作。 （我来自用户空间）
我已阅读这篇关于x86-64的wiki文章州
堆栈上的压入和弹出始终以 8 字节跨度进行，指针的宽度为 8 字节。
我可以看到这可能是 32 位驱动程序在 64 位上可能失败的原因，因为它发出 pop() ，弹出的数据量是驱动程序预期的两倍。
我刚才提到的内容可能完全不合时宜，因为我是一个用户空间人员，在这种情况下，或者其他情况，有哪些实际示例（代码或外行解释）来说明为什么 32 位驱动程序在 64 位上运行时会失败一点？
From past readings it seems most 32 bit drivers won't work on 64 bit.
At a purely conceptual level, I see a 64 bit machine as having extra 'room' when using 32 bit drivers so am trying to determine why most often they will not work. (me coming from user-space)
I have read this wiki article on x86-64 which states
Pushes and pops on the stack are always in 8-byte strides, and pointers are 8 bytes wide.
I can see this perhaps being a reason a 32bit driver might fail on 64bit as it issues a pop() which pops twice as much data as the driver expected.
What I just mentioned may be completely off the mark as I am a user-space guy, in which case, or otherwise, what are some practical examples (code or layman explanation) of why 32 bit drivers fail when run on 64 bit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
简而言之，您不能将 64 位地址存储在 32 位指针中。因此，如果您的代码涉及到操作系统来回传递指针（就像设备驱动程序通常所做的那样），那么结果不会很好。
驱动程序通常用于在物理设备（例如磁盘）和内存之间移动数据。驱动程序将被要求将 X 磁盘扇区传输到地址 Y 处的内存中。
在 64 位操作系统上，Y 将是 64 位地址，因此您的 32 位驱动程序无法处理此问题。当然，存在一个问题，即传递的指针的大小是预期的两倍，因此如果它确实运行，它可能会在错误的内存上留下印记......
Put simply, you can't store a 64-bit address in a 32-bit pointer. So if your code involves passing pointers back and forth to the operating system, as device drivers typically do, it's not going to end well.
Drivers are often about moving data between phyiscal devices (eg, a disk) and memory. The driver will be asked to transfer X disk sectors into memory at address Y.
On a 64-bit OS, Y will be a 64 bit address, so your 32-bit driver can't handle this. And of course there's the issue that the size of the pointer passed is twice what it expects, so if it DID run it would probably stamp all over the wrong memory...
请记住，驱动程序是用来与硬件对话的。如果 32 位驱动程序代码加载到距硬件 的位置超过 4GB 的内存区域会怎样？内存映射寄存器 是？驱动程序代码将在内存中乱写，与它本身或它应该驱动的硬件无关。
Remember that drivers are there to talk to hardware. What if the 32bit driver code was loaded into a memory area that's more than 4gigabytes away from where the hardware's memory-mapped registers are? The driver code would be scribbling in memory that has nothing to do with itself or the hardware it's supposed to be driving.
x86-64 处理器无法在特权（内核）模式下运行 32 位代码。兼容模式仅适用于用户空间。
x86-64 processors can't run 32 bit code in privileged (kernel) mode. The compatibility mode is only available for user space.
我的2分钱值。微软并不担心发布升级或补丁时造成的混乱。
特别是关于与 x64 一代操作系统兼容的旧版硬件。
我在这里谈论的是无数的科学硬件，这些硬件只有 32 位驱动程序，并且该硬件不再可用且不再受支持，因此实验室只能运行 XP 或最多 7 x86。同样，消费者也购买了生物识别扫描仪和各种医疗设备。
x64 路径应该设计为适应传统的 32 位硬件。
My 2 cents worth. Microsoft doesn't give a rats about the mess it causes when releasing upgrades or patches.
Especially about Legacy hardware being compatible with x64 generation OS's.
I'm talking here about the myriad of scientific hardware out there that only has 32bit drivers with that hardware being unobtainable and unsupported any longer, thus leaving Labs running XP or at best 7 x86. Likewise consumers how have bought Biometric scanners and various medical equipment.
The x64 path should have been designed to accommodate legacy 32bit hardware.