1 hour ago,W3bbo wrote
Having now sat through the keynote and had a look at the WinRT stuff, I'm unconvinced that "WinRTis Windows" as the presenters claim.
I guess the proof will be in the pudding, and we don't have to wait too long for a download.
To me, WinRT is a series of native, "Win32" if you will, components that all have suitable managed wrappers that run on the CLR4. WinRT itself is a framework that hosts the CLR4 (rather than having a separate CLR fork) and includes the BCL4 assemblies in addition to the new Windows 8-specific ones (such as the sensor framework).
Everyone seems to throw all native development into the "Win32" bucket. Strictly speaking I'd put things like Window classes and the Message Pump in this bucket, and other things under the Windows (base) API. Windows Forms is directly built on top of Win32, and WPF to a lesser degree.
It explains a lot: the JS stuff most likely uses the DLR - which means it's possible someone will add the ability to use Python and other DLR languages. The presence of C++ was probably referring to CLI/C++ rather than pure native C++ on account of how the "XAML" box overlapped both the C# and C++ blocks.
There has been a version of Silverlight with XAML for Windows Embedded for a while now. XAML is really just a format for specifying object graphs so it could be used "natively" if you can express the concepts in a language like C++. Many people confuse it with markup languages that operate differently.
People often complain about the performance of .NET client applications. One of the biggest problems (that gets talked about less that memory bloat, graphic perf etc) is startup time. This is a big issue for anyone building a utility type app that you want to spin up quickly without a noticeable delay.
It is so bad that the IronPython team at one time had a workaround that interpreted scripts on the first run to give instant results. On subsequent runs jitted code was used. This is sad in a lot of ways because the performance of subsequent runs is amazing. Their users needed the scripts to support quick editing and iteration. For windows client developers the only way to get this rapid startup performance is to trying NGen, or write a native app.
I believe the source-level compatibility with Trident is a coincidental with the fact the DLR JS runtime strictly complies with the ECMAScript specification. I don't believe the native JS JIT engine makes any appearances in WinRT. This is further evidenced by the support of the HTML+JS platform in Blend, which is just a design-time host for XAML and presumably a similarly .NET-derived HTML+JS platform.
Following on from my last point, embedding trident in a native app is a great way to get quick startup and a simple programming model. With IE9 graphics acceleration was the icing on the cake. For the reasons of startup performance I don't think you'll see anything other than trident.
Off-topic, if this means Microsoft has developed a managed HTML+JS platform, it's possible we'll see a decent web-browser made available for the Xbox 360.
I doubt you'll see any managed browser, although Microsoft's efforts to port newer IE versions to Windows Phone might offer something in the future.
Any thoughts, speculation, or evidence otherwise?