有没有办法让 Windows 64 位上的应用程序在 64 位和 32 位模拟层下执行代码？
我感兴趣的是我是否可以编写一个应用程序，该应用程序能够在没有模拟层的情况下调用一些代码以及在 32 位模拟层内调用一些代码。
主要原因是我需要使用 API SetWindowHook，并且我想为 64 位和 32 位应用程序设置钩子。
当然，我可以创建 2 个应用程序（一个用于 32 位，另一个用于 64 位）并同时启动它们。但是，我需要更多代码来管理它们（启动、停止、升级等）。
因此，我正在考虑是否有可能拥有一个应用程序。
我唯一的想法是拥有一个应用程序和 2 个 COM DLL（32 位和 64 位），并使用代理进程来运行 32 位代码。然而，它需要一些额外的 COM 包装器等等。
I am interested whether I can write an application which will be able to call some code without emulation layer and some code inside of 32 bit emulation layer.
The main reason for that is that I will need to use API SetWindowHook and I want to set hook both for 64 bit and 32 bit applications.
Sure, I can create 2 application (one for 32 bit and another for 64 bit) and launch them simultaneously. However, I will need more code to manage them (start, stop, upgrade and etc).
So, I am looking whether it's possible at all to have one application.
The only idea which I have is to have one application and 2 COM DLL's (32bit and 64bit) and use a surrogate process to run code of 32 bit. However, it will require some additional COM wrappers and so on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我无法提出更好的方法，但我能做的是为您提供一个简单的基于钩子的工具的源代码，该工具可以完成完全相同的事情。请随意阅读对您有用的内容：
http://www.pretentiousname.com/NoBarTab/ NoBarTab_poc3.zip
（如果这个 URL 将来中断，只需上一级；可能是因为我已经完成了它并为该工具及其源代码放置了一个真实的页面。）
这是一个 VS2010 C++项目，但应该很容易在旧的 IDE 中编译。 （写这篇文章实际上让我暂时不再使用 VS2010，呵呵。）
显然，如果你使用它，请重命名任何窗口类和二进制名称，以避免与我的工具发生冲突。 （名称中带有“NoBarTab”的任何内容。）
FWIW，这是我几周前开始编写的工具，但还没有时间完成。不过，挂钩部分已经完成。它挂钩窗口创建，以便针对特定进程，从 Windows 7 任务栏中删除选项卡。 （我尤其讨厌 VMware 使用该功能的方式。）无论如何，当我完成它时，我都会发布源代码......
32/64 位挂钩部分已全部完成。我唯一没有时间做的是添加一个配置 UI，以便您可以指定它应该关心哪些进程，但这对于您正在做的事情并不重要。
（我应该说，我从 Win7 任务栏中删除选项卡的方式完全是一种黑客行为，可能会破坏 Windows 的未来版本。没有记录的方法可以做到这一点，所以我不得不解决一个令人讨厌的组装问题。您实际的挂钩代码不过，我感兴趣的都是“正确的”。）
另外，我这样做是为了使几乎所有真正的逻辑都在主 64 位 exe 中。 32 位 EXE 的存在只是为了安装 32 位钩子 DLL，32 位和 64 位钩子 DLL 都只是将消息发布到主 64 位 exe 的隐藏窗口。这是否适合您正在做的事情，我让您自行决定，但我认为这可能符合您将所有内容尽可能集中在一处的愿望。
希望它有用！
I cannot suggest a better way of doing it but what I can do is give you the source to a simple hook-based tool which does exactly the same kind of thing. Feel free to the bits that are useful to you:
http://www.pretentiousname.com/NoBarTab/NoBarTab_poc3.zip
(If this URL breaks in the future, just go up a level; it'd probably because I've finished it and put a real page up for the tool and its source.)
It's a VS2010 C++ project but should be easy to compile in older IDEs. (Writing this actually put me off using VS2010 any further for now, heh.)
Obviously, if you use it, please rename any window classes and binary names to avoid conflicts with my tool. (Anything with "NoBarTab" in the name.)
FWIW, this is a tool I started writing a few weeks ago but haven't got around to finishing. The hooking part is finished, though. It hooks window creation so that it can, for specific processes, remove tabs from the Windows 7 taskbar. (I hate the way that feature is used by VMware, in particular.) I was going to release the source code anyway when I finished it...
The 32/64-bit hooking part is all done. The only thing I haven't got around to is adding a config UI so you can specify which processes it should care about, but that's not important for what you are doing.
(I should say that the way I remove tabs from the Win7 taskbar is a complete hack and might break with future versions of Windows. There's no documented way to do that so I had to settle on a nasty kludge. The actual hooking code that you'd be interested in is all "proper", though.)
Also, I made it so that almost all of the real logic is within the main 64-bit exe. The 32-bit EXE just exists to install the 32-bit hook DLL and both the 32-bit and 64-bit hook DLLs just post a message to the main 64-bit exe's hidden window. Whether that is suitable for what you're doing I leave to you to decide, but I figure it probably fits with your desire to have everything in one place as much as possible.
Hope it's useful!
SetWinEventHook 是更高级别的挂钩 API 为您处理 32 位/64 位内容。这是在今天另一个问题的答案中出现的，我认为这里值得一提，以防万一这解决了你的问题。完全归功于@atzz 的回答。
SetWinEventHook 是否与较低级别的 SetWindowsHookEx 将取决于您正在做什么。 （就我而言，我可能可以在其他答案中重写 NoBarTab 代码以使用更简单的 API。不过，还没有详细查看。）
SetWinEventHook is a higher-level hooking API which handles the 32-bit/64-bit stuff for you. This came up in the answers to another question today and I thought it'd be worth mentioning here in case that solved your problem. Full credit to @atzz for his answer over there.
Whether or not SetWinEventHook is as suitable to you as the lower-level SetWindowsHookEx will depend on exactly what you're doing. (In my case, I could probably re-write the NoBarTab code in my other answer to use the more simple API. Haven't looked in detail yet, though.)
使用模拟层的最大原因是您的 64 位代码将拥有更大的地址空间。例如，您的数据地址为 0x12345678aa000000。如果将该指针直接传递给 32 位代码，它将被截断为 32 位地址空间。也就是说，高位 32 位被删除。因此，对于 32 位代码来说，数据的地址看起来像是 0x00000000aa000000。这显然是一个完全不同的领域，而不是您想要的。
是的，这是可能的。不，你不应该这样做，除非你对 x86 和 x64 汇编非常有经验，并且可以访问 32 位源代码以确保它知道它实际上在 64 位空间中运行并且还可以访问 64-位代码，以确保它传递给 32 位代码的所有数据仅位于 32 位地址范围内。
不，除非您试图进行 UBER UGLY hack，否则不希望在没有模拟层的情况下执行 32 位代码。
The biggest reason for the emulation layer is that your 64-bit code is going to have a larger address space. Say, for example, you have data addressed at 0x12345678aa000000. If you pass that pointer straight to 32-bit code, it will get truncated to 32-bit address space. That is, to say, that the high-order 32 bits get removed. So the address to your data looks like 0x00000000aa000000 to your 32-bit code. This is clearly a completely different area and not what you intended.
Yes, it's possible. No you shouldn't do it unless you're extremely experience with x86 and x64 assembly, and have access to the 32-bit source code to ensure that it knows that its actually running in 64-bit space and also have access to 64-bit code to ensure that all of the data it passes to the 32-bit code is only in the 32-bit address range.
No, executing 32-bit code without the emulation layer is undesirable unless you are trying to make an UBER UGLY hack.
我认为你唯一的希望是通过进程外 COM 之类的东西来完成它，因为每个进程都必须是全 32 位或全 64 位。
I think your only hope is to do it through something like out-of-process COM because each process has to be all 32 bit or all 64 bit.