Ever since Windows 8 was first shown to the public back in June 2011 people have speculated about / been confused about what relation the "new system" has to the existing Windows, technically - is "Metro" a thin layer over "Desktop" Windows, like Media Center or Bob? Or is it the reverse, the desktop some virtual-machine environment on top of the "new system", like Mac OS "classic mode"? Or are they two systems running side-by-side?
In fact it's none of those things - the new environment/UI isn't a new shell running on top of, underneath, or alongside the existing shell. Rather, it's a set of new features added and refactorings made to every layer of the existing system, together with a set of policies designed to create the effect of a fresh new environment by encouraging/enforcing a path through only the "new" parts of each layer.
So, for example, the app permissions / sandbox that new-style apps run in is actually a new general low-level system feature that desktop apps can use too - IE10 desktop uses it for "Enhanced Protected Mode". But this isn't really being publicized or promoted because why would desktop app developers rewrite their code to work with it? Similarly the windows that new-style apps run in aren't being controlled by some separate window manager, they are just regular windows (HWND) in the existing window manager - but that window manager has new features for smoother composition/animation and touch manipulation of windows, and new security features to enforce Z-order rules so apps can't pop up windows on top of new-style apps or steal focus or whatever. Most of the new WinRT APIs aren't available to desktop apps but there is no fundamental purely technical reason they can't be. And so on.
It looks like in many places, dogma and internal turf wars are behind the decisions. Some things however seem quite reasonable, like having one comprehensive API available to both .NET and native applications and scripting languages - but then only Win Store apps can use most of them... sigh
Oh, and no threads for you, and all I/O is dogmatically asynchronous. Ryah (of node.js) would be proud.
More hilarity: "As is this case with most of WinRT, contracts aren't usable in desktop applications. This means that, for example, a desktop e-mail client such as Outlook can't be used as a share target."
MS pushes the line that desktop apps shouldn't depend on Windows store apps being installed on the same machine, and vice versa. In other words, there's no official bi-directional communication method between the two.
It seems like a good iterative approach to me. Classic desktop apps can still run, but it seems clear they are no longer preferred. WinRT offers an interface over Win32, a skim coat to even out all the cracks, quirks and special cases that have appeared over the years. At some point down the line you can jettison Win32 altogether and replace it with whatever you want, or even leave it in place.
WinRT isn't just a new library, though it is that in part. More so, it's a whole new infrastructure for building and assembling Windows programs. If Windows 8 is successful—and more specifically, if Metro apps flourish—WinRT will be the foundation on which Windows apps are built for decades to come.
Unlike the popular belief that Windows 8 is a bet-your-company on this kind of decision for Microsoft, the article makes it clear that technically the OS API remains the same at the lowest level. To me, this makes the whole Metro interface seem like the now discontinued Active Desktop[1], where the desktop wallpaper became a live webpage.
Also curious to know how a sandboxed Metro environment would be different from a sandboxed virtual machine like .NET. With third party applications being accessible from Windows Store, this makes the whole Windows security topic a concern once again.
Quick tip: skip directly to page 4. Start reading from "The indomitable iPad". All you need to know thus far is that windows has been, for better or worse, mainly relying on a complex cluster fuck called COM.
i have a headache. I am going to sleep.
Let's be clear on 1 thing. WinRT IS a (right now pretty bad and incomplete) alternative to Win32 (sure WinRT is implemented using Win32 but that is simply to reuse code). The WinRT implementation doesn't have anything to do with the scope.
The WinRT scope IS to replace in distant future Win32. Sure right now WinRT is basically targeted at tablets running full screen apps, but this might change in the future.
Also WinRT is sharing a symbiotic relationship with "old" Win32. Right now they do sit side by side. Heck explorer.exe is running both "WinRT" (is running in a windows with class ImmersiveBackgroundWindow) as well as the desktop.
Interesting article but kind of weird that it goes into such a level of technical detail while still attempting to explain basic concepts like garbage collection.
I find it in the middle in a good way. Detailed enough for tech people yet still explain some basic (but important) terminologies for curious people. It's a win-win situation really: tech people do not know all the things about Win32 (think about a mobile dev who wants to try out the new OS). I also like the way he mentioned COM and .NET as unsearchable, guess what is the next big framework/foundation from Microsoft?
Wow, Windows 1.0 desktop is a tiling window manager! I use i3 on Lubuntu and previously awesome. Would be nice if MS compromised and had tiling for apps in Windows 8 desktop mode.
[+] [-] bztzt|13 years ago|reply
In fact it's none of those things - the new environment/UI isn't a new shell running on top of, underneath, or alongside the existing shell. Rather, it's a set of new features added and refactorings made to every layer of the existing system, together with a set of policies designed to create the effect of a fresh new environment by encouraging/enforcing a path through only the "new" parts of each layer.
So, for example, the app permissions / sandbox that new-style apps run in is actually a new general low-level system feature that desktop apps can use too - IE10 desktop uses it for "Enhanced Protected Mode". But this isn't really being publicized or promoted because why would desktop app developers rewrite their code to work with it? Similarly the windows that new-style apps run in aren't being controlled by some separate window manager, they are just regular windows (HWND) in the existing window manager - but that window manager has new features for smoother composition/animation and touch manipulation of windows, and new security features to enforce Z-order rules so apps can't pop up windows on top of new-style apps or steal focus or whatever. Most of the new WinRT APIs aren't available to desktop apps but there is no fundamental purely technical reason they can't be. And so on.
[+] [-] aristidb|13 years ago|reply
It looks like in many places, dogma and internal turf wars are behind the decisions. Some things however seem quite reasonable, like having one comprehensive API available to both .NET and native applications and scripting languages - but then only Win Store apps can use most of them... sigh
Oh, and no threads for you, and all I/O is dogmatically asynchronous. Ryah (of node.js) would be proud.
More hilarity: "As is this case with most of WinRT, contracts aren't usable in desktop applications. This means that, for example, a desktop e-mail client such as Outlook can't be used as a share target."
[+] [-] damian2000|13 years ago|reply
Some further info on this here for those interested: http://stackoverflow.com/questions/7465517/how-can-a-metro-a...
[+] [-] quotemstr|13 years ago|reply
Not so much. Don't confuse WinRT, an optional helper library, with the system calls you're actually allowed to make inside an app container.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
WriteFile is available in Windows Store applications. You have to use CreateFile2 to get a HANDLE, but CF2 can still create synchronous IO handles.
[+] [-] aik|13 years ago|reply
So basically Metro apps can only share with Metro apps? So a Metro Outlook can be shared with.
[+] [-] hoov|13 years ago|reply
All I/O has been asynchronous since Windows NT. Any blocking calls are just the CRT helping you out.
[+] [-] Hominem|13 years ago|reply
[+] [-] thwarted|13 years ago|reply
This reads like .NET marketing from years ago.
[+] [-] arocks|13 years ago|reply
Also curious to know how a sandboxed Metro environment would be different from a sandboxed virtual machine like .NET. With third party applications being accessible from Windows Store, this makes the whole Windows security topic a concern once again.
[1]: http://en.wikipedia.org/wiki/Active_Desktop
[+] [-] donebizkit|13 years ago|reply
[+] [-] mariusmg|13 years ago|reply
The WinRT scope IS to replace in distant future Win32. Sure right now WinRT is basically targeted at tablets running full screen apps, but this might change in the future.
Also WinRT is sharing a symbiotic relationship with "old" Win32. Right now they do sit side by side. Heck explorer.exe is running both "WinRT" (is running in a windows with class ImmersiveBackgroundWindow) as well as the desktop.
[+] [-] aristidb|13 years ago|reply
[+] [-] sondh|13 years ago|reply
[+] [-] dmix|13 years ago|reply
Seems caught in between them all.
[+] [-] mmariani|13 years ago|reply
http://arstechnica.com/features/2012/10/windows-8-and-winrt-...
[+] [-] CrankyBear|13 years ago|reply
[+] [-] account_taken|13 years ago|reply
[+] [-] Zecc|13 years ago|reply
[+] [-] undantag|13 years ago|reply