WinxGui Home

很多人问WinxGui会如何发展？这里回答了这个问题：

http://code.google.com/p/winx/wiki/TodoList

广告：“【第二届】Erlang Fans交流会”议程 发布啦。

Q: 用了winx再用string就不行了，这个有什么办法没？

A: 怎么会呢？提示什么错误？

Q: vc6的stl的string

#error “vc++ 6.0 patch - std::basic_string has bugs, need to fix them.”

A: 哦，你先include <string>再include winx了。

应该先include <winx.h>，或者include <stdext.h>，或者 include <stdpatch.h>。

最后一个是最轻的。

Q: 哦，这样就可以了啊。还有，winsdk这个一定要放到../../../../winsdk去么？

A: 嗯。推荐各个sdk并列放。

Q: 一般是我已经有环境了，再加入winx这个库。现在为了winx似乎我的路径就要重新调整。

A: 当然也可以#define WINX_USE_DEFSDK，这样就不会要求了。

Q: 哦，还有这个define，我试试。

A: :)

Q: 果然可以了。

本文是应最近不少关注WINX的朋友申请加入WINX团队而写。感谢他们。

考虑到目前对WINX了解的人比较少，我决定暂时不采用团队的模式进行WINX开发。而是采用代码捐献的形式。这是开源社区中不错的一种开发模式，我注意到WTL、Zend等库都不同程度采用了这种开发方式。详细规则最近会公布。这里可以简单说一下。任何有志于改善、推广WINX的朋友，可以：

• 实现你觉得WINX需要但是目前未提供的功能。
• 在 http://www.winxgui.cn/task/ 上认领一个任务，并进行开发。
• 在 http://www.winxgui.cn/ 上与他人交流WINX开发的心得，或者提供WINX的开发帮助指南。
• 对 http://www.winxgui.cn/ 上的文章进行英文翻译。

你可以事先和我打个招呼（xushiweizh AT gmail dot com），在开发过程中我们可以聊聊进展情况，一起分析技术难题。如果发现有人和你做同样的事情，我也可以帮忙牵一下线。

最后，你的代码/文档如果被WINX采纳，我会在征得你的同意的情况下，把它纳入WINX的官方版本，并在 WINX贡献榜：WINX代码/文档贡献者名单 中记录下你的努力。

如何让WordPress只是在Blog文章列表中只是显示一个概要？

 

其实很简单，注意到上面工具栏中的被标记的图标了吗，把光标定位在你希望在Blog文章列表显示的“概要性描述”之后，点击改图标，即大功告成。

也许，读者最多的一个疑问，是为什么我把这个博客设置为需要注册才能够发表评论。那么我这里解释一下。

其一，减少垃圾评论。对于那些通过程序（或者人工）发布的广告，我将严格进行清理，而要求读者注册才能够发布评论，也是为了减少这类广告信息。对于那些匆匆过客，我建议你只是看过即可；如果你是WINX的长期关注者，我建议你注册本博客，并且我们会慎重考虑你的评论和建议。

其二，本博客不止允许注册用户发表评论，甚至允许发表自己的文章。我希望这个Blog是开放的，它可以成为C++开发者，特别是界面开发者，交流的平台。

其三，在将来，我希望把本博客更进一步发展，注册用户可以修改一些特殊的页面，如果文章的作者允许这样做的话。不过，这要在本博客引入版本管理之后才开放这一功能。我决定整合wiki的版本管理功能到WordPress中，使得它更象一个内容管理系统（CMS）。

不知道大家注意到没，本网站的页脚（右下方）有句话：“CODE IS POETRY”。这么美丽的句子当然不是我发明的。这是WordPress网站上的，我把它借用过来，是因为它正好表达了我设计WINX界面库的一种观念：写代码是一种艺术。你的代码就如同诗句一样，简洁而优雅。

Q: 我应该到哪里下载WINX？它支持哪些编译器？如何编译？

• 您可以到Sourceforge上下载WINX。链接：http://sourceforge.net/projects/winx/。
• 您也可以从Google Code上下载WINX：http://code.google.com/p/winx/
• 目前WINX主要分为3个包，您可以根据自己的需要，下载一部分或全部：
  • winx-xxxx.zip
    - 必需组件。这里xxxx是版本号，请下载最新版本的winx。
  • winsdk.zip
    - 如果您使用VC6.0，并且希望用WINX的所有功能，那么您需要它。
  • opencv.zip
    - 如果您是OpenCV的开发者，希望WINX和OpenCV一起工作，那么您需要它。
