云风的 BLOG: 被 insight 折腾了一晚上

我装的 insight 是 6.3 版的，在 mingw 官方网站就可以下载 bin 安装包，用起来也非常方便。

可惜 gdb 的 6.3 版在 windows 下 attach 到一个进程调试时总是不对。如果在代码里写上 int 3 制造一个调试中断。中断发生后，再启动 insight attach 到出错进程，看不到被调试进程正确的堆栈。这一点让我非常郁闷，每次调试程序都必须用 insight 或 gdb 来引导，而不能像以前用 VC 那样，出错了再启动调试器。

下午 google 了一下，这似乎是 gdb 的一个 bug 。从一个帖子上推断，bug 最近被 fix 了。找到 gdb/insight 的官方网站，发现 gdb 现在已经是 6.5 版了，不过只有 source code 下载。我这种懒人当然是希望有人帮我 build 好了。windows 下用这些 GNU 的东西，光是 build 就可以让人脱层皮，我是领教过好几次的。

google 了老半天，硬是没找到有好心人 build 出一个 win32 下用的 6.5 版的 insight 。咬了咬牙，决定自己动手，丰衣足食。

我的 windows 下没有装 cygwin ，只有一个最小安装的 mingw ，所以首先去拉了个 msys 下来。这个是 build 这些 GNU 软件必须要的，否则 shell 脚本都运行不了。装 msys 倒是简单，安装完毕启动后感觉还不错，跟 cygwin 差不多。windows 上用这个的话，至少列目录可以 ls 了，不至于老是敲错。

接下来简直是噩梦。

我怀疑 windows xp 在进程管理上一定有 bug ，用 insight 带的 make 执行一遍，运行到一半就会因为 fork 失败而进行不下去。我们知道 make 的工作机制就是不停的 fork 子进程来干活的。windows 在进程管理上远不如 *nix 的系统，这 make 在我的机器上就是水土不服。出了问题后，怎么杀进程重新来都不行了，只能重启。好在 make 在重启后可以继续。就这样，我重启了 3,4 遍系统后，终于把 make 跑完了。

可到了最后，居然出现一行 Error ，说是 gdb 不支持 native target i686-pc-mingw32 (._.!) 看到这里人都要崩溃了。继续 google 出错信息，发现有人为这个说了 sorry ，据说要交叉编译出 mingw 的版本。真是吐血啊，只好放弃。

今天得到了几个教训：

1.不要把 GNU 的东西放到 Program Files 目录下，我就是因为 vim 被缺省安装到那里，导致人家写的 makefile 中引用这样的带空格的路径，不能正常工作。你只能去诅咒微软为啥把这样重要的目录名中间加个空格，明显制造不兼容嘛。

2.Windows 下不要对 GNU 系列的源码发布包抱太大希望。那些东西是好的，可惜 Windows 不吃这套。如果想用的话，尽量去找人家做好的安装包。

3.Windows 系统真的是滥，我们这样的 Windows 用户之所以总能忍受，是因为我们学会了用特定的方式去用系统，回避了许多可能出现 Bug 的地方。

Comments

最近做了比较多的windows和linux下的编程。经典的体会是： linux是自己设计给自己用的。方便，简单，简单，方便。实用主义者。 windows是设计给别人使用的（据说VS的开发团队里不少人用VIM写程序），设计的很完美，很复杂，路子对了很方便，路子不对，就等死吧。问题要么很简单，可是如果一旦不简单，要解决就太难了。。。完美主义者。设计的很完美（windows的核心设计还是非常精巧的），实现的不完美。

Posted by: RiverZhou | (16) February 9, 2010 11:49 AM

干嘛在WINDOWS下用GDB, VC不是很好用么.

Posted by: initial-x | (15) May 24, 2007 12:40 PM

用户体验跟文件定位符有什么关系？谁规定说文件定位符必须跟user perspective一致？呵呵，自己制造的迷障

Posted by: d | (14) May 15, 2007 12:39 PM

