хотя, наверное, DELPHIUNICODE ключик поможет, с перекомпиляцией, но имхо, это извращение

один фиг, ещё время модификациифайла надо (ну и размер файла, опционально, ибо при упаковке можно будет взять)

FindFirst/FindNext там UCS16  а в String по умолчанию UTF8, перекодировать надо будет.

Но на всякий случай проверьте там не все так просто.

FindFirst/FindNext можно и анси-вариант юзать  :) в этом и прелесть. Но мне как раз юникод и надо,

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

Обмануть можно, но обман рано или поздно раскроется.

:) оптимизация зачастую заключается в обмане. И иногда это "прокатывает". Буду думать сейчас, сразу всё же время для файлов сохранять или ждать этапа обработки.

ладно, спасибо за беседу, пойду печеньки делать

Опять двадцать пять...
Когда вы уже научитесь озвучивать задачу, которую решаете, а не искать хаки на  способ решения, который придумали? ...
Я про XY problem, если что...

Кто сказал?

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

формат данных не мой, ну что тут поделать...

В твоейй программе не твой формат?

моя программа - обработчик, но не пользователь

это часть формата данных, используемых играми типа Торчлайт-2, Хоб или Ребел Галакси

Всё равно, каждый раз одно и то же... И ладно бы люди были разные...

эй, ну что за претензии сейчас-то?

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

1. Менять размер массива лучше на какое-то большее чем 1 значение. я меняю на тысячу. текущее место вставки в массив запоминаю и инкрементирую. по окончании устанавливаю размер на текущее место вставки
2. действительно существуют более оптимальные варианты чтения папок чем findfirst/next. самому 'поднять' шансов мало. но можно юзать готовый everything, есть api
3. в последнее время списки файлов вообще перестал вычитывать, обрабатываю файлы сразу 'по ходу', скорость обработки выросла раза в 2, да и памяти на сотнях тысяч не напасешься