Вызов 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?
Ответы 3
Вам нужно будет загрузить 32-битную dll в отдельный 32-битный процесс, а ваш 64-битный процесс будет взаимодействовать с ним через межпроцессное взаимодействие. Я не думаю, что есть способ загрузить 32-битную dll в 64-битный процесс в противном случае.
Здесь есть неплохая статья:
Доступ к 32-битным DLL из 64-битного кода
Это 64-битная -> COM -> 32-битная вещь, которую я описывал. Прочитав эту статью и попытавшись заставить образец работать, я решил, что есть будет лучшим способом. По крайней мере, я на это надеюсь.
Ответ Джона правильный. Невозможно смешать 32-битные и 64-битные модули в одном процессе. Вам нужно начать второй процесс. См. Также мой ответ здесь: stackoverflow.com/questions/6523075/…
Вам не обязательно использовать оболочки COM +, но вам нужно использовать 32-разрядный процесс.
Это правильно. См. Страницу Microsoft: msdn.microsoft.com/en-us/library/windows/desktop/…
Суррогатные процессы Windows кажутся хорошим потенциальным подходом: stackoverflow.com/a/359389/3195477
Вам нужно написать свои исполняемые процессы как 32-битные процессы (в отличие от Any CPU или x64), чтобы они были загружены WoW32 для Vista. Это загрузит их в 32-битном режиме эмуляции, и у вас не будет проблем с точкой входа. Вы можете оставить свои библиотеки в режиме AnyCPU, но ваши исполняемые файлы должны быть скомпилированы как x86.
Похоже, они обдумывали это, но им нужен увеличенный потолок памяти, который предлагает 64-битная версия.
Одна половина верна: 32-битные процессы запускаются на машине x64, если вы скомпилируете их как x86. Но если ваш исполняемый файл - x86, а ваши библиотеки - AnyCPU - своевременный компилятор сделает из них код x64, что делает их несовместимыми с (32-битным) исполняемым файлом. Итак, все, включая сборки должен быть x86 или AnyCPU.
Ответ Джона верен, если вы не хотите перекомпилировать существующие библиотеки DLL; однако это может быть вариантом и для вас.
В настоящее время наша команда переводит наш код FORTRAN с x86 на x64, чтобы увеличить потолок памяти.
это работает до тех пор, пока у вас нет 32-битных сторонних сборок (без исходного кода), которые нужно добавить в качестве ссылки ...
Возможный дубликат Доступ к x86 COM из x64 .NET