ed 更新啦

下载地址：ed_1.7.4068.2052

说是不更新，但还是忍不住更新了，而且以后还会继续更新下去，希望大家多反馈意见和bug，让ed不断的完善下去，如果你的建议被采纳，你的姓名将被列到ed的感谢名单上。

今天发布了ed 1.7版本第一个bug修复版本：ed 1.7.4068.2052：
构建次数：4068
界面语言：简体中文
代码行数：18931
修复功能：
* 删除菜单中的加速键。[2020-12-14]
* 统一规范对话框排布。
* 修复只允许一个实例允许配置失败错误。
* 打开所有支持的语言开关。
* 发布包中包含License。[2020-12-15]
* 重写设计了一下快捷键，主要是在行处理编辑上更快捷方便、统一。
* 优化查找窗口清除界面闪动问题。
* 完善了所有菜单提示，以及没有打开任何文件时，变灰的菜单项。
* 将保持对话框代码中文本移动到资源中，为以后国际化做准备。[2020-12-16]
* 将浏览窗口中代码中字符串移动到资源中。
* 给工具栏增加了n种小工具。
* 解决工具栏没有打开一文件时造成的程序崩溃。

昨天向一个问题，关于ed 如何支持国际化
ed 可能下一步要发布一个繁体中文版和英文版，我想在实现这些功能前，最好想一种更好的设计，尽可能的减少以后发布新的版本支持时所做的工作。

调查一下，大家有什么好的建议都可以在下面发评论。我先说一下各种方法的优缺点。

1. Vista的MUI
Vista下可以很容易的支持多语言版本，rc编译器支持生成.mui为后缀的pe资源格式，当exe加载的时候，会自动根据系统语言设置去加载正确的.mui文件，比如一个简体中文的.mui一般放在zh-CN目录下。

优点：工具级别的支持
缺点：只能用在vista下

2. 将语言相关的资源抽出来，放在单独的资源dll中
ed主程序在驱动的时候，根据配置去加载正确的资源dll，现在很多软件使用这种方式。

优点：ed主程序不需要重写编译
缺点：需要多发布很多资源dll，ed现在的代码需要做一些改动。一个外国人制作资源dll需要使用reshacker来翻译制作，有时候还需要根据字符串的长度改变界面的一些排布。

3. 使用ini格式的资源字符串
现在许多软件使用一个配置文件来存放各种多语言版本字符串，比如对话框中的字符串都从这个文件中读取后显示出来。

优点：很方便支持新的语言。
缺点：效率上没有上面两种方式高。

4. 在同一份ed资源中，添加多种语言的资源
.rc文件支持，同一份对话框，多种语言。

优点：不需要额外发布语言包
缺点：需要我来维护多种语言，需要各种语言的翻译者协作，很难控制。

5. 编译不同版本的ed
需要我维护不同版本的ed.rc，这也是我现在的build内建支持的方式，现在支持的语言只有简体中文和英文两种语言。要支持繁体中文版本，只能有懂繁体的用户从现有版本用reshacker一类的工具翻译制作。

优点：比较容易控制，底层工具支持。
缺点：编译的时候，需要多花几十秒。需要额外发布多语言版本的安装包和升级包。

我能想到的现在有上面四种支持多语言的方法。各有优缺点，我自己现在比较倾向于使用方法2，这也时ultraedit使用的方法。

【后记：后面的内容是这篇blog写后3小时添加的随笔：
当我开始写liveupdate自动升级模块中，重新系统的考虑了一下版本问题，感觉现有build的内建支持方式没有什么问题。自己做了一些改动，将版本信息最后一位修改为语言，而不在包含debug/release、mbcs/unicode信息。版本组织一直困扰着我，使得升级和发布的许多模块都停滞不前，现在我想我已经解决了这个问题，下一步就是完善自动升级。需要asp web模块、liveupdate 和实际程序3方的共同合作才能完成。 周日的工作成果是实现了下载cab压缩升级包的解压工作。
】

User: