苛评MFC: 难以伸展的Windows控件

MFC封装了很多Windows API，但是最大的问题是，谁再去扩展MFC？ 虽然每个应用都在扩展MFC，即继承MFC来实现，但是要使得继承MFC的类得以重用比较困难。理由是：
1 消息大部分都被封装成虚函数，那么被下游开发者扩展的时候就受制与此。正因为如此，VCL的第三方控件非常丰富，而MFC的第三方则少，甚至比DLL还少。
2 如果存在WM_USER+xxx的消息总不免会与用户抢，但是VCL则不同，他自己有自己的Dispatch机制，该机制还能对非Windows控件分发消息。最好的印证是TSpeedButton为非Windows控件，但是它可以被XpMenu等第三方开发商得以扩展它的样式和外观，但是如果用MFC编写非Windows控件则难以实现这点。再看看Panel的对齐方式对于窗体的布局有很多好处，而MFC则没有支持，到了C#以后才抄袭。TPanel等控件的对齐方式正是通过自身的Dispatch机制实现的。
3 MFC的Windows资源没有得到有效管理。我们知道，MFC的SelectObject仍然使用Windows的管理，仍然需要用户自己去管理字体，刷子，画笔等等。但是TCanvas则不同，它自己管理这些资源。
4 MFC被MS抛弃，就是office系列自己定义了控件，又不开放。
5 MFC对于API的进步连机器码到汇编的进步都不如。
6 MFC消息不通过注册形式提供，扩展不容易。
7 MFC为非容器机制。 容器机制来合理分离控件的职责（与GTK+比较）
8 MFC 强制使用继承，使用麻烦而且耦合紧密。
9 MFC要从自定义资源创建窗体非常困难。但是VCL和GTK+都可以轻松通过代码装入自定义资源来创建窗体并响应窗体的各项消息。

最近在用MFC，老是怀念VCL，尤其是TCanvas。看到有人说VCL的三长两短心里不平。不平有二，1从设计上来说，VCL或GTK+肯定比MFC来得先进，2为什么国人可以有对这些玩意儿说三道四而没有人站出来自己设计一套更先进更完善的类库组建机制呢？是不是设计没问题，而盈利模式才是问题？