VS 2015 的跨平台特性对 Qt 会带来多大的冲击呢？ 第1页

更新：擦，本来只有一句话，推荐Qt，远离微软，有人追问，补充了点，有人又追问，又补充了点，然后出了趟门回来，感觉跟捅了马蜂窝一样。既然都说到微软了，那就接着展开一下。

问题的本源

微软就是战线太长了，忙着去主导各种标准，制订各种框架，这样的话，才能更好的夹带私货，用一个你必须用的东西推进另外一个他想让你用的东西，诸如dx和windows，诸如c#和 http://asp.net，而又因为主导了开发者，才能进一步主导用户，而主导了用户，大量的利润便会随之到来。在整个链条中，如果消费者没得选择，开发者也没得选择时，微软就能想卖啥就卖啥，完全基业长青了。出个新东西没关系，不符合我的利益我就不支持。如果新东西很有前途，那我自己搞一套，然后再把我的开发者和用户绑架过去。

到底哪一个方向会有前途呢？微软自己也说不清。到底哪个领域对今后的软件生态影响比较大呢？微软自己也道不明。只能朝着各种有苗头的地方去努力，以前技术领域比较窄，微软可以囊括整条产业链，编译器/IDE/框架，开发者基本可以躲在微软的圈子里不出来。后面各个技术领域蓬勃发展，分支越来越多，微软就有些力不从心了。但是战略依旧没变，任然试图去主导任何一个技术领域的标准。利用自己的影响力去忽悠各种开发者：“跟我来吧，有美好的明天”，但技术领域每天都在推陈出新，产生新的细分。为了主导更多的新领域，称霸完一个领域后，微软的重心并不是完善该领域，而是继续集中精力称霸其他新的领域。

对于支持期的技术，微软会利用自己强大的影响力进行各种捆版整合，告诉你：“新的革命又到来了，你准备好了么？”，告诉你：“用了它之后，你就什么都不愁了”，“XXX即将停止支持”，然后各种社区中，一堆mvp前扑后拥的进行推广：“XXX大法好，MS法力无边”；书店的柜台上，瞬间多出几十本红色封面黑色封面的宝典；CSDN的主页里，各种微软 TechED, 夏令营。很多人一看，我靠，全世界都在用，我再不用是不是就要被淘汰了呀？

完成支持后，微软进入绑架期，为了不让你用其他的东西，微软想尽一切你的需求，然后为满足你可能的一切需求，开始拼命的飙版本，来兼容各种各样的东西。很多人觉得这个东西好像挺强的，什么都能做，不用学其他了，微软就笑开花了，觉得可以绑架大家了，于是开始疯狂的用该技术夹带越来越多的私货，或者是新技术，或者是为了强迫其他人用另一个东西，为了兼容这些私货，继续飙版本，这就叫绑架。

等到你积累了越来越多的代码，或者成熟框架后，你突然发现，原来你能做的事情，就是只能在微软给你划定的一亩三分地里面不断的耕耘。想用它开发一个微软商业上不支持的东西？没门。依赖微软越久，做出选择的成本越来越高。这时会有两种结局，第一种，微软给你指出下一个革命的方向，你别无选择，斩断原有积累投入到下一个革命中。异或，微软觉得自己在这个领域江山稳固了，竞争对手都没了，不会再出什么幺蛾子了，于是彻底开始不思进取，你用着过时的技术干着急。

曾任微软副总裁的李开复回忆：“一个产品队伍一旦失去了假想敌，就会松懈，盖茨和鲍尔默也会撤回对它的投资和支持。比如说，微软IE击败网景之后，微软就降低了投资，致使它的浏览器多年没有再进步，直到又出现了‘火狐’这个敌人，才又开始振作。”火狐就是网景的“遗孤”。

微软的绑架

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去吧，这就叫绑架。面对绑架你别无选择，开发者微软系的代码和经验积累越多，想离选择非微软的东西成本就越高，想不被微软绑架的代价就越大。

