主页
Top.Mail.Ru Yandeks.Metrika
论坛:“抢”;
当前存档:2003.09.01;
下载:[xml.tar.bz2];

向下

ASPack等...... 找到类似的分支


Region   (2003-08-10 20:27) [0]

Есть ли какие-то побочные эффекты при использовании программ типа ASPack (то есть, например, сжатая программа где-то не запустится).
И какую из программ подобного типа использовать наиболее эффективно?

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



Dred2k   (2003-08-10 20:34) [1]

Оттестируй и увидишь все эффекты.
Какая лучше - не знаю, upx иногда пользую. Вообще, при таком подходе ничего хорошего, только памяти больше отжирается. Тем более, что прошли те времена, когда от прикладух еше и размер минимальный требовался. Если думаешь, что от взлома защитит - ты ошибаешься. Баловство все это ;)



Region   (2003-08-10 20:35) [2]

Мне от взлома защищаться не надо, исключительно размер уменьшить.
А какие "все эффекты" я должен увидеть? Только ли увеличение требовательности к ресурсам?



Dred2k   (2003-08-10 20:44) [3]

"Все эффекты" - это все возможные ошибке при запуске упакованного модуля у тебя на тачке. Ничего такого, влияющего на запуск на "других тачках", упаковщики не делают.



Anatoly Podgoretsky   (2003-08-10 20:46) [4]

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



Ketmar   (2003-08-10 20:56) [5]

2Anatoly Podgoretsky © (10.08.03 20:46) :
а цель, например -- быстрее даунлоадится. тем более, что сжимает UPX однако весьма лучше зипа...



k-man   (2003-08-10 21:37) [6]

Побочный эффект это наличие распаковщиков которые появляются вслед за самим протектером Солодовникова. В результате он становится бесполезен.



nikkie   (2003-08-10 21:56) [7]

>а цель, например -- быстрее даунлоадится. тем более, что сжимает UPX однако весьма лучше зипа...
Если это цель, то неужели нет архиватора, который сжимает не хуже UPX и умеет делать SFX?

Вообще, при таком подходе ничего хорошего, только памяти больше отжирается.
就是这样。



Best Guns   (2003-08-10 22:01) [8]

Я не верю, что какой-либо exe упаковщик сожмет лучше RAR"а (не sfx, конечно)



Ketmar   (2003-08-10 23:03) [9]

> nikkie©(10.08.03 21:56)
любой .exe-упаковщик лучше рара. потому что не нужны дополнительные шаги после скачивания. скачал -- и наслаждаешься. рар (а 7zip вкуснее %-) -- это для пакетов. одиночные файлы... фу. неизящно.



Ketmar   (2003-08-10 23:05) [10]

и ещё. не смущайте народ. если запускается ОДНА копия программы, то ни разу не больше. ну немножко ломается механизм подкачки из PE, и PE вынуждены укладывать ровными рядами в своп, вместо того, чтобы сразу читать. в итоге несколько тормозно при первом отсвопливании. реально -- кто заметит? распаковщик же юпх НЕ ТРЕБУЕТ для распаковки дополнительной памяти. выравнивания на 4 кб не считаем -- это не размеры.



Morfein   (2003-08-10 23:34) [11]

Между прочим недавно попалась проблема... программа, сжатая UPX"ом не запустилась на компе с системой WinXP и каким-то там последним (по утверждению владельца) сервиспаком. Совершенно не запустилась. И никаких сообщений об ошибках.



Ketmar   (2003-08-11 00:14) [12]

ну, хреновый релиз -- та ещё дура. ребята как всегда решили "улучшить" запускалку и, кажется, менеджер мозгов, а в итоге наплодили мелких, но неприятных багов. это раз.
два: небось юпх был еще тех времён, когда предки в мамонтов камнями кидались?



Dimaxx   (2003-08-11 00:51) [13]

У меня в ХР любая с Upx запускалась. И никаких глюков...



nikkie   (2003-08-11 01:39) [14]

>凯特玛
если запускается ОДНА копия программы, то ни разу не больше.
Ну если одна, то почти соглашусь. Сам же говоришь - тормозит при запуске. И память отжирает сразу по полной...

