Иконка

← →
Sergo (2002-07-09 11:33) [0]

А почему после сжатия ASPack"ом исчезает иконка из экзешника, которую я ранее вставил при создании проги?

← →
Александр (2002-07-11 15:27) [1]

Глюк. попробуйте сжать UPX. Если понадобиться- напишите мне на мыло

← →
Eugene Lachinov (2002-07-11 17:26) [2]

Если есть, поставь режим сжимать все ресурсы, кроме первой иконки

← →
Александр (2002-07-11 19:56) [3]

:) А еще лучше пиши на API.

← →
Eugene Lachinov (2002-07-11 19:59) [4]

>Александр
Такой режим есть в Petite - аналог ASPack

← →
Юрий Зотов (2002-07-12 02:11) [5]

А зачем вообще сжимать?

Выигрыш - в размере Exe. Проигрыш (причем ОЧЕНЬ сильный!) - в размере требуемой памяти и в скорости.

Емкость винтов - десятки Гб, так что выигрыш в размере Exe почти не заметен.

Емкость памяти - в сотни раз меньше, так что проигрыш в памяти НАМНОГО ощутимее. А для системы еще и НАМНОГО важнее.

Чтобы не сломали? Ерунда - давно написаны распаковщики для AsPack и ему подобных. И постоянно пишутся новые.

Так зачем вообще сжимать?

← →
Елена (2002-07-12 10:46) [6]

Юрий, разработчик программы ASPack пишет:

"Do compressed files load faster or slower?
In most cases programs load faster, because they are smaller and require fewer disk accesses to load the executable image. Decompression is very fast".

Вы бы с ним поспорили? :o)

← →
Johnmen (2002-07-12 10:56) [7]

>Елена © (12.07.02 10:46)

Если не верите Юрий Зотов © (12.07.02 02:11),
то поверьте хотя бы здравому смыслу !

← →
Anatoly Podgoretsky (2002-07-12 11:15) [8]

Особенно серьезен прогирыш для dll они проецируются в память и используются многими программами

← →
Елена (2002-07-12 12:31) [9]

Johnmen, получается, что программист, написавший эту программу, не в ладах со здравым смыслом? :o)

← →
RV (2002-07-12 13:35) [10]

2Елена ©
Здравый смысл - получить деньги

← →
Johnmen (2002-07-12 14:14) [11]

>Елена ©

А вы правильно перевели приведенное вами утверждение ?
Во-первых - в большинстве не означает во всех
во-вторых - загрузка сжатого+декомпрессия не обязательно < загрузки оригинального
Просто авторы пытаются сэкономить место на диске (ха-ха) и увеличить скорость загрузки за счет уменьшения времени дисковых операций на чтение. Ну допустим они выиграют 0.33 секунды на вашем приложении. И что ? Это, типа, рулез ? Лично для вас ?

← →
Malder (2002-07-12 15:13) [12]

Юрий Зотов
давно написаны распаковщики для AsPack

Можно ссылочку ?

← →
Юрий Зотов (2002-07-13 01:14) [13]

> Елена © (12.07.02 10:46)

Лена, разработчик лукавит. Он, безусловно, ОЧЕНЬ сильный программист и прекрасно знает механизм работы виндов с Exe-файлами. Но он заинтересован в продвижении своей программы, поэтому так и говорит. На самом же деле все более чем спорно.

Вкратце и очень грубо ("на пальцах") дело обстоит примерно так.

В Win32 запущенный Exe-файл становится как бы частью памяти, которую сам же и использует использует при своей работе. Но расположена эта "память" на диске, в виде самого Exe-файла (нечто вроде swap). В виртуальном адресном пространстве процесса система выделяет область, равную размеру его дискового Exe-файла и сопоставляет эту область с самим Exe-файлом (проекция, отображение, file mapping), а далее Exe-файл рассматривается, как эта область памяти и используется для подкачки страниц в физическую память - откуда уже и исполняется непосредственно. Причем для процессоров x86 размер такой страницы - всего 4К, поэтому подкачка происходит довольно часто (конечно, страницы система кэширует, но тем не менее).

Именно так Win32 работает с Exe-файлами. И ничего другого она делать с ними просто не умеет. Поэтому, если Exe хочет быть выполненным, он обязан подстраиваться именно под этот механизм, и ни под какой другой. Запомним это и пойдем дальше.

Если файл не компрессован, то страница просто подгружается - и все, она готова к работе. А если компрессован? То не готова, ее сначала нужно распаковать. А кто это сделает? И куда распакует?

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

Итак, чтобы компрессованный код мог быть выполнен, в памяти его в любом случае надо распаковать. Вот они где, потери времени. Не на ЗАГРУЗКУ, а на РАСПАКОВКУ во время ВЫПОЛНЕНИЯ - что гораздо важнее. Хотя разработчик и пишет, что распаковка очень быстрая, но она, тем не менее, существует и скорость гробит, никуда от этого не денешься.

Но помимо потерь в скорости, это еще и потери памяти. Потому что система подгружает ЗАПАКОВАННЫЙ ОБРАЗ кода, выполнить который сразу нельзя - а для его распаковки нужна дополнительная память (и совсем не маленькая, а точно равная размеру обычного, незапакованного кода). Об этом разработчик вообще умалчивает - а это уже явное лукавство.

