Turning to the past to power Windows' future: An in-depth look at WinRT | Hacker News Reader

Turning to the past to power Windows' future: An in-depth look at WinRT

arstechnica.com

129 pointsco_pl_te27 comments

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.

Having finally (almost) finished the article...

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."

>> a desktop e-mail client such as Outlook can't be used as a share target

So basically Metro apps can only share with Metro apps? So a Metro Outlook can be shared with.

Yes. Kind of sad, because I think these "contracts" are an awesome idea, and I don't like them being artificially limited like that.

Yep. Not only can you not share to desktop apps, you can't share from desktop apps, though they still have the Charm on the side for it. So you get this wonderful little flyout:

http://i.imgur.com/THJHM.png

Attention! This Message box has no content. [Cancel] [Ok]

Reminds me of what happened when you dragged something to an open application in the taskbar in WinXP (and maybe later versions too).

You got a message saying, essentially, "the computer knows what you want to do but refuses to do it for you".

It's borderline insultingly user-hostile.

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.

Some further info on this here for those interested: http://stackoverflow.com/questions/7465517/how-can-a-metro-a...

> Oh, and no threads for you, and all I/O is dogmatically asynchronous.

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.

> Oh, and no threads for you, and all I/O is dogmatically asynchronous.

All I/O has been asynchronous since Windows NT. Any blocking calls are just the CRT helping you out.

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.

This reads like .NET marketing from years ago.

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.

[1]: http://en.wikipedia.org/wiki/Active_Desktop

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.

Yeah, I'm not sure who the expected audience for this piece is. Programmers? IT people? Non-technical?

Seems caught in between them all.

Here's a tweet from the author of the article before it was published that might shed some light on that:

"I have possibly the nerdiest, longest article I've ever written going up at 1930 Central tonight."

https://twitter.com/DrPizza/status/260154952868057088

So, I'd say the audience is nerds in general. I agree the article doesn't seem to have a definite target audience, but I think — in some sense — that is the beauty of Ars Technica's content. It's accessible enough that non-technical nerds can get value from it, but technical enough that more hardcore nerds appreciate it.

My intended audience is, I guess, anyone who's ever taken something apart in a bid to figure out how it works. The ability to put the thing back together again such that the thing continues to work is strictly optional.

I hope it's deep enough that programmers who haven't been tracking Microsoft's efforts religiously will find it educational, but not so deep that someone who's merely interested in what makes the operating system tick is scared off.

I expected this to be a short, mainly fluff 1 pager based on the title. I was pleasantly surprised when it wasn't. In order to pass judgement on MS's design choices for WinRT you really need to understand the history of the technologies involved. I think that this does a great job of doing just that.

BTW, I fall into the "programmer who hasn't been religiously tracking MS" category.

Thank you for writing it like this. Parts of it I was quite familiar with, but parts of it I have zero exposure to, and I really like being able to review the parts I already know as a way to check your credibility on the parts I know nothing about. Only thing I found lacking was I disagree with the characterization of the OS/2 split - 'forcing Microsoft...' seems to imply a backwards cause and effect from my understanding of things. But if that's the only nit I can pick in such a long detailed article, then it's darned well done.

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?

If you want to decide if you should develop a Windows 8 app you can skip the history lesson and read from page 5.

http://arstechnica.com/features/2012/10/windows-8-and-winrt-...

I'd liked this story more, a lot more, if they hadn't broken it into seven (7!) fucking pages.

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.

Am I the only one who always reads WinRT as "winner tea" ?

It seems like a Wii U -like device would be a great match for Windows 8. Or just a desktop-tablet combo, working together seamlessly.

Reply on news.ycombinator.com