Вы будете удивлены, но после автоматической замены string --> AnsiString, char --> AnsiChar и т. д.

и еще парой десяткой правок вручную проект успешно скомпилировался и запустился (хоть и с кучей багов и сообщений) на Delphi XE8.

На Delphi 2010 только скомпилировался, но не запустился сплошные Access Violation. Вот и думайте, какая версия Delphi стабильнее.

Походу, проще купить мощнее комп и сразу переходить сразу на XE8, чем мучаться с глючной 2010, а потом в итоге всё равно переходить на XE8. Думаю только - почему XE8

папка

C:\Program Files (x86)\Embarcadero

занимает 21 Гб что туда такого напехали. Можно ли оттуда что нибудь удалить и вообще заставить XE8 работать побыстрее ...

Правок около 100. Проект убитый костылями. Перенесся с отключением кучи функций (надо теперь постепенно восстанавливать и включать) и с кучей багов, также с эмуляцией Delphi 7 в среде XE8 (во всех функциях AnsiString и AnsiChar) - но в целом работает. Удивительно то, что на XE8 оказалось проще перенести, чем на 2010. Теперь буду думать перейти все таки на XE8 или навставлять костылей и остаться пока на D7. Вариант с D2010 точно теперь отметается, либо сразу XE8, либо оставаться на D7 и дальше городить костыли.

Разумеется, сразу и не решится. Более того, сначала багов будет еще больше. Но борьба с багами - в любом случае это неизбежный процесс при переходе на новую версию Delphi - особенно юникодную.

Но если string --> AnsiString, char --> AnsiChar не сделать то проект вообще не работает, даже с багами, так как очень много там заточено на 1-байтную кодировку - получается что лучше сделать string --> AnsiString, char --> AnsiChar при первоначальном переходе на новые Delphi, а потом уже в новой Delphi потихоньку исправлять баги и избавляться где надо от AnsiString итд.

Еще есть идея - создать свой тип, назвать

type
string7 = AnsiString
char7 = AnsiChar

и переходить не на AnsiString, а на тип string7 - который первоначально будет = AnsiString а потом пробовать иногда его менять на string и следить за багами

Судя по всему, по экспериментам компиляции в разных вариантах - оказалось, в моём случае лучше всего что-то среднее.

Не менять прям всё на Ansi, а поменять на ANSI только код модулей, которые самописные и не являются модулями форм. Потому что если поменять на UTF-8 - мой код в 95% случаев перестанет работать или будет много багов, там много кода для работы с файлами и т. д. - где важно чтобы именно 1 символ строки соответствовало 1 байту и разделить код, который можно перевести на UTF-8 и который нельзя - довольно сложно - проще всё оставить на ANSI.

Код модулей форм, код, сгенерированный Delphi и всё, что связано с VCL стараться не трогать - пусть будет в Unicode.

В общем, в процессе работы проекта будет много перекодирований из Ansi в Unicode и обратно (при обращении из форм к моим самописным модулям) - но как я понимаю, это не проблема - в конце концов работать будет уж точно не хуже, чем сейчас на Delphi 7, а над багами можно работать. По алгоритмам перекодирования из Ansi в Unicode и наоборот не проблема - у меня только русский и английский - можно смело хранить в Ansi в нужной мне кодировке (Windows 1251) - а не в той однобайтной, что Windows подсунет. На крайний случай можно вообще написать свои процедуры перекодирования Ansi-->Utf8 и обратно чтобы не зависели вообще никак от системных настроек.

В общем, написать нормальный скрипт замены - который максимально - насколько это возможно - произведёт замены только там, где это нужно - чтобы можно было потом обойтись минимальным количеством правок.

Кстати, уже сейчас - когда часть кода осталась на Unicode, а мой на Ansi, глюков стало гораздо меньше.

Кстати, спасибо за советы. С Delphi 7 тоже получилось. В 99% кода при включенной опции . Далее пишу что было сделано - на случай если кому ещё может пригодится.

"Бета-версия: Использовать Юникод (UTC-8) для поддержки языка во всем мире"/"Use Unicode UTF-8 for worldwide language support"

больше нет крякозябр. За счет добавления дополнительных костылей (получилось перехватом обращений к свойствам Text, Caption компонентов - перехватчики пришлось писать для каждого компонента свои - тк одни хранят данные в Ansi, другие в Unicode - но в целом ничего страшного и не такие уж костыли - всё вполне компонуется в один модуль - но если посчитать общее количество костылей за все годы по теме нормального отображения ANSI - можно испугаться).

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

Проблемы только в интерфейсе, в отображении русских букв в интерфейсе Windows.

С файлами никаких проблем нет - более того, используются свои форматы файлов - при разработке форматов - разумеется, предполагалось, что русские буквы записываются в кодировке Ansi. Можно, конечно, всё тупо перенести на Юникод - но это будет потеря обратной совместимости.

Усложнять без необходимости не хочется - поэтому придётся по умолчанию всю внутреннюю логику оставить в ANSI - а при обращениях к VCL - использовать Unicode. Полностью ПО переводить на Юникод имеет смысл - если продавать ПО за границу - чтобы могли использоваться языки, отличные от русского и английского (а если варианты только русский или английский то и ANSI сойдёт).

UPD. При переходе всё работает с минимальными багами, хотя баги ещё есть. При переходе на XE8 - как оказалось, многие костыли - которые были в D7 - оказались и не нужны - поэтому собственно эти костыли не надо и переносить.

Например, некорректная отрисовка некоторых элементов (TDateTimePicker, например) больше не требует костылей для исправления - так как отрисовывается всё нормально без костылей. То, что модальные формы после сворачивания/разворачивания гуляют с переднего фона на задний как захотят - похоже, в Delphi XE8 тоже решено.

Не говоря про проблемы с Unicode - тут нагороженные костыли скорее мешают.

Для использования private-переменных классов (если уж нужен такой костыль) - не обязательно копировать файл класса целиком себе в проект и его менять - можно использовать Helper-ы. Но придётся отказаться от Delphi XE10 - разработчики Delphi решили, что это баг и такую возможность закрыли. В XE8 ещё можно это использовать нормально.

Размер Delphi XE8 - тоже, в принципе, уменьшается и не так много занимает - достаточно зайти в папку Program Files\Embarcadero - и снести всё лишнее - например - то, что относится к Linux и Android и прочее.