All Stories
之前说过想用Intel C++编译Qt来着，于是从VeryCD上找到Windows、Mac和Linux的Intel C++安装镜象不辞辛苦地下载下来安装。结果让人很沮丧啊。
在Windows 7中，无论编译64位版本还是32位版本，都会编译失败，我怀疑是因为Intel C++用了Visual C++的头文件引起的问题，但是我直接用MSVC2010来编译64位的Qt，虽然也是编译失败，却跟Intel C++报的错误不同，好像C++11标准的问题，在Webkit部分中有类名为nullptr，这个名字在C++11中作为保留字了。也不知道那些用MSVC2010编译成功的是用了什么参数。至于使用MSVC2008的配置，我就没兴趣编译了，因为我不喜欢MSVC2008的SxS。
然后在Mac中编译，32位版本也是编译失败，64位版本编译倒是全部通过了，但貌似make install不完整，那些头文件就没有复制过去，还缺了些什么不知道，反正直接把Qt源代码目录中的include目录复制过去是不能用的。于是也放弃了。
后来么，在Windows上下载了32位和64位的TDM GCC，编译了两个晚上才编译出来，话说那个-nomake "demos examples docs"参数不起作用啊。试了试编译Ninayan 64位，可以运行。
这两天看到Nokia的Qt论坛上有个叫Qt4iOS的人，说他做的Qt for iOS插件就要可以正式发布了，好期待啊。又看到有人说，Necessitas虽然还在Alpha版本，但已经可用性很高了，我看了下，现在居然已经提供4.8.0版本的for Windows/Mac/Linux的SDK了。不过在Mac上安装好后想编译Ninayan才发现，源代码还需要做些修改，比如源代码中通过预定义宏只识别了Windows/Mac/X11/Symbian/Maemon，但是这个Android不知道是什么宏，不知道上哪去查点资料看看。
于是最近还在网上看到的消息，是说Windows Phone的下个版本会支持C++开发，如果这样的话，Qt也会很快就支持WP开发。啊，如果Qt真能用于Android、iOS和Windows Phone的开发，那就太牛逼了。说实话，如果这些port的质量可以的话，只要价格不是太离谱，我应该会买这license去的。
春节放假时有一天突然想到Qt是支持用Intel C++编译的，有icc的mkspec，而且Intel C++在Windows、Mac和Linux都有，还能生成32位和64位的可执行文件，于是就想试一下，如果确实可行，以后就不用GCC了，虽然GCC也很好。
比较囧的是，在Windows上，Intel C++除了最核心的编译器，其他的都是用Visual C++的，比如运行时，甚至包括nmake，于是很不幸的是nmake貌似不能通过命令行参数指定并行编译，只能单线程编译了，纠结。
自己编译Qt的话，Windows和Linux都要为32位和64位系统分别编译，Mac倒是只要编译一个就行了，但是有个小问题是上次在Mac OS X 10.6.7上编译Qt 4.8.0时64位版本到后面有个什么库没有，于是只能编译32位版本了，囧。
1月21日下午3点半就从公司走人了，到柯桥、绍兴路段堵了一会儿。
除夕，小丫头给我发短信说最近遭遇了很多很多不幸，跟做梦似的。她爸爸过世了，给人家干活时从屋顶摔下来。她自己流产了。我不知道自己可以做些什么。橙子在Facebook上说，还是放不下吗。我说，我想关心她，却没了以前的那种男女之情，倒有点像亲情。
春节的行程比较充实，初一中午在家接待干妈一家，晚上去干妈家。初二去大姨家。初三在家休整。初四接待大姨小姨，下午还去上坟。初五晚上去小姨家。初六，就是今天，到上海。
木有宽带的日子，真不习惯啦！
今天彻底打酱油了，我们shared dev team也只剩下我，老大和Jason三个人了。因为晚上2点才睡，才睡了不到6个小时，于是下午就坐在办公椅上睡了近1个半小时，最后是被他们讨论一个bug的声音吵醒的，啊哈哈，老大还说让我看一下，现在只有我在这方面有经验了，我囧，我完全没经验的说，后来还是Sherman厉害啊！ 再后来，就跟老大讨论了一会儿C++ singleton的实现，以及跨DLL数据引用等等。问题是有个Watson的bug，我从一次crash的call stack中发现，程序在调用_exit后，该程序中的static object应该是已经瞬间被无声息地干掉了，所谓无声息的，就是说，连它的析构函数都没被调用的。但这时嵌入的CLR还需要做一部分扫尾的工作，而恰恰是这扫尾工作又反过来调用了那个貌似已经被干掉的static object，于是程序crash了。当然这只是我的猜测，我猜测嵌入的CLR就是要生存周期长一点，于是一直在代码中试图找一下它是怎么从C++端嵌入CLR的，然后怎么用CLR的。我发现的情况貌似是这样的，先用Managed C++写了一个dll，这个dll可以在DllMain，还可以导出函数，而据我前些天才知道的知识，.NET编写的普通的DLL形式的assembly跟原本的DLL不一样，没有DllMain的。而这个DLL通过导出函数返回一个对象的指针，这个exe程序通过GetProcAddress获取导出函数，再调用这导出函数获取对象指针。这个返回的对象呢，是个CLR Bridge，也就是说，通过这个对象，可以从C++端创建CLR中的对象，调用CLR对象中的方法等等。也就是说，从代码中，我没看到Jeffray Richter在《CLR via C#》中说的那种CLR host的方法。现在我仍然在怀疑，是不是我代码没看全，但我确实之前也在整个代码目录下搜索文本，没有那几个用于host CLR的API调用。似乎有点跑题了。然后我就跟老大说了一下我发现的这些情况，略微讨论了一会儿，老大表示自己也不知道，唔，其实我也不指望他知道，只是有这么一种想跟人分享自己的发现的欲望而已。基本上，我就觉得这很可能是此bug的root cause了，但老大说可能只是个cause，而不是root cause，好吧，其实就是缺少验证而已。一个比较有说服力的验证方法是自己用C++写个小程序，然后用相同的方法调用CLR中的代码，最后能制造出同样的crash，只是我最近木有动力去做这些事而已。另外就是，即使确定了这是个root cause，简单地说来，这个root cause应该就是对象销毁的顺序不对，这是可以肯定的，但之后也不好fix，因为这个程序实在太庞大了，有很多对象，然后引用关系也很复杂，以我目前对它的了解程度，根本没能力对理顺这个关系，于是也就fix不了了。而且还有个另外的问题是，那个static object是该程序中用于实现singleton的一种方式，我觉得比较奇怪，老大说，这是为了应付多线程的情况。还有种应用多线程的singleton实现方式是在create instance时加锁，唔。关于这个话题，在前段时间看到TopLanguage group中有个讨论，提到boost中某个库中的singleton实现，貌似很干净的实现，不用锁，也不是static object，能适应多线程，囧，具体的不记得了，貌似boost中有好几个子库中都有自己的singleton的实现，得再去看看代码才行，另外好像《Modern C++ Design》里也有对多线程singleton实现的讨论，春节放假看看去。 话说，今天还看到Mono，发现除了有Mono Touch外还有Mono for Android，不过免费试用版都只能在emulator上跑，最便宜的个人版license也要399刀。不禁大骂Qt的不给力，为毛只能为Symbian和MeeGo用，Android port至今还在alpha...
有个同事，平时看我在公司里用手机连公司的WIFI，很是眼热，一直问我怎么用。我就告诉他，要装个ProxyDroid，而且手机得root先。这样持续了将近1个月，今天他突然跑过来对我说，都怪你都怪你，现在我的手机刷得只剩下闹钟了。原来他的HTC G12昨天被他用什么一键root软件强行root，结果不能启动WIFI了。于是今天中午和另一个同事一直在OF外面折腾这手机，希望能恢复WIFI。结果还是没有什么进展，而且最后从网上看到，似乎他的G12是所谓的木马机，笑死了。
今天看到，豆瓣推出阅读器了，除了Web版和iPad版，毫不意外地有Kindle递送服务。说起Kindle，之前有一段时间我非常想买一个电子书，当时只考虑了1000出头的Kindle3和500左右的Bambook，不过好在每当一有这种强烈的购买欲望时，都有一股理性的声音说，你不是个爱看书的人！然后就拖到现在也没有买。自从上次去上海图书馆，亲自把玩了一会儿Bambook，非常庆幸自己没有一时冲动买了这么个设备，这页面切换的速度太慢了，效果太难看了，版式也很丑，啧啧！不知道Kindle到底怎么样，得找个地方也亲身去体验一下，才能决定到底能不能符合我的要求啊。
把Charles Petzold的关于打印的那章代码拿来都试了一遍，发现PopPad工程里的过程就是我想要看的。对比了一下代码，沮丧地发现貌似两者只有获取到DC的方法不同，PopPad里是PrintDlg返回的，而bug里的代码是通过CreateDC创建的。但之后也发现了，这个代码很奇怪啊，不但有CreateDC，还有CreateIC，经过调试发现，大部分时候都是在调用CreateIC的，这让我纠结了好一会儿，想不明白为什么要调用CreateIC，MSDN上明明说的CreateIC返回的DC是不能用来画东西上去的，只能用来查询信息的。又经过几次调试，发现CreateDC是在打印前在调用了n次CreateIC后最终会被调用一次的，这时候才发现，传给CreateDC的DEVMODE*居然里面的dmCopies值一直是1，而我明明需要的是2啊！于是我就猜，是不是application层把明明是2个copies合并成1个了，然后相当于只打印1个copy，于是打印机的设置只对第1份copy起作用。因为这个猜想，又小小地郁闷了一把，该不会要去调试application层的X++代码吧。不过马上，在kernel层的call stack乱翻，翻到其中一个地方，硬是把所有dmCopies值都改成1了！把这行代码注释掉试了下，果然如愿可以把设置应用到第2份copy上了。我猜，当时这代码的作者大概是考虑到不是所有的打印机都支持multi copies的，所以干脆把这个字段都改成1了。然后就是写邮件啦啦啦啦啦！
这事一了，人突然就松懈下来了。
又回到以前那种每次写blog都是写工作内容的流水帐的状态了么，这是不是意味着离我辞职又不远了。
好吧，上午还是在继续折腾SQL Server版本兼容性的bug。主要的代码昨天就修改完了，今天要提交code review，就再仔细检查了一遍，然后发现，因为多加了一个.cs文件，于是在enlistment的根目录下build所有工程的时候，某一个工程会出错。之前加了这文件，是直接在某个目录的sources文件，嗯，类似于makefile的一种文件里，添加了新增加的那个.cs文件路径就好了。于是在整个enlistment里搜遍了所有sources文件里的内容，愣是没在其他sources文件里找到有引用这些文件的。后来看了一下error log，发现它是在进入某个目录build时报的错，到该目录下又不死心地看了下sources文件，没找到要添加文件路径的地方。后来看到一个.csproj文件，打开看了一下，死马当活马医，把新文件路径加进去再build，居然通过了。艹，这个build system太贱了吧，不同的工程用不同的描述方式。
下午继续折腾打印设置不生效的问题。好吧，一点头绪都没有，一点进展都没有，跟几个同事讨论了下，几乎也没有有价值的提示。现在还剩下两件事可以做，一是试试其他report的打印有没有这个问题，这可以基本上确定root cause是在application层还是kernel层，大体上我现在是比较倾向于认为是kernel层的问题，大概就是打印API使用的问题。二是自己写个打印demo，仔细观察一下打印API的工作方式，也就是通过这个demo来模拟bug的运行流程。
好吧，我又无聊了，又写工作上的事了。
今天可是过得很纠结，两个bug开始全都一愁莫展。一个是打印设置的bug，搜索了一下以前的相关bug，看现象跟我现在的这个很类似，结果人家只是改了一下DOCINFO中的datatype字段的取值就搞定了，到我这里就不知道该怎么进行下去了。下午就在折腾另一个bug，安装程序在安装extension时只检测了SQL Server 2005和SQL Server 2008，于是在只有SQL Server 2012的机器上进行不下去了。需要修改的代码还是有好几处地方，照样画葫芦地改了一下，结果拿给人家测试时因为强命名的问题折腾了近一个下午。这里顺带提一下，如果把assembly拿到64位的Windows上去测试，用sn添加验证入口时不光要用32位的sn添加一遍，还要用64位的sn添加一遍。而且要注意的是，这个sn运行是在测试机器上运行的，不是开发机上。后来才知道，原来tester们有一个job跑一下，一台测试机就可以彻底屏蔽掉强命名的验证的，叹气。不过还好后来在在下班前终于编译了个private build让tester去测试一下，晚上回住处后看了一下公司的邮件，tester说在32位和64位机器上都测试通过了，稍稍心安了一点。
晚上team building，在蜀香村吃饭，算是农历年年前的散伙饭。Fiona也来了，她在元旦前辞职后就没见过了，估计这次也是最后一次见她了吧。她比我稍微晚一些日子进的team，实际上她是build team的，接触并不多，只有过两三次因为build上的问题打过点交道，但感觉是个很nice的人。很瘦，说话轻声轻气的。
自从两年多前从老东家辞职以来，这是第一次进图书馆吧。
交了100元押金，办了张普通的借书证。用RFID技术的整个图书馆流程上基本可以做到无人值守也能很方便地运作。
去一楼的中文图书外借馆里看了看，书并不很多，甚至感觉跟以前我读的那大学，以及以前那那东家的图书馆里的藏书差不多多。可能这里的特色是古籍，珍本，孤本什么的收藏多吧。另外，几个阅览室里的座位也并不多，而且无一例外的是没有空位的。
总之，比较失望。
