我有一个 32 位 DLL，旨在通过 com 模型和关联的 tlb 文件进行访问。
该 DLL 似乎是 x86。
有没有办法从 x64 程序访问这种 DLL？ tlb 文件与 x86/x64 无关吗？
我问这个问题是因为有些功能似乎可以工作，其他功能似乎可以工作，而 o̶t̶h̶e̶r̶s̶ ̶a̶r̶e̶ ̶m̶i̶s̶s̶i̶n̶g̶ ̶c̶o̶m̶p̶a̶r̶e̶d̶ ̶t̶o̶ ̶t̶h̶e̶ ̶.̶ n̶e̶t̶ ̶a̶s̶s̶e̶m̶b̶l̶i̶e̶s̶ 。
--Edit--
由于 OEM 方面的错误而出现组件缺失。
在大多数情况下，类型库的目的当然是与平台无关。您在 Microsoft 提供的 Windows 编程中遇到的大多数都是这样。在 .NET 中最明显，这使得编写可以在 32 位或 64 位模式下运行的代码变得非常简单，由 AnyCPU 平台目标公开。使用 Microsoft.Office.Interop 中的互操作类或编写在 Office 程序内运行的扩展不需要任何特殊操作，您可以使用完全相同的类型库。
但是，当您使用由从未考虑过它可以在 64 位代码上工作的程序员创建的类型库时，效果并不总是那么好。最典型的问题是由方法参数引起的，这些参数实际上是底层的指针，但被扁平化为整数类型，long是典型的选择。这些指针值在 64 位模式下为 64 位宽，当您尝试将它们填充到 32 位整数中时，它们会出现错误行为。 HANDLE 值就是一个很好的例子。
迄今为止，最臭名昭著的 oops 是 Microsoft 的。 ADO 的类型库已损坏，这是一个广泛用于与数据库引擎通信的数据库提供程序库。他们在 Windows 7 SP1 中进行了重大更改，当程序员在该操作系统中构建程序并发现它不再适用于旧版本的 Windows 时，这一更改导致了广泛的痛苦。哎呀，情况正好相反，这种类型在 64 位操作系统上应该是 32 位的，但在 64 位操作系统上却被声明为 64 位。当您拥有 Windows SDK 版本 8、adoint_Backcompat.h 头文件、ADO_LONGPTR 类型时，您会看到此错误。取而代之long在 adoint.h 中。
最好与原始程序员合作来解决这个问题。或者，为了利用 COM 代理，当从 64 位进程调用时，它们可以在进程外运行 32 位代码。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
