Здравствуйте!

Чисто для любопытства интересует следующий вопрос.

Если в Delphi 2005/2006 (возможно и в Delphi 8 - не проверял) скомпилировать Win32-приложение (кстати, и для VisualStudio, начиная с 2003), то его невозможно сжать упаковщиками типа upx.

Вроде бы создается проект для платформы Win32, а не для .NET, а такая картошка получается. Где туплю?

Попробуй так:
upx.exe -9 --force Project1.exe

ASPack жмет нормально и все работает.

upx.exe -9 --force Project1.exe

Да, это upx пишет.
Спасибо за ответы. Просто было немного страшно , а вдруг программа не заработает на каком-нибудь компьютере.
Был такой глюк, когда распакованная программа не работала на 2000, а на XP Работала.
Исходный еxe работал и на двух, а распакованный отказался

Цитата(FlashSoft @ 3.1.2006, 23:15 )

Да, это upx пишет.

Будем ждать новой версии. Может поправят анализатор.

Цитата(FlashSoft @ 3.1.2006, 23:15 )

Был такой глюк, когда распакованная программа не работала на 2000, а на XP Работала.

Это только методом тыка проверять.
Хотя лично такого ни разу не встречал.
Я вообще всегда сжимаю upx'ом, а потом расжимаю - после такой чистки файлы лучше раром пакуются.
Но с глюками еще не встречался.

А, кстати, upx лучше, чем ASPack?

Цитата(Guedda @ 4.1.2006, 13:16 )

А, кстати, upx лучше, чем ASPack?

Вопрос спорный. Когда как.
Но обычно UPX жмет сильнее.
Кроме того, стоит учитывать побочные эффекты, которые оценить сложно.
Лично я выбрал upx. На мой взгляд, более серъезная поделка.

А, если можно, где можно почитать про побочные эффекты одного и другого?
Спасибо.

Цитата(Guedda @ 4.1.2006, 13:53 )

А, если можно, где можно почитать про побочные эффекты одного и другого?

Сложный вопрос. Обычно вычисляется экспериментальным путум.
Можно спросить у upx методом
upx -help
Он покажет варианты ключей, что можно не сжимать. Обычно это и есть проблемы.
Также можно попробовать поиск по форуму по слову upx
Обычно проблем никаких, но есть и исключения.

сжимать программы а особено длл ваще оч вредно оочч)
это нагружает систему)

Цитата(FRAGNATIC @ 4.1.2006, 20:55 )

сжимать программы а особено длл ваще оч вредно оочч) это нагружает систему)

C этого места по подробней можно?

Что касается, что лучше upx или AsPack, то вопрос спорный, но об не корректной работе программ упакованных upx я слышал, да и сам сталкивался, а вот об не корректности упакованных AsPack нет. Сам долгое время паковал upx, но сейчас перешел на AsPack

Код

C этого места по подробней можно?

красиво расписать не смогу всё
а перво источник в дауне( а так в кратце про длл

Цитата

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

В общем... Мне так кажется, что вообще не нужны паковщики программ. А писать нужно на API, чтобы программы занимали меньше места.

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

Цитата(FRAGNATIC @ 4.1.2006, 20:55 )

сжимать программы а особено длл ваще оч вредно оочч) это нагружает систему)

Тут я не согласен. Одно дело сжимать dll общего назначения, а совсем другое паковать ехе.
Паковать ехе ничем не вредно. Oсобенно писанные на VCL.

Цитата

Паковать ехе ничем не вредно

При быстрых процессорах это даже полезно
так как работа HDD гораздо медленнее чем с RAM и зачастую
распоковка в RAM происходит быстрее чем чтение с диска большого
файла.

чтобы это ( тормоза ) заметить -- файл должен быть несколько сотен мегабайт
и ужаться он должен в несколько десятков мегабайт. что при правильном подходе к проектированию просто нереально: при сто-метровых exe-шниках стоит задуматься о разделении функциональности...
Добавлено @ 14:12
P.S.
exe-шники максимального размера, что на компе нашел:
nero.exe 19087360
WINWORD.EXE 12037688
причем ни первый ни второй не жмутся
Добавлено @ 14:13
P.P.S.
оба читаются меньше чем за секунду

Хорошо бы засечь время поточнее....

код такой:

Код

{     double time = 0;     DWORD begin = GetTickCount();     if ( CopyFile("D:\\nero.exe", "NUL", FALSE) )         time = ( GetTickCount() - begin ) / 1000.0;     return 0; }

перед запуском копировался файл на 700 метров ( для очистки кеша ) время 0.344 сек.

Я имел ввиду по точнее определить время запуска сжатого и не сжатого
exe, хотя nero не лучший пример так как грузит много библиотек.

куда уж точнее ( там время зависит уже от особенностей строения программы )?
+ ты говорил о экономии времени за счет считывания меньшего числа байт с диска. эта экономия незначитильна ( доли секунды )

alexeis1
да время разумеется у сдатого будет меньше совсем на незаметную какплю
хотябы потому что сжатый сначало распаковывается а потом запускается) вот и всё.
я говорил о забивании памяти)

FRAGNATIC, а теперь давайте по думаем сколько памяти мы там жрем пакуя стандартный exe размером в 1Мбайт при этом пользователю мы можем отдать этот не упакованный вариант, а наш конкурент с похожей программой его упакует и получит 300Кбайт. И мы оба выходим на рынок. И нтересно чей продукт купят? При этом этого 1 Мбайта в памяти ни кто не заметит. Упаковка exe значительно упрощает распостранение программ, при нынешних мощностях вычислительной техники заботиться об 1Мб памяти это просто смешно. У нас половина программ народ пишит когда при старте грузит в память все формы при этом программы в памяти занимают ужас сколько.

