C++ 在Windows7中使用32位shell扩展64位

我想开发一个与WindowsXPSP2（32位）和Windows7 64位兼容的shell扩展（上下文菜单处理程序）

是否可以在64位Windows中运行32位shell扩展，或者必须将shell扩展移植/重建为64位才能在64位Windows 7中使用

在64位操作系统中使用32位shell扩展是否存在任何缺点/已知问题

---

32位应用程序在64位Windows中运行良好，但我不确定是否有外壳扩展，因为如果我的理解正确，外壳扩展在加载到Explorer进程的proc COM服务器中，在64位Windows中应该是64位进程……或者是“32位模拟”的一种形式为在64位操作系统中运行的32位外壳扩展提供？

外壳扩展只是一个DLL，规则是32位应用程序只能加载32位DLL，而64位应用程序只能加载64位DLL。这是没有办法的

32位shell扩展在64位系统上可能仍然有用，因为这意味着任何加载shell扩展的32位第三方应用程序都可以工作。例如，TortoiseSVN附带并安装32位和64位版本，在64位Windows上，您仍然可以从32位应用程序（如第三方文件管理器）访问TortoiseSVN上下文菜单

---

但是资源管理器本身是64位Windows上的64位本机扩展，因此如果您希望它在资源管理器中工作，则需要64位版本的扩展。

Shell扩展是COM组件。如果将其安装为进程外服务器，则Windows（DCOM）应负责所有32 64位编组

---

然后，MIDL编译器将创建64位存根，并在进程中加载。

您可以使用32位资源管理器，就像在64位Windows中一样。它们可以处理32位DLL扩展，这些扩展可用于搜索内容、预览数据以及在上下文菜单中显示的内容。内置资源管理器为64位，忽略32位扩展。

不是选项。只需向您的项目中添加另一个配置，该配置除了x64目标之外还使用Win32目标。如果您的代码是干净的，那么生成x86和x64版本的DLL就不会有问题了。@HansPassant:这听起来是个正确的答案。@HansPassant:我还想知道32位和64位shell扩展是否应该有不同的GUID。它们应该共享相同的GUID。在64位操作系统上注册32位扩展应导致将其放入registry@Petesh：但是在64位操作系统上仍然需要64位shell扩展的构建吗？或者32位扩展在64位操作系统中运行良好吗？这是错误的。内容菜单处理程序是进程内扩展，不能作为进程外扩展来实现。分布式COM（DCOM）不支持apply@Micky你的链接不支持你的声明。有其他参考资料吗？具体地说；及；和。你的？@Micky:你的第三个链接错了（第一个链接的引用就是证明）。第一个链接中的引用是一个示例列表，即并非详尽无遗。第二个链接确实支持你的观点。你为什么不首先把它链接起来？你是否打算扩展你的答案来概述如何制作一个进程外上下文菜单处理程序？