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.
Thread beginning with comment 519104
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: "19th Century Dentist"
by malxau on Wed 23rd May 2012 09:22 UTC in reply to "RE[7]: "19th Century Dentist""
Member since:

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.

That's true, but it seems odd reasoning to me to say that battery life can be improved by starting over - with no existing applications - as opposed to improving Win32, and having improved battery life with a nonzero number of working applications on day one. Especially if those applications that are broken can be fixed with more minor changes instead of a rewrite, it's more likely to happen more quickly.

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

What Alfman's getting at is that operating systems do not schedule threads that are blocked waiting for something to do, whether it's a new UI message or blocking network IO. These processes consume zero CPU; not a small amount, but zero. The memory manager is free to take back any pages associated with these processes, and will do so, if it believes it can use that memory for something else more important. In other words, we already have that capability, and modern systems rely on this all the time.

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

That's really it in a nutshell. In Win32 if you want to write a process that uses background processing for something, battery life goes down, but you can write the application. In WinRT you can't. Which is better depends purely on your values (absolute battery vs. flexible applications.)

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.

That new hardware would work fine with existing blocking or async network APIs (recv, select, WSAAsyncSelect, the works.) The thread is asleep doing nothing, and when the hardware tells the OS it has data, the OS can schedule the thread and tell it that it has data.

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

If a process contains no threads that have been scheduled for a long period, the memory manager will trim the working set of that process. The reclaiming aspect in low memory situations hasn't changed much. What has changed is when the process is suspended the _entire_ working set can be pushed out, including to disk, in a sequential fashion. This means it can be read back sequentially rather than faulting page-by-page when the application becomes active again, making resume times faster.

Ironically, this only works because resuming a suspended process is a more heavyweight operation that happens less often than a random context switch to a thread that hasn't run in a while. So switching to a suspended app is marginally slower than switching between traditional running applications, but the benefit is that in the worst case, when out of memory, the IO patterns are better when switching.

That said, be honest here, how often do you use a system that is paging data to/from disk so aggressively for this to matter?

Reply Parent Score: 2

RE[9]: "19th Century Dentist"
by Alfman on Wed 23rd May 2012 16:11 in reply to "RE[8]: "19th Century Dentist""
Alfman Member since:


Ah, it turns out my post repeated alot of things you said in yours.

Thanks for explaining how Metro swaps out it's entire working set. It didn't stand out to me but it may be the source of some minor differences.

"In Win32 if you want to write a process that uses background processing for something, battery life goes down, but you can write the application. In WinRT you can't. Which is better depends purely on your values (absolute battery vs. flexible applications.)"

I personally don't like not being able to run things in the background, even if it's something I as a user would have to grant on an individual application basis, I'd rather be able to do it.

I wonder how a metro dvd burning software would work, or P2P, video conference overlays (aka netconf), or whatever that I'd want to run in the background. Microsoft might carve out some exceptional APIs for these, or it may not. Maybe it's not supported at all, maybe only privileged commercial software will be granted exceptions. Maybe only microsoft software will be allowed to do it and we'll be forced to interface through it.

What sucks about all this is that independent 3rd party developers are no longer in the driver's seat, we cannot build new innovations on top of metro without mother microsoft's consent no matter how much customers may want it.

Edited 2012-05-23 16:21 UTC

Reply Parent Score: 2

RE[10]: "19th Century Dentist"
by Alfman on Wed 23rd May 2012 18:02 in reply to "RE[9]: "19th Century Dentist""
Alfman Member since:

More info on Metro background tasks:

Below are some snippets. Metro background processing quota's are above "zero", but still extremely limited.

"Scenarios that are not appropriate for background tasks are indexing mail, transcoding photos, running SETI type workloads, or anything that requires user interaction through displaying UI or audio."

Table 5 – CPU resource constraints on background tasks
Lock screen app: 2 CPU seconds per 15 minutes
Non-lock screen app: 1 CPU second per 2 hours

Table 6 – Example network throughput for background Data throughput, in megabytes (MB)

Lock screen apps:
From 188KB to 3.5MB per 15min depending on bandwidth (avg 208B to 4.2KB per s).

Non-lock screen apps:
From 3MB to 60MB per day (avg 34B to 694B per s)

"Critical background tasks
Real-time applications like VOIP that rely on the Control Channel or Push Notification trigger may not want their critical background tasks to be suspended due to resource constraints in the middle of something important; for example,. an incoming call. Hence, background tasks that use the Control Channel or Push Notification trigger receive guaranteed application resource quotas (CPU and network) for every running task."

"if a device is running on AC power then background tasks are not network constrained. They are free to use as much network bandwidth as they need ... Note that CPU usage for a background task is always resource constrained even if the device is running on AC power."

"Threading model for background tasks hosted in the app
If background tasks authored in C# or C++ are hosted within the app instead of the recommended BackgroundTaskHost.exe, there are some threading model complexities to keep in mind.

Decoupling the background task from the app
For non-JavaScript apps, the background tasks are hosted in an in-proc DLL that is loaded in a multi-threaded apartment (MTA) within the app. For JavaScript apps, background tasks are launched in a new single-threaded apartment (STA) within the WWA host process. The actual background task class can be either an STA or MTA threading type. Because background tasks can run when an app is in a Suspended or Terminated state, they need to be decoupled from the foreground app. Loading the background task DLL in a separate apartment enforces separation of the background task from the app while allowing the background task to be controlled independently of the app."

This is all ok for power constrained tablets, but it's kind of wasteful to impose on owners running metro on multicore desktops with oodles of ram. A better approach is to give owners a choice in the matter so they can configure metro however they want.

Edited 2012-05-23 18:14 UTC

Reply Parent Score: 2