Итог: паковать нужно, но с умом, не нужно паковать все и вся.

PS:
По мне лучше при написании приложения следить, что бы оно память не ело как фиг знает что. (все чаще встречаю вроде бы не плохо организованные приложения, но память едят как фиг знает что)

Alex
ну про ехе может я и не прав)
а вот про длл которые тоже очень любят поковать я думаю всёже их не стоит поковать=)

Цитата(FRAGNATIC @ 6.1.2006, 00:17 )

ну про ехе может я и не прав) а вот про длл которые тоже очень любят поковать я думаю всёже их не стоит поковать=)

С чего бы это вдруг? dll по-сути - это тот же ехе, только без возможности запуска.

Цитата

В общем... Мне так кажется, что вообще не нужны паковщики программ. А писать нужно на API, чтобы программы занимали меньше места.

Только паковщики не нужны, имхо. Файл можно сжать WinRAR, а еще лучше 7zip (для пересылки по почте, например).
А вот защищиать программы от просмотра разными редакторами ресурсов, отдалять процесс дизассемблирования, надо. А сделать это без упаковки программы очень сложно (хотя никто не отменял скрэмблирование и заинлайнивание всех функций в исходнике и др).
Вот такая ситуация.

А можно так.
Если в программном комплексе используется много exe, dll, то можно рантайм-библиотеки не линковать к файлам, а класть в текущий каталог с файлами или system32.
Тогда скорость должна немного возрасти, так как всеми файлами используются одни и те же библиотеки.

Это сообщение отредактировал(а) FlashSoft - 6.1.2006, 03:01

Цитата

С чего бы это вдруг? dll по-сути - это тот же ехе, только без возможности запуска.

выше уже писал
по сути да
но длл препологает под собой один запуск а юзает её много приложений!

Цитата(Alex @ 6.1.2006, 01:12 )

FRAGNATIC, а теперь давайте по думаем сколько памяти мы там жрем пакуя стандартный exe размером в 1Мбайт при этом пользователю мы можем отдать этот не упакованный вариант, а наш конкурент с похожей программой его упакует и получит 300Кбайт. И мы оба выходим на рынок. И нтересно чей продукт купят? При этом этого 1 Мбайта в памяти ни кто не заметит. Упаковка exe значительно упрощает распостранение программ, при нынешних мощностях вычислительной техники заботиться об 1Мб памяти это просто смешно. У нас половина программ народ пишит когда при старте грузит в память все формы при этом программы в памяти занимают ужас сколько.

ну вообщем-то а смысл поковать 2мб и преврать их в 1мб ? по мне так разницы не какой темболее если речь идёт о 20 мб которые мона в мегов 18 превратить.
размер критичен тока для вирусов и троянов а для нормальных приложений он имхо не важен))
насчёт покупателей то покупатель выберет то приложение которое лучше работает поэтому надо старатся чтобы твоё приложение было лучше чем у твоего конкуретна)
и мало кто ведётся на мелкий размер скорее даже я знаю многих которые подумалибы что за нах чё оно такое маленькое хорошоя прога не может быть такой мелкой и выбралибы 1мб =))))
а насчёт заботится об памяти имхо 1мб ни что но всёже когда можно всеголишь не упоковав приложение спасти его то это номано) а если все начнут поковать и так по одному мб......
а то что многие пишут приложения которые и так расходуют памяти немерено из-за кривости то это уже их роблемы.

Это все безполезный спор из разряда "На вкус и цвет ..."

Что касается скорости, то это вопрос спорный, трудно поддающийся измерению. Думаю что разница в скорости загрузки конечно есть, но ее величина, особенно абсолютная, не настолько велика чтобы тратить время на ее определение. Единственное когда эта разница может быть существенной, так это при запуске программы с медленных носителей, таких как FDD и Flash-диски. Первые наверное уже врядли интересны, а вот вторые, как мне кажется, последнее время становятся более актуальными.

Что касается размера, то тут опять-же, все зависит от носителя. Конечно, при хранении программы на HDD, размер не имеет значения. Но, вот например у меня есть комерческая программа, которая после ужимания может работать с FDD. Причем, есть потребители которые ее так используют. Хотя конечно это скорее исключение чем правило.
Для Flash-дисков, размер опять же наверное не так существенен - их удельная стоимость снижается гиганскими темпами.
Ну и конечно размер может иметь значение при дистрибуции. Особенно если она осуществляется по интернету - широкополосный интернет пока еще доступен далеко не всем.

Что касается UPX | ASPack | .... Опять же вопрос личных пристрастий. Хотя, лично я отказался от использования UPX. Я уже когда-то писал что столкнулся с серьезной проблемой при его использовании. С тех пор пользую AsPack - пока (года 3) проблем не было и у меня, ни у моих клиентов.
Добавлено @ 14:01
Да, совсем забыл.
О занимаемой памяти ужатыми DLL. Конечно, как уже кто-то здесь писал, памяти такой процесс будет занимать больше. Но, не забывайте, речь идет о виртуальной памяти. Поэтому, использование реальной физической памяти опять же будет сильно зависить от постороения программы, алгоритмов ее работы, текущего режима использования, ...
Так что здесь тоже все не так просто и однозначно .

Я думаю, если хорошо знаешь API, ассемблер не понадобится.

процесс сжатия идёт, но файл не сжимается

Добавлено @ 14:36 

я сравнивал - у меня противоположный результат (проект на D7 был)