Coffeehouse Thread

56 posts

has Anders commented on WinRT?

Back to Forum: Coffeehouse
  • SteveRichter

    I am interested to read what Anders thinks about WinRT and the deemphasis of .NET.

     

  • DeadX07

    WinRT is really the successor of Win32. It cleans up the API's with better accessibility, naming conventions, and exposes it to multiple languages using language projections, which allows you to use your language of choice, and when calling a WinRT API, the code should look like what you're used to in whatever language or platform you choose. It isn't meant to destroy or de-emphasis .NET, but there are fears that it will happen anyway. It provides a new way for API's to be done in Windows at the lowest level, outside the CLR.

    In prior times, let's use Vista as an example, we were introduced with the DWM (Desktop Window Manager) which had cool new features like Aero glass. These features are baked into Win32 though, which means you have to P/Invoke to use them from .NET. The .NET team would have to write wrappers around the new Win32 features to make them available in .NET, but because of time constraints, that stuff never made it into .NET API's. WinRT removes this problem by allowing the Win32 API to be directly available through WinRT, so you can just directly access it. This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

    Now here's the flipside, and the problem I see. WinRT right now is not really accessible to .NET, its accessible to Metro apps. And Metro apps are far limited in the API's they have compared to .NET. WinRT only has a subset of API's from .NET, like it doesn't include things like WPF, Silverlight, or WinForms because those don't make sense in WinRT. But the API's are severely restricted to API's that only make sense to Metro style apps.

    I think the limitations and exclusions in WinRT are what make .NET developers feel like .NET is going out the window, and I agree with the concern. WinRT apps actually can only use specific API's, otherwise your app cannot be included in the App Store, and thus cannot be available to Windows 8 consumers.

    I'm going to stop there. I hope this clears up some confusion. I like the idea of improving the Win32 layer with WinRT, but I think restricting the API's and favouring Metro style apps only is a very bad decision. Personally I am a fan of compatibility (Windows XP, Windows Vista, Windows 7) and am an avid supporter of the Desktop. I personally wouldn't use WinRT for any serious applications, that's my take.

  • SteveRichter

    , DeadX07 wrote

    This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

    Which is terrific. What I do not understand is the shift to native over managed. I thought the thinking on performance had been that the next generation of hardware would solve that problem.

    And I do not follow why the JITer and GC the .NET framework cannot smply be improved to address performance problems.  I am impressed with how quickly the shell namespace extension I wrote recently in C++ starts up. The preview handler I wrote starts instantly. But why would a .NET version have to be slower? Can there be prestarted .NET processes, which somehow are able to latch onto a set of preloaded .NET assemblies at process start ( if assembly loading is the cause of slow starting .NET apps. )?

     

  • DeadX07

    Managed code will never be as fast as close to the metal native. Managed code lives because of abstraction concepts, and abstraction equals cost.

  • Charles

    , SteveRichter wrote

    I am interested to read what Anders thinks about WinRT and the deemphasis of .NET.

    De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

    WinRT supports .NET, HTML5 and C/C++. This has been the case since the modern Windows programming model was announced at BUILD 2011.

    So, your base assumption is incorrect, thus this post is irrelevant. That said, Anders works on the C# and VB languages, both of which can be used to build modern Windows 8 style apps. You can also build shared WinRT components in C# or VB that can be used from JavaScript and C++.

    Where's this confusion stemming from? Is it because we (I, especially) have been promoting C++? I've already addressed that aspect several times.... C++ evangelism went mostly dark during the .NET Everywhere years and my goal has been to push native into the forefront (where it belongs), bringing how and when we talk about C++ up to par with .NET content on Channel 9.

    WinRT doesn't pick favorites... If you're a .NET developer, then you're all set. If you're an HTML5 developer, then you're all set. If you're a C/C++ programmer, then you're all set. This can't be made more clear. 

    C

  • SteveRichter

    , DeadX07 wrote

    Managed code will never be as fast as close to the metal native. Managed code lives because of abstraction concepts, and abstraction equals cost.

    right. But next years tick/tock of the processor will give us hundreds of millions of more instructions per second, erasing whatever gap there is with the native app. And of course there is many core which is predicted to give apps multiples of CPU resources.  I understand hand held devices have power constraints. But is it predicted that 5 years from now a WinRT native stack will be needed compared to a device that runs mostly managed apps?

     

  • DeadX07

    @Charles I don't think it has anything with you promoting native C++ Charles (Go C++ 11!!! Smiley). I think it has more to do with people's mis-understanding of WinRT (there are a lot of murky explanations of it on the web), and a lot of criticism came from the architectural diagrams at some conference that showed .NET/C# kind of pushed off to the side when they were talking about Metro/WinRT, and that put a lot of .NET developers off.

    I think there is just a "misunderstanding" of what WinRT is, and I think there is a lot of tension from .NET developers because they think Metro will replace WPF, and eventually deprecate .NET. I don't think either of those will be true, not just for compatibility reasons, the desktop is not going away.

    I think the big push for mobile/tablets and bringing them together on the desktop in Windows 8 has a lot of people nervous as well. It's a very bold move and many don't know what to feel about it yet.

    I think right now one thing Microsoft could do is help by, (and without promoting Metro/WinRT or doing anything related to advertising/marketing) is to better explain:

    1) What is WinRT
    2) Why does it currently only support Metro style apps if its a "successor" to Win32
    3) Why does it only expose a subset of .NET API's and "govern" which ones can be used in WinRT apps (this makes developers feel limited, and they don't like that)
    4) What is the future of WPF/Desktop (and including WinForms even, people still use it)

    If I'm wrong on any of these points I apologize and would love clarification. These are based on my own understanding of WinRT/Metro and concerns I hear from other developers.

    @SteveRichter It doesn't really matter how powerful hardware is. Managed code runs on native code. It doesn't exist without it, and no matter what type of device it is or how powerful the hardware, performance and reliability of the runtime/platform/operating system/device should always be the #1 priority.

  • TexasToast

    @SteveRichter:  I dont quite get it either.   I was doing C/C++ (and still do on some micro controller projects) when PC's were 640k and had an 8086 intel chip.   Yes you needed the performance.   I switched to .NET and managed mainly to speed up development in later years .  Yeah it could run a little faster but nobody really notices anymore with all the power on pc/laptops.   I am not leaving C# for any projects I do now for C++ because Microsoft says its retro and cool.   Sorry its not.. 

    That being said, .Net morphing into WinRT with better performance because it is planned in is great.  You still use C# as you normally do just calling into windows is more direct.  When they get WinRT to cover what the .Net libraries do we will be better off. 

    I dont mind using C/C++ on projects where .Net is not available.   For Charles to say they are bringing back C++ back to where it belongs with C# and VB is just a strange comment.  All of us who started with C/C++ enjoy C# development because it is just plain better and more enjoyable to program.   If I need to write a device driver I am glad the C compiler is still supported but we are comparing apples to oranges.

  • SteveRichter

    , Charles wrote

    *snip*

    De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

    Just saying I would like to hear from Anders.

    , Charles wrote


    Where's this confusion stemming from?

    Partly for me it is that I would have expected a Windows 8 OS to be a lot more .NET centric. I think I even remember a Charles C9 video from years ago where he asks the windows server guys why .NET is not a part of server core, the implication being .NET is going to become more and more a part of windows. The message I was receiving from years of C9 videos was that .NET and multi core were it and naturally assumed Wiin32 and .NET would morph into 1 on future versions of the OS.

    Really not complaining.  I understand plans change. But I am a bit sceptical of the native guys saying in 2012 that we need every tick of the CPU clock we can get to run a responsive, power friendly app.

     

  • TexasToast

    @DeadX07: I think your Dead On with your comment.   WinRT was not rolled out too well.  There is also a problem with the Hey C++ is back and you should try it and use it.   My comment is thanks but it is a little too late.   When I was watching C++ and MFC get thrown aside and .NET comes out for VB and C#,  all of us MFC/C++ developers jumped on the .NET C# train.   We like the train it has comfy seats and no header files and crappy syntax to deal with.    Now you want me to write C programs again for windows?   No I will pass.   Get WinRT done and leave me with my C# app.  Anders got it right with his work.   It is just better.

  • DaveWill2

    1 hour ago, Charles wrote

    *snip*

    Where's this confusion stemming from? Is it because we (I, especially) have been promoting C++?

    *snip*

    It seems that way.  However, if there were more Charles to go around then I'm sure the technologies would be carried equally on C9 at roughly the same time.  Resources are resources.  Regulars here know C9 has limited resources.  But the general web sees the collective output from Microsoft, and that includes C9, and it screams native, native, native, oh and html/javascript.

    It doesn't help to not be seeing the .NET technology stack folks talking about .NET and the new boundaries to take advantage of.  Maybe they can't until RTM.  RTM has been hit recently.  Let's see if that changes.

    1 hour ago, Charles wrote

    *snip*

    I've already addressed that aspect several times.... C++ evangelism went mostly dark during the .NET Everywhere years and my goal has been to push native into the forefront (where it belongs), bringing how and when we talk about C++ up to par with .NET content on Channel 9. *snip*

    Herb Sutter espousing micro savings on data center scales adds to it.  Listening to things on this scale is almost like the IBM mainframe days.  I hear .. if you write .NET code you are costing us to have to build 14 more nuclear generators and killing mother earth.  I'm sure that isn't the main intent.  It isn't a warm and fuzzy.  I'm not sure why I haven't understood.  From a pure "as-is" efficiency argument? ... maybe.  But data centers are not appliances.  <strike>The software running on them has to constantly evolve.  Developer productivity needs to trump saving kittens.</strike>

  • brian.​shapiro

    , DeadX07 wrote

    I don't think either of those will be true, not just for compatibility reasons, the desktop is not going away.

    Why do you think Microsoft won't push WinRT for Desktop app development too?

  • DCMonkey

    , DeadX07 wrote

    In prior times, let's use Vista as an example, we were introduced with the DWM (Desktop Window Manager) which had cool new features like Aero glass. These features are baked into Win32 though, which means you have to P/Invoke to use them from .NET. The .NET team would have to write wrappers around the new Win32 features to make them available in .NET, but because of time constraints, that stuff never made it into .NET API's. WinRT removes this problem by allowing the Win32 API to be directly available through WinRT, so you can just directly access it. This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

    Don't you still have to wrap your Win32 API in WinRT objects before you can take advantage of Projection? And MS doesn't have a monopoly on wrapping Win32 APIs in .Net code. They're just usually the one's expected to do it.

  • Charles

    I'd recommend that you watch this: http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-874T

    Further, BUILD 2012 will be chalk full of sessions that make all of this even clearer... Do tune in.

    Now, with respect to the comment about C++ developers preferring C#, well, that's simply not true. You use the right tool for the job at hand. Period. For WinRT, a great use case for C/C++ is that of building high performance shared WinRT components (that both .NET and HTML5 applications can call into). Also, you can imagine taking an existing native application (where portable libraries are used in addition to platform specific, and proprietary, UI layers (a la Obj-C and Cocoa Touch on iOS...) and porting them to Win8. Also, if you write games and want to do so with DX, then use C++. Further, if you want to mix XAML and DX in an app (like Bing does, for example), you use C++. It's not apples to oranges. It's using the right tool for the job at hand. Finally, if C++ is your preferred language, then you just use it along with XAML for UI to build modern apps on Win8...

    With WinRT, you can use multiple tools simultaneously to get the job done and in a way that maximizes user experience...

    If you are attending BUILD 2012, then you will learn all that you need to clear up any confusion here. If you can't attend, then you can watch all the sessions right here on C9 on-demand.

    In terms of more Charles to balance native and .NET content, I've done various interviews that cover .NET 4.5, from GC to JIT to Fx installation. I assume you've watched those pieces?

    C

     

  • Charles

    @SteveRichter: .NET isn't suitable for OS development (kernel mode, etc)... What you're referring to is the interview from a long time ago where we dug into ServerCore. The issue was shipping .NET as a part of the ServerCore image. In fact, that is the case today given that PowerShell relies on .NET to work.....

    Further, .NET is a significant piece in Windows. Think of Media Center UI, PowerShell admin scripts (and, like Windows 7, the way wizards do their thing....).

    C

  • DeadX07

    @DCMonkey Yes. They still need to be implemented into a WinRT API to be available to a language projection, and I wasn't saying that Microsoft had a monopoly on wrapping API's, only it's why new Win32 features don't get implemented into the BCL often times, and how one of WinRT's goals is to solve that.

    @brian.shapiro I have no doubt that WinRT will eventually be available to desktop applications. Simply put, there is a fear in a lot of .NET developers minds that WinRT will replace WPF, which is simply not the case unless Metro is allowed to run on the desktop as well, which currently it cannot. WinRT makes specific assumptions, for example, that only one Metro application is open at a time, which would not be suitable in the desktop environment. Things can change, but since it is just rolling out as V1, not anytime soon.

    @Charles Agreed. .NET is not suitable for OS development. Also, you have done PLENTY of .NET coverage... countless interviews with Anders, Bart De Smet, Erik Meijer and more... so I don't understand why it's an issue. .NET lives because of native and they should be greatful that C++ is evolving into a even more modern language.

    There are too many new areas to cover right now.. C++ 11, Windows 8, Visual Studio 2012, .NET 4.5, C#5, VB, the list goes on. Poor Charles cannot cover them all at once! Unless maybe you have a few clones laying around.

  • JoshRoss

    Has SpectateSwamp commented on WinRT and the deemphasis of VB6?

    -Josh

  • felix9

    , Charles wrote

    De-emphasis? What are you talking about? .NET is a first class citizen in Windows 8.... I don't understand how this thinking has emerged. For one thing, it's wrong. For another, it's wrong....

    C

    I think this thinking emerged from mid-2011, with Bob Muglia's 'stragegy has shifted and Silverlight (also WPF) is dead' and Steve Sinofsky's 'HTML5 and Javascript is the way to develop on Windows 8' messages,  the 'C++ Renaissance' also contributes in someway.

    articles like these appears and went to Slashdot.

    http://www.i-programmer.info/professional-programmer/i-programmer/2591-dumping-net-microsofts-madness.html
    http://www.i-programmer.info/professional-programmer/i-programmer/2830-was-net-all-a-mistake.html
    http://developers.slashdot.org/story/11/08/03/2027207/Wasnobr-wbrnobrNET-All-a-Mistake

    IMHO its the result of the secrecy policy of Sinofsky about Windows 8. Giving a little bit of message once a while and keep mouth shut when people are in doubt and having questions, its very frustrating and kills trusts and confidence.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.