为啥有人愿意给 Qt脚本化而不愿意给微软的界面系统脚本化呢？并不是微软的技术就比不过Qt，而是大家唾弃微软的臭脾气，外加Qt是开源的，为它实现脚本各种方便。这里并不是说开源的东西就一定比微软的东西好，微软有很多领先的技术甩开源几条街，主要问题在于微软的封闭性。所以我的论点并不是一定要用开源，而是建议大家有选择的余地下，选择非微软技术，比如qt, flash这种。

死也要主导行业标准

为了引导行业标准，微软很多设计的很好的东西，各种音视频格式，还有最近的 HD Photo图片格式，比 jpg2000 和google的webp好多了。但是很多人由于微软的封闭不买微软的帐，很多框架和软件都直接支持webp了，也没几个人支持wdp，在这种情况下，我宁肯选择次一等级的 webp。

微软的出过很多标准性的东西，比如wmv, wma格式，当年挺先进的，微软也天天忽悠人去用这两个格式，但是由于封闭，最终失去支持，大家选择了更加开放的方案来代替，微软也就不思进取了，最终视频领域 现在是 h.264/265，音频领域是 he-aac v2。

微软又试图代替 pdf，引领该领域的标准，然后自己出了一个 xps。论技术，确实高于 pdf很多，但是没人用呀，没软件支持呀，连打印机都只支持扫描成pdf格式。所以我选择 pdf并不是因为 pdf技术比微软强，而是因为它不是微软的。而且我估计个两年出个 pdf2，xps也就跟 wmv一样进棺材了。

再比如 SilverLight，微软在没有太大把握的情况下硬推这个东西，就是因为怕c#由于满足不了RIA使得C#开发的开发者流失到微软以外去，为此 .Net还逼迫大家升了几个版本。可惜，大家都知道的，于是微软自己对它的支持都少了很多。

你说微软技术弱么？不弱。那为啥这些明显乱七八糟的东西微软都要硬撑着试图主导行业标准但是最终又主导不了呢？那是因为我们先前提到的微软战略，从几十年前到现在都从来没有变过，然而时代变了。

Win32 API

Win32 是系统层最稳定的接口，一切功能的基础。这么基础的东西，微软该化大力气持续发展对不对嘛？非也，随便举两个例子你就会发现其实它已经落后世界很多了。微软是任性的，觉得我提供的开发模型可以解决一切问题，为什么要参考其他操作系统改进呢？即便其他操作系统提供的功能很好，我也要给你挑挑刺。而按照微软一贯的规律，系统 API领域，我完全控制了，那么我改进的动力也就不那么强了，庶民们岂能妄自议论 Win32 API，更别说想提交改动 patch给我了。

线程同步：如果你写线程同步，你会发现 Win32 API缺很多关键的东西比如：条件变量，读写锁，这两个最基本的能够组合成其他任何同步模型的东西，微软直到 Vista的年代才提供支持（msdn Condition Variable），这就意味着，你如果用了，你将面临很难在 xp下跑的情况。你问微软 xp怎么办，微软说用 event去 wait嘛。你就奇怪了，event这么弱智的东西能代替条件变量么，为啥不再xp年代就支持了？

单次初始化：pthread_once，没错，windows下面由于缺少这个东西，你再做一个全局变量供你的接口访问时，你需要保证该变量只被初始化一次。即便多线程同时调用访问该变量的接口，也不会出现两次初始化的情况，pthread_once就是做这个事情的。直接把代码写成：if (inited == false) { init(); inited = true;} 线程又不安全，外面加一个 CriticalSection，那你又需要在更前面去 Init这个 CriticalSection，还要保证不会发生多次 Init，问题还是没解决。于是很多人在 Windows下的解决方案是，在全局变量声明一个类的静态实例，这样 main()之前，那个类的构造函数能够提前被调用，进而又引入了新的问题，及多个全局实例又会存在谁先谁后被构造的问题，你又得用恶心的 #pragma宏来解决，最后初始化代码一团乱麻。而如果微软提供 pthread_once类似方法，那或许这一切都会变的很清爽。

