本文对图形界面开发库作一个罗列，简单介绍各个库之间的特点和应用，详细的实现细节以及技术特点大家可以参考网上其它文章。

跨软件平台的图形界面开发库。此类库主要应用于X86平台的基于操作系统的软件开发，我们平常写程序希望既能在Window下可以使用，在Linux、Mac等平台也可以使用，应当使用这些开发库，它们都需要调用操作系统的API。

MFC。这是Visual C++使用的一个开发库，应用相当广泛，但是只能在Win下使用，据说在跨平台版本，但费用相当高。

JAVA。以“一次开发，到处运行”著称，使用虚拟原理，在每个平台上要安装一个Runtime环境来实现跨系统，但其运行效率也是一直以来被人垢病的缺点，而且需要使用一门全新的编程语言。

QT。非常强大的GUI库，应用十分广泛，而且有很多IDE支持，KDE、Opera等很多大型项目都是基于它实现的，但使用前你需要先确认下它的授权协议。

GTK+。与QT平行，功能同样非常强大，GNOME、Firefox、Wireshark都是基于它实现的，能很好的实现本地化（在Linux下使用Linux主题的样式，在Win在使用Win的主题），而且它没有QT那样烦人的授权协议。

wxWidgets。相比以上重量级的，它精简了不少，应用也是相当广泛，但好像完善性有待考量，看网上评价，好像有莫名其妙的问题出现，开源的FTP工具FileZilla就是使用它来实现的。

FLTK。更加轻量级，不适合繁杂图形界面，而且对字符集的支持有先天缺限，如果开发功能主导的、体积要求比较小的软件，可以考虑使用它。

TK。其实它只能算是一种脚本语言，在各平台上安装了运行环境后，可以使用简单的图形界面，一般不推荐使用。

对于该类图形开发库推荐两篇文章写得相当详细：

wxWidgets与其他工具库的比较(上)

wxWidgets与其他工具库的比较(下)

跨硬件平台的图形界面开发库。该类开发库一般应用于ARM、PowerPC等嵌入式系统开发中需要图形界面进行人机交互的场合，一般要求GUI不能过多依赖操作系统，一般由驱动层实现了画点、输入函数后，其它的都交由开发库来实现，如画按钮、标题栏等。

QT/E。全称Qt/Embedded，明显是用于嵌入式系统的，功能相当强大，当然也是所有GUI是体积最大的一个，推荐系统资源宽裕的时候使用，跟前面一样要考虑许可证的问题。

MiniGUI。功能、体积都稍逊前者，但许可证问题好像稍微好一点，一般嵌入式系统使用的工具的授权协议都比较严格，都是用来赚钱的，开发、学习用好像是免费的。

uC/GUI。Micrium公司开发的，与uC/OS同门，相比前两者，它要算是最精简的了，不过实现的组件也不弱，以前使用过，可以运行在无操作系统状态，上手非常快。

以上只是作者对于各个工具的一个初步印象，没有应用经验，表达难免空洞，只想给大家作个介绍，起一个抛砖引玉的作用。

直到接触了电子技术高度发展的产物――电脑，深深地被其强大的功能所吸引，更是羡慕程序设计员，他们能设计出各式各样的软件，让其在电脑上运行完成不同的功能。从那以后开始自学“步步高”上的Q/F-Basic，看帮助文档慢慢写一些运算程序，虽然很简单但也非常令我兴奋，极大地激发了我的兴趣。

初中末真正开始使用电脑，当时使用的是Win98，学习了基本操作和网络共享等知识。到了高中拥有了自己的电脑，开始全面了解电脑的软硬件，学习系统维护等，开始接触Visual Basic，完成了第一个图形界面的程序开发后，不断找资料自已学习，并且编写一些小程序。当时性格内向的我，非常向往坐在电脑前写程序的那种工作氛围，即使这很费神，我还是非常喜欢写程序，所以进入大学选择了软件工程方向。

进入大学真正了解了网络，从同学那学到了“动态网站”这个新名词。自此，结合以前HTML的基础从论坛推广开始，自学ASP/PHP、网站宣传、空间域名申请、服务器架设、Flash动画制作、PS/FW图像处理等，这样一路走来，逐渐得到了教师和同学的认可。

在一次开发网站的机会中，认识到了一位老师，这也许是我人生中的一个转折点。在我们沟通的过程中，他第一次地向我介绍了“嵌入式系统”这个概念。融合了软件和硬件的嵌入式系统软件开发终于在我儿时的梦想和目前的志向中找到了一个很好的契合点，他又向我分析了当前以及未来社会对人才的需求等因素，指出拥有多方面知识的跨学科人才是社会急需的。

在经历了暑假KTV系统集成以及代表学校参加的机器人大赛之后，经过仔细的考虑，终于决定向嵌入式迈进，而网站制作、系统优化、Flash动画等均作为辅助项目暂时放下。

