» Оптимизация размера программ (EXE)

MoKC0DeR
Да я не совсем то сказал, что хотел =)
Я имел ввиду packer.cpp, packhead.cpp и т.п.

vito333
Только UPX - бесплатный, а PECompact - нет

На _http://www.wasm.ru/toollist.php?list=8
есть PeCompact 2.40 retail by CollakeSoftware

Varenik
ну, тут не поспоришь
WELLROCK
мы в одном шаге от Варезника

Извеняюсь. Я как-то не подумал

WELLROCK
какие релизы свои ты жмешь, если не секрет?

vito333
http://www.rockteam.org


Добавлено
Я имею ввиду патчи конечно

WELLROCK
а манифесты у тебя не пропадают? я вот пожал свою прогу - тут же сообщают, пропал стиль ХР.

Добавлено
хотел автору отписать - не могу сайт увидеть

Честно говоря я с манифестами жать не пробовал.
В моих прогах из ресурсов только битмап, иконка ну и сам диалог =)
А сайтвот http://northfox.uw.hu

WELLROCK
а ты попробуй
а на сайт - не могу, попробую позже с другого компа

Ну у меня под рукой тоже ничего пока нету
Вечером попробую...

Вот что сказано по поводу Delete Unimortant resources

Цитата:

Delete unimportant resources
delete FILEINFO, XML resources
every resource will be in the destination file

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

Ну может автор пофиксит это дело...

WELLROCK

Цитата:

Ну может автор пофиксит это дело...

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

Ну в прошлой версии вообще консоль была без настроек особых.
Видать некогда ему заниматься этим проектом...

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

То есть у тебя манифест был не в ресурсах а отдельно что ли?

в ресурсах. проверил я MEW - наладить сохранение манифеста и одновременно компрессию не удалось. возвращаюсь на FSG.

Ну это опять же смотря какие файлы жать
Для меня MEW всё же более приемлим.

WELLROCK
нормальные проги а mew заточен под асм, да еще без манифестов, так что пользуйся, а я - увы ...

Ну что ж. Каждому свой пакер

Optimizing Your Code with Visual C++
Mark Lacey
Microsoft Corporation
April 2003
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vctchOptimizingYourCodeWithVisualC.asp
----------------------
Summary: This document describes the code optimization features available in the Visual C++® .NET 2003 product. Additionally, for those readers not already familiar with the advancements made in Visual C++® .NET 2002, a short section describes the new Whole Program Optimization feature that was introduced there. Finally, some "best practices" for optimizing are discussed, as well as general enhancements to the Visual C++ compiler.

Добавлено
Managing Code Size
The GCC compiler supports a variety of options for optimizing your code. Most of these techniques result in the generation of less code or faster code, depending on your needs. As you prepare your software for release, you should experiment with these techniques to see which ones benefit your code the most.

http://developer.apple.com/documentation/Performance/Conceptual/CodeFootprint/Concepts/CompilerOptions.html#//apple_ref/doc/uid/20001861/CJBJFIDD

How Big Is My Program
http://www.codeproject.com/system/howbig.asp

Цитата:

How Big Is My Program
http://www.codeproject.com/system/howbig.asp

Юзать MFC имхо не оптимизация.
Так можно и кодинг на VB назвать самым оптимизированным =)

WELLROCK
ну, упираться в WinAPI, как я, тоже не гуд.

а в топик я разную инфу кладу, но про оптимизацию

Добавлено

Цитата:

Так можно и кодинг на VB назвать самым оптимизированным

думаю, проги на ВБ тоже можно так или иначе оптимизировать,хотя и не представляю как

Цитата:

ну, упираться в WinAPI, как я, тоже не гуд.

Это как раз оптимальный вариант.
Потому что нет никаких длл-ок посредников, никаких "псевдо-функций".

Хотя и тут есть место для оптимизации
Например лучше юзать WriteFile чем _lwrite, потому что _lwrite в итоге вызывает WriteFile.
То же самое касается и MessageBox'a, который в итоге вызывает MessageBoxEx.

