All Stories

郁闷,成质量部的人了

郁闷,成质量部的人了

  睡得少,白天果然很吃力,这是已经亲身验证过无数遍了。  本来想着是上午给个新的编译版本让他们测试一下,结果发现,一个最最最基本的功能都不能用,直接弹出消息框。其实是COM接口抛了个异常,虽然我没有用try...catch来处理,但最后还是被我挂接的未处理异常过滤函数捕获到了,弹出个没有内容的消息框。  于是下午调了近2个小时来定位哪里出的错,因为我自己的电脑上无论怎么样都是正常的,而别人的电脑上无论怎么样都是不正常的。猜了几次,最后想到一个地方,Excel中的CShapes::SelectAll方法,不知道哪里吃错药了,只要一调用该方法,它就抛个异常出来,倒是可以用try...catch捕获到,但却没有什么实际意义,因为我不知道这为什么错了,我以为这就是最正确的用法。  冥思苦想了1个小时,毫无进展,于是上楼去找老大诉苦,我当然不会指望老大知道怎么解决这个问题,而只是想让老大知道我很郁闷很痛苦。  再回到座位上,照老大说的,把自己的进展,遇到的困难写邮件抄送给所有相关人,这样至少让他们自己我还是在干活的。一直到下班的时间,质量部负责这事的人跑来跟我说,这二三四季度的绩效考评放到质量部来做了,我彻底郁闷了,成质量部的人了!不要逼我啊!

crash report

crash report

  以前对这方面没有多少关注,只是偶然看到LuaEdit用了个叫madExcept的库,可以让Delphi程序在运行时如果崩溃了弹出个看起来比较牛的对话框,显示一些当前进程和当前系统的相关信息,并可以让用户选择是否将这份报告通过email发送回开发者。当时很好奇这是怎么做到的,很希望在自己的程序中也集成进这个功能,但很遗憾地发现,这个库只适用于Delphi,而我偏偏就不是用Delphi的。  后来,偶然,没错,以是偶然,看到公司网上有人说FileZilla有一部分这种代码,于是找来看了看,才大致了解了基本原理,并直接把这段代码抠出来用在了项目中,但到目前为了,这个功能虽然加进去了,却还没有发挥实际的功用。因为这段代码针对使用VC编译的程序会生成一个dump文件,该文件需要配合编译时的源代码以及编译器生成的pdb文件协同工作才会有实际用途,而我们的项目没有一个良好的机制把各个发布版本配套的源代码和pdb文件归档。  这些天看了《软件调试》,稍微了解了Windows的错误报告机制,觉得这是一种能很好改善用户体验,帮助开发团队改进软件的方法。  前段时间读Code::Blocks和CodeLite的源代码时,发现在Windows平台下编译时它们都动态装入了一个叫exchndl.dll的动态链接库,却只是装入,没做其他任何事情。根据代码注释中的只言片语,加上后来去down了Dr.mingw的源代码,发现这个dll就是做了捕获未处理异常,生成报告的工作。  于是,我就有了现在这个想法,也许这个想法就是微软的错误报告机制的简装版。首先,确定这套机制由三大部件协同完成:1、未处理异常捕获;2、反馈崩溃信息;3、分析处理崩溃信息。在具体实现时,可按这三部分分别处理,未处理异常捕获,就像exchndl.dll一样,只需要提供一个dll,应用程序只需要装入后,什么也不用管了;反馈崩溃信息,可以另外再写个客户端,将报告信息(文件)传送给服务器端;分析处理崩溃信息,也就放在服务器端了,可以自动作些简单的分析(像WinDBG那样的,配合对应的源代码和pdb,可以找到引起崩溃的代码行),根据这代码行,可以给用户显示个html页面,说明一下崩溃原因等等,当然这需要一定的人工介入,而且也是三部分中最复杂的。这些工作都可以通过微软提供的技术来实现,但还是有不小的工作量,比如像WinDBG那样结合pdb和源代码分析dump文件,这都是调试器的一部分功能了,另外再显示html页面,肯定是需要有先例通过人工编制一个页面。  而且这套机制似乎有个最大的不足,是只适用于VC编译的程序。也许其他的编译套件(Borland、DigitalMars、OpenWatcom、Intel……)也提供了类似的机制,但可能没有VC的完善,不需要人工分析即可定位到源代码行,这是何等方便啊!

CodeLite源码阅读

