upx-ucl - 云端在线

程序：

您的姓名

upx - 压缩或扩展可执行文件

概要

UPX [ 命令 [ 选项 ] 文件名...

摘要

可执行文件的终极包装器
版权所有 (c) 1996-2013 Markus Oberhumer、Laszlo Molnar 和 John Reiser
http://upx.sourceforge.net

UPX 是一个可移植的、可扩展的、高性能的可执行打包程序，用于多种不同的
可执行格式。 它实现了出色的压缩比并提供 *非常* 来迅速
减压。 您的可执行文件在大多数情况下都没有内存开销或其他缺点
支持的格式，因为就地解压。

虽然你可以使用 UPX 免费用于非商业和商业可执行文件（对于
详细信息请参见文件 /usr/share/doc/upx-ucl/copyright)，如果您能，我们将不胜感激
信用 UPX 和我们自己在文档中，可能包括对 UPX
主页。 谢谢。

[ 使用 UPX 在没有适当信用的非开源应用程序中被认为不是
政治正确 ;-） ]

免责声明

UPX 绝对没有保证； 有关详细信息，请参阅文件
/usr/share/doc/upx-ucl/版权。

这是第一个生产质量版本，我们计划未来的 1.xx 版本将
向后兼容此版本。

请向作者报告所有问题或建议。 谢谢。

商品描述

UPX 是一个多功能的可执行打包程序，具有以下功能：

- 出色的压缩率：比 zip/gzip 压缩得更好，
使用 UPX 来减少您的发行版的大小！

- 非常快的解压：在古老的 Pentium 10 上大约 133 MiB/秒，
在 Athlon XP 200+ 上大约为 2000 MiB/秒。

- 对于大多数压缩的可执行文件没有内存开销
支持的格式

- 安全：您可以列出、测试和解压可执行文件
此外，压缩和未压缩文件的校验和是
内部维护。

- 通用：UPX 可以打包多种可执行格式：
* 雅达利/托斯
* bvmlinuz/386 [可启动的 Linux 内核]
* djgpp2/coff
* DOS/COM
* DOS/exe
* DOS/系统
* Linux/386
* linux/elf386
* linux/sh386
* ps1/exe
* rtm32/pe
* tmt/亚当
* vmlinuz/386 [可启动的 Linux 内核]
* 虚拟机/386
* watcom/le（支持DOS4G、PMODE/W、DOS32a和CauseWay）
* win32/pe (exe 和 dll)
* arm/pe（exe 和 dll）
* linux/elfamd64
* linux/elfppc32
* 马赫/elfppc32

- 可移植性：UPX 是用可移植的与字节序无关的 C++ 编写的

- 可扩展：由于类布局很容易支持
新的可执行格式或添加新的压缩算法

- 免费：UPX 可以免费分发和使用。 从 0.99 版开始
UPX 的完整源代码在 GNU General Public 下发布
许可证（GPL）！

你现在可能明白为什么我们打电话 UPX 该“全功能包" 可执行打包程序。

指令

压缩
这是默认操作，例如。 UPX 你的文件.exe 将压缩指定的文件
命令行。

解压缩
全部 UPX 支持的文件格式可以使用解压缩 -d 开关，例如。 UPX -d
你的文件.exe 将解压缩您刚刚压缩的文件。

测试
这个 -t 命令测试压缩和未压缩数据的完整性，例如。 UPX -t
你的文件.exe 检查您的文件是否可以安全解压缩。 注意，这个命令
不检查整个文件，只检查程序中将被解压缩的部分
执行。 这意味着您不应使用此命令代替病毒检查程序。

列表
这个 -l 命令打印出一些关于指定的压缩文件的信息
命令行作为参数，例如 UPX -l 你的文件.exe 显示压缩/未压缩
大小和压缩比 你的文件.exe.

配置

-q: 保持安静，抑制警告

-q -q （或 -QQ): 非常安静，抑制错误

-q -q -q （或 -qq): 根本不产生任何输出

- 帮帮我: 打印帮助

