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

Question

У меня есть приложение, которое мы пытаемся перевести на 64-битную версию с 64-битной. Это .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?

Answer 1

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

Здесь есть довольно хорошая статья:

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

Answer 2

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

Answer 3

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

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