Что же касается утверждения, что маленькие Exe грузятся быстрее, то оно ложно и рассчитано, извините, на дилетантов. Дело в том, что Exe и DLL полностью ВООБЩЕ НИКОГДА НЕ ГРУЗЯТСЯ. Они ПРОЕЦИРУЮТСЯ - то есть, просто сопоставляются начальная и конечная точки (и понятно, что размер файла на скорость этой операции никак не влияет). Физически же в любом случае грузится лишь страница - те самые 4К. Поэтому такое утверждение - тоже лукавство разработчика.

Вот, попробовал изложить, как сумел. Если кому стало интересно - в журнале "Программист" была отличная статья на эту тему. Автор - Крис Касперски. Номера журнала, к сожалению, не помню, а под рукой его сейчас нет, поэтому могу лишь посоветовать зайти на сайт журнала (www.programme.ru) - там были архивы.

Что же касается ссылок на распаковщики для AsPack и прочие, то это не ко мне, это на хакерские сайты. Я совершенно точно знаю, что такие программы давно существуют, но их распространением не занимаюсь.

← →
Malder (2002-07-13 01:31) [14]

просто искал на "хакерских" сайтах и не нашел...
ну да ладно, как-нибудь в другой раз =)

← →
MJH (2002-07-13 03:08) [15]

2Юрий Зотов © (12.07.02 02:11)

А зачем вообще сжимать?
Выигрыш - в размере Exe. Проигрыш (причем ОЧЕНЬ сильный!) - в размере требуемой памяти и в скорости.

не всегда....писал эквалайзер для звуковушки на винАПИ....80 килобайт ЕХЕшник....до 36 сжался....проигрыш в занимаемой памяти - 30 килобайт из 2300....

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

[0.74XPbeta2]Brooklyn Bounce - Club Bizarre

← →
SerGa (2002-07-13 03:37) [16]

Имел эффект от сжатия, правда не файлов, а самого диска, только тогда, когда поставил N лет назад "мамку" DX4 на компьютер с винчестером 112 МВ. Но и Win3.1 работал тогда иначе!

← →
MJH (2002-07-13 03:46) [17]

эсжатие ЕХЕ и дисков - это совершенно разные вещи

← →
MrBeer (2002-07-14 03:35) [18]

To Юрий Зотов:

prezhde chem govoritj chto kompressori uvelichivajut trebovanie k pamyati posmotrite kak ustroen UPX.

Best regards.

← →
Юрий Зотов (2002-07-14 03:47) [19]

Ну и как же он устроен? Разъясните уж, пожалуйста.

← →
SerGa (2002-07-14 04:38) [20]

> MJH © (13.07.02 03:46)
Сжатие exe и дисков - действительно разные вещи. Однако "эффект" был только тогда, когда я написал. А точнее в Win 3.1.x.

← →
Anatoly Podgoretsky (2002-07-14 13:00) [21]

SerGa © (14.07.02 04:38)
Эффект от сжатия диска был точно, в два три раза как обещалось, но при этом теми же словами обещали и ускорение, мол диск медленное устройство, по сранению с память и т.д.
Но что на самом деле было мы помним, но там по крайней мере было честно, не сжатие в чистом виде, а другая файловая система со сжатием, прозрачная для среды, по этому все программы работали не замечая этого, кроме естественно программ обслуживания дисков и это тоже понятно, ведь физического диска то не было

← →
Nikolay (2002-07-14 16:17) [22]

MrBeer © (14.07.02 03:35) после этого фразы хочется ссылочку что бы почитать....

← →
MrBeer (2002-07-14 22:09) [23]

UPX is a free, portable, extendable, high-performance executable packer for several different executable formats. It achieves an excellent compression ratio and offers very fast decompression. Your executables suffer no memory overhead or other drawbacks.

Kompressia postroena na ihnei biblioteke NRV:
NRV is a portable lossless data compression library written in C++. It offers pretty fast compression and very fast decompression. Decompression requires no memory. NRV requires no additional memory for decompressing. NRV supports in-place decompression.

Bolshe informacii + sources na saite razrabotchikov - http://upx.sourceforge.net/

Best regards.

← →
Юрий Зотов (2002-07-15 01:48) [24]

> Mr.Beer

Итак, разработчики UPX утвеждают, что:

1. "...very fast decompression".
2. "Decompression requires no memory".

Но возникает вопрос. Даже если не принимать во внимание, что речь идет об исполнимом коде, то распаковывать в самом принципе можно либо на внешний носитель (диск и пр.), либо в память - ничего третьего человечество пока не придумало. Если на внешний носитель, то, очевидно, о "very fast decompression" и говорить не приходится - по сравнению с памятью и CPU все это очень медленные устройства. Если же в память, то непонятно, каким образом удалось реализовать "requires no memory". Потому что распаковывать "по месту" никак не получится (длина распакованного кода всегда больше, чем запакованного), а для распаковки "не по месту" эта самая memory все-таки required.

