On Tue, Nov 28, 2000 at 09:21:03PM -0800, Stephan T. Lavavej wrote:
> Packed executables also have an advantage on networked systems: they can be
> transmitted to other computers faster, thereby creating the illusion of
> increased startup speed.
Be careful; this idea may end up backfiring on you. On Windows NT (and other
sensible operating systems), executable files are not completely loaded into
memory at once on program startup. A memory "section" is set up which is an
area of virtual memory backed by the actual executable image on disk. As the
CPU executes the startup code of the executable, 4kB pages are demand-paged in
as they are touched. There is usually some prefetching and such going on too,
but that doesn't affect the point here. The point is that parts of the
executable that are not touched on startup are never actually loaded from disk
until they are used.
When running a packed executable, the first thing the unpacker stub must do is
read the whole (packed) executable file and write the unpacked version
somewhere. This unpacked version might end up in a file on disk, or it might be
in memory, which is backed by the system paging file. So, on startup you end up
touching the entire packed executable, plus you need to write the whole
unpacked version to either memory or disk.
These executable packing programs have been around for a while, I remember
PKWare had a DOS program called PKLite at least 10 years ago that did much the
same thing as UPX. In the long run, download bandwidth doesn't matter (how
often do you download new binaries, anyway?), and disk space is too cheap to
worry about (executables aren't a major consumer of disk space). You're not
really saving anything. Let the operating system do what it's best at.
Greg Hewgill
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
