More details on ​jupiter/win​RT

i didnt want to hijack the line endings thread so im starting a new one

The folks over at the MDL forms have discovered some interesting stuff

• Jupiter appreas to be a UI framework called DirectUI (not to be confused with the nativeDirectUI that programs like msn and zune uses ) it lives in Windows.UI.DirectUI.
• .net 4.5 appears to be included by default in win8 and it contains the async stuff, as well as a System.Runtime.InteropServices.WindowsRuntime namespace in mscorlib and assemblies such as System.Runtime.WindowsRuntime.dll, System.Threading.Tasks.Dataflow.dll, System.Reflection.Production and System.Runtime.Serialization.OData
• Both immersive windows and 'jupiter' windows can be created from unmanaged code.
• It appears the difference between immersive windows and regular ones is not huge, by changing a registry key, they have been able to launch immersive windows just as normal ones.

Yeah as the info leaks out it seems like they have done some cool stuff for Vnext

I hope not to much fails or gets cut.

there have been a lot of guesses about stuff like will they start to merge the development tooling and runtimes for things ....  IE:  make it as simple / easy as is practicle to move code and markup from one device to the other.  sure there are things that will not be "right" to move to a different device in some respects but there should be a lot of code that we should not have to write 4 times any more....

as in  :

Object / Entity for data,  one for asp.net, another for silverlight, another for wpf another for xbox

and another one for the phone ......

try and use EF and ria today .....  RIA will work with silverlight but not with WPF (UNless you do a lot of hacking and then you lose parts of what works on silverlight)

and RIA does nada for asp.net or asp.net MVC apps.

i do not care if the transport runtime and the client proxy are different on each consuming client / device ... just let us create the object one time and let me use the same source code on each client.

seems like that could be done and would simplfy the "3 screens and a cloud" implimentation story.

@aL_:, Thank Al.  This is a pretty incredible forum thread you found.  This changes everything.  Seriously.

I now retract anything I said about MS having to speak up.  MS needs to be quiet until BUILD.  Get this stuff working with a solid Beta.  I'm satisfied enough that they're going down an interesting path, and certainly not what I was speculating.

Microsoft needed better tools to build lightweight (native code) applications for small devices. This seems to be in that vein. I hope the xml data format will die someday, but it is better than nothing.

from MDL forums

/target:appcontainerexe        Build an Appcontainer executable (Short form: /t:appcontainerexe)
/target:winmdobj               Build a Windows Runtime intermediate file that is consumed by WinMDExp (Short form:
/t:winmdobj)

oo this is interesting, csc.exe has some new compilation targets.. Windows Runtime intermediate file?  so the winRT/SLR does not run regular IL? the plot thickens..

i recall from the talks on signularity and such that you can get most of the benefits of .net by the compiler and the final code could be native w/o having to give up the c# language and the benefits of the .net framework.  i think that folks generally forget that  it's only MISL before the JIT  if a block in memory has been JIT'ed then it's native code.  do a better job with a tool like ngen and you can ship a MISL package but gen native images on a machine so you get to target different CPU's and OS profiles with one app.

thats one way this stuff can play out ...

Nice roundup of things here:

http://davidburela.wordpress.com/2011/06/14/premature-cries-of-silverlight-wpf-skill-loss-windows-8-supports-all-programming-models/

@Ian2: Just as I expected.

50 minutes ago, Ian2 wrote

Nice roundup of things here:

http://davidburela.wordpress.com/2011/06/14/premature-cries-of-silverlight-wpf-skill-loss-windows-8-supports-all-programming-models/

If he's right, that means the new Start Screen really does only support HTML5 interfaces, and "Jupiter" will run in the old Explorer.

@spivonious:

I really wonder if that is is true.. from what i've seen that you can create immersive apps in c++ (and most likley managed code as well) i am biased ofcourse restricting the new start screen to html/sj apps seems senseless

1 hour ago, spivonious wrote

*snip*

If he's right, that means the new Start Screen really does only support HTML5 interfaces, and "Jupiter" will run in the old Explorer.

I think that is just two different people taking different paths through poking at the new APIs. DirectUI will likely be usable in both "classic" windowed apps and "Immersive" apps. The other guy was just concentrating on getting an Immersive window open via c++.

I think it's all starting to make sense. But I think it still means certain APIs are on their way out.

Things that will be "dead" (as in supported but little or no future enhancement like WinForms):

• WPF: No reason for this to exist in the face of DirectUI other than backwards compatibility.
• Silverlight: May still have a future for cross platform (Country and Western)  but little else. Also replaced by DirectUI for Windows only dev.

i'll be very interesting to see just how diffrent the DirectUI api will be from wpf silverlight.

My guess is that DirectUI will be a superset of wpf and there only will be minor changes required to compile wpf apps as DirectUI apps..

I do doubt that DirectUI will be downported to win 7 or below though, so perhaps there will be an update for .net (4.5?)  that will be api compatible across more windows versions but run on winRT/jupiter on windows 8 and the clr on other versions...

All of this info based on digging around leaked builds is getting me very excited. They had better implement all of this Jupiter stuff or I might cry!

So there's a new WPF-like UI framework coming with Windows that is more coherent and coupled with the host OS better than WPF was? That's good.

What I want to know is if you can make full use of this framework without having to load the CLR or any kind of VM. That is: native C/C++ applications can have these smooth fluid UIs without any JIT getting in the way, or violating the purity of the codebase.

Kind of like "what if the CLR part of WPF was native to begin with, and didn't require the CLR?". So far the screenshots I've seen of Jupiter's "codes" have been reflected CIL, which means the CLR is involved.

Can someone clear this up for me? Thanks.

@W3bbo:

Thats the thing, from the look of things it seems like the CLR is not involved. It seems like they've taken the GC our of the clr an put into something called slr100.dll (Redhawk? a ~200k dll) and either that or winRT is able to run CIL. slr100.dll look unmanaged, it lives in the winSxS folder.

In any case it seems like the gap between native and managed is shrinking significantly in win8, especially with the new interfaces visible to .net that seems to exactly mirror the STL collections such vector and map

ofcourse this is all conjecture from looking at a leak, treat it as such

@W3bbo: It may be that its easier to poke around at the managed level because the the reflection based tools already exist.

This post shows an attempt at loading DirectUI in C++.

God I love this detective work type stuff. Maybe it is good Microsoft isn't talking until BUILD. We would've missed out on all this poking around if they had spilled the beans early on.