Spiga

从Win8回顾微软平台的各种技术

2011-12-03 14:15 by lixiong, 7734 visits, 收藏, 编辑

我安装好Win8 CTP后做的第一件事情就是用调试器研究Win8各个组件的协作关系. 从我半天的研究结果看来, Win8真是一个让我爱不释手的产品. Win8里面涉及到的很多技术正好也是我的兴趣所在. 这篇文章简单回顾一下这些技术的变迁, 优缺点, 和对Win8的影响.

注意, 下面提到的对Win8的分析, 是基于公开的Win8 CTP来做的. 相信Win8面世的时候, 这些技术和细节, 都会发生重大改变. 所以这篇文章不具备实践上的指导价值.

COM -Component Object Model 通用组件模型

COM是上个世纪中期设计出来的伟大产品. COM旨在解决软件复用的问题. 在COM以前, 大家都是用代码级别的复用, 常见的就是C/C++的库, 无论是原代码库还是lib库, 都是需要编译后才能重用的. COM使得技术人员可以在二进制上进行复用. 从Win95, OLE32和Office95系列开始, COM就是微软平台上的一个技术基石, 无论是DirectX API, 还是最常见的剪贴板, 以及后来.NET Framework的host接口, 都离不开COM. 但任何伟大的产品, 都有局限的一面. COM在局限性在下面一些地方

STA/MTA/NTA等等线程模型过于复杂

线程模型, 特别是STA, 设计的目的是方便使用者. 但COM的线程模型严重依赖于太多系统组件, 比如Win32 Message, RPC和Windows系统服务, 使得程序员需要熟悉和了解太多系统知识才可以正确地使用线程模型. 否则用STA导致死锁简直就是家常便饭.

开发工具没有提供足够支持

COM和Visual Studio 6.0的关系, 就如同现在CLR2/VS2005, CLR3.5/VS2008和CLR4/VS2010的关系一样铁. 使用COM开发, 当时的选择要么是VB6, 要么用ATL. 这两者都有天生的局限. VB6适合企业开发, 特别是当时流行的MIS系统, 数据库系统这样的CS应用, 但是VB6不够灵活. 而且VB6里面由于缺少多线程支持, 无法用MTA的模型. ATL功能强大, 足够灵活, 但是使用起来特别复杂. 每次实现一个接口, 都要做一大堆C++的仪式性工作, 比如实现多重继承, 定义新的模板, 使用大量的C宏. 神经再粗大的程序员, 都经不起这样用C++的.

无止境地扩充到DCOM, COM+, DTC, MSMQ以及后来的.NET Remoting/WCF, 使得最后的复杂度无法控制

为了更好地适应企业级别的开发, COM被进一步延伸和演化成了DCOM和COM+. 所谓"企业级别", 其实是指对安全性和可伸缩性的更高要求. 经典的COM是一个进程内模型, 无法让不同的代码运行在不同的帐号下的, 因为同一个进程只能启在唯一的帐号下. 虽然通过impersonate等方法可以适当地解决问题, 但是为了让安全模型更为全面, 正确的做法是让不同的接口实现, 能够跨越进程甚至跨越机器等安全边界运行, 要能够赋予不同的接口不同的安全级别, 能够和域帐号集成, 支持不同等级的加密等等.远程通用组件模型, 也就是DCOM就这样诞生了. 读者可以尝试运行以下dcomcnfg.exe这个工具, 展开一些节点, 看看属性页, 就能体会到DCOM的功能是多么让人眼花缭乱了. 对于可伸缩性, 微软更上一层楼, 在DCOM的基础上加入了对象池和新的同步模型做成了COM+. 风靡十年的ASP, 就是运行在COM+框架下的最好例子. 更让人叹为观止的是, 微软把DTC和MSMQ的设计也和COM+模型绑定起来. 陌生的读者可能不了解DTC是个多么nb的东西. 简单说DTC是可以让程序员一行代码都不用写, 就让SQL Server和Oracle的数据库操作运行在同一个事务边界里面. 可以想象, 在MSSQL Server刚进入市场的时候, 微软推出这样的功能, 对于抢占Oracle的市场份额有多么重要. DTC和COM+当时成为了很多大公司的标准配置, 以至于后来设计.NET Remoting和WCF的时候, 都还是要考虑对DTC的支持. 这些强大而且复杂的功能, 让本来就复杂的COM更加恐怖. 这样的复杂度虽然也体现了当时的市场需求, 但由于缺乏配套的开发工具, 新的开发语言和更优美的抽象, 使得这条路最后越走越窄.