CodeLite源码阅读

  今天看了一段CodeLite的源代码,很小一段,从app开始看,到Frame。因为想学习使用wxWidgets,阅读现成产品的代码一种比较有效的方法。我并不知道到底有哪些程序是用wxWidgets的,到目前为止了解到的有FileZilla和Code::Blocks,以及这个CodeLite。  学习的主要目标是掌握如何创建各种类型的窗体,如果为窗体设置消息响应。如果在绝大多数情况下,都能比较快速熟练地解决这两个问题,那么基本上可以认为算是会用这个库了。  wxWidgets的处理形式跟MFC比较相似,都是有一个app类,代表当前程序,然后有frame类,表示主窗体,在frame类中再衍生出菜单、工具栏、状态栏等元素,也包括其他一些子窗体,比如CodeLite中,用到各种Pane,这些Pane通过wxAuiManager来管理,可在主窗体上依靠,或脱离主窗体浮动在外。CodeLite和Code::Blocks都用标签页(Tab)的形式作为主界面,也用标签页的形式做Pane,但两者在实现标签页时略有区别。Code::Blocks用了wxFlatNoteBook这个组件,而CodeLite则似乎是自己创建的一种组件,该组件将标签页头和页内容分成两个wxPanel来实现,标签页头部分又在这个wxPanel上使用Tab来展现出页头的效果。这样的好处是标签页头相比wxFlatNoteBook有更多的可控制选项,坏处则是需要自己写不少代码。  现在我最大的困难就在于,还是没有完全搞明白,这个界面是怎么创建起来的,一旦这个框架建立起来了,那剩下的业务逻辑部分都是比较清晰明了的,至少知道大方向上应该怎么走了。

《C++网络编程》

《C++网络编程》

  心血来潮地翻出照例买来即束之高阁的《C++网络编程》,尘封不止一年了,只记得还是在测试组时买的,而且确实连目录和序都没看过,汗!  这次也是因为项目里用到了ACE,看了一点《ACE程序员指南》(所谓的红宝书)中关于reactor中的一点内容,似乎勉勉强强可以凑出一个能用的系统了。才偶然想起,仅有的3本讲述ACE的翻译成中文的书我都有了。拿出这卷1和卷2,发现封面都泛黄了,这日子过得还真是让人哭笑不得!  不负责任地说一句,这两卷《C++网络编程》其实是套讲设计的书。书中以网络编程这个话题为目标,用C++这把究极神兵,辅以设计模式这高等心法,大刀阔斧地讲述怎样设计,为什么这样设计,最后凝结成ACE这套演示成果。  所以在我看来,这两卷最终成为学习使用ACE的入门及进阶的参考书籍,这样的效果只能说是原本功能的副作用而已。

《软件调试》

《软件调试》

  从china-pub上买了本《软件调试》,厚达1000多页的大砖头。开始拿到的前面有8页是空白,到china-pub上去说了一下,该书的责任编辑通过email跟我协商,最后又快递了一本正常的过来,我再把有问题的那本快递给她,如此服务质量,也让人称心满意了。  难得原作者用中文写成,这样就可以让我们中文读者第一时间可以读到如此重量级如此深度的精品专著。  该书从CPU(Intel x86系)对软件调试的支持、操作系统(Windows)对软件调试的支持、编译器(MS VC)对软件调试的支持三大方面进行了讲述,中间结合VC、WinDbg等实例进行讲解。  昨天晚上躺在床上,快速地浏览了一遍,让我深深感叹Windows,噢不,应该是微软的强大。微软从操作系统到开发工具,都为软件调试支持了极其强劲而且方便的支持,窥斑见豹,微软做软件是多么认真,多么负责,微软帝国的崛起除了机遇外,其自身实力和不懈努力是起主要作用的。  翻完这本书,我禁不住想自己写一个应用层的调试器,像OllyDbg那样的。粗略想一下,一个调试器需要具有的最基本的功能:反汇编、CPU寄存器读写、内存读写、单步、断点,以及跟系统相关性比较大的装载模块、内存映射、符号信息读取。这些在Windows上绝大部分都有现成的API可以完成了,除了反汇编比较麻烦点(看看IDA Pro做成什么样了,当然动态调试器是不需要这么复杂的),其他的至少从原理上看,是很简单的,困难的是细节。  嗯,WIND Is Not Debuggger……

ACE还算好用

