德尔福EXE压缩器？ [关闭]答案

【问题标题】：Delphi EXE compressor? [closed]德尔福EXE压缩器？ [关闭]
【发布时间】：2009-04-29 01:21:51
【问题描述】：

有一次，我有一个不错的小压缩实用程序，它可以将我的 Delphi 编译的 EXE 压缩成更小的下载大小，但现在我找不到它了。有什么建议吗？

另外，使用这些实用程序有什么缺点吗？（我主要用它们来缩短农村/拨号用户的下载时间）。

【问题讨论】：

这非常接近重复 - 我在 [delphi] 中添加了另一个相关问题的链接。

标签： delphi compression exe

【解决方案1】：

几年前，我研究过压缩我的可执行文件以使下载更小。

我最终所做的，以及我向您推荐的，是改用像 Inno Setup 这样的安装程序。它不仅会创建一个单独的 EXE 来安装/卸载您的程序，而且它还可以压缩该 EXE，就像单独的压缩器对您的可执行文件所做的一样。

安装程序后，它会被解压缩，因此它永远不会是病毒，也不会增加加载时间。

因此，我同时获得了较小的下载大小和具有专业外观的安装脚本的好处。

附言Inno Setup 是免费的。

【讨论】：

Inno 安装提示 +1：它包括 deflate、bzip2 和 7-Zip LZMA 文件压缩，因此可以安装非常小的安装程序。如果有类似的文件要压缩，它会发光，我有一个安装，其中 ZIP 包大约比安装程序文件大三分之一（都包含相同的文件）。

【解决方案2】：

建议您不要：

EXE 压缩器会使您的应用程序看起来像病毒（自我修改）
gzip/zip 在压缩方面同样有效，并且不会修改您的应用程序
EXE 压缩器会增加应用的加载时间（除非您只是在谈论安装程序，这是另一回事

这个看起来很疯狂的网站提出了我在遥远的过去听到的一个论点（今天是否正确，我不确定，现代包装商今天可能有不同的策略）这篇文章引用了 Win32！ :)

http://topic.csdn.net/t/20000408/08/6785.html

现代多任务操作系统，例如 Windows 95/98 和 NT 使用什么是称为“虚拟内存”系统。什么时候程序启动时，它们的所有代码都是没有立即加载到内存中启动时，与 DOS 一样程式。相反，只有部分正在积极执行的代码是存入内存。例如，说您的程序上有一个打印选项菜单，以及它背后的处理代码印刷。这段代码只会一旦打印加载到内存中功能首先由用户选择。如果在代码加载到内存未使用打印功能一会儿系统会“丢弃” 代码，释放内存占用，如果另一个应用程序迫切需要记忆。这是一部分称为“分页”的过程，是对程序完全透明。

Win32下的另一种分页方式节省内存是否会导致多个程序（或 DLL）的实例代码共享相同的内存。在换句话说，在正常情况下没有真实的情况物理量的差异为代码分配的内存启动 100 个程序实例并启动一个实例。

如果所有 Win32 程序的行为都像 DOS程序，将所有内容加载到记忆并保持在那里直到程序终止，也没有在多个之间共享任何内存实例，你可以想象物理内存的运行速度有多快在数量有限的系统上，导致磁盘交换开始。

然而，这正是当前的 Win32 EXE 压缩器对你的 EXE/DLL 的！他们完全走了针对操作系统的分页系统将所有代码解压缩到内存中并将其保留在那里直到终止。而且因为代码没有存储在 EXE 文件中的“原始”格式（即以同样的方式存储在内存中），操作系统无法在之间共享代码多个实例。

【讨论】：

另见：jrsoftware.org/striprlc.php#execomp
一位同事在使用和不使用 UPX 的情况下进行了一些基准测试。 UPX 最终成为网络共享的胜利和本地驱动器的损失。当然我不能对你引用实际的数字（我不记得它们了，它们会特定于我们的代码），所以请随意忽略我:)。
Jordan Russell (jrsoftware) 是 Inno Setup 的开发人员，Tim Sullivan 在上面的评论中提到的链接是 Jordan 的 StripReloc 程序。所以乔丹显然是压缩方面的专家，可以假设他在 Inno Setup 中做对了。
请参阅下面的评论，了解现代压缩器（如 PECompact）如何避免共享 DLL 部分并以其他方式缓解这些问题。我不想重复自己，只想说在某些情况下它们是有用的，而在其他情况下则不是。这是底线。我认为没有明确的“坏”或“好”，只是另一个实用程序

【解决方案3】：

