【发布时间】：2013-03-21 15:30:09
【问题描述】：
如果 .NET 可执行文件是 PE 文件，为什么所有像 UPX 这样的打包程序都会“破坏”它？
【问题讨论】：
-
我猜你说的是“Ultimate Packer for Executables”当你使用“UPX”首字母缩写词时？
标签： .net compression executable portable-executable
【发布时间】：2013-03-21 15:30:09
【问题描述】：
UPX 专为 native 应用程序而设计。这些是直接编译为机器码的应用程序。
以 .NET Framework 为目标的可执行文件不是本机应用程序，而是托管 应用程序。换句话说，它们在运行时环境（公共语言运行时，或 CLR）之上运行，并被编译成“中间语言”（IL），直到运行时才编译成机器语言（这个过程称为 JIT，或即时编译）。
UPX 可以直接处理非托管机器代码，但它不适用于托管应用程序。如果应用程序的代码被压缩并因此不可读，JIT 编译器将如何即时编译应用程序的代码？它不会；它会看到文件已损坏。
不过，损失不大。今天，压缩可执行文件的缺点多于优点。除此之外，由于托管应用程序被编译为 IL，它们通常比同等的非托管应用程序更小。
【讨论】：
-
但是您没有解释为什么 UPX 也不能处理托管指令。我相信这是有原因的，但你没有提到它。 “如果本机代码被压缩并因此无法读取，CPU 将如何运行它？它不会；它会看到文件已损坏。”几乎与为什么 UPX 不能压缩 x86 二进制文件一样好。例如，它可以在 IL EXE 周围放置一个真正的 EXE 并将 IL EXE 解压缩到另一个文件，如en.wikipedia.org/wiki/UPX
-
我以为我已经讲过了。 UPX 直接处理非托管代码。它进行解码，所以它可以工作。它不适用于 JIT 编译的应用程序，因为 UPX 并非旨在提前解压缩代码并将其提供给 JIT 编译器。是的，我认为您不能为 JIT 编译的应用程序编写打包程序没有任何技术原因。但是，至少在我写这个答案时，UPX 不是。
-
“现在压缩可执行文件的弊端多于好处”