Windows 上的 UCRT 的编译问题似乎解决了

在 clang64 环境下,没有装似乎没办法通过编译。

可以试试不装这个,然后根据 configure 的输出装其他的。

编译了一份 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 了。:fearful:

没办法,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 个赞