Движимый любопытством, я зашел по указанной Вами ссылке, надеясь найти хотя бы поверхностное описание того метода, с помощью которого разработчикам удалось разрешить это противоречие. Но не нашел. То есть, УТВЕРЖДЕНИЙ "very fast" и "requires no memory" нашел не одно, а вот их ДОКАЗАТЕЛЬСТВ - не нашел.

Если плохо искал, то, пожалуйста, подскажите, где же они там изложены. А если хорошо искал, то, значит, их там и нет.

И я пока что склоняюсь ко второму. Потому что знаю, что слов можно говорить сколько угодно, но чудес на свете все-таки не бывает.

А в своих оппонентах (в данном случае, в Вас) мне очень хотелось бы видеть ДОКАЗАТЕЛЬНОЕ отношение к дискуссии. А не просто заявления, основанные на пока что неподтвержденных, но зато противоречащих здравому смыслу чужих словах (к тому же, словах заинтересованных лиц).

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

Чего жду и от Вас. Мне очень хотелось бы знать, каким же это способом при распаковке удается осуществить "very fast" и "requires no memory" ОДНОВРЕМЕННО.

← →
MJH (2002-07-15 02:14) [25]

2Юрий Зотов

распаковывать в самом принципе можно либо на внешний носитель (диск и пр.),

видел какой-то плеер, вроде Blaze, так он свой ЕХЕшник на винт распаковывает....

← →
MrBeer (2002-07-15 02:39) [26]

Юрий Зотов:

How can I reduce memory requirements when (de)compressing ? =========================================================== If you cleverly arrange your data, you can do an overlapping (in-place) decompression which means that you can decompress to the *same* block where the compressed data resides. This effectively removes the space requirements for holding the compressed data block. This technique is essential e.g. for usage in an executable packer.

← →
MrBeer (2002-07-15 02:41) [27]

Юрий Зотов:

P.S. Posmotrite source biblioteki LZO.

← →
MrBeer (2002-07-15 02:52) [28]

lzo-1.08.tar.gz/lzo-1.08/examples/overlap.c

← →
Юрий Зотов (2002-07-15 11:44) [29]

> MJH
О чем я и говорил. Или винт уже перестал быть внешним носителем?

> MrBeer
Снова - о чем я и говорил. Распаковка "по месту", очевидная вещь. Да, она позволяет сильно сократить потребности в дополнительной памяти - но не позволяет избежать их совсем. Потому что длина распакованных данных всегда больше, чем запакованных и на то же самое место они полностью просто не уместятся. О чем и пишется - "reduce memory requirements", а вовсе не "requires no memory". И потребность в дополнительной памяти все равно будет высокой (не менее, чем разность в длинах сжатого и несжатого кода). И чем выше степень компрессии - тем больше дополнителтной памяти потребуется при распаковке. Чудес не бывает.

Так что пока все остается в силе.

← →
Sergo (2002-07-15 12:01) [30]

Ух ты!!! Несколько дней не был, а сколько ответов - спасибо!

← →
MrBeer (2002-07-15 21:14) [31]

Юрий Зотов:

Ya tak ponimaju chto source vi ne smotrelji? Esli bi smotreli togda uvidelji bi chto zapakovanii budet trebovatj stolko zhe pamyati skolko nepakovanii.

P.S. Esli vi tak uverenni v svoei pravote v poslednei instancii, napishite avtoru.

← →
Oleg_Gashev (2002-07-16 01:37) [32]

>MrBeer

>zapakovanii budet trebovatj stolko zhe pamyati skolko nepakovanii.

Вот и нет. Запустил я свою программу с UPX и без UPX. Все время работы программы(!!!!) Task Manager выдавал в Mem Usage 2780 и 2700 KB соответственно. Разница хоть в 80 KB, новсе же есть.

← →
MrBeer (2002-07-16 01:51) [33]

>Oleg_Gashev

eto uzhe unpacker sidit v pamyati, etot overhead neizbezhen.

← →
Юрий Зотов (2002-07-16 02:27) [34]

> etot overhead neizbezhen.

Вот именно. И что бы Вы ни делали, какие бы алгоритмы запаковки и распаковки ни применяли, ПОТЕРИ ПАМЯТИ И СКОРОСТИ НЕИЗБЕЖНЫ.

Большие, или маленькие - другой вопрос. Но они есть. Просто потому, что существует железное требование - ИСПОЛНИМЫЙ КОД МОЖЕТ БЫТЬ ВЫПОЛНЕН ПРОЦЕССОРОМ ТОЛЬКО В НОРМАЛЬНОМ ВИДЕ.

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

И это вовсе не моя правота "в последней инстанции". Это правота CPU - он НЕ УМЕЕТ выполнять запакованный код. ТОЛЬКО нормальный. Отсюда все и идет, что бы ни утверждали разработчики.

О чем я и говорил с самого начала. Выигрыш - в размере дискового EXE-файла. Проигрыш - в памяти и в скорости. Потому что никакой UPX обмануть CPU не в силах. ПРИНЦИПИАЛЬНО не в силах.

Ну не падает яблоко вверх, понимаете? Сколько его ни уговаривай.

Иконка Найти похожие ветки