egor23
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Цитата:| ктсати, я по твоему совету перебазировал свой gtk на 0x6c. может, лучше было бы на 0x004 и пусть система сама их размещает? |
0x6c брался из расчёта чтобы dll-ки размещались до 0x700...
т.к. не нашёл информацию какие адреса зарезервированы за системой (и есть ли они вообще), а сообщение об ошибки помню:
Цитата: Перемещение произошло из-за того, что библиотека
Dynamically Allocated Memory заняла область адресов, зарезервированную для
системных DLL Windows. |
Цитата:| а то сейчас после них кусок в 84 мб остаётся - далеко от идеала |
потери минимальны
Цитата:| может, лучше было бы на 0x004 и пусть система сама их размещает? |
это вроде как не совсем правильно, т.е. более праивльно указать конкретные адреса.
по поводу размещения dll есть два варианта:
или рядом с 0x004 (напрмиер 0x00A00000 не проверял)
или рядом с 0x700 (в данном случае 0x700 условность)
и соответственно dll-ки которые грузятся "всегда" размещаются ближе к "рубежу"
0x00A или 0x700
Добавлено:
Bulat_Ziganshin
Цитата:| 100%-ный метод я знаю только один - использовать 64-битную систему. и этот подход - не панацея, а всего лишь ещё один способ, который может помочь многим, кто хочет увеличить сжатие в fa. такой фичи нигде больше нет |
Issue 72
Heap процесса - опробован, память резервируется, осталось только научить FreeArc с ним работать, если такое возможно.
dll-ка - не факт, что сможет "раньше всех" подцепиться, но если сможет тоже чудно.
какой вариант лучше надо смотреть
Heap процесса \ dll-ка - решают проблему dll-ок, не задумываясь сколько там этих dll-ок и какие это dll-ки, не измененяя dll-ки.
также можно тонко настраивать "резерв", меняется "один байтик",
по умолчанию резервируется 1МБ.
но всё это мысли, т.к. могут всплять какие-нибудь "мелочи"... |
