Under the Windows 8 hood: Questions and answers from the trenches
Microsoft officials are remaining adamant that they plan to stay mum about the details regarding the Windows 8 developer story until mid-September, when the company holds its Build conference. But that doesn't mean that developers who are curious, if not outright anxious, about the future of .Net and Silverlight are sittling idly by waiting for all to be revealed.
Several devs have weighed in over the past couple of weeks with their best guesses as to what Microsoft is crafting on the development-framework side of the Windows 8 house. Meanwhile, I've been interviewing some of those taking apart Microsoft Windows 8 Milestone 3 (M3) internal builds that have leaked in the hopes of piecing what developers should expect when porting and writing apps for Windows 8, which is expected to come to market in 2012.
As is evident from the e-mail Q&A's I've conducted with three of these individuals in the past week, it's not easy to tell exactly what Microsoft is planning from the leaked bits in regards to the so-called Jupiter Windows 8 UI library; the "native" HTML framework that will rely on the Internet Explorer rendering engine; and/or the future of the Common Language Runtime (CLR) at the heart of the .Net Framework. But there are some clues.
The three developers I contacted were:
Michael Brown, Microsoft MVP in Client Application Development, and President Kharasoft, Inc., blogging at http://azurecoding.net/blogs/brownie, and tweeting at @browniepoints. (Brown said that even though he's a Microsoft Most Valuable Professional, "none of this information was provided to me through the MVP program; it was gathered through other public sources.")
Jose Fajardo, Senior Developer involved with Silverlight "and other cool things," who blogs at http://advertboy.wordpress.com, and tweets at @josefajardo.
Jack Ukleja, Software Architect at Device Logic (@DeviceLogic), and tweeting at @JackUkleja
Here are my questions and their answers:
1. I'm still trying to make sense of "Jupiter" -- the layer that supposedly will provide .Net developers with a managed code XAML library for writing Windows 8 applications. Do you think Jupiter is simply the name for Win8's DirectUI?
Brown: At first glance, it’s easy to muddle the two (Jupiter and DirectUI) up. But digging deeper it seems that Jupiter might be the so-called Windows Runtime. DirectUI is a graphic library that sits on Jupiter. In current terms, Windows Runtime is like the .NET CLR (common language runtime) and Direct UI is like WPF. It doesn’t end at analogy either. DirectUI has many of the elements that are present in WPF and Silverlight.
Fajardo: There is definitely no direct correlation between Jupiter and DirectUI. Even in the code that we’ve happened to find that mentions DirectUI there is no mention of Jupiter. All I know regarding this is that there are references throughout Microsoft’s code base of a secret UIFramework that declaratively marks up its UI as xml (using a DUIXML ).
What we know now is that in Windows 8 there seems to be a “Windows Runtime” API that is being built that has a DirectUI namespace that contains a lot of very similar code to what is found in WPF/Silverlight/WPF (more so from Silverlight). It’s not exactly the same code, but rather a very lean, refactored, well thought through interface. Has this replaced the pre DirectUI “duixml + code” ? Or will this new version be an extension of what was always there + the best bits of WPF/SL/WP7 (refactored) ?
We don’t know the answers to any of those questions, and we don’t even know if Build will answer those! I cannot confidently say what Jupiter is (sorry).
Ukleja: DirectUI is most likely Jupiter, but its also possible that DirectUI is a component of a new application framework...lets call it "Windows Foundation". After some poking around, (I've found that) DirectUI (in XP) seems to be a fairly substantial C++ library that paints the UI controls directly to a "canvas" using GDI+. The API hints that it can even load UI designs from XML.
DirectUI (in Windows 8) on the other hand is clearly a close cousin to WPF/SL (extremely similar APIs, XAML based etc), so on a technical level the two APIs have no relation. BUT... they are both children of WinDiv and the evidence shows DirectUI (Win8) is being used as a replacement for DirectU I(XP). This is pretty exciting - it means the Windows team will finally have the tools to bring the Windows UI out of the stone age! (Ever wondered why the Font dialog box didnt change for 45 years?)
2. If I am a .Net/Silverlight developer, why should I care about Jupiter? What's it going to mean to me in the Win 8 timeframe? Brown: As a .NET developer you care about Jupiter because it is in effect the new host for .NET applications on Windows. What’s really exciting about this is that the Windows Runtime has some interesting qualities that aren’t present in today’s CLR. Namely, it appears that Jupiter allows .NET applications to easily leverage native code as if it is a .NET assembly. What this means is that what we know as the .NET framework can be implemented in a language like C++ that targets the machine directly and still be used by a .NET application. In fact, it appears that this is what is happening. For example DirectUI appears to be a native library.
Fajardo: There appears to be a new Windows API that developers can use to interact with Windows (Hardware, services, UI). This appears to be called WindowsRuntime (WindowsRT).
In the current windows world we interact with windows through Win32 API’s. In the new world it’s looking like the new API is WinRT. The API appears to be exposed to the managed world through metadata files found in “System32\WinMetaData”
What’s also important to note is this new API shares similar features/interfaces to WPF/Silverlight/WP7. As I’ve mentioned above it appears thou a group of people have taken bits of WPF/SL/WP7 and refactored them yielding a very lean, performant, developer friendly api, thou in a lot of cases great reduced in functionality.
I’ve done some preliminary analysis of the differences of some of the features across WPF / Silverlight / Windows Phone 7 Silverlight compared to Windows 8 WinRT/WinMD. The example here is looking at the input events across all three (Touch/Gesture/Keyboard/Mouse/Pen etc.) It’s interesting the difference in the API across the UI frameworks, quite eye opening in fact ..
Ukleja: Jupiter includes "XAML"-like approach for building apps. In fact the evidence so far indicates DirectUI API is a close cousin of WPF/SL, so SL/WPF devs will be immediately familiar with it. Assuming it ends up shipping with Win 8 it means you have a third option for building apps, potentially one that runs smoother and integrates nicely with all Win 8 features.
3. Do you think XNA developers should/will have any interest in Jupiter? Why/why not?
Brown: I think Jupiter is the most important thing that has happened for ANY .NET developer. Having the majority of your application, the framework that supports it, running as native code gives a performance boost across the board. The question is what frameworks will be ported to native code. And if not, how will they fit into the new ecosystem?
Fajardo: Today in the world of WP7 and Silverlight, we can mix XNA with Silverlight. It’s definitely easier to build forms based UI in Silverlight over XNA e.g. data collection screens, wizards etc. Here's what we know from the Win8 leaked bits: There are Windows Store bits in Win 8; references of allowing games in the store; and XNA can be used for writing games. Ukleja: It depends on whether XNA (or even WPF/SL/D3D) interop is going to be supported by DirectUI from day one. These "airspace" issues have long dogged the integration of XNA/WPF/SL/D3D apps. Its a complicated problem and it would not suprise me if they do not tackle it in V1. If interop is supported then DirectUI will offer a great way to build UI whilst leaving the heavy 3D rendering to XNA. (This scenario is on the cards to be supported by WPF/SL.vNext so that may also influence things...). 4. Do you believe that Windows Phone 7 apps written using Silverlight and XNA will automatically run on Windows 8? If so, why do you believe this? If not, why not?
Brown: That’s hard to say. Think of the fact that an app written for the Silverlight Web plugin won’t necessarily run directly in Windows Phone 7. You have to target it directly. Also one would assume that an app compiled for Intel would have to be re-compiled for ARM (similar to how an application that targets X64 won’t run on 32-Bit Windows). How involved that process is depends on how the framework changes.
(continued on next page)
So.. Is there a future for Silverlight and WPF? Go to the next page for more...
Brown: (continued): I’d imagine that Microsoft will do its best to make the scenario as simple as “change the target and recompile” but it would also behoove the developer to take advantage of the new form that the tablet and desktop experience provides. A vanilla Windows Phone app might look great in that sidebar form factor we saw in the demo, but you really want to provide a new experience for the full screen and 2/3 screen appearance. You’ll probably want to change your tile interface as well to take advantage of what’s available on Windows 8.
Fajardo: Just like it’s not easy to turn your WP7 Silverlight app to Full Silverlight (vice versa), it also doesn’t appear like an easy path for turning your WP7 Silverlight app to a WinMD based app. (of course it’s too early to know this, we still need to see what tooling is available to us with Windows 8 apps)
Saying that, though, if you’re an experienced WP7 developer and understand Silverlight desktop apps then chances are you’ve already built your WP7 apps in a componentized architecture where there are separate libraries of reusable code. For instance you have crucial c# code separated into its own dll that you know works in WP7/Desktop Silverlight. More than likely this same library will work in your new managed Win8 WinMD app.
At the end of the day does it make sense to just port across your 800 by 430 WP7 app to Win8, I’m guessing you’ll want to create a completely custom UI to best leverage the larger form factor.
Ukleja: I have come full circle on this question while trying to answer it. I starting by thinking this wont be easy - Windows 8 will need to provide an implementation of the WP7 APIs, or a clever way to transform the calls into the new "Windows Framework" equivalents. But a quick glance at the "Windows Framework" APIs reveals a striking resemblance to the WP7 APIs... for example Microsoft.Devices.* exists in both.
Given that Silverlight/XNA will obviously exist in Win8... the only remaining issues to solve would be things like screen sizes. So Yes, MS need that app store filled from day #1 and I'm pretty much sold on their intentions to have it filled with WP7 apps :) 5 Are developers who are unwilling/unable to write apps in HTML5 + JavaScript + CSS going to have to make use of Jupiter? How/why?
Brown: I think even HTML5 apps will leverage Jupiter. As I mentioned in my early analysis, HTML5 is just another markup language like XAML. In the end, I think it’ll be compiled down to target Jupiter just like a WPF/Silverlight application.
Fajardo: I really have no idea.. Nothing in the leaked bit’s points to the name Jupiter. However if WinRT and WinMD is the way for managed users to create Win8 apps then use developers will need to pick up learning the new API if they want to build Windows 8 APIs.
6. How do you define an "immersive" app in the Windows 8 context? How do you define a legacy app in the Windows 8 context?
Brown: The immersive apps are those that run in the new shell. They provide interactive tiles and leverage the full capabilities of Windows 8. Legacy apps to me are those targeting the Windows 7 environment.
Fajardo: There is a bunch of namespaces in WinMD (metadata) that have the word Immersive in it.The interfaces within these immersive namespaces almost always related to an “immersive window”, and doing things in an “immersive window”.
In the Win32 world to create a window required the call “CreateWindowEx." There is now a new call we can use to create an “immersive” window “CreateImmersiveWindow” and it can be found in TwinUI.dll Ukleja: I have spotted in the Immersive APIs, references to "PlayTo", "Share" i.e. things that appear to correlate exactly with the 5 items down the right hand side of the new Windows shell. 7. RedHawk, which seemingly is a slimmed-down version of the CLR, also is in Windows 8. Any observations on how the CLR changes could impact Windows 8 developers?
Brown: The slr100.dll or System.Language.Runtime (SLR) is Redhawk (there are references within the library to Redhawk)…it’s the final leg between the executing .NET code and Jupiter. They are flip-sides to the same coin. Fajardo: Again too early in my investigations, I’ve only been concentrating on WinRT/WinMD and its relevance to WPF/Silverlight/WP7. Ukleja: It seems inevitable now the SLR will be shipping in Win8. There are about 10 WCL*.dll (Windows Class Libraries?) that have a dependency on the SLR100.dll. Those WCL libraries appear to contain this big new API (I reckon it might be called "Windows Foundation" as there in one namespace called that) so I cannot see how they can ship without the SLR now. No turning back sort of thing. These WCL dlls might be obfuscated...some people have taken a look inside and all the "exports" (i.e. the code inside) are named tx.mx where T presumably stands for Type and M stands for Member. If this is not obfuscation then it could be some weird side effect of how the SLR works. Is it 100% native code or not? Nobody seems to know for sure. Sometimes I get the feeling this SLR is somewhere between the two.
WinRT (Windows Runtime) is closely related to COM. It's possible Windows Runtime is the marketing name for the SLR, in the same way that .NET is the marketing name for the CLR.
8. WMD: Windows Metadata. What is this? And why should developers care about it?
Brown: COM can provide dynamic information about a library. Because of that, it’s possible to cache this information in a format that’s easily consumed. When you compile a .NET assembly it includes metadata that allows the CLR to understand what that assembly contains and how to invoke it. What WMD provides is that Metadata that .NET expects but instead of providing it for a .NET assembly it provides it for a native library. In a nutshell WMD plus Redhawk combine to make a package of native code look like a .NET assembly to your .NET code.
Fajardo: I summarized what I believe WinMD to be here.
Ukleja: WMD, even though it uses the .NET metadata format, has contains suspiciously COM-like APIs. What I mean by that is for example DirectUI contains some strange looking interfaces....every "normal" interface is accompanied by several others such as I*Statics I*Overrides etc. The new version of .NET also knows about WinRT and has got various libraries to interoperate with it. The API design for "Windows Foundation"/WinRT is very .NET-like (e.g. naming of classes) so I am confused as to whether it has been written in C++ or C#. If its been written in C++ then I am surprised it looks so clean and .NET-like, on the other hand if its written in C#...then they must have a C# to SLR compiler (whatever that means).
9. The $64,000 question: Is Silverlight and/or WPF on its way out? What's your take, given what you've seen with the Windows 8 milestone builds.
Brown: In the future it might not be called Silverlight or WPF. But it’s obviously there in the DirectUI library. We’ve seen simple apps that use Direct UI and XAML from .NET to run in what gets displayed as a “Jupiter Window”. WPF and Silverlight are very much alive in Windows 8. Even if we didn’t have this evidence, drawing out the similarities between HTML and XAML to their logical conclusion would make it highly likely that XAML and .NET would still be present in Windows 8.
Fajardo: Silverlight/WPF has a very long and bright future ahead of it especially when you look at the feature set in Silverlight 5. Silverlight 5 features are massive, it has the chance to challenge people’s perception of what a desktop/web application is. And the improvements in WPF vNext, fixing such things as “airspace”… that too has the potential to ignite a new love for windows desktop applications. 10: Anything else worth mentioning in this discussion?
Fajardo: The one question you failed to ask, and is probably the most important, is around the Windows Application Store .
The success of WPF/Silverlight/WP7/ “Jupiter” will be if the app store allows them, and if the app store allows for a user friendly installation/upgrade experience. If the app store allows easy installation, which means they have a good user friendly solution to getting the user to install/update .Net framework/Silverlight framework, then WPF/Silverlight will flourish.
My number one question that I’m looking for answers from Build is how the App store will install Silverlight/WPF apps that have minimum requirements. At the end of the day, it will all be about the Windows Application Store and what it allows its applications to be built with.