Coffeehouse Thread

13 posts

Windows 8 dev story and compat

Back to Forum: Coffeehouse
  • User profile image
    CKurt

    Wind 8

    This is my adaption of the standard slide from the Day 1 keynote of Build. I have watched some of the sessions about WinRT and came to this conclusion.( orginal slide: http://i.zdnet.com/blogs/davidburela.png )

    Above the white line compatibilty is indicated. Showing C++ applications , games and drivers written for x86 will not work on every version of Windows 8. This makes me think they should really change the message "Everything which runs on Windows 7 will run on Windows 8". They should market the ARM version completely different! Imagine the disaster if "Games for Windows" don't work on Windows...

    Next, it is also unclear if Desktop Applications (WPF , SilverLight OOB, WinForms) will be able to use the new WinRT API's or should keep using the ugly COM way of tapping into Windows.

    What are your toughts on the windows 8 DEV story (and how it has been communicated) ?

  • User profile image
    AndyC

    I think the various version of that slide that were floating around were some of the most confusing bits of build. It's pretty obvious a few people tried to tweak the original to make it clearer, but all that accomplished was increasing confusion.

    ,CKurt wrote

    Next, it is also unclear if Desktop Applications (WPF , SilverLight OOB, WinForms) will be able to use the new WinRT API's or should keep using the ugly COM way of tapping into Windows.

    It's been stated that older style applications will not be able to call into WinRT and WinRT apps will only be able to use the approved subset of Win32 apis and COM objects (though that subset is not entirely defined yet)

  • User profile image
    LCARSNxG

    From what I have seen, WinRT is only for Metro apps. It seems that Microsoft has a new favorite child and they are talking all about Metro. Metro apps are great and all but their message is confusing outside of Metro.

    1. Is WPF now the recommended technology for normal desktop apps? They barely mentioned desktop apps at build. WPF was mentioned a few times. WinForms was nowhere to be found.
    2. If WPF is now the best way to write normal desktop apps, why haven't they improved it much? They did have a few slides mentioning some improvements that were made but WPF didn't seem very important.
    3. What about Silverlight? They have been beating the HTML5 drum for a while now, so people assumed that Silverlight is dead and HTML5 should be used for cross platform LOB apps. But all of their tooling improvements are for Metro HTML5 apps only. Expression Blend doesn't do HTML5 for websites. It only does HTML5 for native windows Metro apps. If HTML5 is the future of cross platform LOB apps on the web, where is the designer tooling to enable these scenarios?
  • User profile image
    figuerres

    IMHO if WinRT is not going to be for "Desktop Apps" then this is a *HUGE* mistake!

    *IF*  WinRT can be the basis for removing over time the old WIn32 and other outdated cruft like GDI then it lays down a basis for a new WIndows core API that we can move foreward with.

    but if WInRT is limited to "Metro" apps then if Metro fails to take off then what happens?

    seems like WinRT should be allowed to stand on it's own even if Metro / Touch become a fad or a fail.

     

  • User profile image
    BitFlipper

    Yes that part of the message is not clear to me either. What is the preferred framework to use for real desktop applications (non-Metro) going forward? As LCARSNxG mentions, WPF has hardly been improved, and as someone that has been doing a lot of WinForms applications for many years, but has done only minimal WPF applications, I'm wondering what I'm supposed to focus on for future projects. I must say I ended up not liking WPF that much - too many performance issues and it's just too over-engineered.

    While I like a lot of what I saw last week, I'm wondering whether turning everything that isn't a Metro app into "legacy" is a good idea. Are all businesses going to be running legacy applications 5 years from now? And is the heavy duty "professional" music application I use that can never work as a Metro app now suddenly going to become a legacy application as well?

    I watched the keynote but didn't watch every other session, so maybe I just missed something. Very possible.

  • User profile image
    fanbaby

    ,LCARSNxG wrote:

    What about Silverlight? They have been beating the HTML5 drum for a while now, so people assumed that Silverlight is dead and HTML5 should be used for cross platform LOB apps. But all of their tooling improvements are forMetro HTML5 apps only. Expression Blend doesn't do HTML5 for websites. It only does HTML5 for native windows Metro apps. If HTML5 is the future of cross platform LOB apps on the web, where is the designer tooling to enable these scenarios?

    I was sure that they would show an equivalent of GWT but in dotnet. I also predicted they would show a version of azure similar to AppEngine

  • User profile image
    AndyC

    One of the things said during the keynote was that trying to come up with a complete replacement for Win32 in WinRT was too much for a single release, so the initial focus was on Metro. Which is why I think it's to be seen as the start of a clear shift in direction away from all the legacy tools whether they be WPF, Silverlight or Win32 itself.

    For desktop applications it's probably worth considering if they can be 'reimagined' with a Metro style UI. Obviously that won't suit every application and for those that really need to be tool heavy (like Photoshop or Excel) it's probably going to be a case of keep doing what you're doing for now. However starting to think about newer WinRT concepts and keeping them in mind when planning for the future is almost certainly a good idea.

    It's also probably worth betting on the Ribbon UI, it's integration with Explorer will not only make applications feel more native but if I were a betting man I'd imagine it's the way WinRT desktop apps will be expected to expose their UI.

  • User profile image
    evildictait​or

    ,AndyC wrote

    One of the things said during the keynote was that trying to come up with a complete replacement for Win32 in WinRT was too much for a single release, so the initial focus was on Metro. Which is why I think it's to be seen as the start of a clear shift in direction away from all the legacy tools whether they be WPF, Silverlight or Win32 itself.

    As a rule of thumb, APIs that are documented on MSDN will continue to work as documented for at least 5 full years after they become marked as "obsolete do not use", and core APIs used by everyone won't change for at least 10 years afterwards.

    The simple reason for this is backwards compatibility of programs and of source code. If Microsoft said "LoadLibrary" is now obsolete - all you guys using "LoadLibrary" now need to call "LoadWinRTLibrary" then every piece of software currently running on Windows would need to be recompiled, retested and reshipped to customers (massive expense to developers) and for all the programs that didn't (e.g. old games, old versions of software and software where the maker went bust or got bored and moved to do other things) would need to be shimmed by Microsoft, at massive expense to Microsoft.

    What normally happens is that new APIs are formed and one calls the other (usually the old calling the new, but sometimes both calling a new intermediary). That way LoadLibraryA, LoadLibraryW, LoadLibraryExA and LoadLibraryExW all work as expected, but the functionality is all contained in LdrLoadDll and NtMapViewOfSection, even though nobody outside of Microsoft ever calls those functions directly.

    In summary, Win32 will still be functionally equivalent to today's Win32 in 2020, with WinRT becoming the standard over the next decade, rather than becoming mandatory in the next release.

  • User profile image
    AndyC

    @evildictaitor:It won't happen like that though, your app will either target Win32, .NET, Silverlight etc or it will target WinRT. It's not a mix and match thing, that's already clear from the Metro side of things and will undoubtedly extend into the desktop world.

    Obviously apps which do target the "legacy" API sets will still continue to run (though possibly not on ARM), just as DOS applications still ran right up to x64 Windows.

  • User profile image
    felix9

    According to brent rector, Microsoft actually tested and ensures those WinRT APIs not related to Metro UI or app model, eg. Networking APIs, to work properly in Desktop apps.

    http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-876T

    and during the Going Native Live at BUILD, the WinRT team are just focusing Metro scenarios in this release, and they are open to consider WinRT for Desktop apps after delivering this release first.

  • User profile image
    cbae

    I finally got around to playing around with VS11. I created a solution with the following projects:

    C# console application

    C# WPF application

    C# Metro application

    C# standard .NET class library

    C# .NET portable class library

    C# Metro class library (can also be used to create WinRT library)

    Each of the class libraries has a public class declaration with a static HelloWorld() method returning a string.

    I referenced each of the class libraries in the 3 different applications. This is what happened:

    Console application: Compiler error because of the Metro class library, which required reference to System.RunTime.dll, which VS didn't add to the project by default. It's also not found in the regular reference assembly folder for .NET 4.5. I had to dig in the.NET 4.0 framework folder in c:\windows\microsoft.net\framework64\ to find it. Once I added this assembly, the application compiled, but I still got a compiler warning. However, the application ran fine and was able to call HelloWorld() from all three class libraries.

    WPF application: Same results as console application.

    Metro application: Compiler warning because of the reference to the standard .NET class library, but it was fine with the portable class library. The application ran fine, and HelloWorld() from all three libraries worked.

    I'm not sure what the deal is with the compiler warnings, but there seems to be some interoperability between Metro and .NET class libraries/applications, even if it wasn't intended.

     

  • User profile image
    AndyC

    ,cbae wrote

    I'm not sure what the deal is with the compiler warnings, but there seems to be some interoperability between Metro and .NET class libraries/applications, even if it wasn't intended.

    There have been similar comments on the official dev forums, where the line has been that even if referencing system/.NET functions outside the approved list does still appear to work in future version (which it may not) it certainly will not pass the App Store tests.

  • User profile image
    Frank Hileman

    @CKurt: Is there any information about a new immediate mode vector graphics API for .net developers, a new Direct2D wrapper?

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.