.NET Framework/CLR

在我眼中, CLR的各方面简直是无可挑剔的. 但可能正是因为CLR太好了, 让微软从2003年开始, 对unmamanged world的投资就不大了.

为了争取企业客户, 全力推广CLR是最正确的做法. 毕竟绝大多数的程序员, 一辈子都是和数据库, 和UI代码打交道. 你总不能让他们一辈子都用C去管理内容, 创建窗口句柄吧. CLR的性能也很有竞争力, 与之对应的编程语言和开发工具也非常给力, 每个新版本都带来长足进步. 但是, 这些再好, 也无法掩饰一个悖论: 要用用C#写出性能可以和C++一个数量级的程序, 不是不可能, 而是花费的代价往往比直接用C++写更大. 这里面有很多原因. 比如系统最底层的API还是unmanaged的, 通过CLR作interop的性能损失无法忽略. 比如用C#的话程序员的控制力很弱, 从工具和语言层面上很难对性能精雕细作, 一不注意就box/unbox了. 比如JIT编译器为了实现自己的安全模型和异常处理, 每次访问成员函数的都是都要生成代码确认this指针是否为空. 这个世界上还是有很多程序, 是需要对性能做严格控制的. 在CLR高速发展的几年中, 对应的系统平台, Win32 API, C++开发工具, 只有完善性的改善, 并没有重大突破. 这个问题对Windows平台本身影响不大, 但如果寄希望于在移动设备上, 大家都指着C#来开发, 就有点天方夜谭了. 这样的失衡, 使得微软在移动设备和消费者产品这两个严重需要unmanaged和系统投入的领域缓慢发展了很长时间.

WPF

在我看来, WPF是一个设计得很美的产品. WPF解决了传统Win32 UI程序的四大局限. 1) Win32的绘图是由各自Window元素独立控制, 基于GDI的. WPF引入了rendering thread来提高性能, 优化算法, 借用GPU加速. 2) Win32依赖于GDI Object, 在开发复杂窗口程序的时候, 很容易就遭遇资源泄露和资源不足. 比如早期的淘宝旺旺, 开到几十个窗口的时候, 程序就会出问题. 所以淘宝针对这个问题, 使用了统一控制台, 合并多个窗口到标签页的方法来解决. 而WPF只有最外面的窗口使用了Win32 Window和GDI, 内部的元素都是抽象成了WPF自己的元素, 不额外占用Win32 GDI资源的. 3) Win32窗体程序严重依赖Windows Message模型. 这要求程序员对系统知识有深入的了解. 而且Win32 API并不是非常利于使用, 比如要进行UI thread和Worker thread之间的通信, 往往需要和SendMessage这样的API打交道. 在WPF中, 引入了Dispatcher类和BeginInvoke方法, 把这些复杂问题抽象了. 加上CLR提供了更方便高效的开发环境, 使用WPF是很愉快的工作. 4) Win32缺乏数据, 设计和代码三者之间的模式抽象. 这三者在WPF中对应了数据绑定, XAML文件, 以及后台代码. 在WPF中可以更直观地使用各种模式比如MVC和MVVM. 这些都体现了WPF设计上的优美.

