tlb文件是否与体系结构关联? [英] Does a tlb file have an association with architecture?
问题描述
我有一个32位DLL，旨在通过com模型和相关的tlb文件进行访问.
该DLL似乎是x86.
是否可以通过x64程序访问这种DLL? tlb文件x86/x64是否不可知?
我之所以问是因为某些功能似乎可以正常工作，而其他某些功能却崩溃了，并且o crashtcrashh̶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̶p
-编辑-
由于OEM方面的错误而出现缺少的程序集.
在大多数情况下，类型库无疑是与平台无关的. Microsoft发行的Windows编程中遇到的大多数人都是.在.NET中最明显的是，这使得编写可以在AnyCPU平台目标公开的32位或64位模式下运行的代码变得非常简单.使用Microsoft.Office.Interop中的interop类或编写在Office程序中运行的扩展不需要任何特殊的操作，而您使用的是完全相同的类型库.
但是，当您使用由程序员创建的类型库(从来没有认为它可以在64位代码上运行)时，效果并不总是那么好.最典型的麻烦是由方法参数引起的，该方法参数实际上是底层的指针，但被展平为整数类型， long 是典型的选择.这些指针值在64位模式下为64位宽，当您尝试将它们填充到32位整数中时表现不正常. HANDLE值是一个很好的例子.
到目前为止，最臭名昭著的哎呀是微软的. ADO的类型库已损坏，这是一种数据库提供程序库，已广泛用于与dbase引擎进行通讯.他们在Windows 7 SP1中进行了重大更改，这一更改在程序员在该操作系统中构建程序并发现它不再适用于旧版Windows时，引起了广泛的痛苦.糟糕的是，这种类型在64位操作系统上应该是32位，但在64位OS上被声明为64位.当您拥有Windows SDK版本8，adoint_Backcompat.h头文件(ADO_LONGPTR类型)时，可以看到此消息.在adoint.h中由 long 代替.
最好与原始程序员合作，以解决此问题.或者利用COM代理，当从64位进程调用时，它们可以在进程外运行32位代码.
I have a 32bit DLL that is designed to be accessed through the com model and the associated tlb file.
The DLL appears to be x86.
Is there any way to access this kind of DLL from an x64 program? Are tlb files x86/x64 agnostic?
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̶ .
--Edit--
Missing assemblies appear due to error on the part of the OEM.
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.
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.
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.
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屋！