我不知道有什么专门针对 Delphi 的，但 UPX 在这类事情上很受欢迎。唯一的缺点是可执行文件在启动时必须解压缩，这可能需要一些时间。不过，对于大小合理的可执行文件来说，它似乎非常快。

【讨论】：

【解决方案4】：

您可能想到的是ASPack - 它是一个用Delphi 编写的EXE 压缩器，但可以压缩任何EXE。不过，它可能在 Delphi EXE 上做得更好。我同意其他答案，即您不应该仅仅为了节省下载时间而使用 EXE 压缩器。在某些特定情况下，EXE 压缩是个好主意，但通常不是。

请改用一个好的安装构建器，特别是如果您能找到使用 7zip 压缩的安装构建器。我知道InstallAware 在内部使用 7zip 来实现最大压缩。根据您拥有的 Delphi 版本，您也可能拥有 InstallAware 许可证。

如果不出意外，您可以免费使用7zip 构建具有基本安装行为的自解压存档。安装程序需要单独下载 SFX。

【讨论】：

在看到 Delphi 2007 安装的实际效果后，我不会再用众所周知的 10 英尺长的杆子接触 InstallAware。我无法相信使用它不会增加可执行文件的压缩大小。
我认为 Embarcadero 应该使用 innosetup 进行 Delphi 设置。我最近不得不进行一个复杂的设置，包括 SQL Server 2008，在安装过程中下载必要的组件。当我进入 Inno Setup 时，简直不敢相信它有多棒。
InnoSetup 真的很棒，不能再推荐了。我已经用它做了一些非常简单的安装。永远不会回到 Wise/InstallShield 等...
您不喜欢的不是 WISE 或 InstallShield，而是 Microsoft Installer (MSI) 技术。我不同意你们所有人。我更喜欢构建 MSI...但是我通常使用 Orca，但那是因为我非常熟悉 MSI 内部结构。我还在 Delphi 中编写了我自己的自定义操作 DLL。问题是，太多人在不知道自己在做什么时使用 WISE 和 InstallShield 来创建垃圾 MSI。
我曾经使用过所有提到的安装程序，并且无法使用现有的 MSI 软件包，InnoSetup 是迄今为止最容易使用、配置和扩展的。我还强烈建议使用 ISPack 编辑器和扩展，它们可以让编辑脚本变得更加容易。

【解决方案5】：

使用带有 lzma 选项的 UPX 进行最大压缩。

upx --lzma yourfile.exe

【讨论】：

【解决方案6】：

压缩的 EXE 或 DLL 的主要不便之处在于操作系统无法在多个实例之间共享代码。
所以你在浪费内存，每次启动实例时都必须解压缩，表现出类似病毒的行为，甚至没有压缩安装的下载优势。
唯一正面的情况是直接从网络驱动器启动。

【讨论】：

是的，它可以共享代码，但这取决于它是如何打包的。大多数共享代码都在 DLL 中。例如，PECompact 默认忽略 DLL 的共享部分。此外，如果您不压缩 DLL，则这些 DLL 的进程实例之间的共享内存不会受到主 EXE 压缩的影响。

【解决方案7】：

我相信终端服务器（如 Citrix）如果未压缩，将为您的应用程序二进制文件使用相同的内存。这意味着在 Citrix 环境中，压缩的 exe 文件可能会带来小灾难。

【讨论】：

它被称为“共享内存”，用于 EXE 或 DLL 的多个实例的情况。使用它的不仅仅是终端服务器，而是所有现代操作系统。这个想法很简单。如果虚拟内存页面 (4KB) 已经存在，则只需引用它。如果单个进程更改了该内存，那么它会以一种称为写时复制的方法将其私有化。但是，您需要记住，并非所有可执行压缩器的行为都相同，有些可以配置/默认跳过共享部分。

【解决方案8】：

UPX 应该可以工作，尽管它不是 Delphi 特有的。

【讨论】：

【解决方案9】：

我用的是 PETite：http://un4seen.com/petite/

【讨论】：

【解决方案10】：

我也会投票给 upx。除了提到的缺点之外，它还可以防止基本的逆向工程和那些蹩脚的“资源黑客”工具。顺便说一句，其中很多，而且大多数都无法打开压缩的可执行文件。

【讨论】：

【解决方案11】：

不久前，我在 SO 上问了一个关于在 Delphi 可执行文件上使用 UPX 的弊端的问题，我得到了一些很好的回答。

Are there any downsides to using UPX to compress a Windows executable?

【讨论】：

【解决方案12】：

您可以使用PECompact，因为人们无法轻松解密它，并且正如测试所示（显示在主页上，只需向下滚动一点）它比 ASPack 或 UPX 更好，我在以前的 Delphi 上使用过它项目

【讨论】：