再优美的东西都还是有局限性的. WPF的问题在于过多的模式和对CLR过度的依赖. 了解WPF框架的人都知道, 就一个简单的dependent property, 就把设计模式这本书里面的模式用掉一大半了. 分析WPF框架代码的话, 简直就是看一本设计模式的百科全书. 我曾经统计过, 关于mouse click这样一个event回调, WPF里面有7种不同的实现方法, 分别各有好处, 旨在解决不同问题. 在这样高度灵活的背后, 牺牲的是程序性能. 无论是五花八门的模式, 还是最常用的数据绑定, 背后的主力都是CLR的reflection. 过度依赖于reflection导致WPF程序规模一大, 性能上就出问题. 就算再怎么优化, 也总找不到原生Win32程序那般流利的感脚. 使用reflection也体现了对CLR的依赖. 所以前面CLR的局限性, 也适用于WPF.

微软产品的互操作性

微软的产品线虽又长又多, 但是各个产品之间一定是能够互操作的. 比如C#可以和C++互相调用. 任何语言开发的程序都可以嵌入Browser Control来借用IE的功能. Office暴露了VBA接口, 通过VBScript都能够自动化Office程序. 各种管理工具无论是Explorer还是MMC, 都暴露了编程接口可以让程序员添加自己的功能. 我见过客户用ASP.NET在后台用VBScript生成Excel表格, 然后把表格嵌入在 IE浏览器中, 再使用JavaScript来帮助客户编辑, 最后提交回MSSQL数据库做完成报销功能的. 完善的互操作性充分保护了用户的投资, 使得客户对微软平台用一次就上瘾, 几乎没有不可能完成的任务. 仔细分析, 其实这些互操作有一个共性, 都是把暴露COM接口作为内部实现原理. 这个做法导致了三个局限性, 首先是牵涉到了前面提到的COM的复杂度. 其次是潜在的性能损耗. 最后是在具体开发的时候, 都需要一些仪式性的工作来引入或者定义COM接口, 使得开发过程不够自然流畅. 在CLR和COM互操作的调用栈里面, CLR的RCW, CCW, 安全处理, 列集拷贝等等, 耗费的时间带来的性能开销简直是可以到了肉眼可察觉的地步(听硬盘的声音和看任务管理器里面CPU的波动).

Win8

在讨论完这些技术背后的故事后, 再看看为啥我就对Win8爱不释手了.

Win8引入了Windows Runtime, 简称WinRT. WinRT是一个操作系统模块, 运行在用户态, 介于Win32的上层和应用程序的下层, 目的在于提供更高效友好的开发接口供Win8的程序员使用. WinRT在二进制模型上基本就是照搬了经典的COM. WinRT和CLR互不依赖, WinRT可以被CLR使用. WinRT通过C/C++实现, 效率高是一个方面, 更重要的时Win8引入了projection的概念, 就是可以把WinRT的API用最直接最高效的方法, 提供给上层的编程语言调用. 这个语言可以是C#, C或者JavaScript.

对于第一次接触Projection的朋友, 可以把Projection认为是一种新的Windows API模型. 传统的操作系统API, 要么是暴露DLL的方法, 要么是通过COM接口. 无论是哪一种, 在CLR中调用的时候都有不小的开销. 使用这些传统API的效率, 比调用一个C#自己的方法, 效率差了多个数量级, 根本的原因在于CLR的安全模型, 内存模型和传统的unmanaged模型不兼容, 所以跨越边界的调用需要额外的代码来处理. 而Projection提供的模型, 是在提供新功能的同时, 还针不同编程模型和语言, 提供了最利于它们调用的方法. 这样就主动避免了不同模型之间为了互相兼容导致的开销, 也使得程序员写代码的时候非常自然流畅, 调用的时候根本感觉不到和调用本地函数的区别. 当然, 能够实现这一点, 也是得益于CLR, C#语言和VS开发工具这十年的长足发展. 举个例子, C# 5.0中引入了await关键字, WinRT中引入了async operation. Projection技术把C#中的await语句转换为WinRT async operation的调用, 而且这个调用直接从managed code直接跳到unmanaged code, 中间没有任何冗余, 也不需要CLR Engine的介入. 进一步的信息, 可以参考Build大会关于WinRT的多个演讲. 后面的callstack也提供了直观的例子.

