WINX与ATL/WTL/MFC的关系，以及跨平台问题

说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来开发。所以，跨平台的方案，永远有很多种。