但是在 JavaEye 的某个帖子里知道 Exerb 后，事情就变得简单了。Exerb 是一个可以把 Ruby 脚本以及其依赖的 Ruby 扩展库转换成 Windows 下的单个的可独立运行的可执行文件的工具（这么长的一句话读起来是不是很有想扁我的冲动？:p），到 Exerb Project 的主页 下载安装包解开并执行里面的 setup.rb 即可完成安装。

用法也很简单，先执行 mkexy your_script.rb，让 mkexy 启动你的脚本并运行，这期间它会自动探测出 your_script.rb 所依赖的类库文件以及扩展库文件，并在 your_script.rb 结束运行后创建一份清单 your_script.exy，然后执行命令 exerb your_script.exy 即可生成 your_script.exe。OK，现在可以轻松地把你的 Ruby 脚本分享给朋友们了。(注1)

看到这里，也许你会跟我一样想，哇哈哈哈，有了这个工具，用 Ruby 来做 GUI 的小工具就变得有意义了啊。没错，对依赖 fxruby、wxruby 的 Ruby GUI 脚本也能正常的使用 Exerb 完成转换 (注2) (注3)。但是，由于 Exerb 会把 fxruby/wxruby 的运行库嵌入到 .exe 文件里，生成的 .exe 文件都非常大，fxruby 的在 9MB 左右，wxruby 的 11MB 左右。对于一个功能简单的小工具来说，这个程度的体积显然是很多人不能接受的。

事实上，已经有了一个 GUI toolkit 运行库很小，VisualuRuby，虽然它是 Windows Only 的，虽然它现在在 Vista 上还有点小问题。不过这又是另外一个话题了，我会在下一篇 blog 里继续聊。

注1: 在这之前也许你需要用 upx 压缩一下生成的 .exe 文件，因为它确实比较大，一个最简单的 Hello world 也有 1.4MB 左右。

注2: Tk/Gtk/FLTK 我没有试过，对 Tk 不感兴趣，Gtk 在 Windows 下的运行库太过庞大，FLTK 则是因为找到的 ruby-fltk 在 Windows 下的二进制发行版依赖的 Ruby 版本太老，源代码发行版还没来得及尝试自己编译。

注3: 对于 GUI 脚本，使用 exerb -c gui your_script.exy 可以避免生成的可执行文件运行时带有 Windows 命令行窗口。

./a_tiny_script 2>&1 | tee the_log_contain_both_stdout_and_stderr.log

这个命令的精华在于 2>&1，意为让 stderr 使用 stdout 的文件描述符，效果也就是将 stdout 和 stderr 内容合并，并且输出到 stdout 被定向的位置。在这里也就是管道中的 tee 命令的 stdin 上，然后 tee 将得到的输入同时显示在屏幕上和记录到日志文件里。爽吧？

以前为了在 PHP 脚本里实现这样的功能竟然使用了 ob 系列函数 + 自定义的 output callback 函数，并且这样也只能做到同时显示和记录 stdout，真是晕到死。

不过这么多年来一成不变的浏览器＋软件下载站＋手工浏览下载的模式已经让我厌倦了。懒人总是有懒人的办法，因此也就有了这个使用 Windows 命令行脚本编写的 AutoUpdateSoftOnSkycn.cmd。

AUSOS 的工作原理很简单，用 wget 取得软件下载站上的某个软件的介绍页面，然后使用 grep/sed 来分析页面的文本取得此软件的下载地址，再次使用 wget 取得这个软件。使这个工作流程能真正应用的重点在于，大多数软件站的某个具体软件的介绍页面地址都具有持久性，这是为了提高使用具体关键字时自己在搜索引擎中的排名，同时也方便用户访问和自己管理。

基于这个工作原理，AUSOS 稍加修改就可以适用于大多数软件下载站，实际上这也是我下一步的目标。不过这样一来配置文件 AUSOS.conf 和项目列表文件 ItemIDList.ini 就会复杂一些了，到时候也许会做一个 GUI，如果真的需要的话。

另外编码过程中发现 Win2k 以后 Windows 命令行脚本虽然增强了很多，但还是有些不便，也许以后会移植到 bash 脚本上，这样虽然看上去没那么 NB 了，不过可以做到跨平台。Windows 下用 Cygwin 里的 bash 来执行；Linux 自是不必说，bash 已经流行很多年了。

写完发给一个 coder 朋友看，他说“Windows shell script 都可以写那么长，你丫真素 YD。”，呵呵。

如果你有兴趣的话可以在线看看 AUSOS 在 Vim 中高亮后的代码。并且，使用说明也可以在这里比较方便的看到。