最近发现一个很好用的 Unix 工具集，提供了几乎所有 Unix 命令的 Win32 移植版本，而且不用安装，直接解压使用，也没有任何其他的DLL文件调用。完全可以作为 cygwin 的替代。URL：http://sourceforge.net/projects/unxutils/

Posted by: yousp | (13) May 13, 2007 10:50 AM

我们做的跨平台项目, 一开始让 win32 下用 VC 编译，别的平台用 gcc 。写久了以后，发现统一成 gcc 更为方便。至少写 makefile 简单了。另外，VC 这个东西总有一天需要摆脱的，或早或晚而已。我现在对 IDE 没啥兴趣，还是自己组合开发工具来的灵活。

Posted by: Cloud | (12) May 12, 2007 12:06 AM

不知道换个方法：先用VC搞定源代码，然后用GCC编译会如何？还有不知道云风认为Dev-Cpp如何？

Posted by: 极光炫影 | (11) May 11, 2007 11:47 PM

GNU的人太孤芳自赏才是，而且MinGW在写GUI程序时真是让人很不习惯，还有它会自动处理些命令行参数，又没见什么文档记述，莫名其妙的问题会让习惯了VC的人头痛不已。说起gnu make，网上说得最多的好像是3.81版的有问题，都建议回退使用3.80或更早版本，而且对于只提供configure的源码包，MinGW环境定义的变量跟Cygwin是不同的哈，有的就是只能用Cygwin，不然真的掉一层皮都没用-_-b

Posted by: missdeer | (10) May 11, 2007 11:00 PM

在windows下为什么非得用gdb insight呢？对于windows平台VC是优秀的。当然，非*nix首选gdb 和insight。

Posted by: longtrue | (9) May 11, 2007 10:49 PM

说到那个make，前段时间用cygwin的make也是气得要死，死活不认windows的路径。后来Google了好久才发现是cygwin port的make的bug

Posted by: Atry | (8) May 11, 2007 01:11 PM

用引号而不用转移字符这是Windows的毛病。输入cmd /?可以看见一大堆关于如何使用一个参数中的带引号的参数…… 然而，文件名有空格，这个并不是Windows专有的，Linux自己的文件系统也允许有空格。一个程序不转换转义字符往往不仅仅是功能问题，还是一个安全问题。

Posted by: Atry | (7) May 11, 2007 01:06 PM

文件名支持空格本就是件糟糕的事情，重要文件夹使用空格更是扯淡的事情。哪天 windows 升级，文件名支持 " / * 这些，老项目一样玩完。这不关用户体验的事情。 GNU 整个社区维护着一个庞大的代码库，那么多操作系统上都可以正常工作，惟独需要为 windows 多考虑一些东西，只能说 windows 设计的有问题了。 btw, windows 下解决文件名中的空格，并不是用转义字符解决的，而是用引号，这本身也是一个糟糕的设计。关于这一点的批评也不是我一个人提出的。 windows 的桌面系统的易使用性是大众都承认的。但也只限于表面。一旦系统出了毛病，比如被种了木马，恶意软件，就算是专家也不能轻易解决问题。大多数人都是将就着用，只要还能用就算了。

Posted by: Cloud | (6) May 11, 2007 12:46 PM

也支持Atry

Posted by: nothanks | (5) May 11, 2007 11:26 AM

跟一般用户提什么make fork 线程进程那不是扯蛋嘛

Posted by: Anonymous | (4) May 11, 2007 11:05 AM

windows在流行的操作系统中已经算容易使用的了要知道用电脑的只有少数人是专家

Posted by: Anonymous | (3) May 11, 2007 11:05 AM

我支持小A 最近公司总在强调用户体验，为啥它就不能支持空格呢？

Posted by: jls | (2) May 11, 2007 10:04 AM

GNU也有责任，这么重要的地方，为什么不做转义字符，ext不是也支持空格吗，连自己本应支持的都做不好，还期待用户去回避空格。

Posted by: Atry | (1) May 11, 2007 06:07 AM

云风的 BLOG

思绪来得快去得也快，偶尔会在这里停留

被 insight 折腾了一晚上

Comments

Post a comment