tlb 文件与架构有关联吗? [英] Does a tlb file have an association with architecture?

问题描述

我有一个 32 位 DLL，旨在通过 com 模型和关联的 tlb 文件进行访问.

I have a 32bit DLL that is designed to be accessed through the com model and the associated tlb file.

DLL 似乎是 x86.

The DLL appears to be x86.

有没有办法从 x64 程序访问这种 DLL?tlb 文件是否与 x86/x64 无关?

Is there any way to access this kind of DLL from an x64 program? Are tlb files x86/x64 agnostic?

我问，因为一些功能似乎工作，别人撞车，和人失踪相比.NET程序集.

I am asking because some functions appear to work, others crash, and 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̶ .

--编辑--

由于 OEM 方面的错误而出现缺少的程序集.

Missing assemblies appear due to error on the part of the OEM.

推荐答案

在大多数情况下，类型库当然旨在与平台无关.您在 Microsoft 提供的 Windows 编程中遇到的大多数都是.在 .NET 中最明显，这使得编写可以在 32 位或 64 位模式下运行的代码变得非常简单，由 AnyCPU 平台目标公开.使用 Microsoft.Office.Interop 中的互操作类或编写在 Office 程序中运行的扩展不需要什么特别的，您使用完全相同的类型库.

Type libraries were certainly intended to be platform agnostic in most cases. Most any one you'd encounter in Windows programming that were shipped by Microsoft are. Most visible in .NET which makes it very simple to write code that can run in either 32-bit or 64-bit mode, exposed by the AnyCPU platform target. Nothing special is needed to either use the interop classes in Microsoft.Office.Interop or write extensions that run inside an Office program, you use the exact same type libraries.

但是，当您使用由从未考虑过可以在 64 位代码上运行的程序员创建的类型库时，这并不总是那么有效.最典型的问题是由方法参数引起的，这些参数实际上是引擎盖下的指针，但扁平化为整型，long 是典型的选择.这些指针值在 64 位模式下为 64 位宽，当您尝试将它们塞入 32 位整数时会出现错误行为.HANDLE 值就是一个很好的例子.

But that doesn't always work out so well when you use a type library created by a programmer that never considered it to work on 64-bit code. The most typical trouble is caused by method arguments that are actually pointers under the hood but flattened to a integral type, long being the typical choice. These pointer values are 64-bit wide in 64-bit mode and misbehave when you try to stuff them into a 32-bit integer. HANDLE values are a good example.

到目前为止，最臭名昭著的 oops 是 Microsoft 的.ADO 的类型库已损坏，这是一个广泛用于与 dbase 引擎通信的数据库提供程序库.他们在 Windows 7 SP1 中进行了重大更改，当程序员在该操作系统中构建他们的程序并发现它不再适用于旧版本的 Windows 时，这一更改会导致广泛的痛苦.oops 正好相反，一种在 64 位操作系统上应该是 32 位的类型，但在 64 位操作系统上被声明为 64 位.当您拥有 Windows SDK 版本 8、adoint_Backcompat.h 头文件、ADO_LONGPTR 类型时，您会看到这个 oops.替换为 adoint.h 中的 long.

By far the most notorious oops is a Microsoft one. The type library for ADO was broken, a database provider library that's widely used to talk to dbase engines. They took a breaking change in Windows 7 SP1, a change that cause widespread misery when programmers built their programs in that operating system and found out it no longer worked on older versions of Windows. That oops went the other way, a type that was supposed to be 32-bit on 64-bit operating systems but was declared to be 64-bit on a 64-bit OS. You can see this oops when you have the Windows SDK version 8, adoint_Backcompat.h header file, the ADO_LONGPTR type. Replaced by long in adoint.h.

最好与原始程序员一起解决这个问题.或者为了利用 COM 代理，当从 64 位进程调用时，它们可以在进程外运行 32 位代码.

Best to work with the original programmer to get this sorted out. Or to take advantage of COM surrogates, they can run 32-bit code out-of-process when called from a 64-bit process.

这篇关于tlb 文件与架构有关联吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！