>небось юпх был еще тех времён, когда предки в мамонтов камнями кидались?
А это влияет??? И что же будет с программой, упакованной современным юпх, когда потомки на звездолетах летать будут?

>фу. неизящно.
Ну вот и нашлась истинная причина. ;)



Ketmar   (2003-08-11 01:48) [15]

> nikkie©(11.08.03 01:39)
>Ну если одна, то почти соглашусь. Сам же говоришь - тормозит при запуске. И память отжирает сразу по полной...
ну так утиль размером в десятки мегабайт никто и не жмёт. а софтину на 100 кило, чтобы она стала 30 кило -- отчего бы и не пожать?

>А это влияет???
вот будешь громко смеяться, но развитие ИТ не стоит на месте. появляются новые системы, у них -- новые баги. правятся старые баги. и так далее. а то что же ты, пардон, на дельфи 2 не пишешь? это же не влияет? и что будет с твоим софтом на д5/д6, когда потомки... (и так далее).

>Ну вот и нашлась истинная причина. ;)
а чем плоха? причина как причина. не хуже любой другой. %-)



nikkie   (2003-08-11 02:05) [16]

>вот будешь громко смеяться, но развитие ИТ не стоит на месте...
что-то я такое подозревал... :)
ты только на мой вопрос не ответил
>И что же будет с программой, упакованной современным юпх, когда потомки на звездолетах летать будут?

>ну так утиль размером в десятки мегабайт никто и не жмёт. а софтину на 100 кило, чтобы она стала 30 кило -- отчего бы и не пожать?
ок, резюмируем: Ketmar одобрил сжатие upx-ом программного продукта, состоящего из 1 exe-файла (если файлов несколько - то рекомендуется использовать архиватор), размером порядка 100 килобайт, если предполагается, что она не будет запускаться в нескольких экземплярах. цель этого мероприятия - забота о юзере, который скачает ее на плохонькой линии за 10 секунд, а не за 30...



nikkie   (2003-08-11 02:07) [17]

да, забыл смайлик добавить...
:))
наезда никакого не подразумевалось...



Ketmar   (2003-08-11 02:55) [18]

> nikkie©(11.08.03 02:05)
>ты только на мой вопрос не ответил
а как я тебе отвечу-то? я что, пророк Ивасик? %-)

>цель этого мероприятия - забота о юзере, который скачает ее на плохонькой линии за 10 секунд, а не за 30
на...ть на юзера. аплоадить мне быстрее %-))

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

да понял я, понял. не параноик. по крайней мере, еще не окончательно. %-)



y-soft   (2003-08-11 06:36) [19]

>Morfein © (10.08.03 23:34)

Между прочим недавно попалась проблема... программа, сжатая UPX"ом не запустилась на компе с системой WinXP и каким-то там последним (по утверждению владельца) сервиспаком. Совершенно не запустилась. И никаких сообщений об ошибках.

Наблюдал аналогичный эффект, но с Aspack. Не разбираясь, перешел на UPX 1.24. - глюк исчез

Также сталкивался с невозможностью использования сжатых ресурсов в формате HTML...



k-man   (2003-08-11 07:20) [20]

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



nikkie   (2003-08-11 13:45) [21]

> на...ть на юзера. аплоадить мне быстрее %-))
Зачем же тогда аплоадить, если на юзера на...ть??? ;)
А я думал, что народ выкладывает свои произведения исключительно из заботы о юзере. Шоб ему бедному просветления достичь при помощи этих 30К.



Camus   (2003-08-11 14:10) [22]

> Ketmar © (10.08.03 23:05) [10]

> распаковщик же юпх НЕ ТРЕБУЕТ для распаковки дополнительной
>记忆

Так утверждает его разработчик - это да. Но тогда непонятно вот что.

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

Если второе, то все ясно - рекламный трюк и ничего более. А если же первое, то еще один момент - как динамическая распаковка дружит с маппингом самой системы? Видимо, подружить их можно, но, опять же, ценой дополнительного кода, который тоже съедает и память, и скорость.

