Имеет ли файл tlb связанную архитектуру?
У меня есть 32-битная DLL, которая предназначена для доступа через модель com и связанный файл tlb.
DLL выглядит как x86.
Есть ли способ получить доступ к такого рода DLL из программы x64? Являются ли файлы tlb x86 / x64 независимыми?
Я спрашиваю, потому что некоторые функции кажутся работающими, другие аварийно завершают работу, и другие проблемы
—Редактировать—
Отсутствующие сборки появляются из-за ошибки со стороны OEM.
Решение
Библиотеки типов, безусловно, должны были быть независимыми от платформы в большинстве случаев. Большинство из тех, с которыми вы сталкивались при программировании Windows, поставлялись Microsoft. Наиболее заметно в .NET, что делает очень простым написание кода, который может работать как в 32-битном, так и в 64-битном режиме, предоставляемый целевой платформой AnyCPU. Ничего особенного не требуется, чтобы использовать классы взаимодействия в Microsoft.Office.Interop или писать расширения, которые запускаются внутри программы Office, вы используете точно такие же библиотеки типов.
Но это не всегда работает так хорошо, когда вы используете библиотеку типов, созданную программистом, который никогда не считал ее работающей с 64-битным кодом. Наиболее типичная проблема вызвана аргументами метода, которые на самом деле являются указателями под капотом, но сведены к целочисленному типу, долго быть типичным выбором. Эти значения указателя имеют 64-разрядную ширину в 64-разрядном режиме и ведут себя неправильно, когда вы пытаетесь вставить их в 32-разрядное целое число. Значения HANDLE являются хорошим примером.
Безусловно, самый печально известный ой — Microsoft. Библиотека типов для ADO была повреждена, библиотека провайдера базы данных, которая широко используется для общения с движками dbase. В Windows 7 с пакетом обновления 1 (SP1) произошли серьезные изменения, которые привели к серьезным страданиям, когда программисты встраивали свои программы в эту операционную систему и обнаружили, что она больше не работает на старых версиях Windows. Этот упс пошел другим путем, тип, который должен был быть 32-разрядным в 64-разрядных операционных системах, но был объявлен 64-разрядным в 64-разрядной ОС. Это можно увидеть, когда у вас есть Windows SDK версии 8, заголовочный файл adoint_Backcompat.h, тип ADO_LONGPTR. Заменен на долго в adoint.h.
Лучше всего работать с оригинальным программистом, чтобы разобраться с этим. Или, чтобы воспользоваться преимуществами суррогатов COM, они могут запускать 32-битный код вне процесса при вызове из 64-битного процесса.
Другие решения
Библиотека типов содержит флаг x86 против x64 в Перечень SYSKIND. На самом деле он даже поддерживает 16-битную Windows. Это можно прочитать с помощью ITypeLib :: GetLibAttr метод, что-то вроде этого:
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 — это не флаги, это перечисление, у вас нет значения типа «любой процессор».
Прошло много времени, но я думаю, что правильный ответ — «это зависит». Некоторые вещи могут быть обработаны прозрачно, некоторые — нет. Я предполагаю, что большую часть времени там будет некоторая специфичность для платформы, но кто-то, кто более осведомлен об этом, может исправить меня.
Попробуйте эту статью о переносе midl (язык, используемый для создания библиотек типа com) на 64bit. http://msdn.microsoft.com/en-us/library/ms810720.aspx
Но на самом деле ваша проблема не в этом. Это просто дескрипторы типа связки. Вопрос будет в реализации этих типов в DLL. Вы не можете загрузить 32-битную DLL в 64-битный процесс.
Могу ли я загрузить 32-битную DLL в 64-битный процесс в Windows?
Возможное решение, если вы не можете портировать dll, включая суррогатный 32-битный процесс и межпроцессное взаимодействие
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
detector