Does the tlb file have an associated architecture?

Question

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

The DLL looks like x86.

Is there a way to access this dll version from an x64 program? Are tlb x86 / x64 files agnostic?

I ask, because some functions seem 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̶s̶e̶s̶e̶s

- Edit -

Missing assemblies appear due to an OEM error.

Answer 1

Type libraries, of course, were designed to agnostic the platform in most cases. Most of the ones you encountered when programming Windows that were shipped by Microsoft. Most notable in .NET, which makes it very easy to write code that can work in either 32-bit or 64-bit mode displayed by the target of the AnyCPU platform. Nothing special is required to use the interop classes in Microsoft.Office.Interop or to write extensions that run inside the Office program; you use the same type libraries.

But this does not always work so well when you use a type library created by a programmer who never believed that it works with 64-bit code. The most typical problem is caused by method arguments, which are actually pointers under the hood but flattened to a holistic type, which is a typical choice. These pointer values ​​are 64-bit wide in 64-bit mode and do not work correctly when trying to write them to a 32-bit integer. HANDLE values ​​are a good example.

Unfortunately, the most notorious issues are Microsoft. The type library for ADO was broken, a database vendor library that was widely used to work with dbase engines. They took a break in Windows 7 SP1, which caused widespread misfortune when programmers created their programs on this operating system and found out that they no longer work on older versions of Windows. It was different, a type that was supposed to be 32-bit on 64-bit operating systems, but was declared 64-bit on a 64-bit OS. You can see this if you have the Windows SDK version 8 header file, adoint_Backcompat.h, type ADO_LONGPTR. Replaced by long in adoint.h.

It is best to work with the original programmer to figure it out. Or, to take advantage of COM surrogates, they can run 32-bit code outside the process when called from a 64-bit process.

Answer 2

The type library contains the x86 vs x64 flag in the SYSKIND enumeration . In fact, it even supports 16 bit Windows. It can be read using the ITypeLib :: GetLibAttr method , something like this:

int _tmain(int argc, _TCHAR* argv[]) { CoInitialize(NULL); CComPtr<ITypeLib> tlb; LoadTypeLib(L"C:\\myPath\\MyFile.tlb", &tlb); TLIBATTR *patt; tlb->GetLibAttr(&patt); switch(patt->syskind) { case SYSKIND::SYS_WIN64: printf("WIN64"); break; case SYSKIND::SYS_WIN32: printf("WIN32"); break; case SYSKIND::SYS_WIN16: printf("WIN16"); break; } tlb->ReleaseTLibAttr(patt); CoUninitialize(); } 

Note. SYSKIND is not a flag, it is an enumeration, you do not have something like the value "any CPU".

Answer 3

A lot of time has passed, but I think the correct answer "depends on it." Some things can be handled transparently, some will not. I guess most of the time there will be some specific bitform, but someone more knowledgeable about this can fix me.

Try this article on porting midl (the language used to generate the com type lib) to 64-bit. http://msdn.microsoft.com/en-us/library/ms810720.aspx

But actually your problem is not tlb. These are just beam type descriptors. The problem is the implementation of these types in the dll. You cannot load a 32-bit DLL into a 64-bit process. Can I load a 32-bit DLL into a 64-bit process on Windows?

A possible solution if you do not transfer the DLL, including a surrogate 32-bit process and interprocess communication http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/