网络接口：用过 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下写，就会觉得这真是个玩具呀。

TLS：TLS有数量限制也不管了，但是线程本地存储这个东西是需要 destructor的，即我创建了一个本地存储来存一个对象，我可以设置一个 destructor函数指针，在线程退出时，这个函数会被自动调用到。比如你想实现一个 per-thread cache（比如类jemalloc的 arena），线程退出时能够被自动析构，这个最基本操作在 Win下却可以把你别扭死，原生TLS API没有这个支持，你又不想所有线程退出都要强迫使用者调用一下 destructor，那么你开一个线程监听所有线程？还是怎么招？看看 boost和 jemalloc这些在 win下的 destructor实现，你就会发现恶心的要死，就像要在一块工整的电路板上，焊接一根非常碍眼的飞线一样。

GDI/GDI+: GDI是牛逼的，出生早又承当了 GUI的基础工作，毕竟那么多年了，做成这样是无可厚非的。但是XP年代的 GDI+一出生就落后于时代。比同期的同一个级别的开源项目 Cairo（gtk后端，wine用来模拟gdi/gdi+的后端，webkit/mono后端）和 Quartz（OS X图形后端）来，GDI+除了速度卡外，图像质量差，功能简陋，不支持抗锯齿，对GDI的字体效果也并没有质的改进。所以 Windows下的应用软件，一直因为字体和图像质量受到诟病。直到后面的 Direct2D出来希望改进这个局面，也已经是好多年以后的事情了。大量兼容 xp的程序还在跑在 GDI/GDI+上。

（ 问题有很多，以下省略若干字）

按微软的能力，想改进这些基础接口，应该不是难事。但基础接口的长期滞后，折射出的是该公司全胜时期的傲慢。

统治与分治

微软的接口设计向来是缺乏美感的，喜欢复杂化，喜欢什么东西都搅合在一起。什么叫做大一统？就是什么都能做，貌似很强大，一个东西能做的事情很多，开始是好的，但是随着时间的推移，耦合度高，各种盘根错节，一旦其中一个设计很 “巧妙”的东西过时了，那所有依赖它的东西将面临死亡。什么叫做分治？就是保证简单性和可拆分性，每个系统专心做好一件事情。一个不行，换掉即可，整个解决方案是由若干全部可以替换的子模块组成的，这叫分治。

Windows技术栈就是一个典型的大一统设计，他有很多很巧妙，依赖性很强的东西。比如，“一切都是窗口”，这个思想，从设计上来说就是有问题的。举个简单例子，WSAAsynSelect 用过的人都知道，这是一个网络接口，用来判断哪个套接字上有事件。但是却又要传一个窗口句柄过去，让窗口来接受网络事件，这就是一个很搞笑的例子。微软为什么这么设计呢？因为应用程序本身有一个消息循环了，就是窗口消息循环，但是如果处理网络的应用程序使用类似 unix poll的方法，去等待消息的话，窗口消息就得不到处理了。如果把poll放到一个线程里的话，那UI线程要找网络线程做点事情，那网络线程在 poll的等待周期中，如果没有新的网络数据过来，可能短时间内没办法理会 UI线程的请求。于是微软的解决方案，就是让网络层的事件合并到 UI的窗口事件中，这样就比较方便了，全部在窗口消息队列，你要把UI和网络放到一个线程也可以，两个线程也罢。这样把两个风马牛不相及的事情搅在了一起的：“巧妙” 设计在微软的技术栈里数不胜数。

合理的处理方法应该是啥？应该是继续使用 Poll，每次 poll可以设一个比较短的时间，并且可以被外面线程唤醒，这样就不会出现之前的问题了，两件事情不会搅在一起，这就叫可拆分性。结果呢，不关网络，大量的其他东西都和窗口搅起来了，等到 Windows程序要移植的时候，就会变得万分痛苦。有人说不是有 IOCP么？看看有多少一流的服务器支持 iocp？再说java可以把所有不同操作系统的异步事件模型封装成NIO，对 Windows对的 iocp却提供单独的接口，而且直到 7.0以后才有，微软总喜欢和全人类反着来。

