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 519028
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: "19th Century Dentist"
by Alfman on Tue 22nd May 2012 17:29 UTC in reply to "RE[5]: "19th Century Dentist""
Alfman
Member since:
2011-01-28

Nelson,

"The Win8 execution model says: 'If programA wants to use the Network, it must explicitly state so declaratively, and then when it does, it must behave predictably or be killed.'"

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


"Most programs, realistically, don't need to always be running..."

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


"I agree, but in my own experience its been more than a few timesI've had to kill tasks."

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.


"Windows 8 tablets and laptops support ultra low power states in which the network card will wake itself back up when data comes in over the wire. Something that can't be done if an application is polling doing a blocking read."

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.

"With Win8 you hand the OS a background task, and you'll have your network data pushed to your app when it comes in, its basically a 'Don't call us, we'll call you'."

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


"I think its demonstrably true that Metro Apps use less resources."

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


"A great majority of them do not run in the background at all, others use resources moderated by the OS, and there is less resident memory taken up by the apps."

I understand this, but I feel like your insinuating that most win32 apps do run in the background when minimized when I actually think they're blocked on input and are completely asleep. Even if they are not, an OS could always force them to sleep until they're brought back to the foreground as policy demanded.

Again, I'm not trying to undermine the merit in winrt, it may be a wonderful API (apart from certain restrictions...). I just don't know if there's any substance to the argument that win32 inherently wastes more energy.

Edited 2012-05-22 17:41 UTC

Reply Parent Score: 4

RE[7]: "19th Century Dentist"
by Nelson on Wed 23rd May 2012 04:21 in reply to "RE[6]: "19th Century Dentist""
Nelson Member since:
2005-11-29


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.
http://blogs.msdn.com/b/b8/archive/2012/04/17/reclaiming-memory-fro...

Reply Parent Score: 2

RE[8]: "19th Century Dentist"
by malxau on Wed 23rd May 2012 09:22 in reply to "RE[7]: "19th Century Dentist""
malxau Member since:
2005-12-04

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.
http://blogs.msdn.com/b/b8/archive/2012/04/17/reclaiming-memory-fro...


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[8]: "19th Century Dentist"
by Alfman on Wed 23rd May 2012 15:44 in reply to "RE[7]: "19th Century Dentist""
Alfman Member since:
2011-01-28

Nelson,

"Well, you'd run into compat issues with previous Windows desktop apps."

Possibly, but lets look at a comparable situation: windows applications already go through very lengthy hibernation periods with *zero* energy consumption when the whole system hibernates. Nobody demanded a new API when windows added support for hibernation and most existing applications do survive hibernation cycles without any deliberate effort by application developers. As long as the OS keeps it's application resource state in sync with the application itself, then the application can work obliviously as though no hibernation ever happened. So I think compatibility problems are a bit exaggerated.


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

Please elaborate. Operating systems are ultimately responsible for when applications are scheduled to run. Either an application is permitted to do something in the background or it is not. If it's OS policy to put background applications to sleep and deny them any background processing, then it doesn't matter whether they're winrt/win32, they'll still have the same power state footprint. It's true end users may become annoyed existing win32 apps won't run in the background like they used to on an older OS, but lets be clear - it is OS policy restricting them, not the win32s. They're expectations of background processing need to be corrected for the new OS.


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

I don't know why you're making this so complex.
Please see above, win32 apps weren't "designed to save state", yet hibernation works. Any win32 application can handle power management events if it chooses to. Any additional functionality in metro could have been added to win32s.


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

But you were trying to highlight a difference that's not there. Busy waiting causes all multitasking systems to crawl, which is why win32 applications don't do it. Show me an existing windows application that employs busy waiting that you'd like to run on metro?


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

Ok, but you need to understand that even with win32s, using either blocking threads or asynchronous events, the application thread is NOT scheduled to run until the data is "pushed to you". I think you have a fundamental misunderstanding that win32 apps work by polling everything all the time, that's probably the source of nearly all our disagreements, so maybe we should go through a a simple example?


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

Well the link goes on to explain the principals of virtual memory and memory swapping. I could be missing something, but A cursory reading didn't reveal anything to me that was specific to Metro.

Reply Parent Score: 2