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

Nelson,


"Puts things in perspective for snobby developers. We serve the consumer, and the trends are overwhelmingly pointing towards a walled garden with curated apps with first class touch support."

Call me cynical, but I believe microsoft wants us to serve their platform *instead* of the consumer.


"PCs have gone mobile which means we need better battery life and that itself necessitates a new execution model. Having all apps running all the time is extremely wasteful."

Not quite. There is absolutely nothing about the old win32s that necessitates applications to be running all the time (foreground or background). At their core, most windows applications are fundamentally built on top of a simple loop which is event oriented. So as long as the operating system is not sending it any events, the majority of existing applications won't use any CPU time. Go ahead and look at the task manager and check to see if your minimized programs are using more than 0% CPU, in the majority of cases the answer is "no".

"Microsoft is for once, ahead of the curve when it comes to a converging ecosystem with a strong developer story. This leap into a new era will pay dividends for them."

It's interesting you should say that. I used to think microsoft was more developer friendly a decade ago when I developed entirely for windows. Then everything changed around the time of Vista. OS programmers like myself were upset to witness our platform imposing new non-elective kernel lockouts and DRM controls that put a huge wrench in open source development. Even commercial developers were shafted when microsoft broke thousands of drivers. And customers were shafted when their hardware was no longer usable. 2K/XP drivers would already work as is if not for the DRM and lockout restrictions designed to make them not work. It was a slap in the face when 3rd party tools designed to allow end users to install XP and open source drivers were banned.


That was really the turning point for me as independent/open source kernel developers were clearly unwelcome on windows any more. Now they're going even further and restricting the installation of user space applications...well this is what I have to say about that:

http://www.bing.com/images/search?q=mr+yuck

Edited 2012-05-22 06:08 UTC

Reply Parent Score: 7

RE[3]: "19th Century Dentist"
by Nelson on Tue 22nd May 2012 06:11 in reply to "RE[2]: "19th Century Dentist""
Nelson Member since:
2005-11-29


Not quite. There is absolutely nothing about the old win32s that necessitates applications to be running all the time (foreground or background). At their core, most windows applications are fundamentally built on top of a simple loop which is event oriented. So as long as the operating system is not sending it any events, the majority of existing applications won't use any CPU time. Go ahead and look at the task manager and check to see if your minimized programs are using more than 0% CPU, in the majority of cases the answer is "no".


Maybe in a singled threaded world, but most multi threaded applications are consuming CPU resources while minimized.

CPU utilization is just one facet, there's stuff like utilizing the network which can prevent the PC from entering low power states for the network card which becomes a concern. Same thing with audio playback.

I think Metro, with OS managed background tasks (which have strict resource caps and policy imposed) are a great middle ground between battery efficiency and multitasking.

Thanks for the thoughtful reply.

Reply Parent Score: 2

RE[4]: "19th Century Dentist"
by Alfman on Tue 22nd May 2012 07:14 in reply to "RE[3]: "19th Century Dentist""
Alfman Member since:
2011-01-28

Nelson,

"Maybe in a singled threaded world, but most multi threaded applications are consuming CPU resources while minimized."

Certainly an app can spawn threads that consume large amounts of CPU time in the background, however it's likely that these threads are just reacting to more events such as network activity or topping up audio buffers. If you have a music player or P2P app, then running it in the background is often exactly what the user wants (who wants to stare at the P2P screen all day?). Can we say a background application is wasting energy when it's doing what the user wants in the background instead of the foreground?

I think the bigger problem is applications that waste cycles in the background doing non-productive things. One example I'm thinking of now is a game that keeps running even when minimized, but I really don't know if this is a common problem in practice.

"CPU utilization is just one facet, there's stuff like utilizing the network which can prevent the PC from entering low power states for the network card which becomes a concern. Same thing with audio playback."

Well yes, but if the user is playing music or downloading files, he probably doesn't want his device to go to sleep until those tasks are done. I wouldn't classify these things as wasteful when the application is doing what the user wants it to do.

I have to wonder whether shutting everything down in the background (win32s or not) would cause frustration that applications can't do work in the background (like downloading, teleconfrencing, music, etc). If an OS permits these 3rd party background tasks, then I don't see why win32 is worse than alternatives. If it does not, then it should be possible to suspend a win32 application while it is backgrounded.

"I think Metro, with OS managed background tasks (which have strict resource caps and policy imposed) are a great middle ground between battery efficiency and multitasking."

Not to deny this, but I'm not seeing why this excludes the win32s. Although it may seem that way, I'm not really trying to promote win32s, but I'm not convinced their depreciation was motivated by poor resource utilization. I suspect that resource utilization in desktop apps won't be much different than their metro counterparts. Now I might be all wrong, but I haven't seen anything technical to convince me otherwise.


"Thanks for the thoughtful reply."

Thank you as well!

Edited 2012-05-22 07:28 UTC

Reply Parent Score: 5

RE[4]: "19th Century Dentist"
by l3v1 on Tue 22nd May 2012 11:32 in reply to "RE[3]: "19th Century Dentist""
l3v1 Member since:
2005-07-06

