Поддержка Unicode в VB

[vip.fedor]

Имеется программа в VB6, в контролах и коде, которой используется русский текст (ANSI, как я понимаю). Например: Сообщения об ошибках.
В региональных настройках Windows имеется настройка: "Выберите язык, соответствующий языку используемых программ, которые не поддерживают Юникод выберите используемый язык". Так вот, если винда не на русском, и расположение не СНГ, то там, как правило стоит что угодно кроме русского.

В таком случае, все сообщения отображаются "кракозябрами". Visual Basic тоже на такой винде в режиме отладке будет отображать не то что нужно.
Вопрос: как сделать корректное отображение русских шрифтов в программе на VB, без смены параметра Non-Unicode языка в региональных настройках? Программа уже написана, и переписывать используя другие контролы или еще что-то это крайний вариант, так как кода много.

Буду признателен за любой толковый комментарий по данному вопросу.

[VBTerminator]

Это не VB-программы не поддерживают юникод, а среда разработки. Выход - смириться.

[Хакер]

vip.fedor, подожди моего ответа, появится время, и я отвечу большим постом.

[Qwertiy]

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

PS: Лучше подожди ответ Хакера.

[vip.fedor]

Спасибо, проблема актуальна, буду ждать ответа.
Вот тут: http://support.microsoft.com/kb/236404 упоминается о каком-то IPDK для развертывания многоязычных программ.
Но русский, не поддерживается =(.

[Хакер]

В общем.
VB сам по себе как языке поддерживает юникод. Юникод выбран для использовани для сохранения строк в COM. VB (и VBA) делался максимально COM-ориентированным.

Поэтому все строковые переменные VB — юникодные. И все входящие и исходящие вызовы между компонентами (написанными неизвестно кем и неизвестно на каком языке) тоже сохраняют юникод.

Однако, как только дело доходит до взаимодействия VB и системы, то тут всё не вовсе не сладко. Очевидно, что VB приложение само по себе с системой не взаимодействует (мы не говорим о вызове API через Declare Function или через TLB, потому что это уже выходит за рамки понятия «само по себе»). Оно взаимодействует с рантаймом, который теоретически может быть написан под разные операционные системы и разные даже аппартные платформы, и вообще работать по разному (в зависимости от используемой версии рантайма), но на практике существует только версия рантайма для Windows (хотя я что-то слышал краем уха про Mac).

Рантайм содержит помимо всякой хитроумной объектной модели для поддержки работающего проекта, ещё и реализацию всех «встроенный» функций языка, и реализацию всех контролов. Так вот, из соображений совместимости со старыми ОСями (вроде Windows 95) с одной стороны, и со старыми версиями VB (вроде VB4) с другой стороны, реализация встроенных функций и встроенных контролов устроена так, что используется неюникодный API-интерфейс ОС (просто за неимением другого, скажем, в Win95). Хотя конечно есть unicows, позволяющий получить юникод даже под Windows 95, правда в чуть ограниченном объёме, но эта фишка появилась только в 2001 году, а VB6 как известно был выпущен в 98 году. Появись MSLU до 98 года, был бы шанс, что рантайм VB6 был бы юникодным от начала до конца. Но...

К тому же ещё и при использовании записи/чтения в/из файлов VB6 конвертирует юникодный текст в неюникодный используя текущую неюникодную локаль. Оно и понятно, ибо американцы бы неистово возмущались, записывая в файлы «Hello, World!», а потом наблюдая в блокноте H?e?l?l?o?,? ?W?o?r?l?d?!?».

Теперь о том, как это решить.
Как это обычно бывает в моём случае, я вижу невероятно большое множество вариантов (на самом деле есть не так уж много базовых вариантов, но уж очень много их взаимных комбинаций).

Самый крутой и понтовый вариант — это модифицировать msvbvm60 таким хитрым образом, чтобы она стала полноценно юникодной. Сам этот способ предполагает кучу вариантов того, как это можно сделать. Начиная от вариантов «малой кровью» при помощи модификации некоторых мест по-живому, заканчивая крутейшим вариантом разреверсинженирить весь рантайм в исходный код, а затем заново собрать из этого исходника, но так, чтобы рантайм получился насквозь юникодным. Хотя этот способ юридически не чист. Нельзя модифицировать и реверсить рантайм, если верить лиц. соглашению (хотя конкретно про рантайм я таких положений лично не видел , а просто предполагаю, что они есть).

Самый чистый вариант — это найти сторонние контролы-заменители для всех стандартных контролов. Причём 100 % совместимые по интерфейсам (с точки зрения утиного подхода, а не COM-подхода, конечно же, (!! хотя, можно ведь и по COM-интерфейсу найти что-то совместимое). Что-то люди собирали вот здесь, но я ничего не скачивал и не смотрел. Смысл обладания контролами-заменителями, совместимыми по интерфейсу, состоит в том, что всё проблема решается просто удалением со своим форм стандартных контролов и рисованием в нужных местах контролов-заменителей. Код при этом переписывать не нужно вообще. В случае большого проекта с большим количеством форм и сложным набором контролов на каждом, удаление и перерисовку контролов можно автоматизировать, решив вопрос просто текстовой заменой контента .frm-файлов.

Аналогично придётся заменить все функции, имеющие связь в внешним миром (например MsgBox). Это достатоно легко сделать технически, потому что достаточно просто объявить в своём модуле функцию с именем MsgBox и она уже заменяет функцию MsgBox из рантайма, так что свой же код править не придётся, ну а чтобы теперь вызвать функцию из рантайма надо MsgBox заменить на VBA.MsgBox.

Разумеется, релизовать свои варианты стандартных функций, например свой вариант MsgBox не составляет никакого труда — достаточно просто обернуть вызов системной API-функции MessageBoxW. Никаких проблем с выводом юникода не будет вообще. См. пруф-пример.

Третий вариант решения проблемы состоит в написании невидимого ассистанс-агента, который сам перехватывает обращения ко всему, к чему надо, делает необходимые подмены. Своего рода первый вариант, но правится не DLL, а всё фиксится непосредственно во время работы.

Отдельная проблема состоит ещё и в том, что среда разработки тоже не поддерживает юникод. Это означает, про проблематично записать в коде юникодную строковую константу (опять же смотри пруф-пример, как там это сделано) и проблематично дать строковым свойствам юникодных контролов (предположим, что мы каким-то из способов всё-таки добились их юникодности) юникодные знания. Потому что все свойства контролов записываются в frm-файл и они записываются туда не в юникоде.

Но и это тоже разрешимые проблемы.
Проблема с помещением строковых констант в код решается просто. Вообще говоря, даже при отсутствии этой проблемы: плохо помещать строковые коснтанты прямо в код, хорошо помещать строковые константы в string table в ресурсы. И здесь ресурсы приходят к нам на помощь. Ресурсы (сами по себе) поддерживают содержание юникодного текста. Они, к слову, ещё поддерживают содержание даже неюникодного текста с кучей версий текста для разных локалей. Но нам достаточно возможности хранить строковые константы в ресурсах и получать их оттуда при необходимости. Больше никакого человека-понятного текста (кроме комментариев, разумеется), весь человеко-понятный выводимый наружу текст — только в ресурсах. Решено.

Проблема с помещением юникодного текста в качестве значений строковых свойств контролов решается тем, что для контролов предусмотрена возможность сохранения бинарных данных в бинарном же виде. То есть скажем если вы присвоите свойству Picture картинку, то картинка не полезет в .frm-файл в виде текста (или в виду пути к файлу-картинке), она полезет в бинарный .frx-файл в бинарном же виде. Туда же попадают настройки Band-ов для CoolBar(Rebar)-контрола и тому подобные вещи. Поэтому здесь проблема с сохранением юникода решается просто тем, что надо заставить контролы хранить значения строковых свойств не в .frm, а в .frx. Ну и устанавливать их придётся, по всей видимости, не через Property Window, а через кастомный PropertyPage-диалог.

Так что по настоящему неразрешимой проблемы тут нет. Проблема решаема даже абсолютно без применения блэк-кодинга и всяким сомнительных (для кого-то) приёмов. То есть даже стопроцентно чистыми методами всё решается. А уж с применением трюков — тем более.

[ger_kar]

Хакер, твой пост статья как всегда оказалась очень информативной интересной и полезной. Спасибо.
У меня хоть и нет такой проблемы в текущий момент времени, но думаю рано или поздно с этим тоже придется столкнуться, а пока как говориться буду мотать на ус .

Самый чистый вариант — это найти сторонние контролы-заменители для всех стандартных контролов. Причём 100 % совместимые по интерфейсам (с точки зрения утиного подхода, а не COM-подхода, конечно же

А что за такой утиный подход? Можешь хоть немного разъяснить?

Вообще говоря, даже при отсутствии этой проблемы: плохо помещать строковые коснтанты прямо в код, хорошо помещать строковые константы в string table в ресурсы.

Вот с этим есть одна закавыка. Строки в ресурсах с одной стороны это конечно хорошо, можно быстро локализовать приложение если потребуется, но с другой стороны, если потенциально приложение не требует и никогда не потребует локализации и если не решать проблему описанную в этой теме, то стоит ли вообще использовать строковые ресурсы? Дело в том, что когда строка находится прямо в коде, то сразу видно "что это такое", в случае если она будет в ресурсах, да еще если этих строк там очень много, то вместо того, что-бы сразу видеть, с чем имеешь дело, придется иметь дело с идентификатором, что уже не так очевидно. Т.е. читабельность и понятность кода явно уменьшается. Можно конечно использовать под идентификаторы числовые константы с соответствующим строке названием, но для русскоязычных строк это не очень удобно, поэтому константы не выход. Так стоит ли в таких случаях (если локализация не нужна) использовать вместо строковых констант ресурсы в ущерб понятности кода?

Поэтому здесь проблема с сохранением юникода решается просто тем, что надо заставить контролы хранить значения строковых свойств не в .frm, а в .frx. Ну и устанавливать их придётся, по всей видимости, не через Property Window, а через кастомный PropertyPage-диалог.

А можно чуточку поподробнее про этот метод. То, что нужно заставить все вполне понятно, но непонятно как. Т.е. можно конечно создать ситуацию при которой наряду с .frm файлом у формы появится и .frx файл, который сделает сама среда, а дальше то что?

Так что по настоящему неразрешимой проблемы тут нет. Проблема решаема даже абсолютно без применения блэк-кодинга и всяким сомнительных (для кого-то) приёмов. То есть даже стопроцентно чистыми методами всё решается. А уж с применением трюков — тем более.

А можно хоть один трюк для примера? Может с трюками даже проще будет. Кстати вариант с перехватом это же чистейший трюк или все таки нет?

[Хакер]

А что за такой утиный подход? Можешь хоть немного разъяснить?

Это вопрос общей эрудиции.
Утиный тест
Утиная типизация

придется иметь дело с идентификатором, что уже не так очевидно

Если не очевидно, значит надо уволить и прогнать поганой метлой того, кто придумывал имена идентификаторам, и нанять того, кто делает этого хорошо.

То, что нужно заставить все вполне понятно, но непонятно как.

А я откуда знаю? Если бы мне понадобилось, я бы разузнал за пару минут. Какие нибудь особенности обращения с PropertyBag-ом. Вот глянул сейчас PropertyBag-овские свойства, там нет никаких способов выбрать, что и как. Значит просто достаточно сохранять не-текстовые данные, чтобы они сохранились в frx-файле, а не frm.

А можно хоть один трюк для примера? Может с трюками даже проще будет.

Примеры были.

[ger_kar]

Это вопрос общей эрудиции.

Да... Общую эрудицию нужно тоже повышать

Если не очевидно, значит надо уволить и прогнать поганой метлой того, кто придумывал имена идентификаторам

А как быть тогда в случае себя самого, заняться самобичеванием?

Примеры были.

Имелся ввиду этот вариант?

Третий вариант решения проблемы состоит в написании невидимого ассистанс-агента, который сам перехватывает обращения ко всему, к чему надо, делает необходимые подмены. Своего рода первый вариант, но правится не DLL, а всё фиксится непосредственно во время работы.

[Хакер]

А как быть тогда в случае себя самого, заняться самобичеванием?

Заняться работой над собой.

Имелся ввиду этот вариант?

Все варианты. И подправить «пару байтиков» в msvbvm60.dll, и реверс-ребилд, и патчинг в процессе работы, и перехват WideCharToMultiByte/MultiByteToWideChar, и перехват создания контролов, и пост-процессинг обращений к свойствам с некоторой ручной работой.

[vip.fedor]

Хакер, прежде всего, благодарю, что нашли время ответить и углубись в обсуждаемую тут тему. Как и всех других участников форума.

Самый крутой и понтовый вариант — это модифицировать msvbvm60 таким хитрым образом, чтобы она стала полноценно юникодной.

Разумеется сама теория тут может и интересная, но для решения данной конкретной задачи - абсолютно не конструктивная (все равно, что предложить написать VB заново). Как я вычитал по указанной ссылке, ваше предложение так и осталось теорией (я бы даже сказал фантазией).

Самый чистый вариант — это найти сторонние контролы-заменители для всех стандартных контролов.

Проект большой, контролов много разных. Найти freeware замену юникодными, да еще и совместимые по интерфейсу - задача не тривиальная, а если и разрешимая, то потребует не позволительно много затрат времени.

Аналогично придётся заменить все функции, имеющие связь в внешним миром (например MsgBox). Это достатоно легко сделать технически

Увы, сделать это не так легко, как Вам кажется. Даже Ваш пруф-пример не отработал на 100% и провалился на результате вызова функции Utf8DirtyToUcs2 в моем варианте локале. (см. отчет ниже).

Есть еще интересные задвиги с отображением путей на таких комби-локалях, где Non-Unicode не соответствует языку системы (см. Задача 1).

Это означает, про проблематично записать в коде юникодную строковую константу

Это наименьшая проблема. В моем случае все строки подтягиваются из INI-файла (ANSI), который не проблема преобразовать в Unicode.

Есть еще интересная shareware библиотека, которая работает на отлично (проверил), но узко связана с выводом текста в нужной кодировке независимо от локали в TextBox или Label.
Подробнее тут: http://www.example-code.com/vb/vbUnicode2.asp

Я же склоняюсь, из-за отсутствия нормального (на мой взгляд) решения по переводу всех нужных для полноценной работы составляющих программы в Unicode, предложить пользователю выбор, в случае когда в региональных настройках Non-Unicode не кириллица:
- Работать в английской версии
- Установить в Non-Unicode кириллицу (предупредив о возможных несовместимостях этой настройки с другими Non-Unicode программами)

Ну и обещанная задачка по преобразованию путей:
Система Windows XP SP3 (русский), Non-Unicode - English

Вставляем такой код в модуль:

Код: Выделить всё

Private Declare Function SHGetFolderPath Lib "shell32.dll" Alias "SHGetFolderPathA" (ByVal hwndOwner As Long, ByVal nFolder As Long, ByVal hToken As Long, ByVal dwFlags As Long, ByVal lpszPath As String) As Long

Private Const S_OK = &H0
Private Const S_FALSE = &H1
Private Const E_INVALIDARG = &H80070057
Private Const SHGFP_TYPE_CURRENT = 0
Private Const SHGFP_TYPE_DEFAULT = 1

Public Function GetDocFolder() As String

    Dim strBuffer As String * 1000
    Dim strPath As String
    Dim lngReturn As Long
   
    lngReturn = SHGetFolderPath(0&, &H2E, 0&, SHGFP_TYPE_CURRENT, strBuffer)
   
    If lngReturn = S_OK Then
        strPath = Left$(strBuffer, InStr(strBuffer, Chr$(0)) - 1)
    Else
        MsgBox "Error!", vbCritical, "App"
    End If
   
    GetDocFolder = strPath
   
End Function

А где-нибудь на буттоне у формы делаем вызов:

Код: Выделить всё

MsgBox GetDocFolder

На выходе вместо привычных нам "Общих документов" в строке пути получаем искажение в виде знаков вопросов.
Msgbox похабно исказило путь.
Если вызывать SHGetFolderPathW вместо SHGetFolderPathA, то на выходе тоже не то, что ожидается!

Ниже изображение-отчет по пруф-примеру Хакера с провалом на третьем вызове.

[Хакер]

Это не провал, а суперская демонстрация того, чем чревато такое хранение юникода в строке.

В той теме говорилось, что можно придумать целых три способа хранения UTF8-текста в VB-программе.
Можно хранить его в массиве байт, можно хранить его в переменной типа String (каждому байту стринга соответствует каждый байт UTF8), можно хранить его опять же в переменной типа String, но каждому символу стринга будет соответствовать каждый байт UTF8).

Последний способ хранения был мною же назван самым тупым и уродливым, и даже в названии функции, работающейй со столь по-тупому хранимым UTF8-текстом, присутствует слова Dirty — грязный. В общем, этот метод самый плохой, я назвал его тупым и грязным, и даже функцию назвал Utf8DirtyToUcs2. Вот хорошая демонстрация того, почему он тупой и грязный.

Ещё раз процитирую тезисы из того топика:

Идеологически запрещено хранить UTF8-строку (или UTF7-строку или любую другую) в переменной типа String. Потому что существует как минимум два способа хранить UTF8-строку внтри String-переменной, и не существует абсолютно никакого способа узнать, какой из них используется, не существует никакого способа пометить переменную как использующую какой-то конкретный способ.

Так вот, UTF8 строка, лежащая внутри String переменной, может лежать либо как есть: каждый байт UTF8-строки совпадает с каждым байтом String-переменной, либо в по-глупому-в-юнкод-преобразованном виде, каждый каждый символ бессмысленной UCS-2 строки совпадает по своему коду со значением каждого байта UTF8-строки.

Соответственно, три варианта функции.

Для случая, когда UTF8-строка представляет (как положено) в виде массива байтов.

Для случая, когда UTF8-строка (как не следует делать) засунута в String-переменную в том виде, в каком есть.

Для самого тупого случая (как, надо полагать, у тебя), когда UTF8-строка хранится в String-переменной, причём каждому байту UTF8-строки соответствует двухбайтная пара String-переменная, представляющая UCS2-символ, код которого равен значение соответствующего байта оригинальной UTF8-строки.

Самый тупой случай, dirty-случай — сфейлил, чего и следовало ожидать.

[ger_kar]

Найти freeware замену юникодными, да еще и совместимые по интерфейсу - задача не тривиальная

Вот прочитал эти строки, потом вспомнились эти

Появись MSLU до 98 года, был бы шанс, что рантайм VB6 был бы юникодным от начала до конца. Но...

И возникли следующие вопросы:
Кроме VB6, который вышел в 1998 году, существует еще и VBA, последняя версия которого встроена в MS Office 2010 и у которого имеется практически идентичный собственный набор контролов. Интересно эти контролы поддерживают юникод или нет и как вообще возможно это проверить?

[Qwertiy]

Кроме VB6, который вышел в 1998 году, существует еще и VBA, последняя версия которого встроена в MS Office 2010 и у которого имеется практически идентичный собственный набор контролов. Интересно эти контролы поддерживают юникод или нет и как вообще возможно это проверить?

Да, поддерживают. Как извлекать собрался?

Элементарно проверить :)

[ger_kar]

Да, поддерживают. Как извлекать собрался?

Ну вообще эти контролы проживают по адресу при стандартной установке пакета офис "C:\Windows\System32\FM20.dll" и в VB их можно просто подключить. Если нет установленного офиса, то тогда видимо придется таскать эту библиотечку с приложением. Мне это по крайней мере видится так.

[Хакер]

Найти freeware замену юникодными, да еще и совместимые по интерфейсу - задача не тривиальная, а если и разрешимая, то потребует не позволительно много затрат времени.

А я вот не вижу в этом никакой проблемы. Хоть бери и сам пиши клоны стандартных контролов с поддержкой юникода. Ну я просто не верю что кто-то уже не сделал эту работу. Слишком очевидная задача, пробема, нужда. Неужели в том топике, на который я дал ссылку, ничего не подошло?

И вообще. Для конструктивной деятельности по решению проблемы напиши список контроллов, которым нужно обеспечить юникодность. Может быть общими силами найдём каждому пункту из списка юникодный аналог-заменитель.

[ger_kar]

Вот стандартные контролы, которые устанавливаются с офисом живут в библиотеке Dll, другие контролы живут в ocx файлах, а какая собственно разница между двумя этими способами хранения и чем ocx файл отличается от dll?
И еще заметил такую особенность. Работая в VBA и используя тамошние контролы нельзя создать массив этих контролов, а подключив офисную библиотеку к VB6, в самом VB6 можно запросто сделать массивчик с этими контролами. Почему это происходит?
Кстати раз с офисными контролами все так замечательно в плане поддержки юникода, то может и другая сопутствующая старым контролам проблема тоже разрешилась? Речь идет о поддержке стилей Windows XP.

[Хакер]

чем ocx файл отличается от dll?

Расширением.

[ger_kar]

Получается, что по внутреннему устройству *.dll идентичен *.ocx? И для превращения одного в другой достаточно банальной смены расширения файла

[ger_kar]

А я вот не вижу в этом никакой проблемы. Хоть бери и сам пиши клоны стандартных контролов с поддержкой юникода.

Вообще хорошо бы изучить такой момент, как написание собственного контрола. Очень хорошо, если бы появилась статья с подробным описанием как это вообще делается, потому как я например представляю себе этот процесс весьма приблизительно. Да и масса других (за исключением некоторых ) тоже. Конечно если начать писать свой контрол, то рано или поздно что-нибудь получится, но хотелось бы получить не что-нибудь, а стандартный, нормальный по всем критериям, контрол.
А посему все таки сначала лучше конечно было-бы почитать как это делается. Что-бы точно иметь представление, что обязательно нужно учесть и что обязательно нужно сделать и наоборот, что делать не следует. Что-бы прочитав статью сразу идти по нужной дороге а не метаться на распутье и проверяя всякие тупиковые направления. В интернете я натыкался на подобные статьи, но там все было с пятого на десятое и поэтому информативность их была крайне низкой. И потом, какой инструмент (язык программирования) лучше выбрать для этой цели, с чего начинать и чем закончить. Тогда после прочтения вполне возможно это действительно будет легко и просто А пока все очень не просто (естественно сужу по себе ).

[Хакер]

Получается, что по внутреннему устройству *.dll идентичен *.ocx?

И идентичен .exe, .sys, .cpl, .scr. Идентичен PE-файлу.

И для превращения одного в другой достаточно банальной смены расширения файла

Превращения чего во что? Да, для переименования файла достаточно переименовать файл.

[ger_kar]

Превращения чего во что?

Файла dll например в файл ocx и наоборот. Что касается превращения, то речь шла именно о превращении, а не просто переименовании. Понятно что переименовать можно без проблем, но получится ли при этом полноценный ocx файл если просто переименовать файл dll в ocx. И если эти файлы идентичны, но нафига надо было городить огород и выдумывать ocx файлы?
То что эти файлы соответствуют PE формату совсем не означает что они идентичны, например между exe и dll ведь разница все таки есть.

[Хакер]

Как же ты любишь оффтопить.

[ger_kar]

Все. Завязываю

[Qwertiy]

И если эти файлы идентичны, но нафига надо было городить огород и выдумывать ocx файлы?

Как же ты любишь оффтопить.

А мне тоже интересно Можешь перенести в отдельную тему и ответить?

[Qwertiy]

Ну вообще эти контролы проживают по адресу при стандартной установке пакета офис "C:\Windows\System32\FM20.dll" и в VB их можно просто подключить. Если нет установленного офиса, то тогда видимо придется таскать эту библиотечку с приложением. Мне это по крайней мере видится так.

Думаешь, лицензионное соглашение офиса позволяет таскать его контролы? Не уверен, что даже использовать позволяет...

[ger_kar]

Ну в любом случае перенос будет не криминальней, чем переделка рантайма VB. Кроме того если принять во внимание тот факт, что на большинстве компьютеров MS Office как правило есть, то решается все очень просто. Да и контролы по многим параметрам сходны со стандартными VB'шными.

[vip.fedor]

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

Обязательно напишу, но сейчас есть более актуальная проблема, как вернуть корректный путь состоящий частично из кириллицы.
Описанная мной выше функция возвращает для WinXP RU SP3 в среде где Non-Unicode = English, вместо - "C:\Documents and Settings\All Users\Документы", "C:\Documents and Settings\All Users\? ? ? ? ? ?". Что делает недоступным один из важных путей хранения настроек программы. Есть идеи как получить со всеми этими преобразованиями между ANSI и Unicode корректный путь?

[iGrok]

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

Обязательно напишу, но сейчас есть более актуальная проблема, как вернуть корректный путь состоящий частично из кириллицы.
Описанная мной выше функция возвращает для WinXP RU SP3 в среде где Non-Unicode = English, вместо - "C:\Documents and Settings\All Users\Документы", "C:\Documents and Settings\All Users\? ? ? ? ? ?". Что делает недоступным один из важных путей хранения настроек программы. Есть идеи как получить со всеми этими преобразованиями между ANSI и Unicode корректный путь?

А это достаточно просто лечится - либо правкой строк в объявлениях на As Long и оборачиванием их же в вызовах в StrPtr(), либо объявлением нужных функций в TLB вместо Declare.
Вот информация по теме:
viewtopic.php?f=44&t=26149&p=6611256
viewtopic.php?f=1&t=44028&p=6763783

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

[vip.fedor]

правкой строк в объявлениях на As Long и оборачиванием их же в вызовах в StrPtr()

Спасибо, но Вы уверенны что это работает? Можете продемонстрировать рабочий вариант такого решения? Или это опять теория?