网站做qq登录界面,适合穷人的18个创业项目,木材加工公司网站建设,李笑来做的一个网站2019独角兽企业重金招聘Python工程师标准 别用微软的东西。商业目的性太强#xff0c;千万别被微软牵着鼻子走#xff0c;血淋淋的教训。微软推出的垃圾多了去了。它什么都想做#xff0c;很多都没做好#xff1a; MFC#xff1a;Win31时代出生#xff0c;… 2019独角兽企业重金招聘Python工程师标准 别用微软的东西。商业目的性太强千万别被微软牵着鼻子走血淋淋的教训。微软推出的垃圾多了去了。它什么都想做很多都没做好 MFCWin31时代出生Win95、98时壮大虽然一直在更新但是接口和概念都太老气。你要做现代界面大量东西要自己手工去弄。同一个界面一个熟悉MFC的程序员需要开发2周而一个刚刚学习 Qt我认为Delphi、Java做界面也很快不比Qt差甚至更好一个月的大学生三天就搞定了。 WTL好几个百万 DAU量级产品都试用过最后都放弃没用了微软也不怎么管了。 SilverLight对抗 Flash当年刚推出的时候被微软碰成下一代桌面/web的统一解决方案有的人真的去用了结果呢傻逼了。想找点第三方控件少的要死想招人也招不到最后切换会flash去。 ASP.Net当年微软到高校里面忽悠大学生学学了半天就业了发现网页全部是 linux下的解决方案傻逼了。一线的互联网公司就没有使用 SqlServerASP•Net的都是清一色开源免费。 C#这个还算好的了十多年前照样当年骗着大学生学说是比 java好很多。我很多年收到的学生简历都是精通C#问题是十多年都过去了看看今天的 TIOBE排行榜java的分值是 c#的 4倍以上服务端开发web/非web企业级开发java都是完爆 c#更别说java开发 android设备的app了。微软的话再次没算数当年学了很长时间 c#的学生工作后碰都不会碰一下。 XNA笑话一个当年搞了好多 XNA游戏开发大赛告诉大家 XNA就是游戏开发的明天可以快速搭建小型游戏或者快速编写游戏demo供验证。我们在评估使用什么给新人做 Demo用最后评估下来PythonPanda3D易用性比 xna强几条街呀。 DirectMusicDirectInputDirectPlay全都傻逼了。 声音方面 Wave接口 - DSound接口 - CoreAudio接口它就稳定不下来的。 微软的思路就是看着一个开发工具好然后自己也要搞一套然后借着自己强大的影响力哄骗所有人来用他们的东西最后大家用下来还是觉得开源的好。 微软的界面解决方案GDI/Win32自己画MFC/GDI自己画基于Win32的各种界面库WPFSilverLightDirect2D看得你都不知道选哪个但是你要做现代流行界面的话一个Qt我认为Delphi、Java不比Qt差甚至更好当然甩MFC多少条街直接秒杀他们所有。 再给你说个血淋淋的教训公司的游戏当年用的dx8开发开发了两年内测时微软开始推所谓革命性的dx9了但是微软强调说dx9兼容dx8但是dx9性能更好而且今后不会再有dx8的大更新。好吧先不管游戏先上着但是竞争对手的游戏马上声称完美支持dx9充分发挥dx9的xxxx我擦没办法既然今后趋势是dx9那就改学起来也挺快的不就是api嘛改了三个月基本改完。但是碰到各种坑各种文档上找不到答案网上还没人遇到的坑当年dx9比较新前前后后折腾了1年半游戏才算ok了。跑了没多久这时微软的 dx10出来了号称完美兼容dx9但是dx9不会再有本质上的更新了你们快学dx10吧性能很好等你学会了 dx11又来了。 试想你一个程序员一大半的时间都在给微软交学费值得么人生有多少时间呀这就叫做被微软牵着鼻子走。再回过头来看看 OpenGL到现在为止还在用着 1.2/2.0标准ES 3.0刚出这就叫做稳定。一旦被商业利益捆版你就傻逼了.Net到现在好像都5.0了吧 跨平台 我之前对写一些客户端的代码用很多 VC的特性是抱容忍态度的毕竟每个程序员有自己熟悉的领域。在项目时间有限的情况下让熟悉 Windows的程序员在用很多 VC Only的特性如 DWORD, DibSection, CString, #pragma once 等东西也是可以容忍的毕竟当年客户端一般都是 Windows。 后来客户端发生了变化一份代码需要同时运行于多个平台。除了vc编译外还需要gcc, clang编译。当我们一份代码需要同时运行在 win32, 移动平台和 flash(crossbridge) 中时当年积累的这些 vc only的代码化了不少时间翻新成跨平台的代码了。尽管vc有 #pragma once这些还是比较先进的语法糖但 gcc/clang没有的情况下只能退而求其次。 通过这次翻新今后客户端也跟服务端执行一样要求清一色的跨平台再也看不到任何vc only的代码了。所有项目去 vs化。 答疑1【商业目的性太强给微软教学费这几句非常可笑现在还想学一个东西保一辈子么学什么不是学网页游戏火学Flash手机来了学objectc学android开发游戏引擎变成了Cocos和unity3d做网站后来流行PHP等等这类例子太多了楼mfcvbasp这些当年都带来了很多就业机会让人入了门楼主主观情绪太强】 没错正式学了新的才会抛弃微软的东西比如学了Qt当年可是n多人学了Delphi立马可以笑傲MFC多年才会抛弃 MFC/WPF学了 php才会抛弃 asp学了 java才会抛弃 c#学了 flash才会抛弃 silverlight学了 MySQL才会抛弃 SqlServer。然后你会发现我当初干嘛学微软的那些东西呀浪费我时间么 当年很多人是靠mfc vb开发那是因为没有更好的今天有那么多的其他选择mfc vb已经可以退居二线了。也正是因为有那么多平台需要应对特别如果是C/C程序员才不能用太多CString这些只能在vs下跑没法到android和服务端用gcc编译没法到ios下用clang编译的代码。这叫去微软化。 再者如果你没得选比如你用dx那么你就受苦吧它每隔两年出一代搞那么多版本到底是一开始接口就没设计好需要不断重构呢还是故意非要重新弄一套当初出9我没记错的话就是为了推winxp的只有xp能跑。而dx10又是为了推vista和win7逼着你游戏要更好效果必须dx10而你想玩好游戏的话你可能被迫升级你的操作系统。这就叫商业利益驱动。 反观其他平台开发很多图形工作站用ogl游戏主机用oglandroid用oglios用oglmac用ogl而ogl几十年到今天主要版本还是2.0包括es2.0这就叫没有商业利益驱动的情况。 如此类推出一个新平台有微软的vs2015和Qt、Java那么用Qt或Java吧。 如果你觉得vs作为ide很好用的话在没有更好替代的ide前你可以用vs这个ide来写Qt或者Java代码嘛。这叫逐步去微软化。 更新擦本来只有一句话推荐Qt或Java远离微软有人追问补充了点有人又追问又补充了点然后出了趟门回来感觉跟捅了马蜂窝一样。既然都说到微软了那就接着展开一下。 问题的本源 微软就是战线太长了忙着去主导各种标准制订各种框架这样的话才能更好的夹带私货用一个你必须用的东西推进另外一个他想让你用的东西诸如dx和windows诸如c#和 asp.net而又因为主导了开发者才能进一步主导用户而主导了用户大量的利润便会随之到来。在整个链条中如果消费者没得选择开发者也没得选择时微软就能想卖啥就卖啥完全基业长青了。出个新东西没关系不符合我的利益我就不支持。如果新东西很有前途那我自己搞一套然后再把我的开发者和用户绑架过去。 到底哪一个方向会有前途呢微软自己也说不清。到底哪个领域对今后的软件生态影响比较大呢微软自己也道不明。只能朝着各种有苗头的地方去努力以前技术领域比较窄微软可以囊括整条产业链编译器/IDE/框架开发者基本可以躲在微软的圈子里不出来。后面各个技术领域蓬勃发展分支越来越多微软就有些力不从心了。但是战略依旧没变任然试图去主导任何一个技术领域的标准。利用自己的影响力去忽悠各种开发者“跟我来吧有美好的明天”但技术领域每天都在推陈出新产生新的细分。为了主导更多的新领域称霸完一个领域后微软的重心并不是完善该领域而是继续集中精力称霸其他新的领域。 对于支持期的技术微软会利用自己强大的影响力进行各种捆版整合告诉你“新的革命又到来了你准备好了么”告诉你“用了它之后你就什么都不愁了”“XXX即将停止支持”然后各种社区中一堆mvp前扑后拥的进行推广“XXX大法好MS法力无边”书店的柜台上瞬间多出几十本红色封面黑色封面的宝典CSDN的主页里各种微软 TechED, 夏令营。很多人一看我靠全世界都在用我再不用是不是就要被淘汰了呀 完成支持后微软进入绑架期为了不让你用其他的东西微软想尽一切你的需求然后为满足你可能的一切需求开始拼命的飙版本来兼容各种各样的东西。很多人觉得这个东西好像挺强的什么都能做不用学其他了微软就笑开花了觉得可以绑架大家了于是开始疯狂的用该技术夹带越来越多的私货或者是新技术或者是为了强迫其他人用另一个东西为了兼容这些私货继续飙版本这就叫绑架。 等到你积累了越来越多的代码或者成熟框架后你突然发现原来你能做的事情就是只能在微软给你划定的一亩三分地里面不断的耕耘。想用它开发一个微软商业上不支持的东西没门。依赖微软越久做出选择的成本越来越高。这时会有两种结局第一种微软给你指出下一个革命的方向你别无选择斩断原有积累投入到下一个革命中。异或微软觉得自己在这个领域江山稳固了竞争对手都没了不会再出什么幺蛾子了于是彻底开始不思进取你用着过时的技术干着急。 曾任微软副总裁的李开复回忆“一个产品队伍一旦失去了假想敌就会松懈盖茨和鲍尔默也会撤回对它的投资和支持。比如说微软IE击败网景之后微软就降低了投资致使它的浏览器多年没有再进步直到又出现了‘火狐’这个敌人才又开始振作。”火狐就是网景的“遗孤”。 微软的绑架 MFC就是一个很好的例子当年同 VCL竞争时挺上进的VCL一死MFC也跟着死了现代的界面系统都是 windowless直接绘制控件了笨重的mfc还在基于系统控件。大量的onpaint自己做人招不到不说工作效率奇低熟练的mfc工程师还比不过学习Qt、Delphi、Java一个月的学生开发效率高你说我会选啥mfc还需要各种奇巧淫技才能达到qt、delphi、java的效果弄那些技巧的人变动项目就傻逼了考虑到这一点你说我又会选啥最近两年界面开发又开始脚本化了你会发现 Qt、Java有各种支持脚本除了内嵌支持 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技术比微软强而是因为它不是微软的。而且我估计个两年出个 pdf2xps也就跟 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下写就会觉得这真是个玩具呀。 TLSTLS有数量限制也不管了但是线程本地存储这个东西是需要 destructor的即我创建了一个本地存储来存一个对象我可以设置一个 destructor函数指针在线程退出时这个函数会被自动调用到。比如你想实现一个 per-thread cache比如类jemalloc的 arena线程退出时能够被自动析构这个最基本操作在 Win下却可以把你别扭死原生TLS API没有这个支持你又不想所有线程退出都要强迫使用者调用一下 destructor那么你开一个线程监听所有线程还是怎么招看看 boost和 jemalloc这些在 win下的 destructor实现你就会发现恶心的要死就像要在一块工整的电路板上焊接一根非常碍眼的飞线一样。 GDI/GDI: GDI是牛逼的出生早又承当了 GUI的基础工作毕竟那么多年了做成这样是无可厚非的。但是XP年代的 GDI一出生就落后于时代。比同期的同一个级别的开源项目 Cairogtk后端wine用来模拟gdi/gdi的后端webkit/mono后端和 QuartzOS 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# 和 asp.net绑定太紧asp.net和 iis绑定太紧iis和 windows又绑定太紧。微软的东西才出来都是先进的可封闭的微软不愿意同外面合作。你要用我先进的东西你就一个系列都要用。最终全部都搅在一起了风险是相当大的系统就像一个吞噬了各种化学物的怪兽一般蹒跚前行。 而所谓简单性和可拆分性的东西是四处皆可替换的东西。比如你做 web开发你选一门语言python语言就做好语言的事情。外部的网络框架可以用 djangoflask, web.py等等接口可以用 fastcg / cgi / wsgi / uwsgi / apache_mod, 而外部的服务器可以用 apache, nginx, lighthttpd。清晰的被分成语言层、框架层、协议层、服务层 四个不同的层次每个层次若干备选方案互相兼容web.py过时了我换 flaskapache过时了我换nginx。每个产品都专注做好自己的事情并前后适配其他层次的方案python出问题了我换 ruby换php协议任然用 apache_mod或者 fastcgi。这就是分治具备美感的设计。 这样的情况在微软的技术体系里很难出现这些技术运行到windows下水土不服不说微软自己就不让你选你要写asp .net那语言你就用 c#vb比较小众用了asp.net你就要用iis而iis只能跑在 windows下。外部的人很难兼容进来本来微软就不太愿意支持其他技术。那么好一开始可能领先但是随着时间推移这么长的链条中间一环出问题可能会导致其他的跟着他一起被人抛弃。 微软一方面出于商业考虑生怕自己技术链中哪个环节被人替换一方面有些接口设计充满耦合考虑不周导致后面大量的主动升级和被动升级什么 ocx, com, atl, oledx1-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#但是现在也面临诸多挑战 CEFChromium Embedded Framework用js直接写Windows本地应用如网易云音乐用CEF效果拔群Qt系列脚本越来越多互联网公司在用如Wps自己CUI库/脚本例子太多了。这些方案你或多或少都能挑出些问题来但不可否认的是她们正从各个方向蚕食 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远离微软的技术。但是完蛋了一堆人上来围攻那我真得正儿八经的把微软这事情说的清楚点才行了否则我变成误导题主了。 其实世界是欢迎微软改变的我们这些从小学电脑就用着盗版微软系统的人对微软也还是有感情的。但是微软这次能否迎来新生还得看微软自己我们是帮不了他的。 转载于:https://my.oschina.net/u/2546684/blog/752985
