Together with this it will have a new UI framework, DirectUI (no relation to the previous internal-only
DirectUI), which is loosely based on Silverlight and XAML, but will have a native API together with a
managed (SLR) API. Basically, this will be their third try at the Avalon concept after WPF or Silverlight.
Take 1: CLR + WPF
Take 2: CoreCLR + Silverlight
Take 3: SLR + DirectUI
This will be the supported way to write "immersive" Win8 apps in managed code
This will be good for .NET developers because:
They'll get to write immersive apps after all
They'll have a version of .NET with much-improved performance (esp. startup time), and a UI framework with better hardware accelerated graphics
They'll finally be able to write Explorer and IE extensions in managed code
This will be bad for .NET developers because:
It will be yet another not-quite compatible framework, after WPF and Silverlight
Because they are starting over again, and with more stringent performance standards, it will probably be less capable/full-featured than current Silverlight/.NET, like going back to Silverlight 3
Since it's being developed by the Windows team as part of Windows, they'll probably apply the more stringent "run the memory allocator in a different mode so SimCity will work" Windows approach to maintaining backwards compatibility as well, which means even in the future it will probably evolve more slowly than mainline CLR (plus, of course, Windows is on a slower release cadence).
You could probably develop immersive apps in Silverlight or WPF if you really wanted, but the
Windows team wouldn't recommend it as performance wouldn't be to their standards and you'd
probably have to go through a bunch of interop hoops to use the DirectUI widgets etc.
Anyway, this would explain why they vaguely hint at there being some kind of .NET story,
but refuse to say anything - if the answer was a straight yes or no, it'd be easy enough,
but the answer is "it's complicated", so before saying anything they have to figure out how to spin it
I kind of like the idea of SLR, an integrated .NET into the Windows Shell. But then they should integrate .NET 4.0 and not fork it. The next version of .NET should ship with the next version of Windows, or they should make it so "Windows Update" can install a new SLR into windows without breaking anything.
And it does explain why no straight forward answer can be given before the BUILD conference. It also is in line with "Build Windows" and "Biggest change since Windows 95" taglines.
We will have to wait and see.
If it's true they will need a lot of time to reach that goal and that's maybe why Sinofsky doesn't want to promise a release in 2012.
I hope you are right, it would at least be a step in the right direction. Such an approach could work well. Although I don't see why a "user mode" CLR that keeps moving at the current CLR development pace can't be put on top of a "kernel mode" SLR. Maybe not kernel/user mode as we currently know it, but more "core" vs "full". The Windows team can then focus on the "core" SLR (slower moving, less features, basically replaces Win32), while the DevDiv continues to develop the current CLR and rich features. These will basically just live in different namespaces but be equally accessible to developers. Not sure how workable that can be.
But in the meantime those of us that don't have direct access to this kind of internal info have to deal with this depressing message from MS where HTML5/JS is clearly and continuously being pushed as the new/only development framework. Whether true or not (too stupid to be true according to me), this is at least the messages that is coming out of MS.
While we don't get an info from MS tiIl Septmeber, we maybe get some info from Mary Jo on Monday. Here what I got in my mail box from Mary Jo: "Yes... I will have more on this Monday. Stay tuned ..."
Very interested to see what Mary Jo has pulled up.
I've heard a lot of references to this "SLR" but haven't seen any actual evidence that it exists.
It would make sense for Microsoft to fix the shortcomings of the CLR platform, but forking it isn't the solution.
Why aren't JIT'd images cached in the system for improved performance? It doesn't make sense to JIT the same assembly every time it runs.
"Jupiter is a user interface library for Windows and will allow developers to build immersive applications using a XAML-based approach with coming tools from Microsoft. Jupiter will allow users a choice of programming languages, namely, C#, Visual Basic and C++. (Hey, maybe this is why Microsoft is calling the next version of Visual C++ "WinC++"?)"
"Microsoft is still going to support Silverlight with Windows 8, and not only as a browser plug-in, my sources say."
So far good news. But it's not official yet.
we all know microsoft sucks at making announcements and retain information that they should really share from day1, that combined with the absolute madness of trying to force developers away from their own development stack tells me that this thing is getting out proportion..
i mean, what possible benefit would microsoft have to wean people from .net/SL/native?
even putting aside the suitability of html/js for general applications, why would they throw away all the work devdiv has made in .net and visual studo/tfs? and perhaps more relevant, all the investments buisnesses have made in .net? buisnesses are after all the biggest income microsoft has.
Going for a web only approach would dissolve any advantage microsoft has on the desktop market, all the apps would work just as well (or better) in chromeOS as in win8. why would microsoft want that?
even though its hard, i really think we need to wait for microsoft to release more info..
Here's my take on it.
@wkempf: From Mary Jo's post I really think Silverlight is in for another round. The App Market on W8 will show which technology wins this battle. Once they have thousands of SL pps in the market it will be impossible to kill it.
@section31:Even better, perhaps we'll have 2 kinds of apps. Some will be written in HTML5/JS and some will be written in SL. There will be some functional overlap and perhaps actual duplication of functionality.
What's cool is that the world will continue to spin around the sun, software developers will still have work, and this whole announcement will be relegated to a line or two in the history section of Windows wikipedia page.
From what I've gathered, here's what I think we'll see:
1. Devs will write Windows 8 apps using XAML that is translated into HTML5+JS. These HTML5+JS calls will themselves be accessing libraries in the SLR. Existing WPF/Silverlight apps may require small tweaks, but for the most part will "just work" in the new system. Anything else and MS are shooting themselves in the foot.
2. .NET as we know it today will slowly be converted over to use the SLR instead of the CLR. This makes the most sense, as it doesn't break existing apps, but takes advantage of the performance gains of having the runtime tied more deeply into the OS. Existing .NET code (separate from UI) will gain performance as calls to System.dll are forwarded to the SLR.
3. Current C++/Win32 devs will be encouraged to move to "WinC++", which will directly target the SLR. Win32/MFC will stop being updated.
MS really needs to provide some more information before September, or they risk losing a large portion of devs. Even something as small as "we will continue developing .NET as a first-class citizen in Win8" would help ease the tension.
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.