又是奇怪的问题 – cygwin1.dll – 这就是软件开发的逻辑

又是RP大失败的一天, 一个奇怪的cygwin1.dll问题让两个人花费了将近2个小时,太失败了:(

在Cygwin版本A1上面编译代码得到程序A; 在Cygwin版本A2上面编译代码得到程序B, 其中A1>A2, 大约是1005.12.0.0 v.s. 1005.10.0.0,从时间上面看A1和A2大约差了4个月的样子. 将代码A分别在机器M1(win2k)和M2(winxp)上面安装, 其中M1是编译生成A的机器, 而M2上面并没有安装Cygwin. M1和M2一起运行A, M1和M2无法通信,其中的M1的TCP数据发送后感觉M2没有及时回送ACK,于是M1开始等待…

郁闷, 于是在另外一个机器M3(win2k)测试, M3安装了Cygwin的A2版本, 不过M3上面的程序也是M1上面编译生成的A, 在M1和M3上面运行A, 顺利通信, 不解???

(0) 于是在M2上面安装Cygwin的A2版本,编译得到B, 运行之, 无论和M1或者M2都无法通信.

开始排列组合:

(1) 更换M2上面的cygwin1.dll为A1版本的, 运行B直接出现错误crash!

(2) 使用M1上面生成的程序A替换程序B, 使用A2版本的dll, 无法通信

(3) 完全使用M1上面的程序A和A1版本的DLL, 运行, 居然成功! 晕, 开始为什么不行???

分析:

(1) 变化在于M2上面安装了cygwin的A2版本, 而以前没有安装, 但是A1和A2版本的cygwin1.dll无法正常通信.

(2) 可以工作的情况是, 两个机器必需安装某个版本的cygwin, 然后使用同一个版本(不必和本机安装的cygwin版本一样)的cygwin1.dll, 于是程序可以正常通信.

cygwin确实是个不错的东东, redhat也对此付出很多的人力物力, 但是其测试仍然有很大的不足, 回过头来看windows, 虽然ws2_32.dll/winsock2.dll的patch不断, 但是兼容性倒是真不错.

产品的可用性是容易达到的目标, 但是可靠性是开发人员梦寐以求的目标, 此言不虚了

http://www.cygwin.com/

真的有人会看到结束而不晕倒, 才怪啊~~~

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注