第一步就是按照实验书上的介绍，制作了一个“基于AT89C51及ADC0809模数转换系统”的作品参加学校的电子设计大赛。在经历了实验箱硬件仿真、万能板单片机仿真、烧程序等一系列过程，克服了种种困难之后终于完成了作品，获得了二等奖。

随后选择了一款网上评论较多的三星44B0来进行ARM起步。为了能更快地熟悉硬件，所以单独购买了PCB空板，及相关电子元器件对照BOM及SCH进行焊接。完成之后，把例程跑了一遍，然后改了一些程序跑通了。由于这块开发块焊接完成后，经反复测试发现串口无法正常工作，又把USB(D12)学习了下，基本跑通了USB服务程序及上位机程序。

在随后的全国大学生电子设计大赛中，未用ARM而是用了一款功能非常强大的51单片机C8051F020。根据数据手册，将该单片机的所有功能写了一个函数库供比赛中使用。这个过程，让我学会了如何使用文档，更深入地了解了MCU的工作方式。

比赛之后，开始进行uC/OS的移植，目标板是LPC2142。选用这款ARM是因为体积小，自带Flash和RAM，并自带USB模块，内置的内存资源也足够跑操作系统，可以省去很多外围电路的问题。

后来又参加了“江苏省大学生素质拓展训练”灭火机器人项目，要求制作一个ARM平台的控制核心，所有传感器以及驱动器协同工作。经过半年的努力终于完了，顺利参加了比赛。

可以说，正是儿时的梦想、大学的兴趣奠定了我走上嵌入式之路。

很多人，在做一个项目前都不喜欢写详细设计，认为多此一举，浪费时间。我以前也是这么想的，一方面是觉得项目小或者根本称不上项目；另一方面，当觉得有必要写写文档的时候，最初还很认真的写写，写到中间，特别是遇到一些问题的时候就不想写了，有些东西通过文字也不太好表达。工作了，一开始也分不清基本、详细设计分别写什么东西，慢慢得写得多了，渐渐明白了两都之间的区别，当然对各自的作用也有了更深的理解，而且在写的过程中遇到的问题，也就是你写程序时会遇到的问题。

基本设计就是把一些功能模块列出来，模块之间的关系画一画；详细设计就要求把每个模块的实现都写出来，包括函数流程图、数据输入输出、函数变量命名、宏定义等，这样基本上两份文档也就出炉了。其实这个也就是要多写写，按文档来，以后就会了。

2、建立统一的错误处理。对于程序中的错误处理，做一个统一的错误处理模块，有助于出错处理。

这个吗，灵活运用吧，小项目上做个统一的错误处理模块开销还是比较大的。但是有一点，要提前为错误处理模块做好准备，比如在每处的错误处理模块上加个宏开关，以便Debug和Release切换。

3、非正式Code Check。代码写完后，尽力想什么因素可能破坏目前的模块，然后证明该情况不会发生。

这一点，我觉得根据不同的场合，不可能要求程序对出现的任何情况都能应付，一般把这一步放在单元测试中吧，单元测试可以用CUnit等自动化的测试框架进行；有条件的话可以在编码完成后使用静态编译工具PcLint(win)、SpLint(linux)进行测试下，如果能保证一个Waring都没有，那你的编程水平和编程风格那是相当地强；调试工具建议用GDB吧，在程序运行过程中动态修改变量值那是相当的强啊，这点我比较欣赏。

4、在确信正确之前不要编译。不要依赖编译器，赊望“下一次一定能成功”。

这个错误，我可以保证80%以上的人都会犯，即使是明知故犯，不多说了，相信我也改不了的，源于人的侥幸心理啊。

5、输入垃圾，不输出垃圾。程序的健状性在这里是作为优秀的程序应该总是能确保正确的输出。

要求对输入参数时行严格的Check，此处出现的问题应该能在单元测试中发现。

6、全局数据重入问题。子程序有重入问题，数据也有重入问题，防止数据在多个子程序中同时被改变。

多任务、多线程里典型的资源共享问题，加锁互斥访问。这里容易被忽视的是全局数据是资源、子程序是资源、子程序访问的全局变量也是资源，不要放过任何一个可以被多个进程、任务、同时访问的资源。

7、避免使用循环控制变量。尽量不要将循环控制变量用到其它程序的判断和使用中去。

这里说的重复使用，不是指循环完成后，把控制变量清零再计数等，而是指使用控制变量的记录的循环次数，放入到其它判断语句中去运用，最好添加其它Flag来进行判断吧。

8、合理使用递归。使用递归能使算法程序减化，但必需保证递归能中断退出。

递归使用要求比较高，难用，但用好了事半功倍，而且有些地方还只能用递归，如下某知名公司面试题：实现函数long strlen(char *p)，要求不使用任何变量。诸如此类的问题，当然就该题目而言是毫无意义的，花时间研究这东西不值得，即使研究出来用在程序中，影响阅读、降低效率也是没必要的。