- 版: 打印版本 UPX

- 精确的: 压缩时，要求能得到一个字节相同的文件
带选项解压 -d. [注意：这是正在进行中的工作，并非所有人都支持
格式呢。 如果您确实关心，作为一种解决方法，您可以压缩然后解压缩您的
第一次编程 - 任何进一步的压缩 - 解压缩步骤应该产生字节 -
与第一个解压缩版本相比，结果相同。]

[ ...待写... - 输入`UPX - 帮帮我' 目前 ]

压缩 各级 & TUNING

UPX 提供十种不同的压缩级别 -1 至 -9和 - 最好的事物。 默认值
压缩级别是 -8 对于小于 512 KiB 的文件，以及 -7 除此以外。

· 压缩级别 1、2 和 3 非常快。

· 压缩级别 4、5 和 6 实现了良好的时间/比率性能。

· 压缩级别 7、8 和 9 有利于压缩比而不是速度。

· 压缩级别 - 最好的事物 可能需要很长时间。

注意压缩级别 - 最好的事物 对于大文件来说可能有点慢，但是你
在发布程序的最终版本时绝对应该使用它。

实现最佳压缩比的快速信息：

· 尝试 UPX --蛮 我的文件 甚至 UPX --超级野蛮 我的文件.

· 试试看 --overlay=条带 作品。

· 对于 win32/pe 程序有 --strip-relocs=0. 请参阅下面的注释。

覆盖 搬运 配置

信息：“覆盖”是指在可执行文件的逻辑结尾之后附加的辅助数据，
并且它通常包含特定于应用程序的数据（这是一种常见的做法，以避免
额外的数据文件，尽管最好使用资源部分）。

UPX 像许多其他可执行加壳程序一样处理覆盖：它只是复制覆盖
压缩后的图像。 这适用于某些文件，但不适用于其他文件，
取决于应用程序实际访问此叠加数据的方式。

--overlay=copy 复制附加到文件的任何额外数据。 [默认]

--overlay=strip 从程序中剥离任何覆盖而不是
复制它。 请注意，这可能会使压缩
程序崩溃或以其他方式无法使用。

--overlay=skip 拒绝压缩任何有覆盖层的程序。

环境

环境变量 UPX 可以保存一组默认选项 UPX. 这些选项是
首先解释并且可以被显式命令行参数覆盖。 为了
例：

对于 DOS/Windows：设置 UPX=-9 --compress-icons#0
对于 sh/ksh/zsh：UPX="-9 --compress-icons=0"; 出口UPX
对于 csh/tcsh：setenv UPX "-9 --compress-icons=0"

在 DOS/Windows 下设置环境变量时必须使用 '#' 而不是 '='
由于 COMMAND.COM 限制。

并非所有选项在环境变量中都有效 - UPX 会告诉你的。

您可以明确地使用 --无环境 忽略环境变量的选项。

附注 用于 “ 支持的 可执行 FORMATS

附注 用于 雅达利/服务条款
这是 Atari ST/TT 使用的可执行格式，这是基于摩托罗拉 68000 的个人
八十年代末流行的电脑。 支持这种格式只是因为
一位作者的怀旧情绪，没有实际用途:-)。 看
http://www.freemint.de 获取更多信息。

打包后的程序解压后与原程序字节相同。 全部调试
但是，信息将被删除。

可用于此可执行格式的额外选项：

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

附注 用于 BVMLINUZ/I386
与 vmlinuz/i386 相同。

附注 用于 操作系统/通讯系统
明显 UPX 不适用于想要从自身读取数据的可执行文件（例如
Win95/98/ME 附带的一些命令行实用程序）。

压缩程序仅适用于 286+。

打包后的程序解压后与原程序字节相同。

最大未压缩大小：~65100 字节。

可用于此可执行格式的额外选项：

--8086 创建一个可以在任何 8086 CPU 上运行的可执行文件。

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

附注 用于 操作系统/执行程序
dos/exe 代表所有“正常”的 16 位 DOS 可执行文件。

明显 UPX 不适用于想要从自身读取数据的可执行文件（例如
Win95/98/ME 附带的一些命令行实用程序）。

压缩程序仅适用于 286+。

可用于此可执行格式的额外选项：

--8086 创建一个可以在任何 8086 CPU 上运行的可执行文件。

--no-reloc 在 exe 头文件中不使用重定位记录。

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

附注 用于 操作系统/系统
压缩程序仅适用于 286+。

打包后的程序解压后与原程序字节相同。

最大未压缩大小：~65350 字节。

可用于此可执行格式的额外选项：

--8086 创建一个可以在任何 8086 CPU 上运行的可执行文件。

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

附注 用于 DJGPP2/COFF
首先，建议使用 UPX *代替 剥离. 条带非常糟糕
习惯用自己的（过时的）版本替换存根。 此外 UPX 纠正一个
strip v2.8.x 中的错误/功能：它将修复存根的 4 KiB 对齐。

UPX 包括 stubify 的全部功能。 这意味着它会自动存根
您的 COFF 文件。 使用选项 --咖啡 禁用此功能（见下文）。

UPX 自动处理 Allegro 包文件。

不支持 DLM 格式（一种相当奇特的共享库扩展）。

打包后的程序解压后与原程序字节相同。 全部调试
但是，信息和尾随垃圾将被剥离。

可用于此可执行格式的额外选项：

--coff 产生 COFF 输出而不是 EXE。 默认情况下
UPX 保留您当前的存根。

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

附注 用于 LINUX [一般]
介绍

UPX 中的 Linux/386 支持由 3 种不同的可执行格式组成，
一种针对 ELF 可执行文件（“linux/elf386”）进行了优化，一种针对
用于 shell 脚本（“linux/sh386”）和一种通用格式
（“linux/386”）。

我们将首先进行一般性讨论，但请
还可以阅读每种格式的相关文档。

此外，还有对可引导内核的特殊支持 - 请参阅
vmlinuz/386 格式的描述。

一般用户概述

运行一个压缩的可执行程序会占用更少的空间
“永久性”存储介质（如硬盘、软盘、
CD-ROM、闪存、EPROM 等）在一个或多个中获得更多空间
“临时”存储介质（例如 RAM、交换空间、 / tmp目录等）。
运行压缩的可执行文件还需要一些额外的 CPU
循环首先生成压缩的可执行文件，
并在每次调用时解压它。

交易了多少空间？ 这取决于可执行文件，但很多
程序节省了 30% 到 50% 的永久磁盘空间。 多少CPU
有开销吗？ 同样，它取决于可执行文件，但是
解压速度一般至少是每秒几兆，
并且经常受到底层磁盘速度的限制
或网络 I/O。

取决于使用和访问的统计数据，以及相对的
CPU、RAM、交换空间的速度， / tmp目录, 和文件系统存储，然后
调用和运行压缩的可执行文件可以比
直接运行对应的解压程序。
操作系统可能会执行较少的昂贵 I/O 操作
调用压缩程序。 分页进出交换空间
or / tmp目录 可能比从一般文件系统分页更快。
“中型”程序，可访问其大约 1/3 到 1/2
存储的程序字节可以特别好地进行压缩。
小程序往往不会受益太多，因为绝对
储蓄较少。 大型项目往往不会按比例受益
因为每次调用可能只使用程序的一小部分，
但 UPX 在调用之前会解压整个程序。
但在磁盘或闪存存储有限的环境中，
那么无论如何压缩可能会赢。

目前，UPX 压缩的可执行文件在运行时不共享 RAM
就像从文件系统映射的可执行文件那样。 作为一个
结果，如果同一个程序由多个同时运行
过程，然后使用压缩版本将需要更多 RAM 和/或
交换空间。 因此，shell 程序（bash、csh 等）和“make”
可能不适合压缩。

UPX 为 Linux 识别三种可执行格式：Linux/elf386、
Linux/sh386 和 Linux/386。 Linux/386 是最通用的格式；
它容纳任何可以执行的文件。 在运行时，UPX
解压存根重新创建 / tmp目录 原始文件的副本，
然后使用相同的参数（重新）执行副本。
默认情况下，ELF 二进制可执行文件更喜欢 Linux/elf386 格式，
因为 UPX 将它们直接解压到 RAM 中，只使用一个
exec，不使用空间 / tmp目录, 并且不使用 /proc。
底层 shell 接受“-c”参数的 shell 脚本
可以使用Linux/sh386格式。 UPX解压shell脚本
进入低内存，然后映射外壳并传递整个文本
脚本作为带有前导“-c”的参数。

一般好处：

- UPX 可以压缩所有可执行文件，无论是 AOUT、ELF、libc4、libc5，
libc6、Shell/Perl/Python/... 脚本、独立的 Java .class
二进制文件，或者其他什么......
所有脚本和程序都将像以前一样工作。

- 压缩程序是完全独立的。 不需要
任何外部程序。

- UPX 保持您的原始程序不变。 这意味着
解压后，您将拥有一个字节相同的版本，
你可以像 gzip 一样使用 UPX 作为文件压缩器。
[ 请注意，UPX 在内部维护文件的校验和，
所以它确实是一个可靠的选择。 ]

- 因为存根只使用系统调用并且没有链接到 libc 它
应该在任何可以运行 ELF 的 Linux 配置下运行
二进制文件。

- 出于同样的原因，压缩的可执行文件应该在
FreeBSD 和其他可以运行 Linux 二进制文件的系统。
[请发送有关此主题的反馈]

一般缺点：

- 不建议压缩通常有很多
正在运行的实例（如“sh”或“make”），因为
不同的压缩程序将不再共享
流程。

- `ldd' 和 `size' 不会显示任何有用的东西，因为它们都是
看到的是静态链接存根。 从 0.82 版开始，该部分
标头从 UPX 存根中剥离，“大小”甚至没有
识别文件格式。 文件 patch/patch-elfcode.h 有一个
补丁以修复 `size' 和其他使用 GNU BFD 的程序中的这个错误。

一般注意事项：

- 由于 UPX 保持您的原始程序不变，这是有利的
在压缩之前将其剥离。

- 如果您压缩脚本，您将失去平台独立性 -
如果您使用 NFS 挂载磁盘，这可能是一个问题。

- suid、guid 和sticky-bit 程序的压缩被拒绝
因为可能存在安全隐患。

- 出于同样的原因，进行任何压缩是没有意义的
程序 suid。

- 显然 UPX 不适用于想要读取数据的可执行文件
从他们自己。 例如，这可能是 Perl 脚本的问题
访问他们的 __DATA__ 行。

- 如果出现内部错误，存根将中止并退出代码 127。
发生这种情况的典型原因是程序以某种方式
压缩后修改。
运行`strace -o strace.log compression_file' 会告诉你更多信息。

附注 用于 Linux/ELF386
请先阅读一般的 Linux 说明。

linux/elf386格式直接解压到RAM，只用一个exec，不使用
中的空间 / tmp目录, 并且不使用 /proc。

Linux/elf386 被自动选择为 Linux ELF 可执行文件。

打包后的程序解压后与原程序字节相同。

运作方式：

对于 ELF 可执行文件，UPX 直接解压到内存，模拟
操作系统内核在 exec() 期间使用的映射，
包括 PT_INTERP 程序解释器（如果有）。
brk() 由压缩文件中的特殊 PT_LOAD 段设置
可执行本身。 UPX 然后将堆栈擦拭干净，除了
参数、环境变量和 Elf_auxv 条目（这是
/lib/ld-linux.so 的启动代码中的错误需要
2000 年 XNUMX 月），并将控制权转移给程序解释器或
原始可执行文件的 e_entry 地址。

UPX 存根大约 1700 字节长，部分是用汇编程序编写的
并且只使用内核系统调用。 它不与任何 libc 链接。

具体缺点：

- 对于 linux/elf386 和 linux/sh386 格式，您将依赖
RAM 和交换空间来保存所有解压程序
进程的生命周期。 如果您已经使用了大部分交换
空间，那么你可能会用完。 “内存不足”的系统
会变得脆弱。 许多程序在以下情况下无法正常响应
malloc() 返回 0。对于较新的 Linux 内核，内核
可能会决定杀死某些进程以重新获得内存，而您
可能不喜欢内核选择杀死哪个。 跑步
/usr/bin/顶部 是检查交换空间使用情况的一种方法。

可用于此可执行格式的额外选项：

（无）

附注 用于 Linux/SH386
请先阅读一般的 Linux 说明。

底层 shell 接受“-c”参数的 shell 脚本可以使用 Linux/sh386
格式。 UPX 将shell脚本解压到低内存，然后映射shell并通过
脚本的整个文本作为带有前导“-c”的参数。 它不使用空间
in / tmp目录, 并且不使用 /proc。

使用已知 shell 的 shell 脚本会自动选择 Linux/sh386。

打包后的程序解压后与原程序字节相同。

运作方式：

对于 shell 脚本可执行文件（以“#!/”或“#!/”开头的文件）
已知外壳接受“-c ", UPX 解压
将文件放入低内存，然后映射外壳（及其 PT_INTERP），
并将控制权与整个解压文件一起传递给 shell
作为“-c”之后的参数。 已知的 shell 有 sh、ash、bash、bsh、csh、
ksh、tcsh、pdksh。 限制：UPX 不能使用此方法
对于在后面使用一个可选字符串参数的 shell 脚本
脚本中的 shell 名称（例如：“#! / bin / sh的 选项 3\n”。）

UPX 存根大约 1700 字节长，部分是用汇编程序编写的
并且只使用内核系统调用。 它不与任何 libc 链接。

具体缺点：

- 对于 linux/elf386 和 linux/sh386 格式，您将依赖
RAM 和交换空间来保存所有解压程序
进程的生命周期。 如果您已经使用了大部分交换
空间，那么你可能会用完。 “内存不足”的系统
会变得脆弱。 许多程序在以下情况下无法正常响应
malloc() 返回 0。对于较新的 Linux 内核，内核
可能会决定杀死某些进程以重新获得内存，而您
可能不喜欢内核选择杀死哪个。 跑步
/usr/bin/顶部 是检查交换空间使用情况的一种方法。

可用于此可执行格式的额外选项：

（无）

附注 用于 Linux/386
请先阅读一般的 Linux 说明。

通用的 linux/386 格式解压为 / tmp目录 和需要 / proc中 文件系统支持。 它
通过 执行（） 系统调用。

Linux/386 仅在专用的 linux/elf386 和 linux/sh386 无法识别时选择
一份文件。

打包后的程序解压后与原程序字节相同。

运作方式：

对于不是 ELF 且不是已知“-c”shell 脚本的文件，
UPX 使用内核 execve()，它首先需要解压到一个
文件系统中的临时文件。 有趣的是 -
由于 Linux 内核的良好内存管理 - 这
通常不会引入明显的延迟，事实上
如果您有足够的可用内存，则根本无法访问磁盘
整个过程发生在文件系统缓冲区内。

压缩的可执行文件由 UPX 存根和覆盖层组成
其中包含压缩形式的原始程序。

UPX 存根是一个静态链接的 ELF 可执行文件，并且
程序启动时的以下内容：

1) 将覆盖解压到一个临时位置 / tmp目录
2）打开临时文件进行读取
3）尝试删除临时文件并启动（execve）
未压缩的程序 / tmp目录 运用 /过程//fd/X 为
通过步骤 2) 获得
4) 如果失败，分叉一个子进程来清理和
启动程序 / tmp目录 同时