Кстати размер при этом увеличится, т.к. эти функции используют больше параметров. Но скорость будет выше.

Цитата:

Это как раз оптимальный вариант

для небольших и несложных проектов - может быть, в других случаях - использовать надо, но упираться - не стоит. Это из собственного опыта тоже. Свой редактор я сначала писал на чистом С, затем сложность меня завалила, сейчас я полностью его переписываю и переделываю на С++, но и тогда и сейчас - чистый WinAPI, так вот сейчас я с завистью иногда поглядываю на WTL - на мой взгляд для создания хребта программы(интерфейса прежде всего) аналогичного класса это самый предпочтительный инструмент, а дополнять и развивать можно как угодно, хоть винапи, хоть мфс.
Хотя конечно, все зависит от цели. Я мог и на VB пописать редактор, но что-то не хотелось, цель другая - минимальный размер, понятность и красота кода, удобный интерфейс, заодно изучаю С/C++ - в общем это ДЗЭН .
У тебя, как у крякера и асмера наверняка другое несколько отношение.
Мне вот уже мой редактор кажется великоватым по размеру кода (53.5 кб неупакованный) - но объективно понимаю, что меньше при его возможностях сделать почти невозможно, только на асме, но думаю, не намного меньше выйдет, а объем работы будет на порядок больше, и ошибок - соответственно. Но тут уже начинается тема соотношения затрат и качества/размера программы, а этого мы не касаемся.
Да и асм я не знаю ((.

Что касается ReadFile и _lread - я в своем Марке попытался максимально ускорить загрузку больших файлов в ричедит. Сделал что мог - максимально простой код на ReadFile, минимум проверок в StreamIn функции. Но! Берем бред2 - смотрим - начинает отображать большие файлы (ну скажем 26 мб txt) - через 1-2 сек одновременно догружая остаток - смотрим исходник - все вроде обычно - даже не ReadFile, а _lread используется, смотрим аналоги на этой же версии ричедита - нифига быстрого, все как обычно - тормоза. Смотрим мой Mark - тот же файл - 5-6 сек. Извращался как мог. Но все равно бред2 отображает файл со скоростью функции ReadFile, а у меня на загрузку в ричедит уходит 75% времени и отображает только через 5-6 сек.
Понятно, что ричедит - не самая лучшая вещь и т.д., что он при загрузке грузит кускамм по 4096 байт и возможно из-за этого тормоза, но как это делает бред2? я соптимизировал, а он все равно намного быстрее

Даже не знаю что сказать %)

Добавлено
Хм. Так у тебя долго грузится при чтении из файла или при записи в ричэдит?

из файла в ричедит

стандартный EM_StreamIn.

просто я экспериментировал по всякому и и когда читал сначала в буфер в памяти а потом из него в ричедит, то картина была следующая: общее время было такое же, как при прямом чтении в рич 5-6 сек, но! чтение ReadFile-ом 26 мег занимает как раз 1-2 сек, а все остальное время - загрузка в рич, то есть именно мелкокусочнобуферная загрузка в рич занимает основное время. А бред2, собака ), работает со скоростью ReadFile.

В принципе, все это умозрительно и почти не имеет практической ценности, так как Марк все-таки грузит большие файлы, а подавляющее большинство аналогов просто дохнет, во вторых, файлы больше 1-2 мег на компе редкость, а их редактирование - редкость еще бОльшая. Просто было интересно и как раз работал над загрузкой, а это вопрос так и не смог выяснить.
А вообще вопрос по быстрому открытию файлов и загрузке в РТФ-контрол у меня остается открытым.

вопрос по скорости бреда2 закрыт - получил письмо от kluga - автора бреда2 - ничего особенного он не делал, использовал STRAMIN, просто ричедит 1.0 быстрее - так что свою прогу буду ускорять своими методами.