Недостатки PE-формата

Лучше уж новый элемент добавить в секцию ресурсов - например SINGLE_ICON.

 

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

 

Позвольте сделать замечание.
РЕ-формат, elf и "всякие другие революционные" будут фуфлом,
если исповедовать Microsoft-коммерц идеологию.
В самом РЕ-формате было заложено много хорошего, но Microsoft
не реализовал и 1% возможностей из-за погони за баблом.
Всякие вирусы, реверсинг, крякми, "отсутствие" защиты - это следствие
отсутствия СТРОГОЙ СТАНДАРТИЗАЦИИ ФОРМАТА и
реализации СТРОГОГО ЗАГРУЗЧИКА ОС, чтобы
не допустить сегодняшнюю возможность
издевательства и испоганивания структуры РЕ файла.
Например, контрольная сумма модуля (кто её использует? и проверяет??),
Строгий Формат Секций (!), защита каждой секции (СRC, MD, паспорт, подпись, и т.д.)
Сама ОС и её загрузчик должны неукоснительно следовать предписанным
правилам, которых должно быть мало и строго прописано.
Как например в некотороых милитари ОС реального времени.
Вспомните историю секции ресурсов, которая хоть немного
спасла Microsoft От полного пиз..ца.
Да они памятник должны поставить ".rscr".
Хотя в существующей линейке загрузчик и не требует этого.
Отсюда и метания в сторону .NET.
Малость и строгость правил облегчит жизнь разработчикам
средств разработки (компиляторы и т.д.), отладка должна быть составной частью формата
и тоже СТРОГО прописана.
Следовательно, должны быть открытыми и доступными исходные коды
основных элементов ОС и сертификации любого продукта.
Для лузеров - виртуальная машина - пусть резвятся.
Тогда и разработка и сопровождение и защита ПО будут
напорядок надёжнее.
ОтсЮда с неизбежностью следует вывод - нужны СТРОГИЕ ПРАВИЛА
и новая "старая" ОС с очень СТРОГИМ загрузчиком.
Но куда деть всё то фуфло, что успели наплодить?
К сожалению в продвижении *nix наблюдается таже история мелкомягких.
OPen Source не должен уподобляться модели дерьмократии.
Правила тоже должны быть СТРОГИМИ.
СТАНДАРТ на формат файла и СТРОГИЙ загрузчик
должен быть обязательно.
Ведь те кто пишет музыку используют всего 7 нот.
Жаль, что забыты добрые традиции DEC.

 

хм... вот уж не думал, что наличие CRC секции в ее заголовке поможет избежать заражения файла вирусом

 

Угу, а еще тела секций зашифровать, а в заголовках - ключ, всю совокупность секций тоже криптануть, для защищенности, а ключ пользователь должен вводить при запуске. )))

 

im1111

Для поиска иконки в заголовке с верятностью 99% не нужно выполнять вторую операцию чтения из файла - скорее всего иконка окажется в первых 16 килобайт. Для любителей гигантских иконок понадобится прочитать ещё десяток-другой килобайт, но даже в этом случае не надо будет выполнять очень тяжёлую по времени операцию перемещения по файлу, т.к. данные возьмутся из кэша винчестера.

Не то же. Seek не нужен будет.

Ещё один seek. А seek - это отнюдь не самая быстрая из файловых операций, иной раз быстрее мегабайт прочитать.

При проектировании исходить надо из худшей возможной ситуации. Т.е. что иконок в секции - тысячи, и нужная нам - последняя. В таком контексте нынешний алгоритм поиска иконок выглядит как поделка уровня школьника "сделать хоть как-нибудь, лишь бы отвязались".

 

В данном случае решает маркетинг и тут свои законы в зависимсоти от сегментации на рынке, а у МС это простые юзеры, которые любят дизайн, для этого нужно хранилище для множества иконок. Можно сделать одну в заголовке, но отображение 48x48 деполировав до 16х16, вообще любая смена разрешения, убьет все дизайнерские труды и ОСь будет уже не так красива. Проектирование разное бывает - если проект укладывается в требования, то ни один нормальный программер работающий на фирме не будет выжимать последнее зная что у него куча работы. В итоге получилась ОСь которая вполне нормально функционирует, а то что вы обсуждаете это мелочи. Сделаете хороший PE угробив месяц на обсуждение того как лучше оптимизировать - потеряете например на проектировании API интерфейса.

 

Великий и могучий MS не заставляет использовать лишнюю информацию.

Будет просто урезанный формат. То, что не дорезал MS, дорежет AntiB

 

Chizh

если не использовать - то зачем тогда держать?

я же не говорю всё подряд резать, нужно что-то удалить - и хорошо, если добавить, но что-то, что нужно!

 

На это и существуют именованные секции, на все случаи жизни.
И вообще, лучше больше информации, чем меньше. То, что сегодня кажется ненужным, завтра может оказаться жизненно необходимым. И тогда что, делать очередной идеальный формат?

 

Chizh
оставить, например 4 байта в резерв и если что - добавить таблицу и смещения дать в этих 2 словах

 

В PE список таблиц описан ещё проще - секции являются массивом, а в заголовке хранится только общее количество.
Ты не учитываешь, что идеальный формат должен быть универсальным. Именование секций и даёт эту универсальность.

 

Chizh
и какая здесь универсальность?? что с того что ты знаешь что секция называется .code?? если можно поставить бит в одном байте, то есть экономия в 7 байт имхо это не много, но по немного можно "с экономить" много байт, вернее удалить "лишнее"

 

На бите же не написано, что это .code. А если мне понадобится ввести секцию .xml, то как мне на бите красиво выгравировать надпись "XML"?

 

Chizh
а зачем? вот зачем вам видеть надпись "XML" ??? главное не название, а предназначение, я так думаю, хотя могу ошибаться

 

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

 

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

 

бит для секции кода, бит для секции данных - это привязка к архитектуре процессора, и никак не универсальный формат.

 

t00x
может бить, но название секции ничего не решает, я так думаю

 

AntiB
Про влияние названия секции - посмотри DDK если начало названия с PAGE хххх слова начинается, то она pageble по написанному в DDK. PS: не проверял, но встретил такую фитчу в DDK.