Linked by Thom Holwerda on Mon 21st May 2012 20:03 UTC
Windows For Microsoft, the traditional desktop is old news. It's on its way out, it's legacy, and the harder they claim the desktop has equal rights, the sillier it becomes. With companies, words are meaningless, it's actions that matter, and here Microsoft's actions tell the real story. The company has announced the product line-up for Visual Studio 11, and the free Express can no longer be used to create desktop applications. Message is clear.
Permalink for comment 519078
To read all comments associated with this story, please click here.
RE[7]: "19th Century Dentist"
by Nelson on Wed 23rd May 2012 04:21 UTC in reply to "RE[6]: "19th Century Dentist""
Member since:

I understand that, but there's no technical reason this kind of meta data couldn't also be applied to win32s, which is just an API.

Well, you'd run into compat issues with previous Windows desktop apps. Metro benefits from the clean break and can afford a new execution model.

But furthermore, Metro is more than the sum of its parts. Its an entire cohesive thing. You have an execution model, a cross language abi, language projections, etc.

The OS is always free to manage resources like it always has. As an example, the linux kernel can run processes inside cgroups which can monitor process resource usage and apply hard/soft limits whether or not application binaries are aware of them. Adding these features to linux didn't require developers to abandon their APIs and rebuild apps from the ground up. I don't see a technical reason OS resource enforcements in metro cannot be applied against desktop apps if that were a goal.

Well, the end goal isn't to make things harder. Its to enforce these policies, and provide facilities to do things the right way. That's the value prop of WinRT. Yes there are restrictions, but here are ways to play within our sandbox.

Of course I agree with that, but by far and large I think applications which don't need to be running in the background are *already* not running in the background because the OS isn't sending them any events to handle. And those that are running in the background are doing it because they're doing real work (like an SFTP client transferring files).

There's a difference, suspended Metro apps are not scheduled at all. The processor can effectively operate in low power states more frequently.

I've inadvertently programmed such tasks myself on more than one occasion, but these were quickly discovered, and in principal one could apply the same quotas against both metro and win32 apps such that the performance degradation of endless loops would be the same in either case.

win32 apps aren't designed for and don't expect such things, Metro apps are. Metro apps are designed to save state, Win32 apps are not.

Hmm, polling and blocking are totally different approaches. Polling is extremely bad, but I honestly haven't seen too much of that since the days of DOS. Polling has been replaced with various kinds of blocking mechanisms (event passing, asynchronous callbacks, IO threads, ...). In all cases though when a thread is blocked on input it is asleep and not consuming any CPU. The OS chooses when to wake it up to handle new IO events.

My point is that while Win32 applications may or may not use best practices. Metro apps must use best practices.

Then I'll need you to explain how the mechanics are different from a win32 event loop, other than being a different API, since the win32s can also be described as "don't call us, we'll call you".

Newer hardware supports ultra low device states in which you can be suspended, and only be awoken when new data is on the wire. As noted above, the app isn't even scheduled until new data on the transport channel triggers it. The data is then pushed to you.

I am skeptical, I'd love a citation for that.

Its simple, suspended apps are not scheduled, and during low memory situations their memory is reclaimed.

Reply Parent Score: 2