Вызов 32-битного кода из 64-битного процесса

У меня есть приложение, которое мы пытаемся перейти на 64-битную версию с 32-битной. Это .NET, скомпилированный с использованием флагов x64. Однако у нас есть большое количество DLL, написанных на FORTRAN 90, скомпилированных для 32-битной версии. Функции в библиотеках DLL FORTRAN довольно просты: вы вводите данные, вы извлекаете данные; никакого состояния любого рода. Мы также не проводим там много времени, в общей сложности может быть 3%, но логика вычислений, которую он выполняет, неоценима.

Могу ли я как-то вызвать 32-битные библиотеки DLL из 64-битного кода? MSDN предполагает, что я не могу, и точка. Я проделал простой взлом и проверил это. Все выдает исключение недопустимой точки входа. Единственное возможное решение, которое я нашел до сих пор, - это создать оболочки COM + для всех 32-битных функций DLL и вызвать COM из 64-битного процесса. Это похоже на головную боль. Мы также можем запустить процесс в эмуляции WoW, но тогда потолок памяти не увеличится и составит около 1,6 ГБ.

Есть ли другой способ вызвать 32-битные библиотеки DLL из 64-битного процесса CLR?


person David J. Sokol    schedule 24.09.2008    source источник
comment
Возможный дубликат Доступ к x86 COM из x64 .NET   -  person StayOnTarget    schedule 25.05.2018


Ответы (3)


Вам нужно будет загрузить 32-битную dll в отдельный 32-битный процесс, а ваш 64-битный процесс будет взаимодействовать с ней через межпроцессное взаимодействие. Я не думаю, что есть способ загрузить 32-битную dll в 64-битный процесс в противном случае.

Здесь есть неплохая статья:

Доступ к 32-битным библиотекам DLL из 64-битный код

person John Sibly    schedule 24.09.2008
comment
Это 64-битная - ›COM -› 32-битная вещь, которую я описывал. Прочитав эту статью и попытавшись заставить образец работать, я решил, что есть есть способ получше. По крайней мере, я на это надеюсь. - person David J. Sokol; 24.09.2008
comment
Ответ Джона правильный. Невозможно смешать 32-битные и 64-битные модули в одном процессе. Вам нужно начать второй процесс. См. Также мой ответ здесь: stackoverflow.com/questions/6523075/ - person Helge Klein; 11.07.2011
comment
Вам не обязательно использовать оболочки COM +, но вам нужно использовать 32-разрядный процесс. - person Rob Hunter; 06.01.2012
comment
Это верно. См. Страницу Microsoft: msdn.microsoft .com / ru-ru / library / windows / desktop / - person John B. Lambe; 09.02.2016
comment
Суррогатные процессы Windows кажутся хорошим потенциальным подходом: stackoverflow.com/a/359389/3195477 - person StayOnTarget; 25.05.2018

Вам нужно написать свои исполняемые процессы как 32-битные процессы (в отличие от любого процессора или x64), чтобы они были загружены WoW32 для Vista. Это загрузит их в 32-битном режиме эмуляции, и у вас не будет проблем с точкой входа. Вы можете оставить свои библиотеки в режиме AnyCPU, но ваши исполняемые файлы должны быть скомпилированы как x86.

person Orion Adrian    schedule 24.09.2008
comment
Похоже, они обдумывали это, но им нужен увеличенный потолок памяти, который предлагает 64-битная версия. - person John Sibly; 25.09.2008
comment
Одна половина верна: 32-битные процессы запускаются на машине x64, если вы скомпилируете их как x86. Но если ваш исполняемый файл - x86, а ваши библиотеки - AnyCPU - своевременный компилятор сделает из них код x64, что делает их несовместимыми с (32-битным) исполняемым файлом. Итак, все, включая сборки, должно быть x86 или AnyCPU. - person Matt; 12.10.2012

Ответ Джона верен, если вы не хотите перекомпилировать существующие библиотеки DLL; однако это может быть вариантом и для вас.

В настоящее время наша команда переводит наш код FORTRAN с x86 на x64, чтобы увеличить потолок памяти.

person Rob Hunter    schedule 06.01.2012
comment
это работает до тех пор, пока у вас нет 32-битных сторонних сборок (без исходного кода), которые нужно добавить в качестве ссылки ... - person Matt; 12.10.2012