UPX 存根大约 1700 字节长，部分是用汇编程序编写的
并且只使用内核系统调用。 它不与任何 libc 链接。

具体缺点：

- 未压缩的程序需要额外的可用磁盘空间
在您的 / tmp目录 目录。 该程序被立即删除
解压，但在整个执行时间内您仍然需要它
该程序。

- 你必须有 / proc中 存根想要打开的文件系统支持
/过程//exe 和需要 /过程//fd/X。 这也意味着你
无法压缩在引导序列期间使用的程序
before / proc中 已安装。

- 像“top”这样的实用程序将在过程中显示数值
名称字段。 这是因为 Linux 从
最后一个 execve 系统调用的第一个参数（通常是
就像是 /过程//fd/3）。

- 由于临时解压到磁盘的解压速度
不如其他可执行格式快。 还是可以看到
启动程序时没有明显的延迟，比如我的 ~3 MiB emacs（它
压缩时小于 1 MiB :-)。

可用于此可执行格式的额外选项：

--force-execve 强制使用通用的 linux/386 "execve"
格式，即不要尝试 linux/elf386 和
linux/sh386 格式。

附注 用于 PS1/可执行文件
这是基于 Mips R3000 的 Sony PlayStation (PSone) 使用的可执行格式
自 90 年代末以来流行的游戏机。 非常支持这种格式
与 Atari 相似，因为其中一位作者的怀旧情绪。

