Does a tlb file have an association with architecture?

Question

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.

Answer 1

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.

Answer 2

Type Library do contain a x86 vs x64 flag in the SYSKIND enumeration. In fact it even supports 16 bits 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 flags, it's an enum, you don't have something like "any CPU" value.

Answer 3

It has been a long time but I think the correct answer is 'it depends'. Some things may be handled transparently some will not. My guess is that most of the time there will be some platform specific bitness in there, but somebody more knowledgeable on that may correct me.

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

But really your problem isn't the tlb. That's just a bunch type descriptors. The issue is going to be the implementation of those types in the dll. You cant load a 32bit dll into a 64bit process. Can I load a 32 bit DLL into a 64 bit process on Windows?

A possible solution, if you cant port the dll, involving a surrogate 32bit process and inter process communication http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/