缺乏审美的设计，才会导致 Win32 API被 GUI所束缚这样一种结果。这在其他系统对比来说，这时听都没听过的事情。这是设计上的偶合，还有商业上利益的选择。比如网页开发，C# 和 http://asp.net绑定太紧，http://asp.net和 iis绑定太紧，iis和 windows又绑定太紧。微软的东西才出来都是先进的，可封闭的微软不愿意同外面合作。你要用我先进的东西，你就一个系列都要用。最终全部都搅在一起了，风险是相当大的，系统就像一个吞噬了各种化学物的怪兽一般，蹒跚前行。

而所谓简单性和可拆分性的东西，是四处皆可替换的东西。比如你做 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。这就是分治，具备美感的设计。

这样的情况在微软的技术体系里很难出现，这些技术运行到windows下水土不服不说，微软自己就不让你选：你要写asp .net，那语言你就用 c#（vb比较小众），用了http://asp.net你就要用iis，而iis只能跑在 windows下。外部的人很难兼容进来，本来微软就不太愿意支持其他技术。那么好，一开始可能领先，但是随着时间推移，这么长的链条中间一环出问题，可能会导致其他的跟着他一起被人抛弃。

微软一方面出于商业考虑，生怕自己技术链中哪个环节被人替换，一方面有些接口设计充满耦合，考虑不周，导致后面大量的主动升级和被动升级，什么 ocx, com, atl, ole，dx1-7类似的东西都可以搞出那么多来折腾人，系统内核 GUI，网络、多媒体，大量的 API偶合在一起。最终简单的一个 Office和 Windows一样臃肿丑陋，这就叫缺乏美感的设计。

C#

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运行时低很多，库也不全，实在难以承当大任。

除了部分人专门从事 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#真正危机的地方。

DirectX

有人奇怪我为何喜欢 OpenGL，话说白了只有一个理由，它是开放的而且它不是微软的。如今很多人会说你看 d3d 接口不错，兼容性高，CPU占用低而且画面好。没错，但记心好点的同志们把时间拉长一点，Win95时代微软强推 DirectX而封锁 OpenGL很多系统调用的事情各位还记得到吧？那各位还记得到 DX才出来时烂成什么样子么？当时业内骂声一片，很多人看了眼接口就扔了，直到 DX5出来的时候，你稍不留神，还会把整个屏幕画花了，或者弄死机了。当年 OpenGL领先 DX不是一个量级。直到 DX8出来了，才算完善了一些。微软为了商业利益，把整个行业拖后了数年之久。直到2006年，很多 3A大作还是以 OpenGL为图形底层，不鸟微软的 D3D。

微软的技术架构，向来不太优雅，耦合度又高。Dx7以前，DirectDraw的表面和 D3D设备还有纹理搅在一起，DSound的坐标系统又可以和 D3D的坐标系统搅在一起。大量的数据结构被定义出来，一个矢量一个矩阵还要单独定义一下，不准我跨平台库用自己的定义么？你就不能用个数组么？你强大是强大，但是你耦合度实在太高了。一个环节更新，所有环节被迫更新，然后就飙版本的原因之一。DirectX的设计就是没有品味的，如果按照简单性和可拆分性的思路来重新考虑，Dx软件包中，应该隔的比较开才行，能不定义的对象和结构体，尽量不定义，用C原始的类型或者数组来接口，这样不会妨碍我外面灵活使用。然后游戏开发者靠一门胶水语言把这些独立模块根据需要粘合在一起，这样的方式是不是更清爽一些呀？