前面提到了COM的局限性在于一个轻量的二进制模型, 被硬生生的扩展成一个无所不能的框架. WinRT取其精华, 去其糟粕, 借用了COM的轻便, 舍弃了复杂性, 在扩展性上依托于上层的编程语言和工具. WinRT通过projection的技术解决了传统互操作性效率不高使用不方便的问题. 以前的路线是希望所有的产品和技术最后都统一到CLR上来. 现在修正为底层模型通过WinRT和C来实现, 然后把这一层高效的组件无缝提供给上层的开发技术比如CLR来使用. 这个转变重新重视unmanaged层面的二进制模型. 归纳为, unmanaged模型的优势在于执行效率高, 可以通吃所有场景, 缺点在于开发和使用成本也高. CLR的优势在于开发成本低, 缺点在于无法通吃各种需求. 现在微软自己用unmanaged来做WinRT, 然后把WinRT提供给上层语言, 这两者就可以取长补短了.

有了WinRT, 有了unmanaged的回归, 再加上微软开发工具和C#语言的长足发展, 前面介绍的各种技术在Win8里面就相得益彰了. Metro是如何修复WPF的缺陷就显而易见了: Win8的metro程序继续使用WPF中引入的rendering模型和XAML, 但是在control的基础设计和实现上, 从CLR转移到了C, 然后通过WinRT来暴露给使用者. 至于使用的灵活性, 比如要不要实现数据绑定, 就看上层使用者自己的选择了.

附录

下面是我研究过程中看到的一些Win8的callstack. 基于这些callstack和我以往的经验, 才写了上面的文章.

Stack1:

Windows_UI_Immersive!`Windows::Internal::CMessageDialog::ShowAsync'::`50'::<lambda_32D66FEFF293CE6B>::<lambda_32D66FEFF293CE6B>

Windows_UI_Immersive!Windows::Internal::CMessageDialog::ShowAsync+0x1a0

image08ee0000!DomainNeutralILStubClass.IL_STUB_CLRtoCOM()+0x8c

application1!Application1.MainPage+<button_Click>d__0.MoveNext()+0xcd

application1!Application1.MainPage.button_Click(System.Object, Windows.UI.Xaml.RoutedEventArgs)+0x80

stack2:

combase!CComActivator::DoCreateInstance+0x121

combase!CoCreateInstanceEx+0x51

combase!CoCreateInstance+0x65

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_TryToUnregisterForIHMNotifications+0x3b

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_HideWindow+0x31

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::HideWindow+0x9

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::DestroyWindow+0x24

Windows_UI_Immersive!Windows::Internal::CPopupWindow::Destroy+0x57

Windows_UI_Immersive!Windows::Internal::CClosePopupCommandHandler::Invoke+0xe 0x73

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_OnButtonPress+0xc0

Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::OnMessage+0x18b

DUI70!DirectUI::NativeHWNDHost::WndProc+0x73

USER32!InternalCallWinProc+0x23

USER32!UserCallWinProcCheckWow+0x100

USER32!DispatchMessageWorker+0x3d4

USER32!DispatchMessageW+0x10

Windows_UI_Immersive!SHProcessMessagesUntilEventsEx+0xe2

Windows_UI_Immersive!Windows::Internal::PopupWindowOperation::Show+0x103

Stack3:

Windows_UI_Xaml!HWWalk::RenderChildren+0x7a

Windows_UI_Xaml!HWWalk::RenderContentAndChildren+0x2d1

Windows_UI_Xaml!HWWalk::Render+0x61e

Windows_UI_Xaml!HWWalk::RenderChildren+0x7a

Windows_UI_Xaml!HWWalk::RenderRoot+0x1c4