• WINX尽量采用纯头文件的形式，并且对C++模板语法的使用作了限制，故此理论上对编译器没有太大的要求。如果你遇到任何问题，可以和我联系。目前已经测试确认可以工作的有：
  • Visual C++ 6.0
  • Visual C++ 2003
  • Visual C++ 2005
  • Mingw32
• WINX对你下载后的各个包目录组织是有要求的，详细看这里。  

Q: WINX跨平台吗？

• WINX目前不支持Unix/Linux族的平台。它支持Windows家族（Win98以上），理论上它支持WinCE，只是我还没有具体进行过测试。
• WINX的发展方向是嵌入式系统等对性能（时间/空间）要求较高的系统。故此跨平台是它要走的路。

Q: WINX有什么特色？

我对WINX的概括是：MOST SIMPLE BUT EFFECTIVE（简单而高效）。展开来讲，它有以下特点：

• 卓越的消息分派机制。正是因为有这个核心支撑，使得WINX成为迄今为止最高效的界面库。
• 简单易用（SIMPLE）是第一目标，尽量使可视化（WYSIWYG）界面开发成为可能。
• 开放。WINX代码是可以和WTL、MFC等界面库的代码共存的。
• 兼容。尽管有更简洁的方法，但WINX还是提供了MFC程序员熟悉的调用界面，并尽量使得MFC代码可以轻松移植到WINX下。
• 不重复制造轮子。在没有一个卓越的解决方案以区别于现有系统之前，先沿用现有的。WINX建立于WTL之上，重用了多数的WTL组件。

Q: WINX为什么不采用Signal/Slot进行消息分派？为什么不借鉴AOP的思想？

• 首先，Signal/Slot是AOP中常见的手法，它是好东西，我个人不排斥它。
• 不过，Signal/Slot始终是AOP中重量级的手法。我说的重量级，不是它重要，而是它的开销大。所以，WINX必须采用其他的选择——更为轻量级的手法。
• 但是你仍然可以将Signal/Slot应用于WINX的消息分派，比如说应用于部分窗口。以后你将看到，WINX它支持AOP，支持Signal/Slot。只是它不用于消息分派，或者说在消息分派中它是一个可选组件。

Q: 你开发WINX的目的是什么？想到盈利吗？

• 开发WINX是我的个人兴趣。我从98年开始在DOS下写第一个界面库（图形界面的，当时还没有，不过也可能是我孤陋寡闻），那是一段难忘的经历。2000年开发了另一个界面库，并以此作为主题写了毕业论文。这个库称为SW系统，它基于Windows平台。SW系统还是很传统，有很多Turbo Vision（我接触的第一个界面库，它是字符界面的，TC++ 3.0的开发环境就是Turbo Vision所开发）、MFC的影子。WINX则是今年1月份开始写，最初是为了一个公司内部的程序作界面而写。
• 做库很有挑战，做界面库更加如此。所以对我来说这是在做一件很有意义的事情。从盈利角度来讲，我个人认为库（Library）很难找到模式来赚钱，所以基本上这个问题可以搁在一边。

未完，待补充…

我们以Hello, World! 程序为例，对比一下各个界面库的代码效率。对于界面程序，个人认为空间效率较之时间效率要占据主导因素，故此这里比较的是空间效率。另外，由于优化的极限是直接用Windows SDK，故此对比亦加入Windows SDK作为参考。参与此次对比的有：

• WINX
• WTL
• MFC
• SmartWin
• Windows SDK

功能：Hello, World!

界面：模态对话框

编译器：Visual C++ 2005

源代码：

• Windows SDK
  hello.cpp
• WINX
  hello.cpp
• WTL
  hello.cpp
• SmartWin
  hello.cpp
• MFC
  HelloMfcDlg.cpp
  HelloMfcDlg.h
  HelloMfc.cpp
  HelloMfc.h

比较结果：

首先，我们对比一下静态链接多线程模式的C库——即MultiThread(MT)时的情形。MFC亦以静态链接方式链接。由于所有的代码均静态链接进去，这种方式无疑是最公平的。对比结果如下：