打包后的程序解压后与原程序字节相同，直到进一步
恕不另行通知。

最大未压缩大小：~1.89 / ~7.60 MiB。

备注：

- UPX 默认为 CD-Mastering 创建一个合适的可执行文件
和控制台传输。 对于 CD-Master 主可执行文件，您还可以尝试
特殊选项“--boot-only”如下所述。
据报道，upx 打包的可执行文件完全兼容
索尼 PlayStation 2（PS2、PStwo）和索尼 PlayStation Portable (PSP)
索尼 PlayStation (PSone) 仿真模式。

- 通常打包文件使用与未压缩文件相同的内存区域
版本，因此它们在解包时不会覆盖其他内存区域。
如果这不可能，UPX 将中止显示“打包数据重叠”
错误。 使用“--force”选项UPX将重新定位加载地址
对于打包文件，但如果它是单个或
主要的可执行文件。

可用于此可执行格式的额外选项：

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--8-bit 使用 8 位大小压缩 [默认：32 位]

--8mib-ram PSone 有 8 MiB ram 可用 [默认：2 MiB]

--boot-only 此格式仅适用于主文件和 CD-Mastering！
它可能会稍微提高压缩比，
解压缩例程比默认例程更快。
但它不能用于控制台传输！

--no-align 此选项禁用 CD 模式 2 数据扇区格式
结盟。 可能会略微提高压缩率，
但压缩的可执行文件不会从 CD 启动。
仅用于控制台传输！

