Может ли приложение Windows, скомпилированное с использованием набора символов Unicode, использовать DLL, скомпилированную как многобайтовую?

Question

Я подозреваю, что ответ «нет», так как, когда я собираюсь включить заголовок, будут определены макросы «T» для использования (wchar_t *), но DLL ожидает (char *).Однако мне было интересно, выполняла ли Windows какое-либо оперативное транскодирование между модулями, которое могло бы заставить это волшебным образом работать (предполагая простые символы ASCII).

Answer 1

Нет, Windows не будет выполнять магическое преобразование на лету.Вам придется сделать это самостоятельно.

Вот как я бы, вероятно, сделал это:

Создайте DLL-оболочку, скомпилированную как многобайтовую (чтобы гарантировать, что заголовки упакованной DLL-библиотекиправильно истолковано).Однако в коде самой оболочки, а также ее заголовка я бы не использовал ни один из макросов ANSI / UNICODE, например _T, вместо этого я бы явно использовал char и 'wchar_t' по мере необходимости.

Для каждой функции обернутой DLL, которая вам нужна, если она имеет какой-либо ввод или вывод символов (непосредственно или в структурах), напишите функцию-обертку, которая преобразует входные строки (типа 'wchar_t *') в 'char *'строки через 'WideCharToMultiByte' перед вызовом функции с переносом.Аналогично, преобразуйте выходные параметры обратно в Unicode, используя 'MultiByteToWideChar'.

Answer 2

Что делает для этого окно, так это то, что все функции Windows API определяются дважды: например, SetWindowText существует как SetWindowTextA, а SetWindowTextW - SetWindowText на самом деле является макросом, который изменяется в зависимости от того, определен UNICODE или нет.

Итак, если вы имеете дело с DLL, которая была скомпилирована с учетом этого использования - тогда Dll будет экспортировать ANSI И Unicode API - и заголовочные файлы будут переключаться между ними.

Если DLL была скомпилирована - как ваше приложение - внутренне с помощью TCHAR, то на самом деле есть две возможные сборки DLL - сборка ANSI и сборка Unicode - потенциально без реального способа их различения - в какой момент вызывается DLL с неправильным видом строки просто сделает его неудачным.

Answer 3

Вы сможете загрузить его, но в случае специальных символов коды символов не будут хорошо интерпретироваться. Вы можете попробовать создать «DLL-оболочку», которая загружает многобайтовую DLL и отображает все вызовы функций. Она будет передавать все вызовы с одной стороны на другую, но она будет «перекодировать» строки в вызовах функций и возвращаемые переменные:)

Answer 4

Вы можете делать это до тех пор, пока у вашей dll нет других конфликтующих зависимостей dll. Вам нужно убедиться, что вы определили функции в своем коде DLL, используя "..." вместо _T("...") и CStringA вместо CString.

Answer 5

Символы, экспортированные из одного, будут даже отличаться от символов, импортированных другим - по крайней мере, при использовании C ++.Таким образом, клиент dll даже не сможет загрузить, так как он не может найти ожидаемые символы в dll сервера.

- EDIT -

В случае, если вы используете C-введите символы экспорта, которые не содержат информацию о типе, вы сможете загрузить DLL.Однако, когда ему присваивается строка wchar_t L"abc", строка из двух байтов на символ будет кодироваться как { 65 00 66 00 67 00 00 00 }, поэтому целевая библиотека DLL будет интерпретировать строку с нулем в конце как "a".