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) ?

14 minutes ago,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)

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?

*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.

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.

3 hours ago,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

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.

49 minutes ago,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.

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.

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.

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.

5 minutes ago,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.