如今 Windows 软件开发究竟该用什么库，C#、Qt，还是其他？
但是说句客观的话，如果你只是为了Win平台的话，而且没有很高的性能的要求，还是C#.net好、、、
如果肯呢个平台多样，就去玩Qt吧、、给国内用户开发那种 1MB-100MB 内的、有官网要下载的 exe 的话，有一个硬要求：
使用 360 清除电脑上的一切缓存之后，冷启动 1s（0.1s 太苛刻了放宽一点）以内必须见到窗口。测试要求在 2013 年生产的 4000 元笔记本电脑上面进行，同时后台开着 360、QQ 和 Chrome，同时还在看直播或者看剧，使用内置电池。要用秒表测量。
除了裸 DX11 估计也就只有 @vczh 的库了吧。认真回答问题的来了：
我总结你的学习目的主要有两个方面：
1、制作Windows下特定用途的软件
2、想学习了解Windows的系统知识
如果仅仅针对 Windows 平台，C# 比 Qt 有太多优势，就像你在 Mac 下，Objective-C 肯定优先于Qt。从语言本身的角度来说，经过高度封装的C++某些时候还是不如C#来的方便，我个人来说，虽然Qt用的比C#熟，但偶尔临时做个什么小工具啥的，还是喜欢用C#，因为开发快，没别的。
Qt的优势，一是跨平台，二是高效率。如果你是追求这两个目的，就不用犹豫了。
你说Qt能写出酷炫界面，其实 WPF 何尝不是呢，想不到什么是前者可以写出，而后者无能为力的。
至于你想通过这两个玩意了解Windows的系统知识，可能很长一段事件都不太可能。因为这两者都太上层了，你很难见到下面的具体实现。就如写个注册表吧，Qt里QSettings、C#里Microsoft.Win32.Registry 都会让你感觉无比自然简单，谁会由此想到RegOpenKeyEx之流的痛苦难受呢。
所以，了解Windows系统最直接的办法，就是直接学习Windows API。
或者你可考虑了解下MFC、WTL之类？
PS：C++ GUI Qt4那本书不算老，深入学习，你会收获熟练的Qt技能，不会白费功夫的。现在市面上能找到的Qt5的书，都是扯淡。相信我。
现在的程序员啊，我问他们为什么不努力成为一流的程序员，他们说坑就那么多划不来。那我问他们为什么不随便学个用用，他们就说不能成为一流的程序员了。
我呸！
什么封闭开放，都比这些人强多了。这些人的理性水平之低，根本选什么东西来学都改变不了命运的。
顺便推荐一下www.gaclib.net ，跨windows/linux/mac/ios/android/wp的C#封闭是吧，我把它抄到C++顺便开源了，只支持windows，这样就开放了，啊哈哈哈。
c#是语言，qt是gui库，你的两个选择就不是一类东西，没有可比性。qt应该和wpf比较。如果只开发windows下的软件，c#是首选没什么好说的。
另外学习c#，还可以使用xamarin进行ios和android开发。
最后我不知道c#体现了微软的什么封闭思想？c#的语言规范早就公开到ECMA, c#的编译器也即将开源，nb的人可以自己实现个c#，我觉得已经够open了如果想开发界面程序，并且有能够深入理解Windows的机制，特别建议用WTL，WTL是微软ATL的那些人开放的一个WindowsGUI程序开发的模板库，无论是迅雷的Blot还是金山的界面库，还有腾讯的界面库，基本上都是在WTL的基础上搭建起来的，WTL解决了一个重要问题，Win32窗口类必须是全局函数，所以用类封装的时候，必须用一些取巧的机制才能顺利的封装窗口类，并且又不失效率，而WTL的thunk机制非常先进，成功的解决了这个问题。在追求效率和开发速度，WTL都做的不错，模板技术的使用使得编译后体积和运行速度远远优于MFC,C#没有Native的时候，WPF开发的程序一旦体积巨大，问题就会暴露出来。Qt，在Windows上体积太大，信号和槽的机制和Windows消息机制存在一定的差异，封装过程的代价还未可知。所以个人看法建议使用WTL，唯一不足是WTL并没有得道官方的正式支持，但代码依然在更新，最近增加了Nuget的支持。没有较极端的要求，我认为 Windows Desktop UI 正确的方向是 WPF。Per-monitor DPI Aware、硬件加速（Direct3D & DirectWrite）、XAML、灵活的布局、MVVM 以及强大的 C#（就说一点：用 await 写 I/O 程序）。说性能差什么的，都是哪年的黄历了，Visual Studio UI 也不算简单了，面对大文件瞬间完成语法高亮，内存占用也不高，只是吃磁盘 I/O（当然我相信这跟 WPF 没关系）。
比某些代码质量糟糕、用 GDI 渲染文字、不支持高 DPI 的垃圾框架不知道高到哪里去了。刚好C#、C++、QT、winform、wpf都懂点，我来跟你说说。
C++和C#是编程语言，QT、winform、wpf是三种技术（其实是三种写界面的UI框架）。
它们常见的组合有三种：
C++搭配QT；（C++搭配mfc已经过时，不推荐）
C#搭配winform；（我目前工作用这个组合）
C#搭配wpf；
你对C++和C#都不熟，而且只是想做一些称手的小工具的话，C#合适得多，开发速度快。
wpf相比winform来说设计理念更先进，当然如果只要粗略区分的话，可以认为wpf能做出更华丽的界面，而且对于不同尺寸的屏幕适配性更好。
做出华丽界面的容易程度（例如电脑上360安全卫士界面）：wpf ＞ QT＞winform
wpf的界面代码使用xaml 代码（类似于XML）写的，相对于winform的直接拖控件、改属性要稍微复杂一些。
wpf还有辅助设计界面的软件叫做blend ，这个就厉害了，不展开讲了。
总之，如果只要求快速开发，软件丑点没关系，那么选择C# + winform，如果想做出华丽的界面，特别是你本人还懂平面设计的话，选择C# + wpf （都只需要安装一个visual studio 就行）。
作为一个研究多年windows界面开发的人来回答下，我认为到目前为止没有真正完美的解决方案。是的，真的没有。每种方案都有自己的特殊缺陷，以至于谁都只能在自己特定领域玩。一个个的点评：
MFC、WTL：不用我说了，设计理念太老。窗口间的组合出控件这模式在windows上有很多bug（如windowless模式，窗口消息传递太多坑）。
qt：这个的主要问题是太大了。如果你要做互联网客户端，一定会对体积有要求，否则安装率上不去。
Wpf：这货就不说了，必须带.net， 而且首次启动慢，部署困难。xp没预装.NET框架。要知道这世界上还有15%左右的xp。但不得不承认框架的设计理念是非常优秀的。
Duilib：以及之类的界面库（soui、gaylib），这个是我研究最多的，然而深入的撸了几年后，我彻底放弃了。最大的原因是没有大公司支持，没有人员投入，你是做不完善的。
就比如设计器、richedit，文本排版，都是天坑。
然而，如果想做一款小巧的互联网客户端我还是首选这类库。原因是小巧，可控。不支持的效果以及缺陷，只有有一两年工作经验的程序员都可以hold的住。
Electron，以及nwjs：我比较看好的方向，但问题还是太大，现在不打包有100m+了！如果想做分发简直是恶梦。（当然我现在在搞的miniblink就是想解决这问题。只是目前里可用还有段距离……）
综上，如果你是个有2年C++开发经验，又想做个可以小巧需分发的客户端，最后还是要选duilib之类比较靠谱。毕竟代码量小，可控，有什么新需求好往里加。
如果不管大小，或者用户环境可控，那么选wpf吧，功能强大。
如果不是那么的在乎大小，但用户环境不可控，建议选QT。WPF部署起来还是麻烦了点，QT可以避免，而且QT效果也不错。
另外我想讲讲这些解决方案里除了electron这类的另外个大缺点：这些库或框架都是自己定义的xml（或别的配置方式，比如我，就是json），学习需要成本，招人也需要成本。而且作为开发，你学习了这套库，去别的地方可能完全没地方用。你的项目上一波开发人员跑路了，重新找人，成本要哭。
所以这是我推荐electron这类框架的原因。H5的方案，到哪都能招的到人，更关键的是，开源前端框架现在不要太多，要任何效果任何控件网上一抓一大把。曾经我是个H5黑，现在我弃暗投明了，H5带来的开发效率提升真不是别的框架能比的。
待续…
实名反对一切说 Qt 是 GUI 库的所有人！人家官方定义是 C++ Framework！跟 Boost 是一个级别的。
也就是说一旦你使用了 Qt，你就可以享有它一切开发特性，包括且不限于数据库、网络、XML、XML Pattern、3D、JavaScript、大量模板类，甚至 Qt 也有一套自己的声明式语言，用于开发富客户端，很是炫酷。而且 Signal / Slot 所有 C++ 实现中也是 Qt 实现得最好。初学者使用 Qt 完全与使用 .Net CLR 一样，学习曲线很缓和。
唯一的缺点就是太大了……基本赞同扫地僧看法，duilib没有资金雇佣优秀的人才去完善她也一直深以为憾。未来我也看好浏览器平台应用到桌面开发，因为目前桌面平台开放性和标准化程度落后太多。近期的方案，electon不太清楚，但nwjs bug和多，用户量大和需要长久维护的要慎重，两者的内存占用也很难控制。我个人觉得react native或weex应该去开发pc版本。不知微信小程序之类的平台会不会有pc版，pc版容器什么时候会native化，但感觉以后可能会有
如今已经2017年，我还经常看到有人，拿着Qt4的特性批判一番Qt，然后拿着C#的新特性，赞美C#。我没用过C#，没用过WPF，我也不评价这些，因为我没有亲自使用过、对比过，这样得出的评价肯定是片面的，不客观的。
但是我用过Qt，至少我能从Qt的角度来看这个问题。
首先我假设，开发只考虑Windows平台，那么我的结论是：
如果你已经有了C++的基础，并且愿意学习QML语言，那么可以考虑下Qt。要是没有C++基础，并且也不愿意学习，那么我不建议使用Qt，因为综合来说，学习成本太高。
我认为Qt现在的方向在于QtQuick这个框架，这个不但是我认为，从官方现在的宣传，开发力度来看，传统的QtWidgets已经基本不改动了，现在精力全在QtQuick这里。QtQuick其实就是QML开发界面，C++开发底层。那么这个角度来说，Qt4就已经淘汰了。当然Qt4里面确实也有QML，但是和5比起来差别是在太多。目前如果要用Qt，我推荐5.7这个版本。
当开发者可以熟练使用QML做界面，C++做底层这样的方式后，就可以发挥出Qt的优势：
首先是开发界面速度快，这是得益于QML本身结构类似于CSS（不是XML），并且有js用于做处理逻辑，开发效率自然不言而喻。不像是以前widgets时代，看起来是拖控件，但是想把界面做的灵活，还是逃不开用C++写界面的问题。
其次底层C++，保证了在界面快速开发的同时，在功能上也不失去灵活（配合C++11）和性能，并且伴有大量Qt的优质库，对于大部分需求，根本不需要找第三方库，直接搞定。比如说JSON解析、XML解析、数据库、日志系统、测试系统等等，Qt不但已经准备好，而且和Qt本身高度融合。
另外QML开发出来的程序，天生就是OpenGL加速，Windows上DPI什么的自然不是问题，想怎么适配就怎么适配。来个复杂的特效，上个粒子系统，也没有问题。
至于程序打包后，算上库，zip压缩后20MB以内肯定妥妥的。我觉得对于现代的一个程序，这不是问题。除非写的是什么超级小工具，一定要力求100KB搞定整个程序，那当我没说过。
对了，为什么说综合学习成本高，因为我看现在要用好Qt，不但要会C++，而且要会C++11，还要多学一个QML。虽然QML本身没多少东西，但是说到底也是一堆知识点，不是说1个星期就可以掌握的那种，也需要一段时间的学习和积累。
果断wpf吧，你既然想在windows上gui开发，去看看微软最新的技术不是很自然的么，再说wpf都10几年前的技术了。就像你在苹果的生态里自然想优先选择苹果自己推荐的技术，想上windows看看微软的呗。
我以前也喜欢别人一说什么就跟人争什么跨平台云云，现在戒了。如果你想开发windows软件自己使用或公司内部使用，强烈推荐使用Delphi. 就开发速度和运行效率而言，目前还没有任何一款开发工具或界面库能与其比肩。Delphi是桌面软件黄金时代的霸主，因为互联网的兴起而没落。但是它的强大是不可否认的。
目前delphi已经出到xe10，支持跨平台软件开发，win，mac，安卓，ios通通支持。而且紧跟时代潮流还推出了UI脚本语言，将界面与功能分离。如果你不需要华丽的界面，那么delphi7就足够了。
目前，桌面软件开发如迅雷，QQ都是用的DirectUI技术，有自家的界面库。很多小公司现在还在用原始又难用的MFC，简直是噩梦。免费的界面库有Qt，缺点是打包之后体积巨大。而delphi可以将软件打包成一个exe文件，体积很小，非常适合做小工具。
如果你不想用delphi，那么C# ＋ .net也是不错的。短平快的话：
1. Electron：js开发界面，可用cpp扩展
2. PyQt5: Py开发界面，可用cpp扩展
3. QWebView：js开发界面，py cpp做后端（非界面部分）
比开发速度，上面三个方案完爆c#
Qt5以后，Qt全面使用gpu加速绘制。
微软自己都很少用 WPF，做个 vscode还要去用 electron。
界面脚本化是大势所趋，弄个界面就该快，改两行代码按个快捷就该跑起来，避免改个文件一编译就等半天，或者出个bug找两天：
编码-测试-编码 这个核心工作流越短越好。上面三个方案都跨平台，况且人的时间本来就有限，上面几门技术学了你不亏，其他好多地方都用得上，关键是开发效率都比c#高。
再比较下性能：https://www.youtube.com/watch?v=8O-0k4MLKs8
Qt 5.6 MinGW 和 .NET 4.5 WPF 跑同一个测试，Qt 的速度是 WPF的两倍！
主要是两个技术序列：
1. 基于web技术的桌面产品，比如vscode，atom，Slack，网易云音乐，钉钉之类的成熟应用挺多，文档也丰富，问问题有人答，搜问题搜得到。
短短两年间，这么多来自微软，Facebook, Slack，Docker等公司的桌面产品使用 Electron开发出来，更多的可以到：Electron Apps 自己看。
2. 基于PyQt的桌面产品：DropBox client, R Studio, Calibre, Eric Python IDE, Spyder, PDF Catalog Creator for Magento，出活快，写小工具用它根飞一样，做专业系统可以和C++Qt无缝整合。
上面两张 R Studio / Spyder 的截图，PyQt做的，不算简单吧，这界面，想看酷炫的可以去看 PyQt的 demo，不要觉得 PyQt有多大， DropBox客户端打包出来 24MB，比很多手机app都小。
Electron 内核整合了 NodeJS，所有 NodeJS能用的模块 js都能用，比如：
node-ffi/node-ffi 模块，可以让你直接调用 C++写的动态库，不需要用C++写个node扩展：
var ffi = require('ffi');
var libm = ffi.Library('libm', {
'ceil': [ 'double', [ 'double' ] ]
});
libm.ceil(1.5); // 2
// You can also access just functions in the current process by passing a null
var current = ffi.Library(null, {
'atoi': [ 'int', [ 'string' ] ]
});
current.atoi('1234'); // 1234
Python/PyQt也有类似的接口。
WPF线上产品不考虑，不要看着你们办公室没人用xp就以为天下没xp了，你去二三线城市的网吧里看看，大范围的xp。现在这个时间点国内还有 45%的电脑跑xp，这问题三年内不会缓解，你要做线上系统你基本不可能抛弃这群用户，做内部工具又没有上面三个快捷，更何况跨平台问题。
虽然我承认 C#是一门好语言，但堆逻辑还是没有 js，python之类的快，且不管 C#还是 WPF，应用面太窄，学会了将来能用的地方也不多，不值得投入。而上面我给你推荐的三套方案，所涉及到的技术应用范畴都广的多，比如你学会了js/Electron，可以无缝把你桌面应用迁移到 web上，比如同时开发web版本，可以稍微该一下做成移动app，学了python/qt，也有好多别的事情可以做。
所以，学一个东西要考虑它本身的价值
ps：用过win32，owl，vcl，mfc，c#，tk，wx，手撸DirectUI，qt
不会坑你
--我 ++
竟然没人知道我的大Delphi在GUI开发领域就没有完美方案，每个技术方案都有缺点，而且根据场景不同各自缺点的严重程度也不同。
所以我的意见是，反正哪个方案都有无数坑，你有能力填哪个的坑就用哪个吧。
比如我，C/C++水平足够好，对Qt MFC都很熟，所以我敢用，有坑我能填，反正有源码，大不了自己去给它打补丁。
C# WPF不开源，遇到坑只能绕开了。
webkit JS，我不熟，遇到坑我是真没办法，所以谨慎选用。
大部分的坑是到了项目的中后期，用户量大了才能发现的，那时你想换框架早就来不及了。
比如 Qt 的 trayicon实现有兼容问题，大约有 千分之几的概率在Windows下托盘图标会出不来，用户量到了上百万的级别你才能发现，所以后来我自己实现了TrayIcon。
Qt的字体缓存当字体很多的时候非常占内存，一位同事给Qt实现了带内存压缩功能的字体缓存。
比较流行的框架，你遇到问题可以去搜索，去问人，比较小众的你到 Stackoverflow都找不到相关话题，只能自己搞定。
这就像有人总问 魔兽世界里哪个职业哪个天赋厉害一样，没有明确答案，因人而异，只能说你会用哪个哪个就厉害。
如果你问学哪个？既然你从iOS的 OC过来的，就学 C#吧！反正未来是属于托管语言的。
由于软件本身的复杂性，人们对软件界面要求比你想像得高得多，需要毫秒级反应，需要3d，需要解决卡或卡帧渲染问题，需要特效，需要换肤，需要直观，需要兼容老的电脑和系统，需要跨平台，需要安装体积小，需要低成本开发，需要保密代码，需要解决安装依赖问题，需要前后台线程同步问题，需要动态生成，需要用户定制功能，目前并没有完美解决方案。
满足以上要求的，目前比较成熟的软件界面库主要有QT，qt+webview可能比较适合普通软件，由于c++的复杂性qt也有很多隐藏的坑。各个大公司在研究UI上是花了血本的，花了无数金钱和时间才研究出定制的UI库，可见UI需要满足现实复杂要求的坑有多大，很多内部成熟的UI库实际上并不如QT来得稳定平衡，很多软件做得不行最大的问题就是UI做得不行。对于大型软件开发如果选择错了UI，会有机会成本问题，后面面临血本填坑问题，一旦选错UI对大型软件可能是致命的，需要做充分考虑。
个人看法。qt的话跨平台特性比较好。如果需要用到很多Windows特性的话，还是c#方便些。
如果是只在Windows上，那应当C#和WPF。
Qt也不错，只要你不嫌它大。注意要用Qt Quick、看Qt5的资料，不要用Qt Widgets，前者是从头来的新东西，比后者要动态得多。