ACE还算好用

  照着红宝书上讲的,用ACE写了TCP的服务器端和客户端进行文件传输,代码量真的很少,而且可读性也很好,虽然没经过测试,但我自以为应该不会有多少问题了。  ACE还算好用,呵呵。既然这样,以后就考虑一直用ACE来做这方面的应用了,又能满足我跨平台的需求。  另外,我还是想建一个图形库,像visio/rose那样的功能,也许功能没有那么强大,但是效果就是朝那个方向发展。

引入ACE

引入ACE

  经过小小的思想斗争,最后我终于决定引入ACE,这个颇具盛名的跨平台网络库。犹豫是因为2个原因,一是我本来没有使用ACE的经验,如果在使用过程中遇到问题也没有求助途径,另一是以前在网上看到过有人说ACE跟MFC配合使用时会有内存泄漏的问题。  但是想了想,如果直接使用socket来写的话,开发效率更低,需要编写的代码更多,更容易出错。之前也是用了boost::asio,大概是因为没用好,反正不但代码写得难看,也没有能照预料中的那样正常工作。  同事在一个小程序中使用了ACE,虽然他用的是WTL,却仍然无形中给了我一种鼓舞,最终我还是决定用吧,泄漏就泄漏吧,反正只是个小程序,不会像服务器那样长时间运行的。稍微熟悉了一下reactor的使用方法,还算容易理解。它通过类继承,虚函数覆盖的方式来响应特定的事件。相比boost::asio使用functor回调的机制,更OO一点,而对于我来说,boost::asio可能多了需要对各种对象进行管理的工作。  争取在剩下的两天里,完成点对点文件传输的功能!

期待一个合法的强大的IDE

期待一个合法的强大的IDE

  虽然打算使用MinGW+wxWidgets来写程序,似乎是可以抛弃VC+MFC或者BCB+VCL这类商业软件了,但是,实际上我发现我根本离不了VC,主要是离不了VAX,这个超级好用超级变态强悍的VC助手。  早先的时候,只用到VAX的智能联想提示功能和跳转到定义或声明的功能,自从看了Martin Fowler的《重构》,VAX的诸多重构功能也成了我目前最常用的功能,日常工作写代码,离了它简直痛不欲生。  写代码最好用的是VC+VAX,但看代码最好用的,个人感觉还是Source Insight这个虽然不思进取,但基础确实不错的东西。Source Insight也可以用来编辑代码,不过比起VC+VAX来还是弱太多了,而且它也是要买license的,最关键的一点易用性方面不足是,多少个版本推出来,还是不支持标签页浏览,真是不可理喻,而且对中文的支持也是一直都没任何改进。  所以最好的工具是能集VC+VAX代码编辑功能和Source Insight代码浏览功能于一身的。但是目前还没有找到能达到这种效果的软件,从免费到商业的,都没有。回到最开始提出来的,要用MinGW+wxWidgets来做开发,还是比较困难的,比较折中一点的办法是,先在VC里做debug版进行开发和调试,定期用MinGW生成release版本进行测试,先打造一个好用的CppCoding工具。

九选三,pass!

九选三,pass!

  周五的时候才知道,原来我报的是6月30日的考试,一直都以为是7月10日的,所以一直都不怎么着急,还觉得练车次数太频繁,殊不知是30日。周六吃过中饭,正在睡午觉,教练还打电话叫我下午去练一下车,我说不行,要5点半才下班,然后拖到周日上午。今天又是6点半就起了床,匆匆赶到训练场,跟江江一起练了一个半小时,单边桥的我老是右边上不去,教练说不要紧。  说好11点集合,还有2个小时空闲,于是无所事事地到百草园去,江江趁这个空隙跑去体检了,我就只好无聊地看看网页,偶然发现blogger又解封了,像是重刑犯放风一样。到10点半的时候去百草园对面吃了一碗炸酱面,太多油,腻死我了。刚好11点,教练简单讲了一下考试时的注意事项,然后把我们带到接送车的地方。  12点半不到就到车管所了,一直到大约2点半的时候才轮到我们考,当时我还多紧张的,可是抽到的是3道,除了定点停车和侧方位停车外,另一项是所有项目中最简单的直角转弯,真是太幸运了。一上去就忘了起步打左转向灯,心里顿时瓦凉瓦凉的。好在后面的都冷静沉着地正常发挥,不但是我,连电脑也是,一点意外都没有,一次就pass了,心中那块石头放下来了。  九选三,pass!