开放的东西能自我适应性，自我修正。Real Networks估计很多人还没忘记，当年的他开发的 RM / RMVB视频格式，因为压缩比高，同信噪比下码率能有更低的码率，画面质量更好，而赢得了广泛的支持。但是 RM / RMVB却是一个封闭的视频格式，虽然领先了业界数年之久，但是数年后即被开放的 H264所代替，H264虽然一开始接受度不高，但是数以万计的人在帮他完善。学院派今天发研究出一种更有效的宏块搜索方式，不出两个月工程界就跟进了。今天有人发现一个运动估计的改进，明天有人实现个更低延迟的缓存管理，或者提升下错误恢复能力。免费的 x264不论从延迟，性能，画质，码率都直接秒杀很多商业公司的编码器，ffmpeg又可以轻易的播放h.264视频。最终 Real Networks抱着它的 rm/rmvb一起进了坟墓，死前还不忘叫一句它正在开发 rmvb2，超越 h.265标准的编码格式，业内嗤之以鼻。视频领域的玩法已经变了，H.264通过不断发展，最终颠覆了RMVB的商业模式，这就是一项技术自我适应，自我修正的例子。

今天的 D3D就像当年的 RMVB，就算他用商业手段狠狠恶心了 OpenGL一把，导致后面 OGL数年发展不顺，但是老话说得好：理胜力为常，力胜理为变；一时之强弱在力，千古之胜负在理。随着 OpenGL新标准的不断完善，虽然暂时不能彻底抛弃 DX，但封闭的 Dx必然会随着微软 Windows 逐渐边缘化，这就叫得道多助失道寡助。

全世界玩一套，微软自己玩一套

还是因为微软最初的战略没有改变，导致全世界一套，微软自己玩一套；微软看不起开源界，开源界也不理微软。再次强调，并不是只有开源才好，而是这么多家公司里，只有微软一家试图自己从头到尾建立一套完整的技术体系，只有微软一家采取如此封闭的策略。然而早年微软可以罩住整条产业链，并且活的很爽，但是现在大量基于开源界的最新成果都和微软技术栈水土不服。

所以开发者会面临：依赖微软和不依赖微软两种选择。依赖微软，很容易和外界形成隔离。而不依赖微软，你得到的是满天下的选择。前者强调高度集成统一，后者强调可拆分替换。然而，世界潮流，浩浩荡荡，顺之者昌逆之者亡。

成也萧何，败也萧何

早年的微软，象一个潜伏在丛林里的猎手，利用自己操作系统的优势地位，寻找着产业链最高端的用户需求。一旦一项技术可以满足用户某种根本需要，微软就不惜牺牲眼前的现金流，来换取未来的行业领导地位和盈利。或快速收购，或恶意打压，或自家出一套，任何一个领域只要有新的东西出现，微软就试图去控制它，并绑架获出钱养活接受了微软标准的软件开发商让他们支持，出钱扶持低端的开发者让他们学习微软标准，于是巨大的利润，随之而来。

这样的战略，使微软茁壮成长，并成为接二连三的行业标准拥有者。然而这样的战略有一个致命的BUG，就是标准必须是与时俱进的，微软需要不断调整已有标准，否则越来越多的标准就会成为束缚住微软的一条条绳索，越来越多的兼容性问题象一座座大山一样压得微软喘不过气来。掌握的标准越多，微软越难改变，随着时间的推移，将会被微软体系外更加迎合用户偏好的竞争者们所取代。

有人说：“微软错过了移动化浪潮，错过了云计算，是因为鲍尔默的误判。智者千虑必有一失，再牛逼的人也有判断失误的地方”。但是通过上面的分析，我们可以看出这种说法的荒谬性，我们需要清醒的指出，就算没有鲍尔默，微软即便赶上了云计算，他也会错过雾计算；他即便赶上了雾计算，他照样会错过烟计算。

这样的战略，使微软早年站到了时代的风口浪尖，又使如今的微软，变得越来越与时代背道而驰，不是微软不想融合，而是融合的成本越来越高。世异则事异，事异则备变，理解了微软的核心战略，就不难理解微软为什么会去弄什么 xps, silverlight；理解了微软的战略，就能理解为何微软的精力总是在制定新标准，而不是改进老标准了；理解了微软战略，就不难理解为何进入2000年以后，微软总是昏招迭出了。

