Цитата:
Сообщение от MadLord
почему новый файл больше оригинала получается на 292 байта?.
|
- Сравни и сходное количество Record - наверняка отличаются
- алгоритм оптимизаци максимально приближен к оригиналу, но все-таки точно повторить его я не смог
- идет не просто пересчет KS - но и полностью перепаковка с новыми Record того b000ff, на котором ты стоишь
Цитата:
Сообщение от MadLord
можно как-то увидеть, в каких модулях не сходится контрольная сумма?....именно просто увидеть...
|
- сделай MAP - вначале каждого Record идет значение KS: зеленый цвет - Ok
красный цвет - ошибка
Чтобы не искать по всей карте - запомни адрес, по которому правил, слева в карте первая колонка эти адреса оnсортированы по возрастанию, я именно для этих случаев и помещал этот адрес. Его значение - это RVA от начала самого loading.kwi
Цитата:
Сообщение от MadLord
ребилд делается именно для record?...я выделял unit и делал ребилд...надо все-таки ребилд для всего лоадинга сделать...
|
- чтобы не дробить задачу, да и заодно сделать все проверки, о которых я знаю, и устранить их - я делаю эту операцию так: Rebuild только конкретного UNIT, а затем пересборку всего loading.kwi - после пересборки (а она вызываются и после серьезных правок, типа добавление новой dll) часто меняется размер самого b000ff - а значит шапка loading.kwi и смещение за ним следующих UNIT
boot - ничем в этом случае не отличается от OS.
Вот только вопрос - зачем трогать boot - там только загрузочный nk.exe - его тронь - система не запустится
Я именно по-этому поставил запрет на замену и редакцию nk.exe как в boot так и в OS
Добавлено через 6 минут
Цитата:
Сообщение от MadLord
ребилд делается именно для record?...я выделял unit и делал ребилд...надо все-таки ребилд для всего лоадинга сделать...
|
Надо добавить сообщение об окончании операции и где новый loading, тогда будет понятно.
Просто boot очень маленький, операция проходит быстро, а визуально, после OS, кажется, что машина еще работает