下载地址:
AutoUpdateSoftOnSkycn.cmd v0.2
超微型的 Cygwin 环境，如果你和大多数人一样没有安装 Cygwin，那么请下载并解压到 AUSOS 所在目录或者 PATH 环境变量中列出的任何一个目录里。

我知道早在几年前就有了这种工具。不过我所找到的这类工具都不大好用，比如 W.Z.Q 的那个，每次修改都要从游戏里切换出来，很不方便。因此一怒之下自己写了个，具备全局快捷键修改，以及 ID 列表保存能力。

同时附上 Delphi 源代码。其实程序很简单，就是用一个循环的 ReadProcessMemory() 来读取 starcraft.exe 进程的内存，并且通过搜索一个特征字符串找到游戏的 ID 列表位置，然后用 WriteProcessMemory() 写入我们设置的彩色 ID 而已。至于如何让 ID 以各种颜色显示，则要感谢前人 W.Z.Q 的研究。事实上我是使用 WinHex 查看经他的 scRedStorm 修改过 starcraft.exe 进程的内存得到的这个“秘密”。

更新历史

v0.1.0221.874

• 解决对 1.08 以上版本无效的低级问题。

v0.2.0

• 即时预览彩色 ID，精确模拟星际争霸对待彩色代码的行为。
• 支持 Windows Vista。为了避免与 Vista 的快捷键冲突，以前的 Ctrl + Alt + Tab 已经更改为 Shift + Tab。
• ID 首尾都可以使用空格。
• 放弃 FlatStyle 控件，在 Vista 里它已经不再好看了。

下载

SCColoredID v0.2.0
SCColoredID v0.2.0 源代码

问题就出在这个 Browser 模式上。 Windows 2000 以上的版本默认把某个用户的注册表文件，各种软件的配置和数据文件等等保存到以该用户的名字命名的个人文件夹里，这个文件夹通常通常位于安装 Windows 的分区的 Documents and Settings 文件夹下。Windows 以环境变量 %USERPROFILE% 来表示它。而我为了让 Windows 彻底崩溃后不用手动去挽救数据，通常会把很多本来位于 %USERPROFILE% 文件夹里的系统特殊文件夹重定义到其他地方。包括 Application Data、桌面等。

结果，在随手删除掉 %USERPROFILE% 里已经无意义的“桌面”文件夹 (因为我已经把它重定义到了其他位置) 后，ACDSee 的 Browser 模式无法正常工作了。表现为由 Viewer 模式切换到 Browser 模式后不会显示出所在文件夹的任何图片文件，或者直接启动 Browser 也不会显示大多数文件夹下的图片文件。

发现造成这个问题的原因浪费了我几天前的一个夜晚几个小时的时间，最后在网友急云的提示下才搞清楚。

或许这只是个很小的，微不足道的，大多数人不会遇到的问题，但至少它对我们软件开发者来说有特别的意义。因为这很可能是 ACDSee 的作者在一定程度上使用了硬编码 (hard code) 造成的。

很多时候，我们为了方便而使用硬编码。要说是在用于教学或者演示的 demo 里为了方便或者突出重点使用硬编码，那是无可厚非的。但如果由此让自己或者别人养成了使用硬编码的习惯，那就罪大恶极了。

其实，著名的由两位数表示年份造成的“千年虫”问题就是个典型的硬编码带来的灾难。

平心而论 Delphi 2005 是个不错的产品，虽然我们可以找出一堆数落她的理由。比如启动太慢，占用内存太多，IDE 太像 Visual Studio 而失去了 Delphi 传统的风格，编辑器反应比较慢等等。不过在同一个 IDE 里同时支持 Delphi for Win32、Delphi for .NET 以及 C# 确实是个很诱人的卖点。以及新增的 Refactoring、UML Modeling 等等都是很实用很重要的功能。

Delphi 2005 是个不错的产品，但 Borland 对她的宣传确实有些过了。

为了证实我的猜想，特设计以下实验，本实验中使用到了字符串(本文提到的字符串都是指 Delphi 默认的字符串 AnsiString)内部结构中的引用计数。

关于字符串的引用计数，结合 D6DG 中的说明和偶的实际研究，得出的结论是，字符串地址实际上是其内容的第一个字符的地址，在此地址之前的 12 字节内存中的内容才是字符串内部结构中的头部，分别是 32 位字符串占用的内容空间大小，32 位引用计数，32 位字符串长度(仅在 Delphi 7 中验证，推测 Delphi 7 以前的 32 位 Delphi 中的字符串结构都应该是这样，未验证)。

以下代码中 sGlobal 为全局字符串变量。

procedure Method1(S: string);
var
  P: PInteger;