病在肌肤，还可以医治，病在肺腑，人就危险了。沿袭了那么多年的战略，成就了微软和他的下游开发商，也害了微软，让微软想改变都改变不了。就像一辆陆地上上装甲车，装甲越厚越坚固，然而现在要到水里开战了，所有装甲一夜之间全成了负担，要寻求救赎，除非把自己从头到尾全拆了才行。进入2009年后，看到当年一致支持自己标准的下游开发商们，粉粉判离微软转投敌营时，微软深刻的意识到，老天已经再也不像原来一样眷顾微软了，这真可谓是：成也萧何，败也萧何！

微软的选择

人什么时候会感觉到压力？就是拥有一个东西，但是看着这个东西一天天的减少，越努力抓住他，却又越抓流失的越快，改变意味着放弃，等待意味着死亡。在这样的压力下，微软昏招迭出，这并不能怪微软高管愚昧，也不能说微软运气差，而是自从步入 2000年以后，沿袭了几十年的一家统治世界的战略与时代变得格格不如了。早年的成功让微软无视各种问题，继续靠惯性又活了15年，错过了自我救赎的最佳时机。

核心战略出问题，不是一朝一夕的决策对错，很多人还不愿意承认，认为换了鲍尔默就能解决，认为开源 .Net，就能救 C#，就能救微软，其实这是一个天真的想法。微软战略从头到尾就没变过，开源其实相当于承认先前战略是失败的，可它却又没有提出一套新的思路和新的战略。事实上早在2000年时微软就进入了战略迷茫期，所以东一榔头西一棒子，没有重点，缺乏主题。虽然如此，还是能靠惯性继续生存，但是自我否定之后，新战略是什么呢？战略层的自我否定会极大的伤害企业向心力，让微软在未来变得更加艰难，同时又没有确立能够经得住实践验证的新战略，这又会使整个企业变得比原来更加迷茫。

但微软能改变么？不能。微软没有办法提出一套和原来战略不兼容的新战略，除非完全把自己和多年经营的生态链砸碎。15年前的最佳改变期被其错过后，如今再怎么变都只能在原有战略框架下寻求小改变，时代的巨流，象一股巨大的引力场，吸引着身躯庞大的微软，无可奈何的掉进自己挖的坑里。

无可奈何的结局

直接送货上门发达了，便利店就萧条了。网上购物兴起了，实体零售业也就死亡了。这就叫做 “新经济体” 代替老经济体。判断一个经济体是否衰落，看的从来不是它银行里还有多少钱，而是看它的商业模式是不是还成立。如今的微软，就是一个核心商业模式被颠覆了的企业。这不是开源能够救得了的，更不是盖茨复出能够救得了的。

听到微软开源，让我想起之前 Sun公司 Solaris开源为 Open Solaris，希望用开源来挽救自己的颓势，没多久它就倒闭了。如今一项根本技术，比如操作系统，已经很难被一家公司所垄断。商业模式一旦被颠覆了，开源也不能成为救命稻草。

事物强弱变换，新旧更替，本来就是自然界的基本规律。盖茨是一个聪明人，看到了未来的局面，知道什么叫月满则亏，水盈则溢，在微软最鼎盛的时候功成身退，高风亮节的做起了慈善，将最苦的差事留给了鲍尔默。所以，聪明的盖茨也是不会复出的，所以，其实我挺同情老鲍的。

结尾故事

一开始就没想喷微软，我不是一个极端的人，一开始只是回答问题，建议题主用 Qt，远离微软的技术。但是完蛋了，一堆人上来围攻，那我真得正儿八经的把微软这事情说的清楚点才行了，否则我变成误导题主了。

其实世界是欢迎微软改变的，我们这些从小学电脑就用着盗版微软系统的人，对微软也还是有感情的。但是微软这次能否迎来新生，还得看微软自己，我们是帮不了他的。

