2013-05-21 4 views
4

У меня есть 32-битная DLL, которая предназначена для доступа через модель com и связанный с ней файл tlb.Имеет ли файл tlb связанную архитектуру?

DLL похоже, является x86.

Есть ли способ получить доступ к этому виду DLL из программы x64? Являются ли tlb-файлы x86/x64 агностиками?

Я спрашиваю потому, что некоторые функции, по всей видимости, работать, другие аварии, а другие Потерялись по сравнению с сборки .NET.

--Edit--

Отсутствующие узлы появляются из-за ошибки со стороны ОЕМ.

ответ

4

Библиотеки типов, конечно же, были предназначены для агностики платформы в большинстве случаев. Большинство из тех, с которыми вы столкнулись при программировании Windows, которые были отправлены Microsoft. Наиболее заметен в .NET, который позволяет очень просто писать код, который может работать либо в 32-битном, либо в 64-битном режиме, отображаемом целевым объектом платформы AnyCPU. Ничего особенного не требуется, чтобы использовать классы interop в Microsoft.Office.Interop или писать расширения, которые запускаются внутри программы Office, вы используете те же библиотеки типов.

Но это не всегда так хорошо работает, когда вы используете библиотеку типов, созданную программистом, которая никогда не считала ее работой с 64-битным кодом. Наиболее типичная проблема вызвана аргументами метода, которые на самом деле являются указателями под капотом, но сплюснутыми до целостного типа, long является типичным выбором. Эти значения указателя имеют 64-разрядную ширину в 64-битном режиме и неверно работают при попытке записать их в 32-разрядное целое. Хорошим примером являются значения HANDLE.

К сожалению, наиболее печально, но это Microsoft. Библиотека типов для ADO была нарушена, библиотека поставщиков баз данных, которая широко используется для работы с dbase-двигателями. В Windows 7 с пакетом обновления 1 (SP1) произошли серьезные изменения, что вызвало всеобщее несчастье, когда программисты создали свои программы в этой операционной системе и выяснили, что больше не работают в старых версиях Windows.Это было иначе, тип, который должен был быть 32-разрядным в 64-битных операционных системах, но был объявлен 64-разрядным в 64-разрядной ОС. Вы можете увидеть это, если у вас есть файл заголовка Windows SDK версии 8, adoint_Backcompat.h, тип ADO_LONGPTR. Заменено long in adoint.h.

Лучше всего работать с оригинальным программистом, чтобы получить эту информацию. Или, чтобы воспользоваться суррогатами COM, они могут запускать 32-разрядный код вне процесса при вызове из 64-битного процесса.

1

Это было долгое время, но я думаю, что правильный ответ «это зависит». Некоторые вещи могут обрабатываться прозрачно, некоторые не будут. Я предполагаю, что большую часть времени там будет какая-то конкретная битва в платформе, но кто-то, кто более хорошо разбирается в этом, может исправить меня.

Пробуйте эту статью о переносе midl (языка, используемого для создания com-типа libs) до 64 бит. http://msdn.microsoft.com/en-us/library/ms810720.aspx

Но на самом деле ваша проблема не в tlb. Это просто дескрипторы типа пучка. Проблема заключается в реализации этих типов в dll. Вы не можете загрузить 32-разрядную DLL в 64-битный процесс. Can I load a 32 bit DLL into a 64 bit process on Windows?

Возможным решение, если вы не можете порт в DLL, вовлекая суррогатный процесс 32bit и межпроцессорное взаимодействие http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

+0

Является ли COM каким-то методом связи между процессами, которые их изолируют? – Mikhail

+0

COM сам нет. COM может быть в proc или из proc. DCOM - это недостаток вкуса. D предназначен для распределенного, либо отдельного процесса или машины, и запросов прокси через rpc. Таким образом, вы можете иметь 32-процессорный процесс, с которым вы можете подключиться через dcom. Dom является одним из вариантов реализации pic. Вероятно, хороший вариант в вашем случае. В этот момент вы решили проблему процесса и можете вернуться к проблеме типа lib. – dkackman

+0

Это одно предложение должно быть «dcom - один из вариантов реализации ipc». Проклятый автокоррект и слишком много аббревиатур – dkackman

2

Тип библиотеку делает содержит x86 против 64 флага в SYSKIND enumeration. На самом деле он даже поддерживает 16 бит Windows. Это может быть считан с помощью ITypeLib::GetLibAttr method, что-то вроде этого:

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(); 
} 

Примечание SYSKIND не является флаги, это перечисление, вы не имеете что-то подобное значение «любой ЦП».