From 318b31550d87684992a1495464e57908eaa32066 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A1szl=C3=B3=20Moln=C3=A1r?= Date: Wed, 7 Mar 2007 14:22:37 +0100 Subject: [PATCH 1/2] spelling fixes --- doc/upx.pod | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/upx.pod b/doc/upx.pod index a242aab7..e4591fa0 100644 --- a/doc/upx.pod +++ b/doc/upx.pod @@ -197,7 +197,7 @@ For win32/pe programs there's B<--strip-relocs=0>. See notes below. =head1 OVERLAY HANDLING OPTIONS -Info: An "overlay" means auxiliary data atached after the logical end of +Info: An "overlay" means auxiliary data attached after the logical end of an executable, and it often contains application specific data (this is a common practice to avoid an extra data file, though it would be better to use resource sections). @@ -345,7 +345,7 @@ Extra options available for this executable format: First of all, it is recommended to use B *instead* of B. strip has the very bad habit of replacing your stub with its own (outdated) version. Additionally B corrects a bug/feature in strip v2.8.x: it -will fix the 4 KByte aligment of the stub. +will fix the 4 KByte alignment of the stub. B includes the full functionality of stubify. This means it will automatically stubify your COFF files. Use the option B<--coff> to @@ -380,7 +380,7 @@ Extra options available for this executable format: Introduction Linux/386 support in UPX consists of 3 different executable formats, - one optimized for ELF excutables ("linux/elf386"), one optimized + one optimized for ELF executables ("linux/elf386"), one optimized for shell scripts ("linux/sh386"), and one generic format ("linux/386"). @@ -408,14 +408,14 @@ General user's overview or network I/O. Depending on the statistics of usage and access, and the relative - speeds of CPU, RAM, swap space, /tmp, and filesystem storage, then + speeds of CPU, RAM, swap space, /tmp, and file system storage, then invoking and running a compressed executable can be faster than directly running the corresponding uncompressed program. - The operating system might perfrom fewer expensive I/O operations + The operating system might perform fewer expensive I/O operations to invoke the compressed program. Paging to or from swap space - or /tmp might be faster than paging from the general filesystem. + or /tmp might be faster than paging from the general file system. ``Medium-sized'' programs which access about 1/3 to 1/2 of their - stored program bytes can do particulary well with compression. + stored program bytes can do particularly well with compression. Small programs tend not to benefit as much because the absolute savings is less. Big programs tend not to benefit proportionally because each invocation may use only a small fraction of the program, @@ -424,7 +424,7 @@ General user's overview then compression may win anyway. Currently, executables compressed by UPX do not share RAM at runtime - in the way that executables mapped from a filesystem do. As a + in the way that executables mapped from a file system do. As a result, if the same program is run simultaneously by more than one process, then using the compressed version will require more RAM and/or swap space. So, shell programs (bash, csh, etc.) and ``make'' @@ -513,7 +513,7 @@ The linux/elf386 format decompresses directly into RAM, uses only one exec, does not use space in /tmp, and does not use /proc. -Linux/elf386 is automatically selected for Linux ELF exectuables. +Linux/elf386 is automatically selected for Linux ELF executables. Packed programs will be byte-identical to the original after uncompression. @@ -602,7 +602,7 @@ Extra options available for this executable format: Please read the general Linux description first. The generic linux/386 format decompresses to /tmp and needs -/proc filesystem support. It starts the decompressed program +/proc file system support. It starts the decompressed program via the execve() syscall. Linux/386 is only selected if the specialized linux/elf386 @@ -614,11 +614,11 @@ How it works: For files which are not ELF and not a script for a known "-c" shell, UPX uses kernel execve(), which first requires decompressing to a - temporary file in the filesystem. Interestingly - + temporary file in the file system. Interestingly - because of the good memory management of the Linux kernel - this often does not introduce a noticeable delay, and in fact there will be no disk access at all if you have enough free memory as - the entire process takes places within the filesystem buffers. + the entire process takes places within the file system buffers. A compressed executable consists of the UPX stub and an overlay which contains the original program in a compressed form. @@ -644,7 +644,7 @@ Specific drawbacks: decompression, but you still need it for the full execution time of the program. - - You must have /proc filesystem support as the stub wants to open + - You must have /proc file system support as the stub wants to open /proc//exe and needs /proc//fd/X. This also means that you cannot compress programs that are used during the boot sequence before /proc is mounted. @@ -683,7 +683,7 @@ Notes: - UPX creates as default a suitable executable for CD-Mastering and console transfer. For a CD-Master main executable you could also try - the special option "--boot-only" as descriped below. + the special option "--boot-only" as described below. - Normally the packed files use the same memory areas like the uncompressed versions, so they will not override other memory areas while unpacking. @@ -759,7 +759,7 @@ Benefits: - Better compression (but note that the kernel was already compressed, so the improvement is not as large as with other formats). Still, the bytes saved may be essential for special needs like - bootdisks. + boot disks. For example, this is what I get for my 2.2.16 kernel: 1589708 vmlinux @@ -806,13 +806,13 @@ Extra options available for this executable format: =head2 NOTES FOR WIN32/PE The PE support in B is quite stable now, but probably there are -still some incompabilities with some files. +still some incompatibilities with some files. Because of the way B (and other packers for this format) works, you can see increased memory usage of your compressed files because the whole program is loaded into memory at startup. If you start several instances of huge compressed programs you're -wasting memory because the common segements of the program won't +wasting memory because the common segments of the program won't get shared across the instances. On the other hand if you're compressing only smaller programs, or running only one instance of larger programs, then this penalty is From 9173c10239a14b857d430adcf9a190ad0cdcf953 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A1szl=C3=B3=20Moln=C3=A1r?= Date: Wed, 7 Mar 2007 17:00:18 +0100 Subject: [PATCH 2/2] yet another spelling fix --- doc/elf-to-mem.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/elf-to-mem.txt b/doc/elf-to-mem.txt index f48ce548..f47b5475 100644 --- a/doc/elf-to-mem.txt +++ b/doc/elf-to-mem.txt @@ -57,7 +57,7 @@ Subroutine do_xmap() of src/stub/l_lx_elf.c performs the "virtual execve()" using the compressed data as source, and stores the decompressed bytes directly into the appropriate virtual addresses. -Before transfering control to the PT_INTERP "program interpreter", +Before transferring control to the PT_INTERP "program interpreter", minor tricks are required to setup the Elf32_auxv_t entries, clear the free portion of the stack (to compensate for ld-linux.so.2 assuming that its automatic stack variables are initialized to zero),