mintty 的项目网址：

https://code.google.com/p/mintty/

这两天使用 mintty 的时候却突然发现配合 MSYS 怎么也无法正常启动了，而且没有任何报错信息，最后通过 MSYS 的 rxvt 终端运行才看到了报错提示：

[Administrator@msys ~]# mintty
m.AllocationBase 0x0, m.BaseAddress 0x68550000, m.RegionSize 0x4B0000, m.State 0x10000
C:\msys\bin\mintty.exe: *** Couldn't reserve space for cygwin's heap (0x68550000 <0x13C0000>) in child, Win32 error 0

在这个网址上看到了有人提出了使用 rebase 命令修改 MSYS DLL 文件首选基地址的解决方法：

http://dreamcloud.artark.ca/msys-not-start/

每个 DLL 文件都有一个首选的基地址，表示映射到使用的进程地址空间中的首选地址，一般默认为 0x10000000。实际情况下可执行程序一般会使用多个 DLL 文件，如果多个 DLL 文件都使用默认的首选基地址会造成系统自动做基地址重定位操作，这样可能导致进程地址空间中碎片的存在，并影响 DLL 的加载效率，因此有些 DLL 文件就直接自己指定了首选基地址。

如果需要查看某个 DLL 文件当前的基地址，可以使用 dumpbin.exe 命令行工具来查看，也可以使用 Dependency Walker 程序打开 mintty.exe 可执行文件，然后查看使用的 msys-1.0.dll 的基地址，例如我修改之前的效果如下图：

查看DLL基地址

从图中可以看出修改之前 msys-1.0.dll 文件的基地址（就是 Base 那一栏了）是 0x68000000。

按照上面链接提供的方法，首先需要退出 MSYS shell，并保证所有使用 MSYS DLL 的程序都停掉，先备份 msys-1.0.dll 文件，然后在 Cygwin 或者 cmd 里直接运行 rebase 命令修改 MSYS DLL 加载基地址为 0x76000000：

[Administrator@cygwin ~]# rebase -b 0x76000000 msys-1.0.dll

直接在 MSYS shell 里修改的话会由于 msys-1.0.dll 正在被使用而修改失败。修改成功之后重新运行 mintty.exe 程序，但还是有问题启动不了，报错信息相应也变了：

[Administrator@msys ~]# mintty
m.AllocationBase 0x763C0000, m.BaseAddress 0x76550000, m.RegionSize 0x23A000, m.State 0x1000
C:\msys\bin\mintty.exe: *** Couldn't reserve space for cygwin's heap (0x76550000 <0x1610000>) in child, Win32 error 0

看来这个修改过的基地址还是有问题的，估计还是和 mintty 程序有冲突的，我们再修改 DLL 基地址为 0x60100000 看看：

[Administrator@cygwin ~]# rebase -b 0x60100000 msys-1.0.dll

这下再运行 mintty 程序终于正常工作了，另外如果系统里没有 rebase 命令的话也可以使用 Visual Studio 2010 中自带的 editbin.exe 程序来修改 DLL 文件基地址的哦，玩的开心 ^_^。

之前因为一个项目需求，需要在 Windows 上使用 Bash 脚本运行 Windows 上的程序，因此想到在 Cygwin 的 Bash 里实现（好吧，这确实比较令人蛋疼）。运行 Cygwin 中的 bash.exe 调用脚本，并启动另一个 VBScript 脚本来对一个 Excel 文件进行修改处理（使用 Windows 的原因了）。

刚开始通过 cscript.exe 命令在 Windows 自带的命令提示符中运行 VBScript 还比较顺便，能顺利打开 Excel 文件并处理成功。但通过 Cygwin 的 Bash 脚本运行之后却老是在 VBScript 的打开 Excel 文件的地方提示找不到文件打开失败，顿时非常困惑。

Cygwin 的 Bash 脚本例子如下，test.sh 为 Bash 脚本程序，xxx.vbs 为处理 Excel 文件的 VBScript 脚本程序，运行 VBScript 脚本前需要先读取输入并传给 VBScript 脚本作为参数：

#!./bash
echo "Test script..."
read TESTVAL

