编译了一份 ucrt+native comp 出来，体感确实比 29.2 好不少
4 个赞
今天重新体验了一下，是要快一些。
用scoop安装，不要装emacs-k，emacs-k安装到C:\Program Files\WindowsApps目录。
建议装emacs-kl，emacs-kl安装在scoop目录下。速度比emacs-k更快，我也不知道为啥。
scoop install emacs-kl
对，但全面的测试有点难搞，我就借 native-comp 作者的 benchmark 随便跑跑了。
Windows app是运行在受控环境中，性能会差些，安全性更好。emacs-kl 就是原生exe，性能更好。
1 个赞
用 UCRT64 版本两天了，几个问题：
- native-compile 离开了 MSYS2 环境用不了，以前也有人提过，这也是为什么 GNU 分发的不开这个
- 同样原因，出了 MSYS2 Emacs 就找不到 gnutls，不影响启动，但比如 melpa 用不了，还好 gnu 和 nognu 都不用 https
- 如果把自帯的包 native-compile 了，不关 Windows Defender 启动会更慢
这个我之前看日本有些博客折腾过，是可以的，只不过比较麻烦。让官方编译的 Windows 版 Emacs 29.2 的 native-comp 特性生效
这个得像官方提供的预编译版本一样，把 Emacs.exe 要用到的 dll 库全都放到 Emacs 安装（也就是 make install 的那个目录）目录的 bin 下，也得一个一个弄很麻烦。
Windows Defender 算是 Emacs 在 Windows 上慢的一个很大原因，不管是编译还是运行。
看来得写一个辅助工具，递归检查 exe 和 dll 依赖的 dll 了。
没办法，Windows 不装杀毒软件就等于给黑客当筛子。
那 Linux 为啥不需要装?
kiennq最近编译出来emacs.exe真是小呀
1 个赞
这个问题讨论得很多嘛。随便说几个，一，大部分 linux 软件是从可信任的包管理器安装的，而 Windows 软件不是。二，linux 软件大多都是开源的，开源多少能增加软件代码被人审查的机会。三，不像 Windows 软件大多拥有全盘的访问权限，linux 有手段可以严格限制一个软件访问哪些目录。还有很多原因，也有一些是劣势。其中最关键的大概是很少有不安全源下载的软件这一点了。
2 个赞
linug入手门槛比windows高，并且linux大多数情况下都是使用包管理器安装，windows用户更倾向于去网站下载exe，另外就是系统文件权限的问题，windows下的管理员权限被滥用也不是一天两天的了
好奇怪啊，上面的那个构建我使用就莫名其妙的高CPU，用你说的这个就正常，而且速度确实提升不少
主要原因还是因为 linux 的用户水平大部分都比较高，不会像小白那样随便找个 exe 不管三七二十一直接双击运行。要是 linux 成了主流的桌面系统，然后到处都是闭源野包不知道哪里来的 deb 满天飞，那一样安全性是个问题。
没那么麻烦，用 Process Explorer - Sysinternals 很容易就能找到 EXE 加载了什么 dll：
打开 Process Explorer 之后可以打开 Lower Pane（菜单 View → Show Lower Pane 或者 Ctrl + L），然后在上面选中 Emacs.exe 即可。或者使用菜单里面的 Find 然后搜索 emacs。
3 个赞
这个是检查正在运行的 Process，看起来应该比 ldd 效果更好。
我找找它有没有 CLI 接口，如果有的话就可以方便地集成进打包脚本和 CI/CD 里了。
找到了：
P.S. 这个工具的作者好像现在是 Azure 的 CTO 吧？
1 个赞
对对，这是一个重要原因。我只是举些例子~ 覆盖不全还望海纳。
试了下kiennq最新的emacs31 ucrt，发现出现了编码的问题，又是典中典的GBK与UTF-8的斗争……
编码没问题啊， 只需要加这一行就行了。
(prefer-coding-system 'utf-8)
其实还有更方便的方法，把 MSYS2 的库先都复制过去，打开 Emacs，再把所有库选中删除，Windows 不让删正在用的库就能把需要的给过滤了
1 个赞