begin
  // S := S + 'k';
  // 字符串实际上是指针，这里只是将其强制转换为 PInteger 备用
  P := PInteger(S);
  // 得到字符串地址左偏移 8 字节的地址，也就是字符串的 32 位引用计数存储的位置
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('S 引用计数: ' + IntToStr(P^));
  P := PInteger(sGlobal);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('sGlobal 引用计数: ' + IntToStr(P^));
  Form1.Memo1.Lines.Add('S 地址: ' + IntToStr(Integer(Pointer(S))));
  Form1.Memo1.Lines.Add('');
end;

procedure Method2(var S: string);
var
  P: PInteger;
begin
  P := PInteger(S);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('S 引用计数: ' + IntToStr(P^));
  P := PInteger(sGlobal);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('sGlobal 引用计数: ' + IntToStr(P^));
  Form1.Memo1.Lines.Add('S 地址: ' + IntToStr(Integer(Pointer(S))));
  Form1.Memo1.Lines.Add('');
end;

procedure Method3(const S: string);
var
  P: PInteger;
begin
  P := PInteger(S);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('S 引用计数: ' + IntToStr(P^));
  P := PInteger(sGlobal);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('sGlobal 引用计数: ' + IntToStr(P^));
  Form1.Memo1.Lines.Add('S 地址: ' + IntToStr(Integer(Pointer(S))));
  Form1.Memo1.Lines.Add('');
end;

procedure sGlobalInfo;
var
  P: PInteger;
begin
  P := PInteger(sGlobal);
  P := PInteger(Integer(P) - 8);
  Form1.Memo1.Lines.Add('sGlobal 引用计数: ' + IntToStr(P^));
  Form1.Memo1.Lines.Add('sGlobal 地址: ' + IntToStr(Integer(sGlobal)));
  Form1.Memo1.Lines.Add('');
end;

在主程序里分别以初始化后的 sGlobal 为实参调用这几个过程后，我们会看到三种方式 S 的地址都跟 sGlobal 的一样，这初步说明 var 方式和 const 方式确实都是按地址传递参数。

但不可思议的是，默认参数传递方式不会是为变量产生本地副本吗？为什么 S 的地址还会跟 sGlobal 一样呢？因为一开始我设计这个实验时并没有添加显示引用计数的代码，所以很是迷茫。之后想起了 Borland 使用了引用计数的方式和 copy-on-write 技术(对于字符串等使用这两个技术的数据类型的变量 A、B，将 A 赋值给 B 时实际上只是赋值 A 的地址给 B，并增加 A 的引用计数，直到两者其中一个被修改时才为 B 申请新的内存空间并且复制 A 的内容，同时减少 A 的引用计数)来优化字符串的操作。于是查阅 D6DG 并且观察 Delphi 的汇编代码和内存(在 CPU 窗口中)得出了本文开头关于字符串引用计数的结论。

这样，添加了显示引用计数的代码之后我们就可以观察到，使用默认方式时 S 和 sGlobal 的引用计数，都是 2，而其他方式时两者的引用计数都是 1，这更有力的说明了 const 方式确实是按地址传递，而不是像默认方式那样只是增加引用计数。这样，当我们把第一个过程中第一行代码的注释去掉后再次运行程序，可以看到默认方式时 S 的地址已经跟 sGlobal 不同了，同时两者的引用计数都是 1 了，说明确实是在 S 被修改后才产生本地副本(copy-on-write)。

那么，现在我们知道参数类型为字符串时， const 方式的参数传递实际是传递参数地址，这可以优化内存的使用，而参数为其他数据类型时是不是这样呢？

为此修改刚才的程序如下，其中 iGlobal 为全局整形变量。

procedure Method1(I: Integer);
begin
  Form1.Memo1.Lines.Add('I 地址: ' + IntToStr(Integer(@I)));
  Form1.Memo1.Lines.Add('');
end;

procedure Method2(var I: Integer);
begin
  Form1.Memo1.Lines.Add('I 地址: ' + IntToStr(Integer(@I)));
  Form1.Memo1.Lines.Add('');
end;

procedure Method3(const I: Integer);
begin
  Form1.Memo1.Lines.Add('I 地址: ' + IntToStr(Integer(@I)));
  Form1.Memo1.Lines.Add('');
end;

procedure iGlobalInfo;
begin
  Form1.Memo1.Lines.Add('iGlobal 地址: ' + IntToStr(Integer(@iGlobal)));
  Form1.Memo1.Lines.Add('');
end;

在主程序里分别以初始化后的 iGlobal 为实参调用这个过程后，可以看到只有 var 方式中 I 的地址跟 iGlobal 一样，而默认方式和 const 都会为 iGlobal 产生本地副本，可见确实如 D6DG 所说 const 会(也只会)优化字符串和记录类型的参数传递时的内存占用。

至此实验目的达到，还附带了解了 string 的内部格式。

附上实验程序源代码。