Спасибо всем за ответы, особое спасибо за ответы приведшие к просветлению SSerge, LearnMagic
Надо сказать, что ,к сожалению, я повел себя как "истинный русский по Задорнову", т.е. читаю инструкцию только если что-то не получается.
И так резюмирую, то что открыл для себя.
Сразу оговорюсь, что все о чем я пишу касается только программ с LCL т.е. Lazarus, CodeTyphon. Программы на "голом" FPC отдельная тема, там я не разбирался.
Итак, разработчики FPC движутся в сторону поддержки UTF8 (юникода) достаточно большими шагами.
Так раньше (до версии FPC 3.0) многие файловые функции такие как AssignFile(), MkDir(), FileExists() ну и многие, многие другие
требовали аргументы- имена файлов в кодировке Win1251 (в случае русской Windows, конечно) или быть точнее в системной кодировке.
А поскольку все переменные (и константы набираемые в редакторе) обычно в кодировке UTF8 то приходилось менять кодировку с помощью UTF8ToSys()
т.е. примерно так :
AssignFile(...,UTF8ToSys(...)), MkDir(UTF8ToSys(...)), FileExists(UTF8ToSys(...)) и так далее
Или для некоторых функций существовали UTF8 двойники Например FileExistsUTF8(), которые уже использовались без перекодировки аргумента (без UTF8ToSys() )
То же касается некоторых методов таких, как например TStrings.SaveToFile(), TStringList.SaveToFile() ну и так далее.....
Теперь (начиная с версии FPC 3.0 т.е Laz 1.6) Эти файловые функции такие как AssignFile(), MkDir(), FileExists() ну и многие, многие другие
требуют аргументы- имена файлов в кодировке UTF8 и теперь можно писать без UTF8ToSys()
AssignFile(...,...), MkDir(...), FileExists(...)
И можно забыть про функции "UTF8 двойники" такие как FileExistsUTF8()
т.е. FileExistsUTF8() и FileExists() будут работать АБСОЛЮТНО ОДИНАКОВО ПРИ ЛЮБЫХ АРГУМЕНТАХ..... ПРОВЕРЯЛ. это так....
То же касается некоторых методов таких, как например TStrings.SaveToFile(), TStringList.SaveToFile() ну и так далее.....
Для того же, чтобы не переписывать и не править весь код где написано:
AssignFile(...,UTF8ToSys(...)), MkDir(UTF8ToSys(...)), FileExists(UTF8ToSys(...)) или FileExistsUTF8() .....
функции UTF8ToSys(), UTF8ToAnsi() и обратные к ним SysToUTF8(), AnsiToUTF8() оставлены как функции пустышки ....
т.е они ничего не делают, а просто возвращают аргумент.
При этом функции типа UTF8ToCP1251(), UTF8ToWinCP(), совсем не пустышки, а выполняют то что обещано исправно !!!!
С этим я и столкнулся в том тестовом примере что привел в исходном посте....
Но внимание !!!! не все функции стали работать с UTF8 например UpperCase() и UTF8UpperCase() работают по разному и сейчас ..... ПРОВЕРЯЛ !!!!
Ну и другие строковые функции тоже.... (функции преобразования строк)
Все мною сказанное верно только для функций где аргументы это имена файлов, каталогов.....
Теперь далее... Для решения разных вопросов совместимости есть у компилятора режим с клюем -dDisableUTF8RTL, при котором вышеупомянутые функции
начинают требовать аргументы в кодировке Win1251, как и раньше, до версии FPC 3.0, но при этом и функции UTF8ToSys(), UTF8ToAnsi() начинают работать как и раньше, перестают быть пустышками.
т.е. в Этом режиме функции FileExistsUTF8() и FileExists() снова будут работать по разному если строка-аргумент содержит русские буквы.
Как откомпилировать проект с этим параметром кому интересно могу подсказать.
Ну например, кто-то написал в своей программе AssignFile(...,UTF8ToCP1251(...)) вместо AssignFile(...,UTF8ToSys(...)), то понятно что данная программа будет корректно работать на под FPC < 3.0 и Русской виндой
при этих условиях UTF8ToCP1251, UTF8ToSys работают одинаково. Но если это откомпилировать FPC 3.0 т.е Laz 1.6 то увы, будет ошибка. Юникодовую строчку преобразуем в CP1251, а функция ждет имя файла в Юникоде.
конечно, по уму надо AssignFile(...,UTF8ToCP1251(...)) заменить на теперь уже, если обратно не возвращаться на AssignFile(...,...), или, если возможен возврат к компилятору FPC < 3.0 на AssignFile(...,UTF8ToSys(...))
А если нет возможности исправить исходники, мозгов не хватает, слишком исходники запутанные, есть вариант откомпилировать проект с ключом -dDisableUTF8RTL и он снова заработает.
А сейчас я расскажу из-за чего я вообще сделал исходный пост.
Есть некоторый проект(ик) использующий ZeosDB (ZeosDBO) фиг знает как правильно... и базу firebird.
Писалось исходно используя CodeTyphon какой версии не скажу, так как склероз с пенсией совсем не за горами.
Но при памяти компилировалось в CodeTyphon 5.5 и все сносно работало.
И вот при перекомпиляции "ради прикола" в Lazarus 1.6, Lazarus 1.7 (транковый) и CodeTyphon 5.9 (до установки 6.0 руки не дошли)
Проект отказывался работать если база данных или(и) клиентская библиотека лежала в каталоге с русскими буквами.
Сначала я думал что все дело в версии ZeosDB (ZeosDBO) и даже качал разные ревизии с их транка и подбирал, "чтоб заработало"
Но потом убедился, что все зависит от компилятора или среды уж как лучше сказать....
Сначала думал ну вот 3.1 до и после, но тут тоже незадача
L 1.6 компилятор 3.0 не работает
ct 5.5 компилятор 3.1.1 работает
L 1.7 компилятор 3.1.1 не работает
ct 5.9 компилятор 3.1.1 не работает
Тогда я решил, проверить, как работают функции UTF8ToSys(), UTF8ToCP1251(), ну и другие под разными компиляторами, средами.
Результат удивил, показал явную связь работоспособности ZeosDB на каталоге с русскими буквами с работой UTF8ToSys
Вот я его и опубликовал, и спросил почему?
Когда я осознал, все то что написал выше, перекомпилировал свой проект с ключом -dDisableUTF8RTL, и о чудо, он заработал и каталоге с русскими буквами и откомпилированный любым из перечисленных компиляторов...
Как оказалось, в ct 5.5 компилятор настроен так, что он изначально (по умолчанию) компилирует с ключом -dDisableUTF8RTL, но его можно отключить.
С версии 5.6 авторы ct от этой политики отказались. Поэтому так и получается..
Вывод: Увы, разработчики ZeosDB не учитывают новые реалии, грубо говоря, ГРУБО, навставляли где-то что-то вроде AssignFile(...,UTF8ToCP1251(...)), и приходится компилировать с ключом -dDisableUTF8RTL,
и при этом не использовать новые стандарты в плане файловых функций. Или забить на то, что базу и клиентскую библиотеку нельзя будет класть по пути с русскими буквами.