Windows_UI_Xaml!CCoreServices::NWDrawTree+0x698

Windows_UI_Xaml!CCoreServices::NWDraw+0x1d6

Windows_UI_Xaml!CRenderTarget::Draw+0x13

Windows_UI_Xaml!CWindowRenderTarget::Draw+0x40

Windows_UI_Xaml!CXcpBrowserHost::OnTick+0x88

Windows_UI_Xaml!CXcpDispatcher::Tick+0x184

Windows_UI_Xaml!CXcpDispatcher::OnReentrancyProtectedWindowMessage+0x133

Windows_UI_Xaml!CXcpDispatcher::ProcessMessage+0xa4

Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x69

USER32!InternalCallWinProc+0x23

USER32!UserCallWinProcCheckWow+0x100

USER32!DispatchMessageWorker+0x3d4

USER32!DispatchMessageW+0x10

windows_ui!Windows::UI::Core::CDispatcher::ProcessMessage+0xc7

windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x6c

Windows_UI_Xaml!CJupiterWindow::RunCoreWindowMessageLoop+0x3b

Windows_UI_Xaml!CJupiterControl::RunMessageLoop+0x1d

Windows_UI_Xaml!CJupiterControlLight::RunMessageLoop+0x8

Windows_UI_Xaml!DirectUI::DXamlCore::RunMessageLoop+0x15

Windows_UI_Xaml!DirectUI::ViewProvider::Run+0x11

twinapi!Windows::ApplicationModel::Core::CoreApplicationView::ViewProviderThreadProc+0x27

This is the end

 

Add your comment