• Windows SDK：48.0 K　Reference：kernel32.dll, user32.dll
• WINX：52.0 K　Reference：kernel32.dll, user32.dll
• WTL：76.0 K　Reference：kernel32.dll, user32.dll, advapi32.dll, ole32.dll, oleaut32.dll
• SmartWin：132.0 K　Reference：kernel32.dll, user32.dll, comctl32.dll
• MFC：184.0 K　Reference：kernel32.dll, user32.dll, advapi32.dll, gdi32.dll, oleaut32.dll, shlwapi.dll, winspool.drv

可以看出，WINX产生的代码效率最高，并非常接近Windows SDK，而WTL则次之。SmartWin虽然以模板构建，但是比之MFC并无太大的优势。

我们再来比较一下动态链接多线程模式的C库——即MultiThread DLL(MD)时的情形。MFC采用动态链接方式。这是大型程序典型的链接方式，因此这个比较结果也颇有意义。

• Windows SDK：6.0 K　Reference：kernel32.dll, user32.dll, msvc80.dll
• WINX：7.0 K　Reference：kernel32.dll, user32.dll, msvc80.dll
• WTL：28.5 K　Reference：kernel32.dll, user32.dll, msvc80.dll, advapi32.dll, ole32.dll, oleaut32.dll
• SmartWin：由于SmartWin编译的lib中没有MultiThread DLL(MD)模式，这里未针对其进行比较。
• MFC：10.5 K　Reference：kernel32.dll, user32.dll, msvc80.dll, mfc80.dll

尽管MFC采用动态链接mfc80.dll的方式，但是它生成的代码仍然不及WINX短小。

说WINX基于ATL/WTL，其实不是准确的说法。实际上WINX的最核心组件（Windows、Dialog、Control）与WTL没有任何关系。只是WINX的句柄类（CWindow、Gdi句柄如CPen等）、资源类（CMenu等）是WTL的实现。

虽然说从重用角度来讲，WINX确实是：ATL -> WTL -> WINX。但对于WINX的性能是不需要担心的。WINX之所以基于WTL，完全是因为并不希望重复制造轮子。但是WINX的窗口机制是独特的，完全区别于现有各种界面库。对COM的连接点事件（ConnectPoint）更是比ATL好得多，使得C++可以如VB、C#一般方便地接收来自ActiveX控件的事件。

我在开发WINX的时候，参考了众多的界面库，如：MFC、ATL/WTL、QT、wxWidgets、SmartWin++，还有sourceforge上的win32gui、vgui等。

我所遇到的第一个问题，是兼容谁的问题。这里的兼容主要是指使用界面的兼容。这个问题不是谁说了算。看看google趋势：

可以看出，MFC、QT用户占了绝大多数。这就为WINX的开发建立了基调：尽量让MFC、QT用户感到熟悉、感到Happy。

另外，我发现一个值得注意的问题：几乎所有的库均有一个“不良倾向”，就是让自己包罗万象，给用户一个完整的解决方案 —— 网络、界面、自动化、XML、OLE等等。 特别是QT、wxWidgets，这种倾向及其明显。

为了明确我不是万能的，WINX不是万能的，在开发之初，我就给WINX一个规则：接纳现有的库，如果不能够提供得更好，就告诉（建议）用户用什么。如果某个问题有多个卓越的解决方案，那么，用户可以自由选择其中一个。

所以，在WINX中，库的关系是平行的：
　WindowSDK：Gdiplus (GDI+)、MSXML、等等
　Xerces-C
　DirectX
　ATL/WTL
　MFC
　STL
　Boost
　Loki
　…
　WINX

而不是：
　　　/— WindowSDK、Gdiplus、MSXML、DirectX
WINX —- ATL/WTL
　　　\— STL、Boost、Loki、Xerces-C

试图让自己成为用户唯一所见，这是一个危险的想法，我认为是这样。

举个例子，用户希望读取xml文件。那么用MSXML，还是用Xerces-C，还是expat？我不能确定用户想要什么。有一点可以肯定的是，WINX不会开发出另外一个XML Parser。如果WINX的代码需要一个XML Parser，我会尽量在一个比较抽象的层次，为以上三者提供一个共同的界面（当然，不是抽象所有的功能，只是WINX所需要的），就如我们抽象WINX_ASSERT一样。

我们回头看WINX_ASSERT这个例子。WINX中是这么实现的：