附注 用于 RTM32/PE 和 臂/聚乙烯
与 win32/pe 相同。

附注 用于 TMT/亚当
此格式由 TMT Pascal 编译器使用 - 请参阅 http://www.tmt.com/ .

可用于此可执行格式的额外选项：

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

附注 用于 VMLINUZ/386
vmlinuz/386 和 bvmlinuz/386 格式采用 gzip 压缩的可引导 Linux 内核
图像（“vmlinuz”、“zImage”、“bzImage”），gzip 解压缩它并使用 UPX
压缩方法。

vmlinuz/386 与其他 Linux 可执行文件格式完全无关，并且与
分享他们的任何缺点。

备注：

- 确保显示“vmlinuz/386”或“bvmlinuz/386”
压缩期间 - 否则错误的可执行格式
可能已被使用，并且内核将无法启动。

优点：

- 更好的压缩（但请注意内核已经被压缩，
所以改进没有其他格式那么大）。
尽管如此，保存的字节对于特殊需求可能是必不可少的，例如
启动盘。

例如，这是我在 2.2.16 内核中得到的：
1589708 虚拟机
641073 bzImage [原创]
560755 bzImage.upx [由“upx -9”压缩]

- 在内核启动时更快的解压（但内核
如今，减压速度并不是真正的问题）。

