Как использовать двоичный файл WM2003 (dll) на устройстве Windows Mobile 6.1 (WM6.1)? (PE-загрузчик не может принимать старые двоичные файлы) - PullRequest
1 голос
/ 06 февраля 2010

Привет!

У меня есть старый плагин (как двоичный файл, DLL), используемый моим приложением. Он был построен для WM2003 . И теперь он вылетает из приложения, если загружен на Windows Mobile 6.1 ( WM5 работает нормально, WM6 тоже).

Исходный код недоступен и больше не поддерживается разработчиком. Поэтому я не могу перестроить его для WM6.1 .

Можно ли пропатчить или преобразовать двоичный файл, чтобы он мог работать на WM6.1 ? Если так, как я могу это сделать?

Спасибо.


Редактировать: Я обнаружил, что проблема заключается в загрузчике PE , который не работает на WM6.1 (по сравнению с WM6 и более ранними версиями).

Ответы [ 2 ]

2 голосов
/ 06 февраля 2010

Использует ли этот плагин MFC или ATL? В более ранних версиях WinMo использовалась другая версия ATL / MFC, поэтому приложения MFC или ATL, написанные в Studio, не будут работать, если вы не развернете более новые библиотеки ATL / MFC вместе с приложением, как старые приложения не будут работать на новых устройствах если вы не развернете старые библиотеки MFC / ATL.

0 голосов
/ 08 февраля 2010

Эта проблема встречается редко, но некоторую информацию можно найти.

Распространенным решением является перестройка двоичного файла в VS2008 ( Новые сборки TCPMP VS2008 для WM6.1 ), но это не поможет, если у вас нет исходного кода.

Я нашел объяснение проблемы и другое решение в списке рассылки cegcc ( arm-wince-cegcc в Windows Mobile 6.1 ). В Windows Mobile 6.1 Memory Management схема была изменена.

Это расположение слотов оставалось довольно постоянным от Windows Mobile 2003 до Windows Mobile 6.0 . Однако с выпуском Windows Mobile 6.1 все изменилось, чтобы уменьшить давление DLL и выручить в диспетчере устройств пространство процесса.

В Windows Mobile 6.1 стеки для диспетчера устройств больше не выделяются в слоте процессов. Вместо этого операционная система использует слот 59 в верхней части Большой области памяти для стеков потоков диспетчера устройств. ...

И обходной путь для этой проблемы - объявить DLL в реестре (чтобы ОС не загружала ее в большой объем памяти).

Мне не нравится этот обходной путь, поэтому я пытаюсь найти бинарный патчер. И нашел его:)

Это на самом деле не патчер, это UPX - Ультимативный Упаковщик для eXecutables . Но это решает проблему отлично. DLL, упакованная с UPX , не приводит к сбою приложения и работает нормально.

...