#if defined(ASSERT)
#define WINX_ASSERT(e) ASSERT(e)
#elif defined(_ASSERTE)
#define WINX_ASSERT(e) _ASSERTE(e)
#else
#ifdef _DEBUG
#define WINX_ASSERT(e) assert(e)
#else
#define WINX_ASSERT(e) 0
#endif
#endif

这意味着什么？ASSERT来自MFC，_ASSERTE来自MSCRT（参见crtdbg.h）、assert来自C标准库。这里没有检测ATLASSERT，是因为ATLASSERT就是_ASSERTE。

尽管实现ASSERT功能并不复杂（肯定远远简单于实现XML Parser），但是我决定还是不自己去做。原因很简单：我没有打算对它作出改进。

最后我们谈谈跨平台。其实我一直在尝试找到一个方案，可以把平台的差异屏蔽。然而，有一点让我感到不安，因为没有谁可以真的做到平台无关，无论我作出多少努力。我要在Linux平台(甚至更多的平台)提供提供Gdiplus（Mono在做这件事）？DirectX？COM？OLE？还是我去告诉用户，不要用Gdiplus，不要用OLE，不要用COM，喏，这里有一个跨平台的方案，你照着办吧。

我会尝试让WINX跨平台。当然我相信只是最核心部分值得这样做。问题的重心仍然在于，你无权阻止用户喜欢用Gdiplus来开发。所以，跨平台的方案，永远有很多种。

尽管对MFC有这样那样的批评（这其中也包括我本人），但是MFC无疑是C++ GUI领域最成功的。WTL源于ATL，由于它的灵活、高效，而赢得了不少人的赞赏。然而要说WTL获得了成功，个人认为言之过早。看起来WTL似乎是“叫好不叫座”，并没有多少成功的产品是真正基于WTL进行GUI开发。

仔细分析一下，这样的结果并不奇怪。虽然MFC产生的代码笨拙，但是MFC的成功除了Microsoft大力推动之外，在于它生逢其时。它简陋的可视化开发界面，和自动代码生成，在当时基本上都是全手工界面开发的情况下，立即获得了青睐。而WTL恰恰是“生不逢时”，它出现于MFC大行其道之时，并且它的关注点在于“灵活，高效”，没有向导支持，所有代码手工完成，这无疑是一种倒退（MS可以强行开发基于WTL的可视化环境，但是WTL的特性并不太适合这样做，因为它“太灵活”了，这是它的优点，也是它的致命伤）。所以WTL仅仅获得少数有特殊需求的，对生成的代码尺寸非常注重的开发人员的推崇，但是Microsoft官方却弃之不顾（试为MS设想WTL可能的推广策略），其中道理不难理解。

WINX关注一个目标：简单而高效（MOST SIMPLE BUT EFFECTIVE）。WINX肯定了WTL技术上的先进性。故此WINX基于WTL，大量重用了WTL的代码。但是WINX除了高效外，更关注的是简单（SIMPLE）。

为了使得界面开发对程序员而言更为简单舒畅，WINX关注点不是在技术上，而是在对开发手段的革新上。WINX重用WTL只是一种手段。WINX重用的是它的实现，不是它的使用界面。

针对MFC的“长处”——半可视化开发，WINX引入了类似Delphi中的属性编程，使得多数常见的效果可以以窗体属性的方式进行表示。尽管目前尚且没没有专门针对WINX进行可视化界面开发的工具，但是它是WINX的发展方向。而且即使是在目前的简陋条件下，你仍然可以象MFC程序员一样，进行半可视的界面开发。

WTL脱离MFC程序员的习惯有点远了。这也是它让初学者畏惧的一个原因。WINX其实是更接近MFC的WTL：它提供了更接近于MFC的使用界面，并努力使得MFC代码可以更加容易地移植到WINX中。关于MFC代码移植，我们已经在WINX中提供了几个样例。有一点你需要理解的是，WINX并不十分关注将一个MFC应用程序移植到WINX下，因为那只有学术价值，但并不具备商业价值，我个人并不推荐你这样做。关于MFC移植，我的侧重点始终在于移植一些具备可重用性较高的MFC代码，例如MFC编写的控件等。

WINX可以取代MFC吗？对于这个问题我只能笑笑。我没有这个奢望。对于我而言，只是试图把我对C++程序员的几大困惑（内存管理、界面编程、自动化——Automation）的解决方案公诸于世，让更多人得益于它而已。从这个意义上来说，WINX只是侧重点在于提供界面开发的解决方案，但它不只是局限于界面库的范畴。