缺点：

（无）

可用于此可执行格式的额外选项：

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

附注 用于 沃特康/LE
UPX 已使用以下扩展器成功测试：
DOS4G、DOS4GW、PMODE/W、DOS32a、CauseWay。
部分支持 WDOS/X 扩展器（有关详细信息
请参阅文件错误 BUGS）。

不支持 DLL 和 LX 格式。

可用于此可执行格式的额外选项：

--le 产生一个未绑定的 LE 输出而不是
保持当前存根。

附注 用于 Win32/个人版
PE支持在 UPX 现在很稳定，但可能还有一些
与某些文件不兼容。

因为路 UPX （以及此格式的其他打包程序）有效，您可以看到增加
压缩文件的内存使用量，因为整个程序在
启动。 如果你启动几个巨大的压缩程序实例，你就是在浪费内存
因为程序的公共部分不会在实例之间共享。 在
另一方面，如果您只压缩较小的程序，或者只运行一个实例
更大的程序，那么这个惩罚更小，但它仍然存在。

如果您从网络运行可执行文件，那么压缩程序将加载得更快，并且
在执行期间需要更少的带宽。

支持 DLL。 但是 UPX 压缩的 DLL 无法共享公共数据和代码
被多个应用程序使用。 所以压缩msvcrt.dll是浪费内存，但是
压缩特定应用程序的 dll 插件可能是一个更好的主意。