# xxx do something xxx

read TESTLEN
echo "Require length: $TESTLEN"

cscript //Nologo xxx.vbs $TESTVAL

# xxx do something else xxx

read TESTEND
echo "...."

初步考虑是 Cygwin 开启的 shell 权限不足，为解决问题，便尝试了各种方法：

• 建立快捷方式设置以管理员方式运行，问题依旧；
• 把 Cygwin Bash shell 换为 MSYS 的，还是同样的报错；
• 通过 runas 命令以指定用户身份运行 cscript.exe VBScript 脚本，依旧。

但非常奇怪的是，我手工运行 Cygwin bash.exe 开启一个终端，然后在终端中运行 cscript 调用 VBScript 结果却又一切正常。

为此不得不又把目光转移到 Bash 脚本代码中，除了刚开始有两个 read 读取输入和 echo 输出操作外，并没有什么特殊的操作。实在找不到办法，就把 cscript 操作放在脚本最前面（使用固定参数，不通过读取输入的方式传入），再运行 test.sh 却惊奇的发现可以正常工作了。有点头绪了，由于运行 VBScript 必须从当前 Bash 脚本中传入参数，因此尝试着把第二个暂时不是特别必要的 read 和 echo 操作注释掉（第 7 和 第 8 行），也工作正常。

再经过反复测试发现 Cygwin 启动的 Bash 在运行了两次 read 操作之后再调用 VBScript 脚本就会出现权限不对的问题，只 read 一次或者完全不做 read 读取输入操作（cscript 命令放在最开始）都不会有问题。

现在也实在没明白两次 read 读取输入操作会导致什么系统环境不一样才使 VBScript 运行失败，Google 之后有朋友也遇到这种问题但没有正确的解答，可能这种改 read 方式并不彻底，但目前也算权宜之道了 ^_^。

rsync是一个开源免费的文件同步和备份工具，可用于本地备份，本地与远程服务器之间的备份，可以实现增量和差异备份，而且由于比较好的算法，在文件备份速度上也相对其它一些文件备份工具有明显的优势。

但 rsync 一直以来没有 Windows 下的原生客户端，都是基于 cygwin 环境实现，实际备份性能会受一些影响，近日看到 rsync 的 基于 MSYS 的 Win32 原生客户端已经被 port 出来，故简单做下性能对比测试。

测试环境：

rsync服务器为 RHEL5 Linux 64bit，8个SATA盘的RAID0做下层存储，采用单千兆网络和千兆交换机
rsync客户端为：RHEL5 Linux 64bit，Windows 2003 Enterprise 32bit

测试时 rsync 均通过匿名方式访问，不经过SSH做用户验证，由于考虑到测试的 rsync 客户端的系统盘速度有瓶颈，客户端文件读写都通过内存文件系统来实现（Linux 上使用 tmpfs，Windows 上使用 ImDisk 模拟内存盘）。

使用同样的客户端主板分别在 Linux 和 Windows 内存中产生 1.5GB 的测试文件，然后通过 rsync 客户端进行备份到服务器（写操作）和从服务器上恢复（读操作）的操作。

备份命令示例：
rsync -hv x.dat 192.168.1.125::rsync0/

测试软件列表：

• 标准 Linux rsync 客户端（RHEL 5 系统自带）
• cygwin rsync 客户端
• MSYS rsync 客户端
  http://sourceforge.net/projects/mingw/files/MSYS/Extension/rsync/
• RsyncWin32 客户端
  http://sourceforge.net/projects/rsyncwin32/

测试结果：
 

从测试结果看，由于 rsync 本身面向类 Linux 环境开发，在 Linux 系统中有着非常好的性能，cygwin rsync 与 Linux 相比有一定差距，但实际使用中还是比较稳定的，而 MSYS rsync 还处于测试阶段，虽然没有出现备份错误，但在千兆网络环境下性能非常差，RsyncWin32 则相对而言问题比较多，备份过程中甚至会出现备份错误。

综上看来，目前在 Windows 上使用 cygwin rsync 做备份客户端仍然算是比较好的解决方案，MSYS rsync 的问题可以啥时候有空再看看咯。