更新：擦，本来只有一句话，推荐Qt，远离微软，有人追问，补充了点，有人又追问，又补充了点，然后出了趟门回来，感觉跟捅了马蜂窝一样。既然都说到微软了，那就接着展开一下。&br&&br&&b&问题的本源&/b&&br&&br&微软就是战线太长了，忙着去主导各种标准，制订各种框架，这样的话，才能更好的夹带私货，用一个你必须用的东西推进另外一个他想让你用的东西，诸如dx和windows，诸如c#和 &a href=&///?target=http%3A//asp.net& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&asp.net&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&，而又因为主导了开发者，才能进一步主导用户，而主导了用户，大量的利润便会随之到来。在整个链条中，如果消费者没得选择，开发者也没得选择时，微软就能想卖啥就卖啥，完全基业长青了。出个新东西没关系，不符合我的利益我就不支持。如果新东西很有前途，那我自己搞一套，然后再把我的开发者和用户绑架过去。&br&&br&到底哪一个方向会有前途呢？微软自己也说不清。到底哪个领域对今后的软件生态影响比较大呢？微软自己也道不明。只能朝着各种有苗头的地方去努力，以前技术领域比较窄，微软可以囊括整条产业链，编译器/IDE/框架，开发者基本可以躲在微软的圈子里不出来。后面各个技术领域蓬勃发展，分支越来越多，微软就有些力不从心了。但是战略依旧没变，任然试图去主导任何一个技术领域的标准。利用自己的影响力去忽悠各种开发者：“跟我来吧，有美好的明天”，但技术领域每天都在推陈出新，产生新的细分。为了主导更多的新领域，称霸完一个领域后，微软的重心并不是完善该领域，而是继续集中精力称霸其他新的领域。&br&&br&对于支持期的技术，微软会利用自己强大的影响力进行各种捆版整合，告诉你：“新的革命又到来了，你准备好了么？”，告诉你：“用了它之后，你就什么都不愁了”，“XXX即将停止支持”，然后各种社区中，一堆mvp前扑后拥的进行推广：“XXX大法好，MS法力无边”；书店的柜台上，瞬间多出几十本红色封面黑色封面的宝典；CSDN的主页里，各种微软 TechED, 夏令营。很多人一看，我靠，全世界都在用，我再不用是不是就要被淘汰了呀？&br&&br&完成支持后，微软进入绑架期，为了不让你用其他的东西，微软想尽一切你的需求，然后为满足你可能的一切需求，开始拼命的飙版本，来兼容各种各样的东西。很多人觉得这个东西好像挺强的，什么都能做，不用学其他了，微软就笑开花了，觉得可以绑架大家了，于是开始疯狂的用该技术夹带越来越多的私货，或者是新技术，或者是为了强迫其他人用另一个东西，为了兼容这些私货，继续飙版本，这就叫绑架。&br&&br&等到你积累了越来越多的代码，或者成熟框架后，你突然发现，原来你能做的事情，就是只能在微软给你划定的一亩三分地里面不断的耕耘。想用它开发一个微软商业上不支持的东西？没门。依赖微软越久，做出选择的成本越来越高。这时会有两种结局，第一种，微软给你指出下一个革命的方向，你别无选择，斩断原有积累投入到下一个革命中。异或，微软觉得自己在这个领域江山稳固了，竞争对手都没了，不会再出什么幺蛾子了，于是彻底开始不思进取，你用着过时的技术干着急。&br&&br&曾任微软副总裁的李开复回忆：“一个产品队伍一旦失去了假想敌，就会松懈，盖茨和鲍尔默也会撤回对它的投资和支持。比如说，微软IE击败网景之后，微软就降低了投资，致使它的浏览器多年没有再进步，直到又出现了‘火狐’这个敌人，才又开始振作。”火狐就是网景的“遗孤”。&br&&br&&b&微软的绑架&/b&&br&&br&MFC就是一个很好的例子，当年同 VCL竞争时挺上进的，VCL一死，MFC也跟着死了，现代的界面系统都是 windowless直接绘制控件了，笨重的mfc还在基于系统控件。大量的onpaint自己做，人招不到不说，工作效率奇低，熟练的mfc工程师还比不过学习Qt一个月的学生开发效率高，你说我会选啥？mfc还需要各种奇巧淫技才能达到 qt的效果，弄那些技巧的人变动，项目就傻逼了，考虑到这一点，你说我又会选啥？最近两年界面开发又开始脚本化了，你会发现 Qt有各种支持脚本（除了内嵌支持 js的 QtScript外，还有 Python的 PyQt，还有 Lua）任你选择。核心代码C++，逻辑界面python，用过脚本开发UI的人都不会想用回C++写UI，因为界面逻辑脚本化可以提高至少两倍以上的生产力。微软的策略呢？想用脚本？没门，因为我不推脚本但是我推c#，所以你想方便的写高级界面？还是跟着我去弄 .net和wpf去吧，这就叫绑架。面对绑架你别无选择，开发者微软系的代码和经验积累越多，想离选择非微软的东西成本就越高，想不被微软绑架的代价就越大。&br&&br&为啥有人愿意给 Qt脚本化而不愿意给微软的界面系统脚本化呢？并不是微软的技术就比不过Qt，而是大家唾弃微软的臭脾气，外加Qt是开源的，为它实现脚本各种方便。这里并不是说开源的东西就一定比微软的东西好，微软有很多领先的技术甩开源几条街，主要问题在于微软的封闭性。所以我的论点并不是一定要用开源，而是建议大家有选择的余地下，选择非微软技术，比如qt, flash这种。&br&&br&&b&死也要主导行业标准&/b&&br&&br&为了引导行业标准，微软很多设计的很好的东西，各种音视频格式，还有最近的 HD Photo图片格式，比 jpg2000 和google的webp好多了。但是很多人由于微软的封闭不买微软的帐，很多框架和软件都直接支持webp了，也没几个人支持wdp，在这种情况下，我宁肯选择次一等级的 webp。&br&&br&微软的出过很多标准性的东西，比如wmv, wma格式，当年挺先进的，微软也天天忽悠人去用这两个格式，但是由于封闭，最终失去支持，大家选择了更加开放的方案来代替，微软也就不思进取了，最终视频领域 现在是 h.264/265，音频领域是 he-aac v2。&br&&br&微软又试图代替 pdf，引领该领域的标准，然后自己出了一个 xps。论技术，确实高于 pdf很多，但是没人用呀，没软件支持呀，连打印机都只支持扫描成pdf格式。所以我选择 pdf并不是因为 pdf技术比微软强，而是因为它不是微软的。而且我估计个两年出个 pdf2，xps也就跟 wmv一样进棺材了。&br&&br&再比如 SilverLight，微软在没有太大把握的情况下硬推这个东西，就是因为怕c#由于满足不了RIA使得C#开发的开发者流失到微软以外去，为此 .Net还逼迫大家升了几个版本。可惜，大家都知道的，于是微软自己对它的支持都少了很多。&br&&br&你说微软技术弱么？不弱。那为啥这些明显乱七八糟的东西微软都要硬撑着试图主导行业标准但是最终又主导不了呢？那是因为我们先前提到的微软战略，从几十年前到现在都从来没有变过，然而时代变了。&br&&br&&b&Win32 API&/b&&br&&br&Win32 是系统层最稳定的接口，一切功能的基础。这么基础的东西，微软该化大力气持续发展对不对嘛？非也，随便举两个例子你就会发现其实它已经落后世界很多了。微软是任性的，觉得我提供的开发模型可以解决一切问题，为什么要参考其他操作系统改进呢？即便其他操作系统提供的功能很好，我也要给你挑挑刺。而按照微软一贯的规律，系统 API领域，我完全控制了，那么我改进的动力也就不那么强了，庶民们岂能妄自议论 Win32 API，更别说想提交改动 patch给我了。&br&&br&线程同步：如果你写线程同步，你会发现 Win32 API缺很多关键的东西比如：条件变量，读写锁，这两个最基本的能够组合成其他任何同步模型的东西，微软直到 Vista的年代才提供支持（msdn Condition Variable），这就意味着，你如果用了，你将面临很难在 xp下跑的情况。你问微软 xp怎么办，微软说用 event去 wait嘛。你就奇怪了，event这么弱智的东西能代替条件变量么，为啥不再xp年代就支持了？&br&&br&单次初始化：pthread_once，没错，windows下面由于缺少这个东西，你再做一个全局变量供你的接口访问时，你需要保证该变量只被初始化一次。即便多线程同时调用访问该变量的接口，也不会出现两次初始化的情况，pthread_once就是做这个事情的。直接把代码写成：if (inited == false) { init(); inited =} 线程又不安全，外面加一个 CriticalSection，那你又需要在更前面去 Init这个 CriticalSection，还要保证不会发生多次 Init，问题还是没解决。于是很多人在 Windows下的解决方案是，在全局变量声明一个类的静态实例，这样 main()之前，那个类的构造函数能够提前被调用，进而又引入了新的问题，及多个全局实例又会存在谁先谁后被构造的问题，你又得用恶心的 #pragma宏来解决，最后初始化代码一团乱麻。而如果微软提供 pthread_once类似方法，那或许这一切都会变的很清爽。&br&&br&网络接口：用过 winsock接口的人都觉得简陋，你想实现高性能的网络服务，需要控制 TCP的大量细节参数，比如 TCP_NOPUSH, TCP_CORK, 还有 QUICKACK这些控制调整 TCP面向流量优化或者面向流速进行化的基本功能，winsock上看都看不到。更别说 Google的 TCP速率优化（Kernel 3.2.12收录的 Google patch）等现代功能了。即便是对比最基本最传统的 posix套接字，winsock的行为也是错乱的，比如 REUSEADDR，再比如 Win32下你监听一个 UDP端口，给远端发送 UDP数据包，如果远端没有监听该UDP端口，那么你服务端收到 icmp: port unreachable后，那个udp socket就彻底被 reset了，后续什么数据都读不进来，持续给你报 10054，搞笑吧。除非你创建udp套接字时做一大堆 *windows独有的* 专门的设置，否则vista之前，你都会被 10054。vista之前，默认情况下，客户端如果拒绝收服务端的 udp包的话，服务端的 udp套接字就用不了了，这是不是在搞笑么？还有各种基础功能限制，比如：缺乏poll支持（强迫你用iocp代替），select最多64个fd，没有 socketpair。当然，没有这些也可以写网络应用，但写惯 unix下的网络代码突然来 win下写，就会觉得这真是个玩具呀。&br&&br&TLS：TLS有数量限制也不管了，但是线程本地存储这个东西是需要 destructor的，即我创建了一个本地存储来存一个对象，我可以设置一个 destructor函数指针，在线程退出时，这个函数会被自动调用到。比如你想实现一个 per-thread cache（比如类jemalloc的 arena），线程退出时能够被自动析构，这个最基本操作在 Win下却可以把你别扭死，原生TLS API没有这个支持，你又不想所有线程退出都要强迫使用者调用一下 destructor，那么你开一个线程监听所有线程？还是怎么招？看看 boost和 jemalloc这些在 win下的 destructor实现，你就会发现恶心的要死，就像要在一块工整的电路板上，焊接一根非常碍眼的飞线一样。&br&&br&GDI/GDI+: GDI是牛逼的，出生早又承当了 GUI的基础工作，毕竟那么多年了，做成这样是无可厚非的。但是XP年代的 GDI+一出生就落后于时代。比同期的同一个级别的开源项目 Cairo（gtk后端，wine用来模拟gdi/gdi+的后端，webkit/mono后端）和 Quartz（OS X图形后端）来，GDI+除了速度卡外，图像质量差，功能简陋，不支持抗锯齿，对GDI的字体效果也并没有质的改进。所以 Windows下的应用软件，一直因为字体和图像质量受到诟病。直到后面的 Direct2D出来希望改进这个局面，也已经是好多年以后的事情了。大量兼容 xp的程序还在跑在 GDI/GDI+上。&br&&br&（ 问题有很多，以下省略若干字）&br&&br&按微软的能力，想改进这些基础接口，应该不是难事。但基础接口的长期滞后，折射出的是该公司全胜时期的傲慢。&br&&br&&b&统治与分治&/b&&br&&br&微软的接口设计向来是缺乏美感的，喜欢复杂化，喜欢什么东西都搅合在一起。什么叫做大一统？就是什么都能做，貌似很强大，一个东西能做的事情很多，开始是好的，但是随着时间的推移，耦合度高，各种盘根错节，一旦其中一个设计很 “巧妙”的东西过时了，那所有依赖它的东西将面临死亡。什么叫做分治？就是保证简单性和可拆分性，每个系统专心做好一件事情。一个不行，换掉即可，整个解决方案是由若干全部可以替换的子模块组成的，这叫分治。&br&&br&Windows技术栈就是一个典型的大一统设计，他有很多很巧妙，依赖性很强的东西。比如，“一切都是窗口”，这个思想，从设计上来说就是有问题的。举个简单例子，WSAAsynSelect 用过的人都知道，这是一个网络接口，用来判断哪个套接字上有事件。但是却又要传一个窗口句柄过去，让窗口来接受网络事件，这就是一个很搞笑的例子。微软为什么这么设计呢？因为应用程序本身有一个消息循环了，就是窗口消息循环，但是如果处理网络的应用程序使用类似 unix poll的方法，去等待消息的话，窗口消息就得不到处理了。如果把poll放到一个线程里的话，那UI线程要找网络线程做点事情，那网络线程在 poll的等待周期中，如果没有新的网络数据过来，可能短时间内没办法理会 UI线程的请求。于是微软的解决方案，就是让网络层的事件合并到 UI的窗口事件中，这样就比较方便了，全部在窗口消息队列，你要把UI和网络放到一个线程也可以，两个线程也罢。这样把两个风马牛不相及的事情搅在了一起的：“巧妙” 设计在微软的技术栈里数不胜数。&br&&br&合理的处理方法应该是啥？应该是继续使用 Poll，每次 poll可以设一个比较短的时间，并且可以被外面线程唤醒，这样就不会出现之前的问题了，两件事情不会搅在一起，这就叫可拆分性。结果呢，不关网络，大量的其他东西都和窗口搅起来了，等到 Windows程序要移植的时候，就会变得万分痛苦。有人说不是有 IOCP么？看看有多少一流的服务器支持 iocp？再说java可以把所有不同操作系统的异步事件模型封装成NIO，对 Windows对的 iocp却提供单独的接口，而且直到 7.0以后才有，微软总喜欢和全人类反着来。&br&&br&缺乏审美的设计，才会导致 Win32 API被 GUI所束缚这样一种结果。这在其他系统对比来说，这时听都没听过的事情。这是设计上的偶合，还有商业上利益的选择。比如网页开发，C# 和 &a href=&///?target=http%3A//asp.net& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&asp.net&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&绑定太紧，&a href=&///?target=http%3A//asp.net& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&asp.net&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&和 iis绑定太紧，iis和 windows又绑定太紧。微软的东西才出来都是先进的，可封闭的微软不愿意同外面合作。你要用我先进的东西，你就一个系列都要用。最终全部都搅在一起了，风险是相当大的，系统就像一个吞噬了各种化学物的怪兽一般，蹒跚前行。&br&&br&而所谓简单性和可拆分性的东西，是四处皆可替换的东西。比如你做 web开发，你选一门语言，python，语言就做好语言的事情。外部的网络框架，可以用 django，flask, web.py等等，接口可以用 fastcg / cgi / wsgi / uwsgi / apache_mod, 而外部的服务器，可以用 apache, nginx, lighthttpd。清晰的被分成：语言层、框架层、协议层、服务层 四个不同的层次，每个层次若干备选方案，互相兼容，web.py过时了，我换 flask，apache过时了，我换nginx。每个产品都专注做好自己的事情，并前后适配其他层次的方案，python出问题了，我换 ruby，换php，协议任然用 apache_mod或者 fastcgi。这就是分治，具备美感的设计。&br&&br&这样的情况在微软的技术体系里很难出现，这些技术运行到windows下水土不服不说，微软自己就不让你选：你要写asp .net，那语言你就用 c#（vb比较小众），用了&a href=&///?target=http%3A//asp.net& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&asp.net&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&你就要用iis，而iis只能跑在 windows下。外部的人很难兼容进来，本来微软就不太愿意支持其他技术。那么好，一开始可能领先，但是随着时间推移，这么长的链条中间一环出问题，可能会导致其他的跟着他一起被人抛弃。&br&&br&微软一方面出于商业考虑，生怕自己技术链中哪个环节被人替换，一方面有些接口设计充满耦合，考虑不周，导致后面大量的主动升级和被动升级，什么 ocx, com, atl, ole，dx1-7类似的东西都可以搞出那么多来折腾人，系统内核 GUI，网络、多媒体，大量的 API偶合在一起。最终简单的一个 Office和 Windows一样臃肿丑陋，这就叫缺乏美感的设计。&br&&br&&b&C#&/b&&br&&br&C#是一门简洁优雅的好语言，是微软中比较少见有品味的设计，这是因为 C#之父 Anders就是来源于微软之外的 Borland。Anders 早年为 Borland 设计的 Turbo Pascal 和 Delphi 就以编译速度快，使用简单和功能强大受到大众的喜爱，所以在设计 C# 时融入了很多早年的审美观。C#语言层面上胜过 java不少。我经常边用边骂 java到9到10了，也没想着好好的学学 C# 的一些特性。Java 这么多年连个 get/set 都不抄一下，连个unsigned都不肯给我用用。用 C#写代码比 java流畅不少，但应用范围太窄呀，我没办法还得接着用 java呀，应用范围广呀。我用 java写的程序随便运行在几乎任何平台上，大量最新的开源成果可以直接应用。可怜的C#却被微软画了一个圈，死死的呆在圈里出不来。其实大家都是欢迎 C#的，不然也不会有 mono这个项目了，但 mono运行效率比 jvm低不少，比原生的 .Net运行时低很多，库也不全，实在难以承当大任。&br&&br&除了部分人专门从事 C#的工作外，现在互联网企业，几乎很难看得到 C#的身影：做移动应用，用原生的 java和 objc。做服务端用 C++/java/各种动态脚本，做页面用 Js 页游用 Flash。做PC游戏用C++/脚本，没C#什么事情。移动游戏主要也在使用 C++/脚本（unity只是众多游戏开发引擎中一个单例未来是否被代替未知，XNA就是个玩具）。唯一只有微软的老本行PC桌面应用，没错，是C#，但是现在也面临诸多挑战： CEF（Chromium Embedded Framework）用js直接写Windows本地应用，如网易云音乐用CEF效果拔群；Qt系列+脚本（越来越多互联网公司在用，如Wps）；自己C++UI库/脚本（例子太多了）。这些方案你或多或少都能挑出些问题来，但不可否认的是她们正从各个方向蚕食 C#的传统地盘。你可能说C#在客户端能做很多非 UI的事情（比数据库和网络还有图像），但 CEF/Qt 这些播放点流媒体、访问下网络、弄下图像或者请求下数据库同样很简单。现在 GUI开发的脚本化进程正在席卷各种桌面开发方案， js等脚本运行速度越来越快，C#速度上并不能体现出数量级的优势，而且基于泛型的脚本语言开发效率比原来高很多，同时这些解决方案全是跨平台的。而整个进程中 C# 被排除在外了，这才是 C#真正危机的地方。&br&&br&&b&DirectX&/b&&br&&br&有人奇怪我为何喜欢 OpenGL，话说白了只有一个理由，它是开放的而且它不是微软的。如今很多人会说你看 d3d 接口不错，兼容性高，CPU占用低而且画面好。没错，但记心好点的同志们把时间拉长一点，Win95时代微软强推 DirectX而封锁 OpenGL很多系统调用的事情各位还记得到吧？那各位还记得到 DX才出来时烂成什么样子么？当时业内骂声一片，很多人看了眼接口就扔了，直到 DX5出来的时候，你稍不留神，还会把整个屏幕画花了，或者弄死机了。当年 OpenGL领先 DX不是一个量级。直到 DX8出来了，才算完善了一些。微软为了商业利益，把整个行业拖后了数年之久。直到2006年，很多 3A大作还是以 OpenGL为图形底层，不鸟微软的 D3D。&br&&br&微软的技术架构，向来不太优雅，耦合度又高。Dx7以前，DirectDraw的表面和 D3D设备还有纹理搅在一起，DSound的坐标系统又可以和 D3D的坐标系统搅在一起。大量的数据结构被定义出来，一个矢量一个矩阵还要单独定义一下，不准我跨平台库用自己的定义么？你就不能用个数组么？你强大是强大，但是你耦合度实在太高了。一个环节更新，所有环节被迫更新，然后就飙版本的原因之一。DirectX的设计就是没有品味的，如果按照简单性和可拆分性的思路来重新考虑，Dx软件包中，应该隔的比较开才行，能不定义的对象和结构体，尽量不定义，用C原始的类型或者数组来接口，这样不会妨碍我外面灵活使用。然后游戏开发者靠一门胶水语言把这些独立模块根据需要粘合在一起，这样的方式是不是更清爽一些呀？&br&&br&开放的东西能自我适应性，自我修正。Real Networks估计很多人还没忘记，当年的他开发的 RM / RMVB视频格式，因为压缩比高，同信噪比下码率能有更低的码率，画面质量更好，而赢得了广泛的支持。但是 RM / RMVB却是一个封闭的视频格式，虽然领先了业界数年之久，但是数年后即被开放的 H264所代替，H264虽然一开始接受度不高，但是数以万计的人在帮他完善。学院派今天发研究出一种更有效的宏块搜索方式，不出两个月工程界就跟进了。今天有人发现一个运动估计的改进，明天有人实现个更低延迟的缓存管理，或者提升下错误恢复能力。免费的 x264不论从延迟，性能，画质，码率都直接秒杀很多商业公司的编码器，ffmpeg又可以轻易的播放h.264视频。最终 Real Networks抱着它的 rm/rmvb一起进了坟墓，死前还不忘叫一句它正在开发 rmvb2，超越 h.265标准的编码格式，业内嗤之以鼻。视频领域的玩法已经变了，H.264通过不断发展，最终颠覆了RMVB的商业模式，这就是一项技术自我适应，自我修正的例子。&br&&br&今天的 D3D就像当年的 RMVB，就算他用商业手段狠狠恶心了 OpenGL一把，导致后面 OGL数年发展不顺，但是老话说得好：理胜力为常，力胜理为变；一时之强弱在力，千古之胜负在理。随着 OpenGL新标准的不断完善，虽然暂时不能彻底抛弃 DX，但封闭的 Dx必然会随着微软 Windows 逐渐边缘化，这就叫得道多助失道寡助。&br&&br&&b&全世界玩一套，微软自己玩一套&/b&&br&&br&还是因为微软最初的战略没有改变，导致全世界一套，微软自己玩一套；微软看不起开源界，开源界也不理微软。再次强调，并不是只有开源才好，而是这么多家公司里，只有微软一家试图自己从头到尾建立一套完整的技术体系，只有微软一家采取如此封闭的策略。然而早年微软可以罩住整条产业链，并且活的很爽，但是现在大量基于开源界的最新成果都和微软技术栈水土不服。&br&&br&所以开发者会面临：依赖微软和不依赖微软两种选择。依赖微软，很容易和外界形成隔离。而不依赖微软，你得到的是满天下的选择。前者强调高度集成统一，后者强调可拆分替换。然而，世界潮流，浩浩荡荡，顺之者昌逆之者亡。&br&&br&&b&成也萧何，败也萧何&/b&&br&&br&早年的微软，象一个潜伏在丛林里的猎手，利用自己操作系统的优势地位，寻找着产业链最高端的用户需求。一旦一项技术可以满足用户某种根本需要，微软就不惜牺牲眼前的现金流，来换取未来的行业领导地位和盈利。或快速收购，或恶意打压，或自家出一套，任何一个领域只要有新的东西出现，微软就试图去控制它，并绑架获出钱养活接受了微软标准的软件开发商让他们支持，出钱扶持低端的开发者让他们学习微软标准，于是巨大的利润，随之而来。&br&&br&这样的战略，使微软茁壮成长，并成为接二连三的行业标准拥有者。然而这样的战略有一个致命的BUG，就是标准必须是与时俱进的，微软需要不断调整已有标准，否则越来越多的标准就会成为束缚住微软的一条条绳索，越来越多的兼容性问题象一座座大山一样压得微软喘不过气来。掌握的标准越多，微软越难改变，随着时间的推移，将会被微软体系外更加迎合用户偏好的竞争者们所取代。&br&&br&有人说：“微软错过了移动化浪潮，错过了云计算，是因为鲍尔默的误判。智者千虑必有一失，再牛逼的人也有判断失误的地方”。但是通过上面的分析，我们可以看出这种说法的荒谬性，我们需要清醒的指出，就算没有鲍尔默，微软即便赶上了云计算，他也会错过雾计算；他即便赶上了雾计算，他照样会错过烟计算。&br&&br&这样的战略，使微软早年站到了时代的风口浪尖，又使如今的微软，变得越来越与时代背道而驰，不是微软不想融合，而是融合的成本越来越高。世异则事异，事异则备变，理解了微软的核心战略，就不难理解微软为什么会去弄什么 xps, silverlight；理解了微软的战略，就能理解为何微软的精力总是在制定新标准，而不是改进老标准了；理解了微软战略，就不难理解为何进入2000年以后，微软总是昏招迭出了。&br&&br&病在肌肤，还可以医治，病在肺腑，人就危险了。沿袭了那么多年的战略，成就了微软和他的下游开发商，也害了微软，让微软想改变都改变不了。就像一辆陆地上上装甲车，装甲越厚越坚固，然而现在要到水里开战了，所有装甲一夜之间全成了负担，要寻求救赎，除非把自己从头到尾全拆了才行。进入2009年后，看到当年一致支持自己标准的下游开发商们，粉粉判离微软转投敌营时，微软深刻的意识到，老天已经再也不像原来一样眷顾微软了，这真可谓是：成也萧何，败也萧何！&br&&br&&b&微软的选择&/b&&br&&br&人什么时候会感觉到压力？就是拥有一个东西，但是看着这个东西一天天的减少，越努力抓住他，却又越抓流失的越快，改变意味着放弃，等待意味着死亡。在这样的压力下，微软昏招迭出，这并不能怪微软高管愚昧，也不能说微软运气差，而是自从步入 2000年以后，沿袭了几十年的一家统治世界的战略与时代变得格格不如了。早年的成功让微软无视各种问题，继续靠惯性又活了15年，错过了自我救赎的最佳时机。&br&&br&核心战略出问题，不是一朝一夕的决策对错，很多人还不愿意承认，认为换了鲍尔默就能解决，认为开源 .Net，就能救 C#，就能救微软，其实这是一个天真的想法。微软战略从头到尾就没变过，开源其实相当于承认先前战略是失败的，可它却又没有提出一套新的思路和新的战略。事实上早在2000年时微软就进入了战略迷茫期，所以东一榔头西一棒子，没有重点，缺乏主题。虽然如此，还是能靠惯性继续生存，但是自我否定之后，新战略是什么呢？战略层的自我否定会极大的伤害企业向心力，让微软在未来变得更加艰难，同时又没有确立能够经得住实践验证的新战略，这又会使整个企业变得比原来更加迷茫。&br&&br&但微软能改变么？不能。微软没有办法提出一套和原来战略不兼容的新战略，除非完全把自己和多年经营的生态链砸碎。15年前的最佳改变期被其错过后，如今再怎么变都只能在原有战略框架下寻求小改变，时代的巨流，象一股巨大的引力场，吸引着身躯庞大的微软，无可奈何的掉进自己挖的坑里。&br&&br&&b&无可奈何的结局&/b&&br&&br&直接送货上门发达了，便利店就萧条了。网上购物兴起了，实体零售业也就死亡了。这就叫做 “新经济体” 代替老经济体。判断一个经济体是否衰落，看的从来不是它银行里还有多少钱，而是看它的商业模式是不是还成立。如今的微软，就是一个核心商业模式被颠覆了的企业。这不是开源能够救得了的，更不是盖茨复出能够救得了的。&br&&br&听到微软开源，让我想起之前 Sun公司 Solaris开源为 Open Solaris，希望用开源来挽救自己的颓势，没多久它就倒闭了。如今一项根本技术，比如操作系统，已经很难被一家公司所垄断。商业模式一旦被颠覆了，开源也不能成为救命稻草。&br&&br&事物强弱变换，新旧更替，本来就是自然界的基本规律。盖茨是一个聪明人，看到了未来的局面，知道什么叫月满则亏，水盈则溢，在微软最鼎盛的时候功成身退，高风亮节的做起了慈善，将最苦的差事留给了鲍尔默。所以，聪明的盖茨也是不会复出的，所以，其实我挺同情老鲍的。&br&&br&&b&结尾故事&/b&&br&&br&一开始就没想喷微软，我不是一个极端的人，一开始只是回答问题，建议题主用 Qt，远离微软的技术。但是完蛋了，一堆人上来围攻，那我真得正儿八经的把微软这事情说的清楚点才行了，否则我变成误导题主了。&br&&br&其实世界是欢迎微软改变的，我们这些从小学电脑就用着盗版微软系统的人，对微软也还是有感情的。但是微软这次能否迎来新生，还得看微软自己，我们是帮不了他的。&br&&br&最后，给大家分享个小故事：&br&&img src=&/a4e6e0fd43aa_b.jpg& data-rawwidth=&268& data-rawheight=&329& class=&content_image& width=&268&&&br&&blockquote&尼古拉·特斯拉（Nikola Tesla，1856年~1943年），被西方科学界的精英人物誉为是唯一堪比达·芬奇并超越爱因斯坦的伟大科学家，是人类有史以来最伟大的天才、发明创造的巨匠，但由于他身上同时也具有某种神秘甚至超自然的特质，也有人称他为神秘怪客或超人。是他发明和创造了交流电系统，对现代世界工业产生了深远影响。特斯拉引起的革命不仅限于电力工程，也涉及其他领域。他在科学和工程学领域取得了大约1000项发明。&/blockquote&&br&尼古拉·特斯拉，交流电的发明者，当年毅然选择放弃交流电专利带给他的暴利，将交流电公诸于众，从此交流电变成了一项免费的发明。因为他觉得，交流电这么基本的东西，是属于全人类的。如果当年特斯拉选择不开放交流电专利，那估计我们今天的社会，都得倒退一百年。&br&&br&一百年后的特斯拉汽车公司，在
Elon Musk 的领导下将自己领先世界的电动车发动机专利向世界开放，同样也是觉得电池车这种东西，是应该属于全人类的。而公司名称选作 “特斯拉” 也代表着向一百年前的 尼古拉·特斯拉致敬。
更新：擦，本来只有一句话，推荐Qt，远离微软，有人追问，补充了点，有人又追问，又补充了点，然后出了趟门回来，感觉跟捅了马蜂窝一样。既然都说到微软了，那就接着展开一下。 问题的本源 微软就是战线太长了，忙着去主导各种标准，制订各种框架，这样的话…
谢邀（终于用上这个高大上的词汇了，真的有点小激动呢）&br&&br&WTL都算不上什么Framework，就是利用泛型特性对Win API做了层封装，设计思路也没摆脱MFC的影响，实际上用泛型做UI Framework也只能算是一次行为艺术，这个思路下继续发展就会变得没法用了，比如 代码过于复杂，编译太慢，出错不好调试等问题难以解决。&br&而且封装得也不完全，还是随处可见 HWND HDC之类的东西。&br&用途主要是写一些很小的程序，或者作为其他UI框架的后端实现部分，比如我写过一个小框架用来做安装卸载程序，非常小，其中创建管理窗口部分是用WTL的。&br&&br&MFC是更高级点的Win API封装，比WTL封装彻底，很难见到HWND HDC了，也提供了不少实用工具类，比如高级控件，泛型容器，IO访问，网络协议等。除此之外，还提供了一些基本框架，比如 Document/View，这就是个MVC的简化版本，只有MV，但是对于数据的管理，消息的传递等又没有什么约束，导致Doc/View被用得乱七八糟。尤其是对事件处理的模型，消息映射是功能简陋，而且容易出错的方式，唯一优点是性能好。 从VC++ 1.X就有MFC了，那时整个UI界的设计思想都比较落后（除了Apple），MFC又背负了沉重的兼容性包袱，比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译，导致MFC后期没有什么发展，就是沿着老的思路完善了些细节，添加了些组件，但是根本性的设计问题没有改进。&br&&br&GTK，这个吃了语言的亏，用C写面向对象实在是痛苦，虽然在思想上比MFC要先进了些，但是写出来的代码比MFC要罗嗦很多了。相比MFC，多了Layout的概念，事件处理上有了Signal/slot，虽然用起来很麻烦。&br&&br&wxWidgets，这个基本就是个跨平台的MFC，对各个平台的差异做了抽象，实际上后端大多还是用平台原生的API实现，好多控件都是直接用系统原生的。有wxWidgets for GTK+的版本，后端就是GTK+，wxWidgets就是一层壳。这也是wxWidgets的优点，它编译出来的程序发行包比较小，性能也不错。&br&&br&以上这些就是上世纪90年代的UI Framework技术水平了，至今它们也依然没有太多进步。&br&下面来谈谈21世纪的技术。&br&&br&Qt，虽然它也是上世纪90年代出现的，但是它在21世纪有了长足的进步。应该说它的起点就比较高，一开始就定位跨平台，而且不满足于简单封装系统API，而是要自己创造出一套完整的API和框架，甚至要代替系统API，所以不仅仅是做UI，而是涉及到了APP开发所用到的所有东西，包括网络，数据库，多媒体，脚本引擎等。signal/slot是Qt发明的，这是事件通知模型里C++语言的最佳实现了，甚至我都觉得这该写进C++标准，估计C++委员会的老顽固们是从不写GUI的。&br&早期的QT也是没有DirectUI的概念的，每一个QWidget都对应一个原生窗口，从Qt4.4开始，只有顶层QWidget才是原生窗口，而Child Widget是Alien Widget，只是个抽象的图层不对应原生窗口，这就实现了DirectUI的概念，很多图形效果也就变得可能了，比如窗口层叠透明效果。&br&在4.8后实现了QPA(Qt Platform Abstraction)，这就使移植Qt变得很容易，目前Qt是支持平台最多的框架没有之一。&br&由于早期授权的问题，Qt对于开源社区不是很友好，导致推广不太顺利，直到它改成了LGPL方式，如果Qt能早点想开了，恐怕就没有wxWidgets的生存空间了。&br&Qt的缺点也是有的，就是太大，不过可以自己剪裁，我可以把QT库剪裁到发行包压缩后2.5MB。&br&&br&WPF，微软在Win Form的思路上走到死胡同后，终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的，绝对不能是代码写出来的，所以有了XAML这个强大的定义工具，不但可以定义UI布局，还包括图形动画效果，消息响应方式等。配合C#这种优秀的语言，更是如虎添翼。但是问题也很明显，就是过于庞大，不仅开发时要用到庞大的IDE和设计工具，发行的安装包也十分巨大，所以目前还是很少有人拿他写通用软件客户端的，大多是做企业项目时写专用客户端。&br&大概4-5年前吧疼讯曾经用WPF写了个QQ，但是只实现了基本功能就已经比C++客户端大好多了，而且运行缓慢，主要是太吃内存，而且那时WPF的优化还不充分。&br&&br&最后我想补充下真正的UI库之王，cocoa。&br&Apple的成功有很多原因，其中之一就是cocoa，cocoa理念十分先进，而且出来得早，我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。&br&定义式的UI，用xib就可以定义UI的绝大部分细节，而且提供所见即所得的可视化设计工具。&br&严格的MVC，而且定义非常清晰，分工明确。&br&signal/slot，虽然不叫这个名字，但思想就是，而且真的是拖动鼠标就能connect。&br&提供了ARC，闭包和反射，给UI开发带来巨大的便利性，当然这得益于Objective-C这个语言。&br&&br&再补充下 Borland的OWL和VCL。&br&我是从Borland C++3.0和Delphi 1.0开始用的，那时的Borland看来很有前途的，可惜后来一系列决策失误导致现在这个公司几乎消失了，同学们不要再往这个坑里跳了。&br&OWL曾经和MFC是竞争对手，设计思想也差不多，个人感觉OWL的API设计更优雅一点，但是在市场上OWL被MFC彻底击败。&br&Delphi是神作，它在RAD（快速应用开发）领域长时间没有对手，直到BS架构取代CS架构。Delphi的特点就是简单、开发快，单纯就写个基本可用的应用来说，可能至今都没有比他更快的，但是缺点就是丑，基本大多数Delphi应用都是一大堆控件堆积在一起，很不美观，另外由于Pascal语言的限制无法和现有大量的C/C++代码融合。虽然后来有C++ Builder，但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差，导致后来开源项目都不太愿意兼容这个编译器了。&br&VCL准确地说不是UI库，而是一套组件接口规范，类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。&br&&br&UI库是个很大的话题，够写好几本书来探讨的，我这里就是随便写点自己的感受。&br&单纯讨论每个库的优劣是没有意义的，而是要放到具体的应用场景里来看，每个库都有自己擅长的场景。&br&&br&如果仅在Windows下，追求程序小巧，用WTL，不足的地方自己实现去吧，但是视觉效果就呵呵了。&br&如果可以大一点，还要好看点，那就Qt。&br&如果完全不在乎大小，只要视觉效果华丽，就用WPF，如果把开发工具价格也考虑进来，那么土豪才会选WPF呢。&br&MFC就是个鸡肋了，除非你现有的工程师不会用别的，或者有历史遗留代码要保持兼容。&br&&br&如果要求跨平台，那么就用Qt，wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。&br&&br&如果是iOS Android，那么最好用原生UI库，除非你写游戏。
谢邀（终于用上这个高大上的词汇了，真的有点小激动呢） WTL都算不上什么Framework，就是利用泛型特性对Win API做了层封装，设计思路也没摆脱MFC的影响，实际上用泛型做UI Framework也只能算是一次行为艺术，这个思路下继续发展就会变得没法用了，比如 代码…
我是来反对楼上某些答案的。&br&我曾经用MFC写了金山词霸（大约20多万行），又用Qt写了YY语音（大约100多万行），算是对两种框架都比较有经验。&br&纠正几个错误的认识。&br&&br&1. “用Qt写的程序编译比MFC慢”的说法是错误的&br&绝对错误，单位代码行数编译Qt远比MFC快得多，因为Qt库的头文件设计非常好，尽量都使用了前置声明，避免了头文件嵌套，几乎所有类都使用了公有类和私有类的设计，把没必要公开的声明放到私有头文件里，避免了编译时引入过多代码。而MFC没有这样的设计。&br&至于大家感觉MFC快主要原因是MFC工程默认打开了编译预处理头文件（PCH），但是这是VC编译器的特性，所有C++程序都可以用，不是MFC特有，Qt也可以使用 PCH&br&方法很简单，在你的 .pro 文件中加入一行&br&&blockquote&PRECOMPILED_HEADER = stable.h&/blockquote&指定 Stable.h这个头文件作为编译预处理文件，MFC里这个文件一般叫stdafx.h&br&然后在 stable.h里 包含你所用到的所有 Qt 头文件，如果你用了很多qt的类可以直接包含所有&br&比如 ：&br&&blockquote&#include
&QtCore&&br&#include &QtGui&&/blockquote&这两个文件里又包含了几乎所有Qt常用类&br&不用担心，即使包含了所有头文件也没关系，有了PCH再多头文件也没影响。&br&&br&如果你还想编译再快点，可以在 .pro里加入下面一行&br&&blockquote&QMAKE_CXXFLAGS += /MP&/blockquote&指定/mp编译选项，编译器将使用并行编译，同时起多个编译进程并行编译不同的cpp&br&&br&而且QT这种引入PCH的方法比MFC的好，由于MFC的PCH选项是每个工程逐个指定的，很容易被某些人搞坏，我曾经无数次修复PCH问题，但是Qt的选项是写在.pro里的，写一次就永远不会错。&br&MFC一旦弄坏了PCH，编译也慢得令人发指。&br&&br&给个参考时间吧，YY最新版本大约 100多万行C++代码，rebuild debug和releae总共需要20多分钟，机器是i5 四核SSD硬盘。其实对于大项目硬盘才是瓶颈，如果换机械硬盘要慢差不多70%，有个同事用10G内存做了个内存盘编译，还能快30%。&br&&br&如果你比这个慢，请检查自己的代码问题。&br&&br&2. “QT本身编译慢”的说法是错的&br&Qt本身其实编译并不慢，慢的是webkit库和例子程序，你如果不改任何选项默认是会编译所有的，webkit本身就是个恐龙级项目，用了太多泛型技术，编译非常慢。另外Qt里附带了数百个例子工程，都编译一边也很慢。如果仅编译QT核心库是很快的，比如QtCore只需要1分钟，QtGui大约5分钟。&br&&br&送个福利（仅限windows vc＋＋ 2008）：&br&&blockquote&configure.exe -qt-libjpeg -qt-zlib -qt-libpng -qt-libjpeg -qt-gif -no-libtiff -no-libmng -nomake examples -nomake demos -no-webkit -nomake doc -no-plugin-manifests -no-exceptions -no-rtti -no-qt3support -no-openssl -no-opengl -no-multimedia -no-3dnow -no-native-gestures -no-style-motif -no-style-cde -no-style-cleanlooks -no-style-plastique -no-sql-sqlite -no-dbus -platform win32-msvc2008&/blockquote&&br&这是我自己用的Qt编译前的配置命令行，把我自己用不到的都去掉了，这样配置编译就快很多了。&br&我把 webkit examples demos 等大家伙都去掉了。如果你真的需要这些，可以安装Qt sdk里面有编译好的版本。&br&&br&补充：Qt creator只是IDE，不是编译器，编译慢真的不关他的事，要看你具体用的编译器是什么。一般来说在Windows下就是minGW，也就是一个移植版本的GCC，的确是不如VC++里的CL快的。&br&如果是其它平台，那么编译器可以换成LLVM的clang，那就快很多了。&br&在Windows下来是用VC++吧，推荐VC2008，Qt和VC的IDE结合非常好，我现在的项目都是用VC2008+QT的，开发效率很高，记得装Visual Assist哦。&br&&blockquote&qmake -tp vc&br&&/blockquote&可以用 .pro生产 .vcproj的VC工程文件，可以用VC++打开编译。
我是来反对楼上某些答案的。 我曾经用MFC写了金山词霸（大约20多万行），又用Qt写了YY语音（大约100多万行），算是对两种框架都比较有经验。 纠正几个错误的认识。 1. “用Qt写的程序编译比MFC慢”的说法是错误的 绝对错误，单位代码行数编译Qt远比MFC快得…
这是Mark Shuttleworth下的一盘大棋....&br&&br&两年前，&a href=&///?target=http%3A///archives/568& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Mark Shuttleworth&i class=&icon-external&&&/i&&/a& 宣布Ubuntu要支持Qt程序，给出的理由是软件的易用性和方便集成的能力，是提供最终用户体验的关键价值所在。Ubuntu不是因为Gtk多么&纯粹&, 多么牛B，多么性感才被选中的，Ubuntu选择的是像OpenOffice, Firefox这样体验上佳的软件，软件的技术框架只是附加选择。当初之所以选择Gnome是因为在当时条件下, Gnome桌面和其软件家族，在功能和系统体验的一致性上很好，而GTK被选择，则仅仅是Gnome使用了GTK，如此而已。&br&&br&然后Mark给出选择软件框架的几个要求和Qt入选的理由：&br&* is it free software? Qt支持商业, GPL和LGPL三种授权，特别是LGPL称为决定性的胜出因素&br&* is it best-in-class?
Qt在软件质量，功能，API设计，文档等方面广受赞誉&br&* does it integrate with the system settings and preferences? 当时Qt在这方面还稍有欠缺，为此Canonical决定赞助&a href=&///?target=https%3A//wiki.gnome.org/dconf& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&dconf - GNOME Wiki!&i class=&icon-external&&&/i&&/a&这样的软件集成进Qt, 结果就是&a href=&///?target=https%3A//launchpad.net/dconf-qt& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&dconf-qt in Launchpad&i class=&icon-external&&&/i&&/a&&br&* does it integrate with other applications?
原文未说明，不过这对Qt程序没什么问题，现在Qt和GTK基本上都统一到了D-BUS作为应用交互的系统总线了&br&* is it accessible to people who cannot use a mouse, or keyboard?
Qt给出的答案是QtQuick QML&br&* does it look and feel consistent with the rest of the system? Qt Style， QML表示没有压力&br&&br&那么，选择Qt是否意味着Ubuntu要亲近KDE而疏远GNOME了呢？&br&Mark对前者给予斩钉截铁地回答：No。 并且用整整一个段落来斩断这种遐想，表面上给出的理由是，KDE并没有集成像dconf-qt这样的软件包，而Ubuntu也无法或不想一个个去说服KDE的程序去集成进Ubuntu。而骨子里，其实Mark就是看不上KDE，随后不久, Canonical宣布解雇全职开发Kunbutu唯一的一个雇员，然后Kunbutu被迫变为完全社区驱动的发行版就是一个很明显的注解。&br&&br&那么，看不上KDE这小三是不是就是因为爱GNOME这大老婆爱得深沉呢？ 是才怪！虽然为了安抚GNOME社区，Mark用了另一个整段来说明选择Qt不等于弃GNOME，当然了，一起生活了这么久，即使一下子想休也不是那么容易休掉的，要慢慢来嘛！ GNOME、GTK推3.x, 咱先不跟了，Gnome shell再慢慢用Unity换掉，嗯，X11, Wayland都不合口味，也扔掉，上Mir.... 哇，这下有点玩大了，釜底抽薪靠什么支持上面的应用, 这是就需要Qt登场了，有了锤炼了好几年的QPA系统抽象层，换底层架构就方便多了。&br&&br&有了这些铺垫，今年初当Canonical宣布她的Ubuntu Phone OS就水到渠成了，被选择的，既不是GTK和GNOME，更加不是KDE，而是最为一个跨越桌面，平板和手持设备的整体系统解决方案的Qt框架，如果你曾经开发过Symbian，MeeGo的Qt程序，当你打开Ubuntu Phone OS的SDK时，你会觉得非常熟悉，没错，Canonical原封不动地把Qt Mobility, QtQuick和Qt其它基础模块一股脑地接了过来。Qt将成为Ubuntu未来地官方API， QML则是跨桌面，平板，手机的原生UI解决方案。&br&&br&这是从Ubuntu的发展和Canonical公司的战略角度来看Qt被选择的背后动机， 如果单纯的比较GTK和Qt的话，Qt在以下方面是胜出的（当然不是各个方面都是Qt好，GTK也有自己的优势）：&br&1. 灵活的许可证&br&
要说这是最核心的，狗血的是，Qt当初不灵活的QPL许可证也是催生GNOME/GTK的最大原因，然而此一时彼一时，Qt一直在进步，先是商业+GPL, 后被Nokia加上LGPL， 已经成了最开放的开源项目之一，无论你是开源，闭源和商业开发者，都可以放心使用Qt。GTK是LGPL，可以被闭源程序使用，但是没有真正的商业License，基本上除了雇程序员自给自足，找不到地方花钱买服务，这对很多项目其实很关键。&br&&br&2. 社区活跃度&br&
Qt核心活跃开发者基本上是GTK的4+倍, 代码commits是GTK的5+倍
(2011年数据），随着Nokia弃用Qt，的统计有所下降，不过还是比GTK高一个数量级，大家可以看Ohloh的详细统计数据&br&&br&3.性能&br&
其实传统的Qt Widgets和GTK相比，性能上彼此彼此。不过QtQuick出现以后，Qt开始甩开GTK好几条街，更确切的说，GTK社区没有拿出相对应的解决方案。&br&&br&4. 分辨率无关开发&br&QtQuick/QML对现代的移动，嵌入式触摸设备的GUI开发是必不可少的。现在的显示设备的另一个特点是，像素密度很大，而且不同设备像素密度差异也很大，即使是桌面平台，随着retina的出现，也开始了DPI竞赛。而GTK+不支持“分辨率无关”开发，这样GTK写出来的程序，在现在的智能手机上看起来就像屎堆上的一对苍蝇... 当然Qt Widgets写出来的也是一样，这就体现出了QtQuick的优势来。而据说，GTK+对此的计划是... GTK4.x再提供支持...... 这样以来，估计用不了多久，连GTK桌面程序看起来也只能是渣渣了。&br&&br&5. 可移植性&br&这也是Qt的王牌之一， 除了三大桌面外，Qt还支持几乎所有主流智能手机操作系统（让我们略过Windows Phone...）, 刚刚发布的Qt 5.1已经尝试支持Android和iOS平台，Qt 5.2将正式支持Android和iOS, 加上本就支持的&i&Symbian(dead)&/i&, &i&MeeGo(dead)&/i&, Tizen, &i&WebOS&/i&, BlackBerry/QNX, VxWorks, Ubuntu Phone OS, Sailfish OS。而GTK只能勉强支持三大桌面(Linux/Unix基本上只能X11, Framebuffer支持有限，EglFS完全不支持）。&br&&br&6. 其它&br&
qt-creator 已经渐渐地称为了VS之外的最佳C/C++ IDE, Qt还有开源社区非常少见的优美丰富的文档，Qt框架覆盖广泛，不仅仅限于GUI，就这点来说拿Qt和GTK比，其实有点委屈了Qt。&br&&br&参考：&br&1. &a href=&///?target=http%3A//www.cs.uta.fi/%7ETKOPS407/sd-seminar-25-2-2009.pdf& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://www.&/span&&span class=&visible&&cs.uta.fi/~TKOPS407/sd-&/span&&span class=&invisible&&seminar-25-2-2009.pdf&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&2. &a href=&///?target=http%3A///archives/568& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt apps on Ubuntu&i class=&icon-external&&&/i&&/a&&a href=&///?target=http%3A///archives/568& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Mark Shuttleworth&i class=&icon-external&&&/i&&/a&&br&3. &a href=&///?target=http%3A///wiki/GTK_vs_Qt& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GTK vs Qt - WikiVS&i class=&icon-external&&&/i&&/a&&br&4. &a href=&///?target=http%3A//dot.kde.org//george-staikos-quick-cost-analysis-qt-vs-gtk& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&dot.kde.org//&/span&&span class=&invisible&&george-staikos-quick-cost-analysis-qt-vs-gtk&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&5. &a href=&///?target=http%3A///phone/app-ecosystem& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&App ecosystem&i class=&icon-external&&&/i&&/a&&br&6. &a href=&///?target=http%3A//www.ohloh.net/p/qt5& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&The Qt 5 Open Source Project on Ohloh&i class=&icon-external&&&/i&&/a&&br&7. &a href=&///?target=http%3A//www.ohloh.net/p/gtk& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&The GTK+ Open Source Project on Ohloh&i class=&icon-external&&&/i&&/a&&br&8. &a href=&///?target=http%3A///questions/281092/why-is-canonical-choosing-qt-over-gtk-for-unitys-next-generation& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&ubuntu touch&i class=&icon-external&&&/i&&/a&&br&9. &a href=&///?target=https%3A//wiki.gnome.org/GTK%2B/Roadmap& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GTK+/Roadmap&i class=&icon-external&&&/i&&/a&
这是Mark Shuttleworth下的一盘大棋.... 两年前， 宣布Ubuntu要支持Qt程序，给出的理由是软件的易用性和方便集成的能力，是提供最终用户体验的关键价值所在。Ubuntu不是因为Gtk多么"纯粹", 多么牛B，多么性感才被选中的，Ubuntu选择的是像…
短平快的话：&br&&br&1. Electron：js开发界面，可用cpp扩展&br&2. PyQt5: Py开发界面，可用cpp扩展&br&3. QWebView：js开发界面，py cpp做后端（非界面部分）&br&&br&比开发速度，上面三个方案完爆c#&br&Qt5以后，Qt全面使用gpu加速绘制。&br&微软自己都很少用 WPF，做个 vscode还要去用 electron。&br&&br&界面脚本化是大势所趋，弄个界面就该快，改两行代码按个快捷就该跑起来，避免改个文件一编译就等半天，或者出个bug找两天：&br&&br&编码-测试-编码 这个核心工作流越短越好。上面三个方案都跨平台，况且人的时间本来就有限，上面几门技术学了你不亏，其他好多地方都用得上，关键是开发效率都比c#高。&br&&br&再比较下性能：&a href=&///?target=https%3A///watch%3Fv%3D8O-0k4MLKs8& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://www.&/span&&span class=&visible&&/watch?&/span&&span class=&invisible&&v=8O-0k4MLKs8&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& &br&Qt 5.6 MinGW 和 .NET 4.5 WPF 跑同一个测试，Qt 的速度是 WPF的两倍！&br&&br&主要是两个技术序列：&br&&br&1. 基于web技术的桌面产品，比如vscode，atom，Slack，网易云音乐，钉钉之类的成熟应用挺多，文档也丰富，问问题有人答，搜问题搜得到。&br&&br&&img src=&/v2-3e1fd19b3dc109ce9998fbe_b.png& data-rawwidth=&481& data-rawheight=&716& class=&origin_image zh-lightbox-thumb& width=&481& data-original=&/v2-3e1fd19b3dc109ce9998fbe_r.png&&&br&短短两年间，这么多来自微软，Facebook, Slack，Docker等公司的桌面产品使用 Electron开发出来，更多的可以到：&a href=&///?target=http%3A//electron.atom.io/apps/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Electron Apps&i class=&icon-external&&&/i&&/a& 自己看。&br&&br&2. 基于PyQt的桌面产品：DropBox client, &a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&R Studio&i class=&icon-external&&&/i&&/a&, &a href=&///?target=https%3A//en.wikipedia.org/wiki/Calibre_%2528software%2529& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Calibre&i class=&icon-external&&&/i&&/a&, &a href=&///?target=https%3A//en.wikipedia.org/wiki/Eric_Python_IDE& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Eric Python IDE&i class=&icon-external&&&/i&&/a&, Spyder, &a href=&///?target=http%3A///ovo-catalog-creator-magento& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&PDF Catalog Creator for Magento&i class=&icon-external&&&/i&&/a&，出活快，写小工具用它根飞一样，做专业系统可以和C++Qt无缝整合。&br&&br&&img src=&/236b60893fcdcc65318ace39d042c44f_b.png& data-rawwidth=&949& data-rawheight=&790& class=&origin_image zh-lightbox-thumb& width=&949& data-original=&/236b60893fcdcc65318ace39d042c44f_r.png&&R Studio&br&&br&&img src=&/v2-bd55b2d357fd75dc311c1_b.png& data-rawwidth=&898& data-rawheight=&613& class=&origin_image zh-lightbox-thumb& width=&898& data-original=&/v2-bd55b2d357fd75dc311c1_r.png&&Spyder &br&&br&上面两张 R Studio / Spyder 的截图，PyQt做的，不算简单吧，这界面，想看酷炫的可以去看 PyQt的 demo，不要觉得 PyQt有多大， DropBox客户端打包出来 24MB，比很多手机app都小。&br&&br&Electron 内核整合了 NodeJS，所有 NodeJS能用的模块 js都能用，比如：&br&&a href=&///?target=https%3A///node-ffi/node-ffi& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&node-ffi/node-ffi&i class=&icon-external&&&/i&&/a& 模块，可以让你直接调用 C++写的动态库，不需要用C++写个node扩展：&br&&div class=&highlight&&&pre&&code class=&language-js&&&span class=&kd&&var&/span& &span class=&nx&&ffi&/span& &span class=&o&&=&/span& &span class=&nx&&require&/span&&span class=&p&&(&/span&&span class=&s1&&'ffi'&/span&&span class=&p&&);&/span&
&span class=&kd&&var&/span& &span class=&nx&&libm&/span& &span class=&o&&=&/span& &span class=&nx&&ffi&/span&&span class=&p&&.&/span&&span class=&nx&&Library&/span&&span class=&p&&(&/span&&span class=&s1&&'libm'&/span&&span class=&p&&,&/span& &span class=&p&&{&/span&
&span class=&s1&&'ceil'&/span&&span class=&o&&:&/span& &span class=&p&&[&/span& &span class=&s1&&'double'&/span&&span class=&p&&,&/span& &span class=&p&&[&/span& &span class=&s1&&'double'&/span& &span class=&p&&]&/span& &span class=&p&&]&/span&
&span class=&p&&});&/span&
&span class=&nx&&libm&/span&&span class=&p&&.&/span&&span class=&nx&&ceil&/span&&span class=&p&&(&/span&&span class=&mf&&1.5&/span&&span class=&p&&);&/span& &span class=&c1&&// 2&/span&
&span class=&c1&&// You can also access just functions in the current process by passing a null&/span&
&span class=&kd&&var&/span& &span class=&nx&&current&/span& &span class=&o&&=&/span& &span class=&nx&&ffi&/span&&span class=&p&&.&/span&&span class=&nx&&Library&/span&&span class=&p&&(&/span&&span class=&kc&&null&/span&&span class=&p&&,&/span& &span class=&p&&{&/span&
&span class=&s1&&'atoi'&/span&&span class=&o&&:&/span& &span class=&p&&[&/span& &span class=&s1&&'int'&/span&&span class=&p&&,&/span& &span class=&p&&[&/span& &span class=&s1&&'string'&/span& &span class=&p&&]&/span& &span class=&p&&]&/span&
&span class=&p&&});&/span&
&span class=&nx&&current&/span&&span class=&p&&.&/span&&span class=&nx&&atoi&/span&&span class=&p&&(&/span&&span class=&s1&&'1234'&/span&&span class=&p&&);&/span& &span class=&c1&&// 1234&/span&
&/code&&/pre&&/div&&br&Python/PyQt也有类似的接口。&br&&br&WPF线上产品不考虑，不要看着你们办公室没人用xp就以为天下没xp了，你去二三线城市的网吧里看看，大范围的xp。现在这个时间点国内还有 45%的电脑跑xp，这问题三年内不会缓解，你要做线上系统你基本不可能抛弃这群用户，做内部工具又没有上面三个快捷，更何况跨平台问题。&br&&br&虽然我承认 C#是一门好语言，但堆逻辑还是没有 js，python之类的快，且不管 C#还是 WPF，应用面太窄，学会了将来能用的地方也不多，不值得投入。而上面我给你推荐的三套方案，所涉及到的技术应用范畴都广的多，比如你学会了js/Electron，可以无缝把你桌面应用迁移到 web上，比如同时开发web版本，可以稍微该一下做成移动app，学了python/qt，也有好多别的事情可以做。&br&&br&所以，学一个东西要考虑它本身的价值&br&&br&ps：用过win32，owl，vcl，mfc，c#，tk，wx，手撸DirectUI，qt&br&&br&不会坑你&br&&br&--
短平快的话： 1. Electron：js开发界面，可用cpp扩展 2. PyQt5: Py开发界面，可用cpp扩展 3. QWebView：js开发界面，py cpp做后端（非界面部分） 比开发速度，上面三个方案完爆c# Qt5以后，Qt全面使用gpu加速绘制。 微软自己都很少用 WPF，做个 vscode还要…
被邀请了很久了，一直在思考，今天终于下决心开始写回答。&br&&br&这个问题的确是够大的，Qt的代码规模在整个开源世界里也是名列前茅的，这么大的项目其中的精华是非常多的，很难说得全面，实际上我对Qt也不是完全了解，里面还有很多我不熟悉的东西。&br&&br&首先，我想谈的是 signal/slot，Qt算是发明了signal/slot，这个思想也被其他一些框架语言借鉴了。&br&&br&谈signal/slot之前先来谈谈C++的缺欠，这个问题也被讨论很多了，这里只谈一点，C++的设计目标是面向对象语言，它不仅提供了对象的定义和构建的方式，也定义了对象间的关系，比如 继承 派生 聚合，但是它没有提供对象间通信和共享数据的方式，这个缺点在一般程序的开发上不算个大问题，我们可以自己简单实现，但是对于GUI开发，这个缺点就被放大了很多倍。GUI上的对象实在太多，窗口是对象，布局是对象，定时器是对象，而且对象间有错综复杂的关系，通信和数据交换非常频繁，比如按钮按下要通知父窗口或容器对象，滚动条变化了要通知列表对象。这种数量庞大的对象以及复杂的通信关系，可不是自己搞个简单的实现就能解决的。&br&&br&说到通信和共享，其实他们是一回事，共享很多时候就是为了通信，而C++里要通信就必然要共享。&br&比如，一个类实例拥有另一个的指针，就可以访问对方的数据，调用对方的方法了，这实际就是共享了一个指针，这个类指针也是另一个对象的this。访问数据和调用方法其实都是通信，把对方的数据拿过来，把自己的数据送过去，交换数据就是通信。&br&&br&在C++里，由于没有GC，管理大量原生指针是极其危险的，对象的生命周期不可控，野指针的出现概率会很高，大型C++ 的GUI项目参与开发的人数众多，很难保证都不犯错。&br&那么用观察者模式呢？其实也一样，还是共享了IObserverXXX指针。&br&那么发消息行不行呢？比如 MFC那样，可以，但是本质上还是共享了窗口句柄，否则消息发给谁呢？而且还带来另外的问题，就是类型安全，消息的参数是无法类型安全的。&br&&br&Qt作为大型GUI项目的Framework，它必须解决这个问题，否则这个程序是写不大的，写大了就会问题层出不穷。&br&来看一段代码，看看Qt 的解决方案:&br&&div class=&highlight&&&pre&&code class=&language-cpp&&&span class=&n&&Window&/span&&span class=&o&&::&/span&&span class=&n&&Window&/span&&span class=&p&&()&/span&
&span class=&p&&{&/span&
&span class=&n&&QPushButton&/span& &span class=&o&&*&/span&&span class=&n&&b&/span& &span class=&o&&=&/span& &span class=&k&&new&/span& &span class=&n&&QPushButton&/span&&span class=&p&&(&/span&&span class=&k&&this&/span&&span class=&p&&);&/span&
&span class=&n&&connect&/span&&span class=&p&&(&/span&&span class=&n&&b&/span&&span class=&p&&,&/span& &span class=&n&&SIGNAL&/span&&span class=&p&&(&/span&&span class=&n&&clicked&/span&&span class=&p&&()),&/span& &span class=&n&&SLOT&/span&&span class=&p&&(&/span&&span class=&n&&on_button_clicked&/span&&span class=&p&&()));&/span&
&span class=&p&&}&/span&
&span class=&n&&Window&/span&&span class=&o&&::&/span&&span class=&n&&on_button_clicked&/span&&span class=&p&&()&/span&
&span class=&p&&{&/span&
&span class=&n&&QPushButton&/span& &span class=&o&&*&/span&&span class=&n&&b&/span& &span class=&o&&=&/span& &span class=&n&&qobject_cast&/span&&span class=&o&&&&/span&&span class=&n&&QPushButton&/span&&span class=&o&&*&&/span&&span class=&p&&(&/span&&span class=&n&&sender&/span&&span class=&p&&());&/span&
&span class=&n&&b&/span&&span class=&o&&-&&/span&&span class=&n&&setText&/span&&span class=&p&&(&/span&&span class=&s&&&clicked!&&/span&&span class=&p&&);&/span&
&span class=&p&&}&/span&
&/code&&/pre&&/div&这段代码，通过Qt的signal slot机制，把QPushButton的点击事件连接到了Window的on_button_clicked响应函数上。&br&Window 和 QPushButton并没有互相保存对方指针，QPushButton的指针b 只是个局部变量，用过之后很快销毁，Window和QPushButton实现了通信，数据共享，事件响应，但是却没有共享指针，而且他们不受对方的生命周期影响，无论谁先销毁，这段代码都不会出错。&br&这种方式还是类型安全的，当signal和slot的类型不匹配的时候 connect是会报错的。&br&&br&有人会说，我们用智能指针不就好了。好啊，智能指针你不会自己写吧，那么用boost？boost里能创建窗口吗？不能吧，还是要其他GUI库的，把两个异构的Framework撮合到一起也不是轻而易举的。再说了Qt出来的时候，别说Boost，STL都还没有呢。&br&&br&signal/slot为对象间通信提供了非常灵活方便的实现，如果你只关心一个signal那就可以只connect一个，可以多个slot连接同一个signal，也可以一个slot连接到多个signal，Qt会负责管理连接关系和对象生命周期，对象销毁时会自动断开连接。&br&&br&Qt为了实现signal/slot也是付出代价的，在无法改变C++语法的情况下，只能通过moc预编译器来扩展关键字。这大概是独一无二的实现方式了，后来的signal/slot实现要不用C++ template，或者发明种语言直接做到语法里，比如C# delegate。&br&&br&最后总结下，Qt的signal/slot是为了解决对象间通信问题，同时避免共享指针造成的内存野指针和对象生命周期问题。&br&&br&下一个议题，等我想好了再说。。。。&br&&待续&
被邀请了很久了，一直在思考，今天终于下决心开始写回答。 这个问题的确是够大的，Qt的代码规模在整个开源世界里也是名列前茅的，这么大的项目其中的精华是非常多的，很难说得全面，实际上我对Qt也不是完全了解，里面还有很多我不熟悉的东西。 首先，我想谈…
这是我大一时候写的音乐播放器&br&&img src=&/f169d4cbbafd6b6bba45bfb_b.jpg& data-rawwidth=&1024& data-rawheight=&683& class=&origin_image zh-lightbox-thumb& width=&1024& data-original=&/f169d4cbbafd6b6bba45bfb_r.jpg&&&br&&br&&img src=&/5c6c5aead67a110e7e56cccc9c4a197d_b.png& data-rawheight=&713& data-rawwidth=&1080& class=&origin_image zh-lightbox-thumb& width=&1080& data-original=&/5c6c5aead67a110e7e56cccc9c4a197d_r.png&&&br&&br&这是大二写的社交软件（当然服务端没花心思搞界面）：&br&&img src=&/cb684c70a863e6d3a77e_b.jpg& data-rawwidth=&1024& data-rawheight=&576& class=&origin_image zh-lightbox-thumb& width=&1024& data-original=&/cb684c70a863e6d3a77e_r.jpg&&&img src=&/ea1d2096708beadded8b1d_b.jpg& data-rawwidth=&1024& data-rawheight=&599& class=&origin_image zh-lightbox-thumb& width=&1024& data-original=&/ea1d2096708beadded8b1d_r.jpg&&&img src=&/ccf61d1bfacebc_b.png& data-rawwidth=&645& data-rawheight=&703& class=&origin_image zh-lightbox-thumb& width=&645& data-original=&/ccf61d1bfacebc_r.png&&&br&&br&用的都是C++/Qt5&br&播放器大概3k行&br&社交软件有1w+行&br&&br&所以，想要界面漂亮，找个&b&靠谱的设计师队友&/b&很重要。&br&&br&----------------------update-------------------------&br&播放器已经开源，欢迎star和fork：&br&&a href=&///?target=https%3A///FreedomZZQ/IcePlayer& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/FreedomZZQ/I&/span&&span class=&invisible&&cePlayer&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
这是我大一时候写的音乐播放器 这是大二写的社交软件（当然服务端没花心思搞界面）： 用的都是C++/Qt5 播放器大概3k行 社交软件有1w+行 所以，想要界面漂亮，找个靠谱的设计师队友很重要。 ----------------------update------------------------…
入门：&br&1.
&a href=&///?target=http%3A///subject/3173123/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&C++GUI Qt4编程 (豆瓣)&i class=&icon-external&&&/i&&/a&&br&2. &a href=&///?target=http%3A//www.devbean.net/2012/08/qt-study-road-2-catelog/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&《Qt 学习之路 2》目录&i class=&icon-external&&&/i&&/a&&br&&br&-----&br&进阶：&br&1. &a href=&///?target=http%3A//qt-project.org/doc/qt-5/qtexamplesandtutorials.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt Examples And Tutorials&i class=&icon-external&&&/i&&/a& (全部跑一遍)&br&2. &a href=&///?target=http%3A//qmlbook.org/%23& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt5 Cadaques&i class=&icon-external&&&/i&&/a& | &a href=&///?target=http%3A//cwc1987.gitbooks.io/qt5cadaquesinchinese/content/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&中文版&i class=&icon-external&&&/i&&/a&&br&3. &a href=&///?target=http%3A//blog.csdn.net/dbzhang800/article/details/6300789& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&1+1=2的 blog 文章索引&i class=&icon-external&&&/i&&/a& (看具体问题如何解决)&br&4. &a href=&///?target=http%3A//.cn/s/articlelist__2_1.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt_一去丶二三里&i class=&icon-external&&&/i&&/a& (看如何DIV界面)&br&5. &a href=&///?target=http%3A//www.qtcn.org/bbs/i.php& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&QTCN开发网 &i class=&icon-external&&&/i&&/a&(看看别人如何写Qt)&br&&br&----&br&深入：&br&1. &a href=&///?target=https%3A//qt.gitorious.org/qt& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt - Qt by Digia&i class=&icon-external&&&/i&&/a& (看源码)&br&2. &a href=&///?target=https%3A//qt.gitorious.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Qt by Digia&i class=&icon-external&&&/i&&/a& (看各种开源代码)&br&3. &a href=&///?target=http%3A///questions/tagged/qt%3Fsort%3Dvotes& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Highest Voted 'qt' Questions&i class=&icon-external&&&/i&&/a& (从高票往低票看)
----- 进阶： 1.
(全部跑一遍) 2.
(看具体问题如何解决) 4.
(看如何DIV界面) 5. (看看…
qt的应用层主要是大型3d，vr，管理软件和器械嵌入软件。日常生活中所用的qt产品比较少。也就&br&virtual box，google earth，VLC player等。但是大型系统就正好相反，这是c++决定的，而非qt。&br&&br&除了Maya之外，包括Houdini，斯特拉电车的系统软件等一大批3d软件都是qt写的，或者qt参与其中，qt（c++或python）是houdini默认二次开发环境。&br&&br&美国宇航局，欧洲宇航局，多个发达国家的地理信息，国土部门是默认qt平台开发。是默认qt开发，宇航局紧急编程系统是qt的python系统。&br&3d软件几乎不能脱离qt，除maya全部使用qt外，autodesk的很多软件都用到qt，测试也用qt。&br&几乎所有vr和游戏引擎都用到qt，其中包含cryengine。&br&&br&catia是世界最大最难的软件系统，全世界所有高级开发（飞机，宇航，汽车，工业，生物）全部都是caria设计的。&br& Siemens NX是仅次于catia的软件。&br&这些软件都有些核心模块qt参与开发，在波音，庞巴迪，洛克希等等公司，qt是catia开发模块的默认模拟开发平台。其中波音公司用的最多（并非所有catia项目都运行在qt。但是有些项目只能，必须运行在qt）。&br&&br&BlackBerry和全世界多数新的核电站控制系统，能源控制系统都是qt下开发的。&br&最先进的能源，防御控制系统，舰船控制系统，是qt下开发的。&br&国家情报和管理系统控制中心：几乎全世界所有国家的中心控制中心（防御，情报，应急），都是基于qt开发，或者是正在转qt了。&br&&br&前段时间大家争论中国银行系统能否去IBM等公司的技术，但是大家不知道ibm等公司的金融业核心技术是在qt上开发的。&br&&br&华尔街多少精英每天打开电脑墙壁（至少4个显示器），其中至少1个是qt做出来的软件，另外一个是qt的python即时编程平台。&br&&br&美国一大批大公司，政府，军方使用的软件都是qt或者qt参与其中，这些软件都是几亿美元以上。&br&&br&现在美国政府，科研和军方，同时有上千个下一代软件黑科技项目是qt的了。&br&&br&&br&因为有人耻笑Qt，所以补充发个例子，其实是目前世界上整合难度最大的系统。&br&本人没有任何认识的人在这个项目工作，所有信息来自于美国媒体的公开信息。&br&以下说一个公开的项目，是最近最热门的武器系统（再次，特别指出，这是都是公开信息）：&br&&b&超级战舰DDG1000“朱姆沃尔特”&/b&&b&级驱逐舰：&/b&&img src=&/6ca07d6c6c980b726b05ae_b.jpg& data-rawwidth=&580& data-rawheight=&235& class=&origin_image zh-lightbox-thumb& width=&580& data-original=&/6ca07d6c6c980b726b05ae_r.jpg&&&br&朱姆沃尔特级驱逐舰：这个最新完工的项目即便在美国也是在报纸上疯狂了一阵子，软件系统难度，超过了欧洲和美国宇航局的宇宙信息系统（欧洲版虚拟宇宙公开宣传是在Qt开发，qt实时干涉，美国的按照招聘来看也是在qt开发，但是没有公开信息），系统运行于实时类linux，是Lynx OS，兼容linux，Qt是整个开发的中心平台，相当多模块是完全在Qt下开发的，可不仅仅用于UI，包括Qt的手机，android，ios，3d都被使用，嵌入式开发更被使用。&br&&br&主体防护，预警层，完全是个虚拟现实的游戏开发，3d环境和雷达，卫星，火控完全整合，Unreal引擎和Qt3D，OpenGL结合，并且和CAD，CAM结合（船体具备某些制造功能）。&br&DDG1000是第一个3d显示预测结果的武器系统，导弹未经发射前，模拟器即可实施显示发射结果以及结果数据，并且数据和指挥中心同步，舰船将逐步实现了远程控制（二期代码升级2018年实现）。是目前世界上整合难度最高的软件系统，qt在其中占有重要位置，不仅仅是UI。&br&Qt在DDG1000的使用，不仅仅是开发过程，Qt最后被整合到控制中心，程序员跟随舰队随时用Python等语言在Qt工作。&br&&br&DDG1000系统，又要整合在其他Qt开发的系统，并且在不同控制中心通过Qt协作。&br&&br&DDG1000系统是经过60多年发展的一个系统，很多尖端模块甚至在计算机没有发明之前就已经开始研发（按照概念可能性）。 这个系统会不断进步。但是很多超级功能还需要10年-20年才能分布实现。&br&&br&&br&DDG1000系统在美国属于级别最高的工程之一，即便是其中最次要的工程，也需要美国公民经过政治审核才能参与。&br&&br&&br&||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||&br&&br&以上说的还仅仅是qt平台，不包括visual studio，eclipse，intellij下的qt插件使用。也不包括金融公司的qt下java使用。
qt的应用层主要是大型3d，vr，管理软件和器械嵌入软件。日常生活中所用的qt产品比较少。也就 virtual box，google earth，VLC player等。但是大型系统就正好相反，这是c++决定的，而非qt。 除了Maya之外，包括Houdini，斯特拉电车的系统软件等一大批3d软件…
&p&奉劝一句，别再花力气折腾这些玩意了，有时间学点能用的东西（Python，c/c++，OOP，vim，爬虫，多线程），比这些折腾美化的东西强万倍。大家都是踩过坑的人，几句劝告，忠言总是逆耳的。&/p&&p&1：特别耗费时间。这句话适合所有Linux发行版，折腾Linux的外观经常耗费半天乃至几天。&/p&&p&2：不稳定，经常一升级那些耗费半天乃至几天的东西就不work了，尽管你已经很小心能不升级就不升级了，但是有时候系统不给你这个选择。&/p&&p&3：收益率太低。因为它们不能积累复用（从Gnome2到3，你的美化东西就不work了），不能转移知识（换个别的Linux也许就完全不一样），不能给你带来长久的效益。&/p&&p&4：Linux折腾的再好看都有明显的瑕疵。Linux从根上开始就没有考虑一丁点美观，没有一个统一的GUI框架，没有一流的设计师、美化师来打好基础。这导致，即使再漂亮的Linux桌面，你一打开软件列表，你总能找到一堆不和谐统一的元素，这没得救了。如果你真的对外观要求很高（比如搞Web前端设计的），就别用Linux了，Mac和Windows都是很好的。&/p&&p&5：Linux的精髓在于快捷方便的编译代码、安装软件、部署应用的能力，以及强大的shell命令组合。你在黑框框的命令行里，能用出Linux 的90%精髓。你完全不用美化系统，甚至，等你熟悉了Linux界面，你会觉得过于catchy的界面是一种distraction，你会觉得这种熟悉又简单的黑色cmd框框能给你一种可靠，一种自信，每次一打开电脑你上来就忍不住想立即打开bash敲几个ls、grep、find、xargs。&/p&&p&6：Linux是专门用来干活的。用电脑的两个目的：工作和娱乐，Linux很难把娱乐包含进来。所以，用于娱乐的电脑和和用于工作电脑最好是物理的两台电脑，同一台机器上的双系统也行。&/p&&p&7：（修改后增加）大IT公司里，或者大的科研组里，server（几十个core，几百G内存，几个GPU的这个x86 server）一般专门IT人员管理的，普通user只能登录使用，不能修改:-(，一般ssh进去，顶多ssh -Y进去远程个桌面，没root权限，想美化也不改了太多东西。老老实实用ssh吧。不过说实话，用tmux 开多个terminal，用parallel -n 32 来开32个core运行自己写的script，用htop看着32个核一起接近100%的感觉确实很爽~~~）&/p&&p&以上～～～轻拍&/p&
奉劝一句，别再花力气折腾这些玩意了，有时间学点能用的东西（Python，c/c++，OOP，vim，爬虫，多线程），比这些折腾美化的东西强万倍。大家都是踩过坑的人，几句劝告，忠言总是逆耳的。1：特别耗费时间。这句话适合所有Linux发行版，折腾Linux的外观经常耗…
啊，就按你列的顺序就行。反正你也看不完。
啊，就按你列的顺序就行。反正你也看不完。
用Qt已经4年了，我来说说感受。&br&在我用Qt的这些年里，Qt一直处于不温不火的状态。有很多公司用，如YY、WPS这样用户过亿的产品，也有不对普通用户的军工、船舶。最近在汽车这块也比较火。但是Qt没有在被大规模的采用，往往是只有部分行业内Qt的使用率很高，这的确是事实。&br&Qt是我的主力开发框架，我拿Qt开发了客户端，服务器端，桌面端，移动端甚至还包括点嵌入式端。这这之中我遇到了很多Qt的不足以及Qt的强大。考虑到题目定义，在本回答中我主要讲不足。&br&&br&0.互联网时代了，很多人已经答过这个，不展开了。&br&1.开发人员不足：这是我现在发现Qt这个生态系统里最大的问题。因为缺少开发人员，导致企业难以招到高质量的Qt工程师，然后不愿意展开Qt的项目，这简直就是恶性循环。我见过有公司因为担心招不到Qt工程师，直接把已经做好的产品雪藏，再用HTML5重新开发一遍。&br&2.工程师们对Qt认知普遍落后：直至今天，Qt从4.8开始推出的QML（QtQuick框架，计划是代替QtWidgets）仍然没在Qt圈子里普及，甚至很多人都不知道这是什么以及这个能干什么，这更别说其他工程师们了。&br&3.学习成本高：Qt有QtQuick，这个开发起来非常方便，但是这毕竟是新的框架，带来了新语言和新的开发模式，这意味着学习成本，很多人看到就望而止步，拒绝学习（没错，是拒绝学习），我本人也是在接触Qt两年后才慢慢接触这个框架。才发现这是好东西。退一步说，就算是只用QtWidgets，这也是C++，这个入门成本太高。套用我以前同学和我说的话：如果我学的是Web开发，我第一天就可以做出可视化的成果，用起来还不错。但是如果是C++，几个星期了说不定还是黑乎乎的控制台，学习的兴趣一下子就没了。&br&4.硬件要求高：我认为Qt的未来在于QtQuick，无论桌面、手机还是嵌入式。但是QtQuick对硬件要求很高（相对QtWidgets而言），没显卡，或者显驱不完善，不好意思，直接拜拜，跑不起来。很多公司因为这个，放弃了QtQuick，回到QtWidgets，去纠结那个C++到底适不适合开发界面的问题。甚至直接抛弃Qt。&br&5.太大：一个HelloWorld 10多MB，我觉得这个正常，毕竟Qt不是系统级别的库，但是很多人接受不了。另外Qt自己也出了lite计划，降低Qt的大小以及对硬件的依赖（一起解决我说的4、5两点），但是截止我编写本答案，该项目仍在开发中。&br&6.宣传力度低：举个例子，Qt以前就有一个虚拟键盘的组件，但是只给企业版，然后前段时间给开源了。但是我问过很多很多人，他们连有这个东西都不知道，仍然自己在造轮子。还有其他很多东西都是如此。其实这个来源的信息都是公布到官方的blog，但是是英文，很多人估计都不会去看一下。&br&7.授权协议：目前Qt是GPL和LGPL，这个就不用我详细解释了吧，动不动就要开源。除非买企业版解除这个限制，但是企业版又是一个大开销。&br&&br&&br&其实啊，我还是挺喜欢Qt的，千万别说我在黑Qt。&br&&br&结论：Qt的前途是光明的，但是道路是坎坷的，Qt加油。
用Qt已经4年了，我来说说感受。 在我用Qt的这些年里，Qt一直处于不温不火的状态。有很多公司用，如YY、WPS这样用户过亿的产品，也有不对普通用户的军工、船舶。最近在汽车这块也比较火。但是Qt没有在被大规模的采用，往往是只有部分行业内Qt的使用率很高，…
先不要脸的推荐一下我自己写的几个PyQt玩意儿&br&1.模仿Mac虾米的客户端，还没有写完，PyQt4，Python2&br&&a href=&///?target=https%3A///harry159821/XiamiForLinuxProject& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - harry159821/XiamiForLinuxProject: Xiami For Linux Project&i class=&icon-external&&&/i&&/a&&br&&img src=&/6bee6705546_b.png& data-rawwidth=&1029& data-rawheight=&689& class=&origin_image zh-lightbox-thumb& width=&1029& data-original=&/6bee6705546_r.png&&&br&&img src=&/de1b1a4be160aaf35426e_b.png& data-rawwidth=&1025& data-rawheight=&687& class=&origin_image zh-lightbox-thumb& width=&1025& data-original=&/de1b1a4be160aaf35426e_r.png&&后面两个布局就没这个强度了&br&2.给Drrr的简单客户端，PyQt5, Python2&br&&a href=&///?target=https%3A///harry159821/DrrrClient& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - harry159821/DrrrClient: DrrrClient For PC&i class=&icon-external&&&/i&&/a&&br&B站展示视频 &a href=&///?target=http%3A///video/av2790951/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&无头骑士Drrr网页电脑版客户端&i class=&icon-external&&&/i&&/a&&br&网页介绍 &a href=&///?target=http%3A//harry159821.github.io/DrrrClient/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Drrr PC Client&i class=&icon-external&&&/i&&/a&&br&&img src=&/cdb07ed59fe332daaa2e5_b.png& data-rawwidth=&1365& data-rawheight=&767& class=&origin_image zh-lightbox-thumb& width=&1365& data-original=&/cdb07ed59fe332daaa2e5_r.png&&&img src=&/038f67f226bfcea9c5ec91f10d3e81d1_b.png& data-rawwidth=&1365& data-rawheight=&767& class=&origin_image zh-lightbox-thumb& width=&1365& data-original=&/038f67f226bfcea9c5ec91f10d3e81d1_r.png&&其实只是个浏览器，里面都是 网页&br&3.给一个电表写的显示，PyQt4，Python2&br&&a href=&///?target=https%3A///harry159821/TDM1001UpMachine& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - harry159821/TDM1001UpMachine: TDM1001UpMachine&i class=&icon-external&&&/i&&/a&&br&&img src=&/a18c53485e0ffba03b334a484f1ef5eb_b.png& data-rawwidth=&1366& data-rawheight=&768& class=&origin_image zh-lightbox-thumb& width=&1366& data-original=&/a18c53485e0ffba03b334a484f1ef5eb_r.png&&&br&其他作品&br&1.网易云音乐 ubuntu 第三方客户端，PyQt5 Python