CPU utilization is just one facet, there's stuff like utilizing the network which can prevent the PC from entering low power states for the network card which becomes a concern. Same thing with audio playback.

I think Metro, with OS managed background tasks (which have strict resource caps and policy imposed) are a great middle ground between battery efficiency and multitasking.


While I agree with your view, if I accept that the target demographic contains only regular content-consuming users, most of the time since Win8 appeared on the scene backers simply seem to ignore that a large number of Windows users are such developers (I mean devs writing complex software and algorithms, not webapp coders) for whom such a task management policy is neither comfortable nor useful. While currently this is not such a big problem, it could become a huge issue if the "classical" desktop eventually gets dropped in favor of walled-garden Metro-only apps.

Edited 2012-05-22 11:35 UTC

Reply Parent Score: 3

BluenoseJake Member since:
2005-08-11

Even commercial developers were shafted when microsoft broke thousands of drivers. And customers were shafted when their hardware was no longer usable


I call BS, driver developers had over 3 years to get ready for Vista, and they dropped the ball. It had nothing to do with DRM, it had everything to do with the developers. MS changed the driver model, boo hoo, they do that once in a while. They did to the graphics card manufacturers with XP, they did it to the rest with Vista.

Please, get over this fictitious DRM issue. The hardware developers just basically refused to ship drivers.

Reply Parent Score: 2

RE[4]: "19th Century Dentist"
by Alfman on Thu 24th May 2012 05:41 in reply to "RE[3]: "19th Century Dentist""
Alfman Member since:
2011-01-28

BluenoseJake,


"I call BS..."
"Please, get over this fictitious DRM issue. The hardware developers just basically refused to ship drivers."


I was one of many windows kernel devs disgruntled over the vista changes. Most drivers for windows XP actually did work *without any modification* when Vista crypto verification and DRM restrictions were circumvented, but these tools were subsequently revoked by MS. Here are a few links + excerpts that might change your mind with regards to the Vista DRM issues, bare in mind that they are from MS sources.

Thanks in advance for apologizing about the BS statement :-)


http://msdn.microsoft.com/en-us/windows/hardware/gg463417

"The Microsoft® Windows Vista™ operating system introduces a new type of process known as a protected process to enhance support for Digital Rights Management functionality in Windows Vista."



http://msdn.microsoft.com/en-us/windows/hardware/gg487431

"Drivers must have the correct content-protection signing attribute to handle some premium content. Microsoft Windows XP audio drivers work in Windows Vista, but cannot handle certain types of premium content if they do not have the correct content-protection signing attribute. If the content requires this attribute, the new protected user-mode audio (PUMA) engine enforces the requirement."



http://social.msdn.microsoft.com/forums/en-us/mediafoundationdevelo.....

"In order for you to receive the Protected Media Path compliance and robustness rules, you will need to send an email request to wmla@microsoft.com. WMLA will provide you with the licensing requirements and steps you will need to take."

"What you are describing is certainly possible in Media Foundation using Protected Media Path (PMP), however MF does not ship with such a network sink. A DTCP enabled network sink would need to be written and it would need to be signed by Microsoft in order for it to be loaded and used by MF."


http://technet.microsoft.com/en-us/library/cc748650.aspx#_Protected.....
/
"PUMA and PVP define interfaces and support specific to audio and video players, device drivers, and hardware, but PMP also relies on a general kernel mechanism introduced in Windows Vista called a protected process. Protected processes are based on the standard Windows process construct that encapsulates a running executable image, its DLLs, security context (the account under which the process is running and its security privileges), and the threads that execute code within the process, but prevent certain types of access."

"Further, to prevent compromise from within, all executable code loaded into a protected process, including its executable image and DLLs, must be either signed by Microsoft (WHQL) with a Protected Environment (PE) flag, or if it's an audio codec, signed by the developer with a DRM-signing certificate obtained from Microsoft. Because kernel-mode code can gain full access to any process, including protected processes, and 32-bit Windows allows unsigned kernel-mode code to load, the kernel provides an API for protected processes to query the 'cleanliness' of the kernel-mode environment and use the result to unlock premium content only if no unsigned code is loaded."


As a vista developer, you can get your driver signed by microsoft's chain of trust, but unless you pay/qualify for PMP certification, then your driver will taint the Vista kernel, imposing additional DRM restrictions on end user systems. When the kernel is tainted, the entire system mysteriously enters a reduced functionality state where hidef video & audio quality can be capped and ports can be disabled; the user is left wondering why things are broken. For example, this next guy came to the conclusion netflix was rejecting his new hidef monitor for hidef 420P streaming, but I actually suspect the actual cause may have been a non-PMP driver tainting the Vista kernel and consequently telling netflix not to render premium content. Even though he never uncovered this, his further comments seem to fit with this assessment.

http://davisfreeberg.com/2008/01/03/bad-copp-no-netflix/


You can blame manufacturers for not revisiting older hardware/software and spending resources to update/certify their older drivers. But MS deserves to share the blame for preventing unsigned/self signed drivers from running that were otherwise completely compatible at an API level. Also MS deserves all the blame for all DRM related driver problems.

Edited 2012-05-24 05:58 UTC

Reply Parent Score: 2