# 关于现在的图形界面库打包exe的体积 **URL:** \ **Category:** 闲聊灌水\ **Created:** [2023 年5 月 8 日 10:30 UTC](https://meta.appinn.net/t/topic/43473 "2023-05-08T10:30:52Z")\ **Posts on this page:** 6\ **Page:** 8
作者： ![w568w](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/w568w/32/7148_2.png) [@w568w](https://meta.appinn.net/u/w568w)\ 发布日期： [2025 年1 月 27 日 10:55 UTC](https://meta.appinn.net/t/topic/43473/147 "2025-01-27T10:55:36Z")
本来需求不同，适合的图形界面库就不同。 上面都讨论得很多了，我就随便写一点不同场景下适用的框架作为补充： - **多 1 字节都会死的场景** ：GDI、Win32（理论上任何编译语言都可以写）、LVGL（这个大概也能写桌面程序？） - **只有几个按钮/编辑框的小程序** （如注册机、安装/清理工具、计算器、信息查看器…）：易语言、aardio（Lua）、Lazarus（Object Pascal）、FLTK/ImGui（C++/Rust） - **正经的中型和大型跨平台应用** ：wxWidgets/Qt/GTK（C++）\[1\] - **下一代框架** ：Slint（Rust+Slint）、Flutter（Dart）、React Native Windows（Typescript）…… * * * 另外虽然人人骂 Electron 体积大、占用高，但和其他一众自称「优于 Electron」的 Web 桌面框架相比，Electron 其实在性能、内存占用和速度方面都算比较优秀的： > **[GitHub - Elanis/web-to-desktop-framework-comparison: An objective comparison of multiple frameworks...](https://github.com/Elanis/web-to-desktop-framework-comparison)** > > An objective comparison of multiple frameworks that allow us to "transform" our web apps to desktop applications. 我现在最反感的是 Tauri，除了体积小一无是处，打开速度慢得要死。 * * * 1. 我记得国产 Windows 软件（如 360 安全卫士）很喜欢用一个基于 DirectX 的框架，忘记名字了，好像是什么 dui/directui 之类的。 ---
作者： ![haitao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/958977/32.png) [@haitao](https://meta.appinn.net/u/haitao)\ 发布日期： [2025 年1 月 27 日 13:39 UTC](https://meta.appinn.net/t/topic/43473/148 "2025-01-27T13:39:02Z")
调curl/ffmpeg是我几个日常工具的基本工作， delphi怎么做不好？还是不会用而已。。。。 软件没有现代还是超现代之分，只是解决问题还是忽悠别人的分别 ---
作者： ![hgoldfish](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/hgoldfish/32/5033_2.png) [@hgoldfish](https://meta.appinn.net/u/hgoldfish)\ 发布日期： [2025 年1 月 27 日 14:22 UTC](https://meta.appinn.net/t/topic/43473/149 "2025-01-27T14:22:16Z")
你直接调命令行那当然简单了啊。很多时候是需要调它的 API 的，delphi 不容易调用 c 库的吧。像我还有一些软件调用 openssl 搞加密。我都是直接链接并调用它们的 API 搞定。调命令行不够高效，还有很多功能没办法用命令行实现。 发现我自己写的小工具基本上都在操控网络啥的。目前还是 C++ 方便。不然我自己其实也会好几门语言。 ---
作者： ![haitao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/958977/32.png) [@haitao](https://meta.appinn.net/u/haitao)\ 发布日期： [2025 年1 月 27 日 14:34 UTC](https://meta.appinn.net/t/topic/43473/150 "2025-01-27T14:34:10Z")
pascal与c几乎的一一对等的。。。。 函数参数的压栈差别，也是一个修饰词的改动而已。 ---
作者： ![hgoldfish](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/hgoldfish/32/5033_2.png) [@hgoldfish](https://meta.appinn.net/u/hgoldfish)\ 发布日期： [2025 年1 月 27 日 14:38 UTC](https://meta.appinn.net/t/topic/43473/151 "2025-01-27T14:38:57Z")
不止这么简单，c 的结构体布局和 pascal 可能是有差别的。 另外要调用 c 函数，得先 include 地些 c 的头文件才能调用啊。总不能每次都自己手动用 pascal 语法再声明一遍吧？ 现在每个语言的 cffi 功能都非常强。但是都做不到完美代替 c++. 包括 python 也是这样。话说我还给 python 弄过 win32api 的包装，当时是打算拿来写 GUI 的。这样子我就不需要 pyqt，只需要安装个 python 包就能写 GUI 了。可以做到 10MB 内。 ---
作者： ![haitao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/958977/32.png) [@haitao](https://meta.appinn.net/u/haitao)\ 发布日期： [2025 年1 月 27 日 15:05 UTC](https://meta.appinn.net/t/topic/43473/152 "2025-01-27T15:05:39Z")
结构体布局是完全对等的。 头文件是需要转换的，有人转好就可以直接用了， 自己转的，工作量大的话，需要自动转换工具——还好它们都是比较有规律的。 GUI的机制，VCL这套 相对来说是最合理成熟的。除非一定要在花哨上别出心裁，但正常解决问题是用不着。 [上一页](https://meta.appinn.net/t/topic/43473.md?page=7)