最后，给大家分享个小故事：

尼古拉·特斯拉（Nikola Tesla，1856年~1943年），被西方科学界的精英人物誉为是唯一堪比达·芬奇并超越爱因斯坦的伟大科学家，是人类有史以来最伟大的天才、发明创造的巨匠，但由于他身上同时也具有某种神秘甚至超自然的特质，也有人称他为神秘怪客或超人。是他发明和创造了交流电系统，对现代世界工业产生了深远影响。特斯拉引起的革命不仅限于电力工程，也涉及其他领域。他在科学和工程学领域取得了大约1000项发明。

尼古拉·特斯拉，交流电的发明者，当年毅然选择放弃交流电专利带给他的暴利，将交流电公诸于众，从此交流电变成了一项免费的发明。因为他觉得，交流电这么基本的东西，是属于全人类的。如果当年特斯拉选择不开放交流电专利，那估计我们今天的社会，都得倒退一百年。

一百年后的特斯拉汽车公司，在 Elon Musk 的领导下将自己领先世界的电动车发动机专利向世界开放，同样也是觉得电池车这种东西，是应该属于全人类的。而公司名称选作 “特斯拉” 也代表着向一百年前的 尼古拉·特斯拉致敬。

1. Qt SDK现在最新版本为5.4，按照官方说法，其LGPL协议下，提供以下目标平台的二进制开发包：

• Windows Desktop x86/64
• Windows Store App
• Windows Phone 8.1
• Android arm5/7
• Android x86
• MacOS
• iOS

如果在GPL协议下或者之前老版本的Qt，可以支持塞班、黑莓、各种嵌入式开发板等平台。Qt支持的目标平台肯定还是比VS2015多的。

2. Qt不仅仅是一个c++界面库，它在实现了一套基于C++的反射功能的基础上，包含了网络、数据库、多媒体、测试框架、国际化工具、打包部署模块等，甚至还自己封装了一个WebKit模块。此外，Qt有收费才能使用的模块：

• Qt Purchasing
  
• Qt Charts
  
• Qt Virtual Keyboard
  
• Qt Data Visualization
  

现在，除了这些传统客户端开发工具以外，Qt也推出了云服务QtCloudServices。这方面我去年写过一篇博客《Qt云服务/云计算平台QTC（Qt Cloud Services）入门（0）—— Introduction》，当然现在可能有变化。

3. 由于平台众多，Qt传统的基于QWidget界面在适配各种不同DPI的屏幕时，设计风格、控件及字体、图标大小等方面是会存在问题的，Qt5.4版本开始，官方宣称解决了DPI的问题：

High-DPI support for Windows and OS X

当然Qt5.4版本以前（包括现在），Qt官方希望大家使用QtQuick（QML，一种基于JavaScript的语言。c++与QML的关系，有点像C#与WPF一样）来解决触屏和DPI的问题，使用QML开发的话，在各个目标平台显示效果都是一样的，并且能够很方便的与C++代码交互。当然，与.Net的WPF比起来，还差很远，但毕竟跨的平台比WPF多。Qt官方有一个用来显示股市信息的QML Demo（http://doc.qt.io/qt-5/qtquick-demos-stocqt-example.html），在Win8、Android、WP上面显示效果都非常好。

4. QtCreator这个IDE与Qt配合起来非常完美，在VS里面使用Qt总感觉怪怪的。如果不使用Qt，由于C++语法过于复杂，VS这种宇宙级的IDE也不能像c#那样来IntelliSense C++，但无论如何还是要强于Qt Creator的。

5. VS2015中C++的跨平台，肯定不会是一次编写处处运行（除非写的是标准C++）。如果带有界面（Win的MFC、WTL，Linux的X11）、或者有用到POSIX、WIN API，怎么可能不修改代码直接跨平台？而Qt有自己的一套GUI、Networks等框架，如果严格使用Qt SDK的标准来开发，完全可以不修改代码，在各个平台编译就行。