QT与KDE的版本对应关系
两者貌似基本是对应的。例如QT3.x出来后，KDE也升级为3.x；QT4.x出来后，KDE紧随其后也升级为4.x。
照这个比对，QT下个版本应该是QT5.x，然后KDE也升级为KDE5.x。。。
然而，现在Nokia将QT魔幻般地变回QT SDK 1.0！
KDE是不是该抓狂了？:-)
QT SDK与C4100编译告警
“warning C4100: … unreferenced formal parameter.”
QT SDK (VC2008)在使用qmake生成makefile文件时，缺省会打开C4100的编译告警开关。就我们的开发实践来说，C4100实在是个多余的告警，尤其是在C++程序中，我们经常定义一些虚函数等作为接口类，这些虚函数本身基本是空函数，由派生类重载出具体的实现。一旦放开C4100告警，VC编译器就看这些函数中没有引用的形参非常不爽，频频给出告警，实在是烦人。
我们可以在头文件中要求编译器忽略C4100告警：
#pragma warning( push )
#pragma warning( disable : 4100 )
void fun1(…){}
#pragma warning( pop )
这样做也有不好的一面，我们不得不修改.h文件，包括一些第三方库的头文件。另外，这似乎也破坏了跨平台的特性，和VC编译器绑定过紧（？不清楚其他编译器，例如gcc，是否也支持这种预处理指令）。
我们决定直接关掉C4100告警，修改以下文件（qt安装在d:\qt\4.6.2目录）：
D:\Qt\4.6.2\mkspecs\win32-msvc2008\qmake.conf
在这个文件中，找到QMAKE_CXXFLAGS_WARN_ON，将它后面的-w34100删除掉。
然后回到自己的工程，重新用qmake生成makefile，此时再编译，就不会有C4100告警了。
Nokia转向WindowPhone之后
MeeGo的发展固然堪忧，QT的发展也固然受到影响，不过受影响最大的应该就是Intel。如果生产出手机芯片，却没有任何一个厂家支持，确实让人烦恼；不能在手机芯片市场站稳脚根，其他移动设备市场即使占有较大份额，估计对Intel也没有太大的意义。
Intel想去寻找另外一个手机大厂来支持它的芯片和MeeGo系统，估计会比较困难。与其这样，为什么不向联发科学习？提供完整解决方案给中国的山寨厂家。中国手机山寨厂家的能力还是很强的，很有可能会对Nokia/Samsong/Moto造成极大的冲击，是手机世界里另一股不可忽视的力量。
Nokia居然选择了WindowPhone
这实在是一件让人费解的事情！作为一个老牌的手机开发商，居然放弃了最核心的手机操作系统部分！媒体拿moto作例子，moto不就是果断选择android才能重新崛起么？话是这么说，可是moto毕竟不像Nokia一样，moto手机部门是整个moto的一部分而已，而手机对Nokia来说，基本相当于命脉。积攒了这么多年的开发和人力，居然无法做出一个与iOS和Android竞争的系统，实在让人无语！
Nokia没有全力发展Maemo是一个错误，与Intel联盟发展MeeGo是另一个错误，转而与微软结盟可能是第三个错误。
当然，这些都是不明真相群众的围观看戏而已。让人忧虑的是QT未来的发展。
毫无疑问，Nokia这次的决定让QT处于非常尴尬的位置。坦率地说，这两年QT在Nokia的支持下发展非常好，4.x版本给人留下了非常好的印象。而现在Nokia据说只会给QT最小限度的支持，QT开发组裁员估计是不可避免的。现在国外各QT/KDE论坛都在热烈讨论是否有必要fork一个版本出来（感谢Nokia在4.x是发布了QT的LGPL版本），可见这个消息给QT开发社区造成了相当大的冲击。
作为商业开发，选择一个开发工具或者开发套件是一件非常慎重的事情。负责任的开发公司对已有的工具都进行了大量的投资（包括人力培训、产品积累、产品管理等），不可能像普通开发人员的个人兴趣那样随时转换工具，这期间涉及大量的版本迁移、客户支持、开发演进等各方面的重大变更。
而我们也恰恰选择了QT作为基础开发套件之一，并在QT上花费了巨大的人力、物力和财力！
即时最终QT社区fork出一个新的QT，在技术支持、开发质量等方面是否能保持目前的水准，也是个很大的问题。面对QT未来发展的不确定性，实在不得不深深地忧虑。
小红伞怎么了？
最近软件开发过程中，遇到一些莫名其妙的问题，例如，在VC2008 Expess环境中，一运行程序就弹出以下信息并结束调试：
the application failed to initialize properly (0xc0000235)
其他一些程序即使是运行起来了，也会有其他一些问题，例如打开对话框崩溃等等。
而在这期间，我们的代码没有任何改动，以前是好好的。
这个问题严重困扰了我们，不同程序出错的位置还不一样，有些甚至连main都没有执行到！我们为了排查，做了以下工作：
（1）重建所有工程，删除所有obj文件，重新编译。结果仍然异常。
（2）接下来只好重装VC2008 Express，重复第一步的操作，结果还是异常。
（3）重新安装QT，并尝试不同的版本，其间包括了对4.6.2, 4.6.3, 4.7的源代码重新编译（每次编译都耗费了3~4小时）！结果还是异常。
这不得不让我们怀疑是其他部分的问题了。在Google上搜索了最近一个月类似的问题，发现国外有用户提到了小红伞。恰好我们的环境中也安装了小红伞杀毒，于是我们也尝试卸载小红伞试试，结果果然是小红伞的问题！卸载完了后，一切恢复正常了！
小红伞在最近的升级过程中，究竟干了什么？
按条件编译版本
在我们开发的软件中，需要根据宏定义的不同，区分编译出不同的版本。例如，代码中有如下定义：
#if MSS_USER_VERSION == 1000… …
#elif MSS_USER_VERSION == 100… …
比较丑陋的方式，当然可以在代码中先定义好MSS_USER_VERSION ，然后再编译版本。但是我们通常采用自动化脚本编译，上述做法无法自动进行区分，需要人工干预。
我们希望在脚本执行时能通过设置不同的环境变量，从而自动编译出相应的执行文件。
以上述代码为例，我们可以修改qt的pro文件，增加如下定义即可：
DEFINES += MSS_USER_VERSION=$$(MSS_USER_VERSION)
脚本在编译前，先设置好环境变量，编译不同的版本，设置不同的环境变量值即可：
set MSS_USER_VERSION=1000
最后，如果只是单纯编译console程序，需要显示地在pro文件中说明，否则qmake缺省会按照window程序编译，导致在命令行中无法看到输入输出信息。
CONFIG += console
VC 2008 Express编译QT程序时产生MAP文件
MAP文件对于定位程序crash问题非常有用，一般情况下，我们总是希望能产生MAP文件以便将来出问题时好进行查找。
在VC 2008 Express中生成MAP文件比较简单，只需要修改工程属性中的link相关项即可。
可是在QT应用中，如何设置呢？这种情况下，是先使用qmake编译pro文件，然后使用VC的命令行方式编译程序，没有相应的VC工程进行设置。
我们可以修改QT在VC2008环境下的全局编译、链接开关。以QT4.6.2为例，假设qt安装在d:/qt/4.6.2目录下。
进入qt安装目录下的子目录： mkspecs\win32-msvc2008
用notepad打开该目录下的qmake.conf文件，找到QMAKE_LFLAGS项，将其修改为：
QMAKE_LFLAGS = /NOLOGO /MAP /MAPINFO:EXPORTS
注意，全部都是需要大写格式。
修改完成后，重新qmake各pro工程文件并编译，就会在生成exe/dll/lib的同时，生成map文件。
上述方法修改的是QT全局的qmake连接标志，编译任何工程都会产生map文件。在实际应用中，我们可能只是希望部分工程产生map文件，这种情况下可以修改工程的pro文件，单独添加QMAKE_LFLAGS即可：
QMAKE_LFLAGS += /MAP /MAPINFO:EXPORTS