关于Windows下巨型软件的单文件化打包

讨论分享
1

背景：

关于将有多个组件的程序进行修改使其成为单文件程序，目前大多使用两种方案

一种是以7zSFX、VMware ThinApp为代表使用的自解压形式，即将文件存于压缩包中，全部解压至磁盘后启动，优点是兼容性好，原理上和一般软件安装流程大同小异；缺点是启动前必须将临时文件写入磁盘，面对巨型软件时，解压占用的磁盘空间和时间巨大

一种是以Enigma Virtual Box为代表的使用内存映射技术实现的单文件打包，这种打包避免了写磁盘——而是转为写内存，大大提高了启动速度，但缺点就是兼容性差（主要是这个），巨型程序运行所需内存多

问题：

期望找到一种能够边运行边解压的方案，以运行中的CPU损耗换启动时间，以支持大型程序的单文件打包

目前进展：

打包为单文件：iso、vhd等虚拟映像格式可以做到单文件挂载后直接正常运行，但无法做到压缩

打包为单文件并压缩：第三方的dwarfs、微软的wim可以做到直接挂载并运行，但兼容性不佳，程序会报错

结合上面两种方案：可行，可以在dwarfs映像中包含一个iso文件，先挂载dwarfs映像，然后挂载iso，其中的ps 2022运行一切正常，额外内存占用和CPU在设置范围内，并且运行速度几乎不受影响

现在唯一的问题是iso挂载时会占用一个盘符，这是一个需要解决的问题

另外，有其他思路也欢迎提出！

2

不一定要挂载到盘符。是可以挂载到空的NTFS文件夹的。

3

用 GitHub - IridiumIO/CompactGUI: Transparently compress active games and programs using Windows 10/11 APIs 可以压缩磁盘上的文件，不影响打开，你看看能不能配合vhdx。

4

如果是个人用.

可以用软链接的方式共享组件.

可能比打包成单文件运行效率更高.

5

期望打包后是可发行的，并不是个人使用

6

一个难点：因为要做成单个文件，vhd和exe必须二进制连接为一个新文件；而Windows的命令行工具是不支持偏移量挂载的
一个问题：压缩率无法达到一个较高的水平
但是或许可以通过调用更底层的接口完成任务，您的方案确实可行，正在继续探索中…

7

iso没能找到挂载至文件夹的方案；vhd或vhdx被打包在wim或dwarfs映像内后，挂载映像，无法二次挂载vhd/vhdx文件，可能挂载vhd/vhdx的程序也遇到了不兼容的情况

8

新进展，根据这个gui工具的说明，直接调用了
compect.exe /EXE:LZX /S:DIR /C
成功地提高了压缩率
在清除多余数据后，它打包的多个样例程序与其他压缩方式已经很接近了。例如Photoshop 2022的某个3.3gb的绿色版本，7z极限压缩后1.45gb，compect压缩后1.69gb，并且在运行时不会占用太多的CPU和内存

现在唯一的问题是无法封包为单文件，必须一个vhd附带一个启动程序来辅助加载，解决后就完美啦

9

哈哈很高兴能帮到你

10

其实我觉得目前最舒服的方式是类似mac的处理方式。程序入口就是一个文件夹，双击打开程序，右键打开文件夹。不知道windows能不能实现。

11

理论上没问题，但实际做起来…可能要单独对每一个软件进行人工处理，使得每一个软件按规范储存获取组件、数据

12

新进展！完成了单文件打包，样本是完全展开后3GB的Photoshop绿色版

目前无法完成任务的方案：
Enigma Virtual Box打包完成无法运行
Cameyo打包了一个小时还在转圈圈
VMware Thinapp构建时报错（但是这个不知道是不是环境原因）
某些自解压打包器因为文件太大直接内存溢出

目前暂时可用的方案：
部分健壮性良好的7z自解压程序等，打包后1.49GB
目前表现最佳的zlib自解压程序，打包后1.72GB
这两种本质上都是自解压，我的E5 2678设备带16GB的RAM，SATA3.2固态（最高连续写入速度约300mb/s），Windows10 LTSC 2019系统，7z自解压启动大约需要四分钟，zlib自解压启动大约需要两分钟。
另外，自解压清理文件需要时间；并且在启动和清理时因为需要大量写磁盘，所以会变得很卡

为了节省空间、保持兼容性，我换用了vhd格式；为了加快速度，我手写了一个挂载程序。这种新方案打包出来大小1.7GB(优化后可以再少200MB左右)，完全冷启动可以控制在4s之内

新方案只有一个小小的劣势：因为软件启动后有一个载入配置文件的过程，这里新方案在载入中消耗CPU要比自解压方案高一些。
具体数据：
自解压方案占用0.4%CPU
新方案占用0.6%CPU
虽然CPU占用高，但是NTFS文件系统很给力，读取时间没能检测到差异

另外，因为新方案直接挂载可执行文件内的文件系统，所以这个新方案被我命名为“自挂载”

最后，其实这个东西在一年多前我就给它找好名字啦，下面是我初一的时候一个吾爱论坛的帖子，里面是一个很不成熟的自挂载程序，基于wim的
https://www.52pojie.cn/thread-1798710-1-1.html

13

想要压缩可以试试用 Zstd 算法压缩，优势是在7z的压缩率上有zip解压的速度，目前 linux 已经在用了。

压缩的软件可以试试开源的 peazip

楼主加油哦，我很看好你 :666:

14

其实这个帖子讨论的主题很早很早（在约二十天前）就已经实现。
本来是想整个项目做完再分享的…但是在开发过程中遇到了新的有价值的问题，所以先把这个半成品发出来，新的问题留给新帖子讨论

这个半成品仅仅是为了演示本帖的讨论主题
注意，需要Windows7或更高的系统，并且不支持大部分沙盒

https://drive.google.com/file/d/1o2mAUoQIeZVO-5Xwscxb_4LUYfa73Q8L/view?usp=sharing

以下是技术细节
用了歪门邪道，在vhd网盘中找了一段空白部分，插入了一个批处理脚本。所以它既是一个批处理脚本也是一个标准vhd虚拟磁盘文件
批处理写出一个小exe，exe的作用是调用相关函数挂载批处理文件（也就是挂载vhd文件）然后启动其中的主程序
如果有人能够测试，希望得到从双击开始到第一个界面出现为止的耗时
在我的计算机上，自解压方式启动耗时为一分多钟，自挂载方式启动耗时在10s内

1 Like
15

这是不是比绿色更极端？
一般，软件能一个exe当然最好，但需要各种库、数据文件配合也难免。
所以，要么是安装包，要么是绿色（解压到一个子目录就可以正常运行）。
能不被系统里的不同版本的库困扰，也不会影响到其它应用，就是很成功的绿色软件了。
单文件的要求只在 传输过程，
使用过程 应该单目录就行了。

16

不是啦，只是为了省去“传输”和“使用”之间解压缩的时间而已。单文件程序也可以不是绿色的（虽然一般会做成绿色的）
这个半成品不是绿色的哦，它只是被打包成了单文件

题外话，这个项目其实包含绿化和单文件打包两个部分，单文件打包在此贴中讨论，而上面提到的新问题就是绿化

17

传输、安装（或解压缩）都是一次性的，
之后的n次使用都是 0解压缩（只是占用了一个子目录及硬盘空间）

18

是的，都是一次性的，所以单文件打包对于需要在同一环境下多次使用的软件没有意义

19

那没有问题，如果不是一次性使用，那研究便携化的意义更大。