Вывод - неизбежны либо потери памяти, либо потери скорости, дибо и то и другое вместе. Чудес не бывает.

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



Ketmar   (2003-08-11 16:36) [23]

> k-man©(11.08.03 07:20)[20]
а вот прекращаем путать пакеры и криптеры, да?

> nikkie©(11.08.03 13:45)[21]
неправильно думал. выкладывают, чтобы пухнуть от гордости: вот, и я в сети своё выложил!

>Camus © (11.08.03 14:10) [22]
>Так утверждает его разработчик
да, Маркус так и утверждает. поскольку использованные методы расписаны подробно, я не имею основания сомневаться. на крайний случай можно посмотреть код распаковщика.

>Если дополнительной памяти действительно не требуется, значит распаковка идет по тому же адресу. Поскольку распакованный код занимает места, естественно, больше, чем запакованный, значит полностью на то же самое место он никак не влезет.
а подумать, прежде чем писать -- ни-ни? (без обид, плиз %-) очевидно же, что дополнительная память (сиречь буфера всякие, места для деревьев, и ты ды) не требуется РАСПАКОВЩИКУ. про распаковываемые данные ни слова. что и верно: как это можно распаковать в тот же объем, который занимали запакованные? это уже не компрессия, это издевательство получается %-)
для примера: BWT-декомпрессор, например, требует много дополнительной памяти для распаковки (помимо памяти для данных). а вот LZ77 -- не требует никакой. теперь стало яснее?

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



Ketmar   (2003-08-11 16:36) [24]

> k-man©(11.08.03 07:20)[20]
а вот прекращаем путать пакеры и криптеры, да?

> nikkie©(11.08.03 13:45)[21]
неправильно думал. выкладывают, чтобы пухнуть от гордости: вот, и я в сети своё выложил!

>Camus © (11.08.03 14:10) [22]
>Так утверждает его разработчик
да, Маркус так и утверждает. поскольку использованные методы расписаны подробно, я не имею основания сомневаться. на крайний случай можно посмотреть код распаковщика.

>Если дополнительной памяти действительно не требуется, значит распаковка идет по тому же адресу. Поскольку распакованный код занимает места, естественно, больше, чем запакованный, значит полностью на то же самое место он никак не влезет.
а подумать, прежде чем писать -- ни-ни? (без обид, плиз %-) очевидно же, что дополнительная память (сиречь буфера всякие, места для деревьев, и ты ды) не требуется РАСПАКОВЩИКУ. про распаковываемые данные ни слова. что и верно: как это можно распаковать в тот же объем, который занимали запакованные? это уже не компрессия, это издевательство получается %-)
для примера: BWT-декомпрессор, например, требует много дополнительной памяти для распаковки (помимо памяти для данных). а вот LZ77 -- не требует никакой. теперь стало яснее?

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



dataMaster   (2003-08-11 16:41) [25]

У меня с ASPack"ом была такая хрень. Сжатая программа не запускалась с CD, а не сжатая запускалась. Ошибку сообщения Windows не помню, но с того момента я больше не пользуюсь EXE-упаковщиками.



Camus   (2003-08-11 17:47) [26]

> Ketmar©(11.08.03 16:36)[24]
> теперь стало яснее?

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

Заметьте - речь идет о памяти, требуемой для размещения самого кода. О всяких там служебно-вспомогательных структурах речь даже и не идет. И даже в этом случае получается - либо нужна дополнительная память, либо теряем скорость на динамической распаковке.

И обойти это, IMHO, невозможно - ну нельзя залить бочку пива в бутылку за раз. Либо порциями, либо в много бутылок.

Так что - не стало яснее.



Ketmar   (2003-08-11 18:08) [27]

хорошо. скажу так: распаковщику не требуется памяти больше, нежели занимала оригинальная программа перед упаковкой (что и имел в виду автор). теперь лучше? %-)



k-man   (2003-08-11 18:14) [28]

> а вот прекращаем путать пакеры и криптеры, да?

Насколько я знаю Aspack то криптер-протектер, а программы которые возвращают кзешник в первозданный вид называются распаковщиками.
Пример Caspr 1.1 распаковывает ASpack 1.1 & 1.2 но не все



