Перешёл с 0.9.30на 1.4 - проект не работает. Опять юникод???

[slyubez]

Потому, что в Delphi одна кодировка - виндовская

Нет такой кодировки. Есть ANSI, и есть UTF-16. Все системные вызовы внутри VCL и RTL идут в какой-то одной из этих кодировок, в зависимости от версии Delphi. Есть возможность также применять API-функции с другой кодировкой, указывая их явно.

Системные вызовы будут unicode, внутренняя кухня (RLT) тоже.

Для кроссплатформенного программирования не факт, что будет хорошо, учитывая, что Windows работает с UTF-16, а Linux - с UTF-8.

[postscripter]

А, ну тады правда только 3.0 поможет.

[resident]

на сколько я понял FPC начиная с долгожданного 3.0 будет Unicode (UTF-16), то биш нужно будет балансировать между 3 кодировками )))

Варианта два: Или это самоубийство или Лазарус заказали

Статейка про заигрывание с мало кому нужными фишками непонятно ради чего. Хуть сюда перепечатывай.
http://habrahabr.ru/post/147281/

[Лекс Айрин]

Это в Линуксе-то?

Не попадалось... обычно, под виндой такие проблемы.

Добавлено спустя 3 минуты 26 секунд:
Re: Перешёл с 0.9.30на 1.4 - проект не работает. Опять юникод???
Видимо, это из-за слоя совместимости с виндовс.

[slyubez]

Не попадалось... обычно, под виндой такие проблемы.

В винде нет UTF8-функций.

[Лекс Айрин]

slyubez,

Здесь мы видим уже знакомую библиотеку kernel32.dll. Правда, имя функции записано не FindFirstFile(), а как FindFirstFileA(). Это объясняется тем, что многие функции в этой библиотеки имеют два варианта: для работы со строками в кодировке Unicode к имени функции добавляется буква "W" (FindFirstFileW), а для работы с кодировкой ANSI добавляется буква "A" (FindFirstFileA).

Добавлено спустя 2 минуты 33 секунды:
Re: Перешёл с 0.9.30на 1.4 - проект не работает. Опять юникод???
Хотя может речь идти и об UTF16...

[slyubez]

Хотя может речь идти и об UTF16...

О ней самой и идёт. В UTF16 любой символ всегда имеет размер не менее двух байт (WideString), а в UTF8 первые 128 символов - однобайтовые, совпадающие с ANSI.