如何强制 32 位应用程序在 CreateObject 中使用 64 位 COM dll？
以下代码的行为有所不同，具体取决于我使用 32 位还是 64 位版本的 wscript：
Set oSQLServer = CreateObject("SQLDMO.SQLServer")
For Each o in oSQLServer.ListInstalledInstances
MsgBox o
Next
在 32 位中，它将列出我的 32 位服务器 (SQL Server 2000) 的实例，在 64 位中，我将获取 64 位服务器的内容 ( SQL Server 2008）。 我需要将此代码转换为 C++（32 位应用程序）。但我需要显示 64 位服务器。如何强制创建的对象使用 64 位 dll 和注册表中的 64 位密钥？
The following code behaves differently depending on if I use the 32 or 64 bit version of wscript:
Set oSQLServer = CreateObject("SQLDMO.SQLServer")
For Each o in oSQLServer.ListInstalledInstances
MsgBox o
Next
In 32 bit, it will list the instances of my 32bit server (SQL Server 2000), in 64 bit I get the contents of my 64bit server (SQL Server 2008).
I need to convert this code to C++ (a 32 bit application). But I need to show the 64bit servers. How do I force the created object to use the 64bit dll and 64bit key in the registry?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
32 位应用程序无法加载 64 位 DLL，64 位应用程序也无法加载 32 位 DLL。
A 32-bit app cannot load a 64-bit DLL, and a 64-bit app cannot load a 32-bit DLL.
我决定使用 ODBC 的 SQLBrowseConnect 和连接字符串
SQLDMO 确实已经死了，而 SQLSMO 仅对于托管应用程序来说是相当短视的。
I've decided to use ODBC's SQLBrowseConnect with the connection string
SQLDMO is well and truely dead, and SQLSMO is rather short-sightedly for managed applications only.