mirror of
https://github.com/upx/upx
synced 2025-10-05 19:20:23 +08:00
Spelling fixes.
This commit is contained in:
parent
1345a3cfd3
commit
398fd8028c
|
@ -45,6 +45,6 @@ These symbols can be defined later in C++ using
|
|||
|
||||
linker->defineSymbol("xx", yy)
|
||||
|
||||
This functionality (we could say it's a simple linker) is achived by
|
||||
This functionality (we could say it's a simple linker) is achieved by
|
||||
compiling the assembly into an ELF object file which a little C++
|
||||
module (src/linker.cpp) can interpret and work with.
|
||||
|
|
|
@ -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 auxillary data atached after the logical end of
|
||||
Info: An "overlay" means auxiliary data atached 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).
|
||||
|
@ -616,7 +616,7 @@ How it works:
|
|||
UPX uses kernel execve(), which first requires decompressing to a
|
||||
temporary file in the filesystem. Interestingly -
|
||||
because of the good memory management of the Linux kernel - this
|
||||
often does not introduce a noticable delay, and in fact there
|
||||
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.
|
||||
|
||||
|
@ -656,7 +656,7 @@ Specific drawbacks:
|
|||
|
||||
- Because of temporary decompression to disk the decompression speed
|
||||
is not as fast as with the other executable formats. Still, I can see
|
||||
no noticable delay when starting programs like my ~3 MB emacs (which
|
||||
no noticeable delay when starting programs like my ~3 MB emacs (which
|
||||
is less than 1 MB when compressed :-).
|
||||
|
||||
Extra options available for this executable format:
|
||||
|
|
|
@ -632,7 +632,7 @@ void PackArmPe::pack(OutputFile *fo)
|
|||
|
||||
//OutputFile::dump("x1", ibuf, usize);
|
||||
|
||||
// some checks for broken linkers - disable filter if neccessary
|
||||
// some checks for broken linkers - disable filter if necessary
|
||||
bool allow_filter = true;
|
||||
if (ih.codebase == ih.database
|
||||
|| ih.codebase + ih.codesize > ih.imagesize
|
||||
|
|
|
@ -29,7 +29,7 @@
|
|||
/*************************************************************************
|
||||
// Use the preprocessor to work around
|
||||
// - that the types embedding these enums have to be PODs, and
|
||||
// deriving from an empty base class (which is the ususal C++ way
|
||||
// deriving from an empty base class (which is the usual C++ way
|
||||
// of "importing" enums) does not yield a POD any more
|
||||
// - that older compilers do not correctly perform EBCO
|
||||
**************************************************************************/
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
/*************************************************************************
|
||||
// Use the preprocessor to work around
|
||||
// - that the types embedding these enums have to be PODs, and
|
||||
// deriving from an empty base class (which is the ususal C++ way
|
||||
// deriving from an empty base class (which is the usual C++ way
|
||||
// of "importing" enums) does not yield a POD any more
|
||||
// - that older compilers do not correctly perform EBCO
|
||||
**************************************************************************/
|
||||
|
|
|
@ -717,7 +717,7 @@ void PackW32Pe::pack(OutputFile *fo)
|
|||
|
||||
//OutputFile::dump("x1", ibuf, usize);
|
||||
|
||||
// some checks for broken linkers - disable filter if neccessary
|
||||
// some checks for broken linkers - disable filter if necessary
|
||||
bool allow_filter = true;
|
||||
if (ih.codebase == ih.database
|
||||
|| ih.codebase + ih.codesize > ih.imagesize
|
||||
|
|
|
@ -1190,7 +1190,7 @@ void Packer::relocateLoader()
|
|||
// The workaround is for hdr_buf and hdr_u_len to describe the Elf headers
|
||||
// (typically less than 512 bytes) when .text is passed in, and include
|
||||
// them in the calculation of shortest output. Then the result
|
||||
// this->ph.method will say which [single] method to use for everthing.
|
||||
// this->ph.method will say which [single] method to use for everything.
|
||||
// The Elf headers are never filtered. They are short enough (< 512 bytes)
|
||||
// that compressing them more than once per method (once here when choosing,
|
||||
// once again just before writing [because compressWithFilters discards])
|
||||
|
|
|
@ -108,7 +108,7 @@ section LBZIMAGE
|
|||
|
||||
section LZIMAGE0
|
||||
|
||||
// this checka20 stuff looks very unneccessary to me
|
||||
// this checka20 stuff looks very unnecessary to me
|
||||
checka20:
|
||||
inc edi // change value
|
||||
mov [1 + ebp], edi // store to 0x000000 (even megabyte)
|
||||
|
|
Loading…
Reference in New Issue
Block a user