Ketmar   (2003-08-11 18:23) [29]

а у нас там речь об UPX шла, вообще-то %-))



Camus   (2003-08-11 18:30) [30]

> Ketmar © (11.08.03 18:08) [27]

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

Вероятно, автор всего лишь имел в виду, что, выделяя память при распаковке, он сразу запрашивает памяти столько, сколько нужно для размещения уже распакованного кода, затем грузит в нее сжатый код и распаковывает его "по месту". С этим действительно согласиться вполне можно (с оговоркой, что такое решение просто напрашивается и поэтому вряд ли можно считать его "ноу-хау"). Но вот согласиться с утверждением, что не требуется 大体 никакой дополнительной памяти, IMHO, нельзя.



Ketmar   (2003-08-11 19:22) [31]

>Camus © (11.08.03 18:30) [30]
я уже выше приводил примеры распаковщиков. а ну-ка разожмите BZIP2-архив (да даже просто зип) без дополнительной памяти.
уточню окончательно: место на декодер тоже в счёт не входит. так: при условии, что в декодере не "прошито" никаких статических буферов, декодер НЕ БУДЕТ запрашивать дополнительную память у системы для распаковки "in-place".

ZYZH
что-то я сегодня слабо соображаю, никак не могу сформулировать %-)



k-man   (2003-08-11 19:51) [32]


> а у нас там речь об UPX шла, вообще-то %-))

в обще у всякого тописка есть сабж :-)



Region   (2003-08-11 19:55) [33]

主啊!
Ну так ответьте мне на вопрос, пользоваться пакерами или нет? Если преследуется такая цель: выложить два ехе-шника по 600 кб в инет?



Region   (2003-08-11 19:58) [34]


> в обще у всякого тописка есть сабж :-)

В сабже есть etc, а в первом сообщении есть "типа". Так что UPX тоже под сабжем.



Ketmar   (2003-08-11 20:16) [35]

>Region © (11.08.03 19:55) [33]
нет. запакуй нормальным зипом.



Region   (2003-08-11 23:49) [36]

谢谢你的建议



Страницы: 1 整个分支

论坛:“抢”;
当前存档:2003.09.01;
下载:[xml.tar.bz2];

楼上









内存:0.71 MB
时间:0.064 c
1-1420
丽娜
2003-08-19 14:49
2003.09.01
ini文件


14-1559
Mr&MsGuns
2003-08-11 18:59
2003.09.01
图书馆创作


1-1430
VEB
2003-08-16 14:13
2003.09.01
组件容器


3-1279
阿列克谢佩图霍夫
2003-08-11 10:03
2003.09.01
BDE中的DecemalSeparator


1-1412
gsus
2003-08-13 20:22
2003.09.01
QuickReport





南非荷兰语 阿尔巴尼亚人 阿拉伯语 亚美尼亚 阿塞拜疆 巴斯克 白俄罗斯 保加利亚语 加泰罗尼亚 简体中文 中国(繁体) 克罗地亚 捷克 丹麦语 荷兰人 英语 爱沙尼亚语 菲律宾人 芬兰 法文
加利亚西语 格鲁吉亚语 德语 希腊语 海地克里奥尔语 希伯来语 印地语 匈牙利 北日耳曼语 印度尼西亚人 爱尔兰语 意大利语 日本性玩偶 韩语 拉脱维亚 立陶宛 马其顿 马来语 马耳他语 挪威语
波斯语 波兰语 葡萄牙语 罗马尼亚 俄语 塞尔维亚 斯洛伐克 斯洛文尼亚 西班牙语 斯瓦希里 瑞典语 泰国人 土耳其 乌克兰 乌尔都语 越南人 威尔士语 意第绪语 孟加拉 波斯尼亚
宿务 世界语 古吉拉特语 豪萨语 苗族 伊博 爪哇 卡纳达语 高棉 老挝 拉丁语 毛利 马拉 蒙古人 尼泊尔 旁遮普 索马里 泰米尔人 泰卢固语 约鲁巴语
祖鲁
英文 Французский Немецкий Итальянский Португальский 俄文 Испанский