支持屏幕保护程序，但文件名必须以“.scr”结尾
（因为屏幕保护程序的处理方式与普通 exe 文件略有不同）。

UPX 压缩的 PE 文件有一些小的内存开销（通常在 10 - 30 KiB 范围内）
这可以通过在压缩期间指定“-i”命令行开关来查看。

可用于此可执行格式的额外选项：

--compress-exports=0 不要压缩导出部分。
如果您计划运行压缩包，请使用此选项
Wine 下的程序。
--compress-exports=1 压缩导出部分。 [默认]
出口部分的压缩可以提高
压缩比相当多，但可能不起作用
与所有程序（如 winword.exe）。
UPX 从不压缩 DLL 的导出部分
不管这个选项。

--compress-icons=0 不要压缩任何图标。
--compress-icons=1 压缩除第一个图标之外的所有图标。
--compress-icons=2 压缩所有不在文件夹中的图标
第一个图标目录。 [默认]
--compress-icons=3 压缩所有图标。

--compress-resources=0 根本不压缩任何资源。

--keep-resource=list 不压缩列表指定的资源。
列表的成员用逗号分隔。
列表成员具有以下格式：I .
一世是资源的类型。 标准型
必须指定为十进制数，用户类型可以是
由十进制 ID 或字符串指定。 一世是个
资源的标识符。 它可以是十进制数
或字符串。 例如：

--keep-resource=2/MYBITMAP,5,6/12345

UPX 不会压缩命名位图资源“MYBITMAP”，
它使每个对话 (5) 资源未压缩，并且
它不会接触带有标识符的字符串表资源
12345.

--force 强制压缩，即使有
标头字段中的意外值。
小心使用。

--strip-relocs=0 不要剥离重定位记录。
--strip-relocs=1 剥离重定位记录。 [默认]
此选项仅适用于具有 base 的可执行文件
地址大于或等于 0x400000。 通常情况下
压缩文件变小，但有些文件
可能会变大。 请注意，生成的文件将
不能在 Windows 3.x (Win32s) 下工作。
UPX 从不从 DLL 中剥离重定位
不管这个选项。

--all-methods 多次压缩程序，使用所有
可用的压缩方法。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认方法都会给出最好的结果。

--all-filters 多次压缩程序，使用所有
可用的预处理过滤器。 这可能会改善
在某些情况下压缩比，但通常
无论如何，默认过滤器都会提供最佳结果。

诊断

退出状态一般为0； 如果发生错误，退出状态为 1。如果发生警告，退出
状态为 2。

UPX的诊断旨在不言自明。

使用 onworks.net 服务在线使用 upx-ucl