48 条回复

  1. #1楼 toEverybody      2011-12-03 14:28
    虽然WinRT是非托管的，与NET无关，对C#这类托管环境中执行的程序，是不是只提高了互操作的性能，对NET的程序执行一点帮助都没有呢？？
    　回复　引用　查看　  
  2. #2楼 penbox      2011-12-03 16:14
    引用toEverybody：虽然WinRT是非托管的，与NET无关，对C#这类托管环境中执行的程序，是不是只提高了互操作的性能，对NET的程序执行一点帮助都没有呢？？

    如果我没理解错的话，应该没有提升.NET程序自身的性能。
    但是如果与非托管代码的互操作有了几个数量级的提升的话，相当于是移除了原来.NET程序性能的短板，程序的整体性能应该还是有很大提升的。
    　回复　引用　查看　  
  3. #3楼 toEverybody      2011-12-03 16:52
    看来原生代码的程序是一种回归，而不是所谓的托管代码程序
    　回复　引用　查看　  
  4. #4楼 编写人生      2011-12-03 19:01
    现实生活是百家争鸣最好，技术也是一样。
    文章不错，:-)
    　回复　引用　查看　  
  5. #5楼 鞠强      2011-12-03 20:52
    mark
    　回复　引用　查看　  
  6. #6楼 韦恩卑鄙 a-zhewg @waynebaby      2011-12-03 21:46
    大家可以参考我们翻译的Build大会视频

    http://talk.boolan.com/



    Using Windows Runtime from C# & VB 这个讲座


    从某种角度来说 winrt和 sl都是走的“不过度依赖CLR编写 而采用metadata包装非托管代码运行时”的思路
    但sl 没有解决“js+html/c++” 如何编写程序的问题
    winrt 不但解决了这一问题
    更做到了对任一winrt语言本身的"自然熟悉"。
    这是微软的周期性佳作
    　回复　引用　查看　  
  7. #7楼 RayOctopus      2011-12-04 22:43
    欣赏佳作的同时，也让我们期待Win8！
    　回复　引用　查看　  
  8. #8楼 testzhangsan      2011-12-24 16:28
    不错啊！
    　回复　引用　查看　  
  9. #9楼 houqidian      2011-12-24 16:55
    程度不够，不是很理解，顶一个！
    　回复　引用　查看　  
  10. #10楼 毛小毛      2011-12-24 17:10
    引用从某种角度来说 winrt和 sl都是走的“不过度依赖CLR编写 而采用metadata包装非托管代码运行时”的思路

    “metadata包装非托管代码”Delphi就是用类似的方法做反射的，只是Exe大了一些。
    　回复　引用　查看　  
  11. #11楼 老光      2011-12-24 17:50
    @韦恩卑鄙 a-zhewg @waynebaby
    "采用metadata包装非托管代码运行时"
    哪里有这一方面的资料?
    　回复　引用　查看　  
  12. #12楼 _冻结_      2011-12-24 18:14
    @toEverybody
    Console.Write("Hello 2b!");
    　回复　引用　查看　  
  13. #13楼 诺贝尔      2011-12-24 18:27
    可是我用win8也没觉得metro程序有多快，反而和wpf的程序的感觉一样。
    　回复　引用　查看　  
  14. #14楼 devil0153      2011-12-24 22:20
    水平还是不够啊，看的半懂不懂，不过核心意思懂了，Win8中WinRT的出现解决了CLR和COM的矛盾，让这两者发挥各自的长处而不是被对方的短处限制，但是我没有理解的是既然传统的CLR与COM的互操作耗费性能，而CLR与WinRT直接调用跳过种种检查和限制，然后WinRT再与COM打交道来提高CLR与COM的交互性能，那么为什么不直接在CLR层直接改进，非要引入WinRT呢？CLR已经使C#与操作系统多了一层了，现在又多了一层WinRT，我真担心最后性能还是没提高多少！我已经被微软的性能问题搞怕了|||-_-
    　回复　引用　查看　  
  15. #15楼 今昭      2011-12-24 22:59
    Perfect Thanks Mr.LiXiong
    　回复　引用　查看　  
  16. #16楼 小果果      2011-12-25 02:12
    感觉写了这么多，其实就是CLR本来是通过COM接口来访问操作系统组件的，而到了Win8，微软在COM底下垫了个C 接口的系统API包装层，也就是WinRT，它为各种语言提供了直接的映射，例如楼主提的那个await关键字的例子。从此旧的程序继续通过COM接口访问，新版的CLR跳过COM接口，直接访问那个C语言包装层。
    　回复　引用　查看　  
  17. #17楼 韩梦芫      2011-12-25 02:37
    哎呀 楼主说的有点深啊 能通俗点的口吻叙述一下就很好了
    　回复　引用　查看　  
  18. #18楼 我想我是青蛙      2011-12-25 15:53
    @toEverybody
    傻逼，滚出cnblogs
    　回复　引用　查看　  
  19. #19楼 zzfff      2011-12-25 16:55
    COM是Component Object Model
    　回复　引用　查看　  
  20. #20楼 slice      2011-12-25 17:38
    其实现在唯一不太明朗的微软也遮遮掩掩的，就是ARM版的Win8，估计不会和X86版的同期发布而是会滞后。
    　回复　引用　查看　  
  21. #21楼 slice      2011-12-25 17:43
    引用devil0153：水平还是不够啊，看的半懂不懂，不过核心意思懂了，Win8中WinRT的出现解决了CLR和COM的矛盾，让这两者发挥各自的长处而不是被对方的短处限制，但是我没有理解的是既然传统的CLR与COM的互操作耗费性能，而CLR与WinRT直接调用跳过种种检查和限制，然后WinRT再与COM打交道来提高CLR与COM的交互性能，那么为什么不直接在CLR层直接改进，非要引入WinRT呢？CLR已经使C#与操作系统多了一层了，现在又多了一层WinRT，我真担心最后性能还是没提高多少！我已经被微软的性能问题搞怕了|||-_-


    无法回答你的问题，不过想到一点，一个是WinRT对C++，Javascript，C#，都一视同仁。它不是COM，也不是专为CLR优化的，它是WinRT。
    　回复　引用　查看　  
  22. #22楼[楼主] lixiong      2011-12-25 18:03
    @zzfff
    多谢~~ 已修改
    　回复　引用　查看　  
  23. #23楼 wantme      2011-12-25 18:05
    据小道消息谣传
    微软正在实施一个计划,就是直接把C#编译成本地代码,而不是通过CLR
    据说微软已经实现了,微软内部的程序就是这么干的,但这么强大的功能他显然不愿意释放出来,因为一旦这样干了,就宣告.net 平台彻底破产.
    　回复　引用　查看　  
  24. #24楼 Just_fly      2011-12-25 18:52
    @wantme
    靠，这岂不是很爽！
    　回复　引用　查看　  
  25. #25楼 Steven Chen      2011-12-25 21:03
    不知道win8下.net的sos还能不能在windbg显示那么详细的信息啊，是不是一切又回到了非托管环境。
    　回复　引用　查看　  
  26. #26楼 五子棋      2011-12-26 09:27
    刚工作时除了MFC别的不会用，现在早已不关心微软的技术更新了。
    linux跟微软层出不穷的各种框架相比，只有C接口的API，其他的交给三方去实现，跟windows跟的有点累，所以只关心C/C++了，抓住不变的东西让别人变去吧。
    　回复　引用　查看　  
  27. #27楼 James Li      2011-12-26 09:49
    这些技术上的变更，我早已失去了兴趣。
    我关心的是，微软依靠.NET平台确实赚了很多money,很多。
    　回复　引用　查看　  
  28. #28楼 宇宙大将军      2011-12-26 09:50
    @五子棋
    是你懒，是你笨！程序员就应该在别人旅游、放松、共享天伦之乐的时间里面去不停的学习新技术。学Linux不用不停的学习？那它肯定会被淘汰！VS都出到2010了，我们微软程序员学得多爽啊，恨不得一个月一个版本！
    　回复　引用　查看　  
  29. #29楼 wantme      2011-12-26 10:37
    试问楼主
    有没有WINRT的范例,贴出来参考一下
    另外就是,C#如果编译WINRT,编译出来后,仍然是IL语言,还是IL语言内部嵌入本地代码
    如果C#的执行程序能有部分包含本地代码
    那将是C#开发者的喜讯
    　回复　引用　查看　  
  30. #30楼 球无      2011-12-26 11:08
    到处是性能，差点看成性能力了
    　回复　引用　查看　  
  31. #31楼 小彬      2011-12-26 12:22
    表示看这些文章都比较吃力的说
    　回复　引用　查看　  
  32. #32楼 BenBen789      2011-12-26 12:50
    我想知道，WPF中new userControl() 后，这个控件怎么释放内存？ 目前它是不能自动释放的。。。
    　回复　引用　查看　  
  33. #33楼 深海沉      2011-12-26 12:59
    不错的，有价值的文章
    　回复　引用　查看　  
  34. #34楼 追杀      2011-12-26 14:22
    @韦恩卑鄙 a-zhewg @waynebaby
    恩,很不错,下载了你们的播放器,翻译的也很好,//build上那两个哥们合作讲的视频太有趣了,呵呵.
    　回复　引用　查看　  
  35. #35楼 Richeir      2011-12-26 14:47
    性能的损耗带来的是开发效率的提升
    　回复　引用　查看　  
  36. #36楼 szwe      2011-12-26 14:56
    引用wantme：
    据小道消息谣传
    微软正在实施一个计划,就是直接把C#编译成本地代码,而不是通过CLR
    据说微软已经实现了,微软内部的程序就是这么干的,但这么强大的功能他显然不愿意释放出来,因为一旦这样干了,就宣告.net 平台彻底破产.

    全部变成本地化程序会有各种各样的问题，比如不安全代码产生之类的。编译成本地代码本来就不是什么很神奇的东西，那并不依赖于语言。
    　回复　引用　查看　  
  37. #37楼 Repository      2011-12-26 14:56
    引用wantme：
    试问楼主
    有没有WINRT的范例,贴出来参考一下
    另外就是,C#如果编译WINRT,编译出来后,仍然是IL语言,还是IL语言内部嵌入本地代码
    如果C#的执行程序能有部分包含本地代码
    那将是C#开发者的喜讯

    我想还是IL，如果真是native代码，那真的爽了。
    如果是在IL语言内部嵌入native代码。为什么不干脆直接编译成native代码，岂不更爽?
    我看了文章之后，我的理解就是微软又多包了一层，CLR不与com打交道，而是与winrt api打交道。
    　回复　引用　查看　  
  38. #38楼 赵小卓      2011-12-26 15:00
    引用宇宙大将军：
    @五子棋
    是你懒，是你笨！程序员就应该在别人旅游、放松、共享天伦之乐的时间里面去不停的学习新技术。学Linux不用不停的学习？那它肯定会被淘汰！VS都出到2010了，我们微软程序员学得多爽啊，恨不得一个月一个版本！

    学习微软的技术就是你人生最大的快乐了吧。怎么有这种想法。
    　回复　引用　查看　  
  39. #39楼 Grart      2011-12-26 15:23
    那移动平台上的芒果系统有没有用到WINRT技术呢？
    　回复　引用　查看　  
  40. #40楼 十一月的雨      2011-12-26 18:52
    这才是真正的大牛~! cnblog有高人啊.
    　回复　引用　查看　  
  41. #41楼 文学爷们      2011-12-26 20:59
    引用wantme：
    据小道消息谣传
    微软正在实施一个计划,就是直接把C#编译成本地代码,而不是通过CLR
    据说微软已经实现了,微软内部的程序就是这么干的,但这么强大的功能他显然不愿意释放出来,因为一旦这样干了,就宣告.net 平台彻底破产.

    扯淡，这个工具在VS里早有了，但是C#编译为本地代码效率反而没有托管的高，而且一些优势也失去了
    　回复　引用　查看　  
  42. #42楼 wantme      2011-12-27 08:31
    @文学爷们
    VS有编译成本地代码的选择????
    是哪儿,麻烦说一下
    　回复　引用　查看　  
  43. #43楼 penbox      2011-12-27 08:45
    @wantme
    Native代码产生器: NGen.exe
    本机映像生成器 (Ngen.exe)
    　回复　引用　查看　  
  44. #44楼 wantme      2011-12-27 08:46
    @文学爷们
    我知道你说的是Ngen.exe吧,那只是一个.net 的外壳而已,程序运行仍然需要.net frame 支持的
    　回复　引用　查看　  
  45. #45楼 韦恩卑鄙 a-zhewg @waynebaby      2011-12-27 12:58
    @诺贝尔
    因为你手里的wpf很少有metro这样全屏动画的吧。wpf在全屏大规模刷新的时候 性能略悲剧
    　回复　引用　查看　  
  46. #46楼 Repository      2011-12-27 14:16
    引用韦恩卑鄙 a-zhewg @waynebaby：
    @诺贝尔
    因为你手里的wpf很少有metro这样全屏动画的吧。wpf在全屏大规模刷新的时候 性能略悲剧

    顶，我有此教训!frame rate上不去，画面抖得厉害，害我用XNA来搞。性能还不错。
    　回复　引用　查看　  
  47. #47楼 amwicfai      2012-01-12 17:32
    好文，写得非常好。
    　回复　引用　查看　  
  48. #48楼 VelvetMark      2012-01-16 19:05
    .NET是座里程碑，WinRT是条光明大道
    　回复　引用　查看　  
最新IT新闻:
· 为什么Google比苹果更令微软恐惧？
· 思科拟2.71亿美元收购私有公司Lightwire
· 社交商务公司Bazaarvoice将于2月24日进行IPO
· 戴尔收购备份软件公司AppAssure
· 4款微软办公应用登陆诺基亚Belle系统
» 更多新闻...