Good Bye MFC?
原文地址在https://channel9.msdn.com/ShowPost.aspx?PostID=31152
起源是VC开发组的一个人的言论“MFC仅仅用于支持旧的代码，新的代码不应该用MFC编写，而是应该用C#或者Managed C++”
Blkbam的观点：还早得很
作者的观点：我在WFC 上的教训够深刻的了，我的时间被浪费了
Simo的观点：MFC会和NT内核以及COM机制一起坚持到底。Box先生的名言'COM is not dead - it's just done'.也可以用于MFC。VB6在慢慢消亡。
Charles的观点：这是进化。
Cider的观点：MFC死了这个观点至少吹了5年了
Sven Groot的观点：MFC停止开发并不意味着禁止你开发。.Net是微软当前的战略，但不是你的。
shreyasonline的观点：没有什么是永久的
作者的观点：MFC不会为新的API而扩展，而微软为了.Net把C++改得乱七八糟。所以我不认为MFC8值得用。我很高兴我还可以用Java。
Cider的观点：Java和C#都是C++发展出来的，所以不要只批评微软发明的托管C++。从你的经历来看，你不应该是个人云亦云的家伙，自己下结论吧。不过最大的IT公司在上面下了很多赌注，你跟哪边？
warren的观点：你在抱怨.NET的兼容性？Linux上不是有MONO了么？
Tom Malone的观点：MONO永远支持一个.Net的子集，但是服务器用linux和MONO，客户端继续用windows和.Net也不错。
Rossj观点：但是有个家伙保证了“只需一次编写，到处可以运行”啊。到底有什么语言是可移植的？
dweller观点：MFC成熟了。WinFX仍保持非托管接口
Mike Dimmick：MFC不是已经被改进来支持.Net和WinForm么？
作者的观点：如果有一个抽象层，那么我可以编写跨平台的代码。我的意思是我在上面投资了过多的时间，而微软又在推广新的技术。这在 WFC, VB k-6, masm, 和quick basic上发生过，现在轮到了MFC
Rossj 的观点：你有什么原因不使用Winelib么？难道它没完成么？
eddwo的观点：我看到你们对WinFX的托管接口非常感兴趣。但是我看到的有文档的高层API都是托管的。只有底层的Avalon API是非托管的。尽管你可以用非托管的程序处理中间语言代码，但是非托管程序会有Avalon的全部功能吗？
作者的观点：Winelib是个灾难，充满了问题。我想Windows Longhorn会有一个常规库，所以我会继续在Windows上开发，但是我会继续我在Linux上的开发，并且使用现有的跨平台开发方案。
