Make Metro apps more useful - ask Microsoft to let them run in the background

[George P Global Moderator]

None of the tasks you listed are something you would delegate to a Metro app. That's why there's a desktop mode. As for Hearthstone, you absolutely could pull off the scenario you cited. Messages are push notifications, which WinRT supports.

 

If you want a WinRT app that manages encoding you absolutely can do that. Just create a service that automatically encodes media items dropped in a user folder and pushes notifications.

 

The key here is the limits that are in place, developers want to be able to do more and not run into, in many cases, the arbitrary limits MS has put in place for WinRT.   If it's the future for Windows and is set to replace Win32 down the line then it'll have to be able to do more than what it can do today.

 

Battery life is fine, on a mobile device, but with Windowed store apps coming I don't see why limits put in place to help battery life should come into play.  There's no reason to not ask for more out of the WinRT API, the OS should be able to tell it's on a desktop and not a tablet and open up more APIs and reduce or remove limits. 

 

It's no surprise that developers want to be able to do more of the things they can on the desktop for WinRT apps, that's one thing they've ask for a lot at BUILD.    I don't see why we can't have more advanced/beefy WinRT apps and have to use the line "use the desktop" to make up for it's shortcomings.  

[Eric Veteran]

The key here is the limits that are in place, developers want to be able to do more and not run into, in many cases, the arbitrary limits MS has put in place for WinRT.   If it's the future for Windows and is set to replace Win32 down the line then it'll have to be able to do more than what it can do today.

 

Battery life is fine, on a mobile device, but with Windowed store apps coming I don't see why limits put in place to help battery life should come into play.  There's no reason to not ask for more out of the WinRT API, the OS should be able to tell it's on a desktop and not a tablet and open up more APIs and reduce or remove limits. 

 

It's no surprise that developers want to be able to do more of the things they can on the desktop for WinRT apps, that's one thing they've ask for a lot at BUILD.    I don't see why we can't have more advanced/beefy WinRT apps and have to use the line "use the desktop" to make up for it's shortcomings.  

 

I don't think they're planning on replacing Win32 with WinRT. It's not meant to be a kernel replacement, only a programming interface. Communicating with Win32 is already possible. How would a phone or tablet handle Handbrake? The battery would be dead in 5 minutes.

[George P Global Moderator]

I don't think they're planning on replacing Win32 with WinRT. It's not meant to be a kernel replacement, only a programming interface. Communicating with Win32 is already possible. How would a phone or tablet handle Handbrake? The battery would be dead in 5 minutes.

 

They're starting to bring more parts of Win32 and WPF into WinRT, I think the end goal is to move the main programming interface to WinRT but not anytime soon.  As far as something like Handbrake, would it be hard to have it or an app like it, toss out a message saying you're on battery power and doing this task will impact it?  Or just schedule the task for when you're on main power.

 

The point I'm making is that WinRT apps are turning into desktop apps, they're going to be windowed, they're going to gain more features/abilities, so why, in that environment, on a desktop PC, would limits set in place to keep battery usage low matter?  Whey would they even be there anyways?

 

Again, the system should be smart enough to know what type of device it's on and if it's on battery or not.   WinRT and the store in general need better apps and that means adding in more APIs and raising or reducing the limitations in place. 

[Brandon Live Veteran]

The key here is the limits that are in place, developers want to be able to do more and not run into, in many cases, the arbitrary limits MS has put in place for WinRT.   If it's the future for Windows and is set to replace Win32 down the line then it'll have to be able to do more than what it can do today.

 

There are zero arbitrary limits in place.

 

There are very heavily researched, considered, and debated restrictions in place for very good reasons.

 

Battery life is fine, on a mobile device, but with Windowed store apps coming I don't see why limits put in place to help battery life should come into play.  There's no reason to not ask for more out of the WinRT API, the OS should be able to tell it's on a desktop and not a tablet and open up more APIs and reduce or remove limits.

 

What makes you think that isn't exactly what they're going to do?

 

Also "on a desktop not a tablet" isn't a meaningful statement. How do you distinguish? Why would a "desktop" PC differ in behavior from the Surface Pro 3 I'm typing this on (with a 4k monitor and separate keyboard/mouse attached).

Other than perhaps a distinction for screen size (<10" versus >=10" or so), there's not a lot to go on. Instead it's more about scenarios. When I'm at work with my "desktop" setup attached and on AC power, I want more power and flexibility at my disposal. But that's because I'm a developer using my PC for fairly advanced tasks. When I'm not working, I'm generally in apps or the browser, and in those cases I want Windows managing everything to maximize battery life (and minimize heat, fan noise, etc) while ensuring responsiveness for the things I'm doing. When it's in my bag in Connected Standby I want it able to provide push notifications and update the lock screen and such, but I don't want anything diminishing my standby battery life.

 

It's no surprise that developers want to be able to do more of the things they can on the desktop for WinRT apps, that's one thing they've ask for a lot at BUILD.    I don't see why we can't have more advanced/beefy WinRT apps and have to use the line "use the desktop" to make up for it's shortcomings.

You have a fundamental misunderstanding of the situation. Enabling the kind of advanced scenarios you're talking about isn't a matter of flipping a switch. It takes a lot of time and thoughtful design and engineering. Decisions about how and when/where to expose greater access to developers will have repercussions for years or even decades to come. As one of the architects of WinRT I can tell you it was always the goal to over time evolve it to accommodate a broader range of scenarios. But those already well-served by the desktop/Win32/WPF world were, for obvious reasons, not the focus for the first release(s).

[Brandon Live Veteran]

I don't think they're planning on replacing Win32 with WinRT. It's not meant to be a kernel replacement, only a programming interface. Communicating with Win32 is already possible. How would a phone or tablet handle Handbrake? The battery would be dead in 5 minutes.

When people refer to Win32 they're generally referring to the API (not to be confused with Win32k.sys, for example, which is the kernel-land implementation of core Win32 APIs on top of the NT kernel).

It is a reasonable goal that existing Win32 API surface (i.e. handle-based, procedural, C-style callbacks) and all of its legacy baggage eventually be replaced with more modern, object-oriented, WinRT equivalents. Same goes for "classic COM" APIs, though those are obviously less in need of modernization than the older Win32-style APIs. An example of this is the CoreWindow and CoreDispatcher runtime classes in WinRT. They're a far cleaner and more modern mechanism than dealing with CreateWindow, HWNDs, WndProcs, and GetMesssage/PeekMessage loops.

There are cases where the WinRT version is more limited. But in many cases that's just a factor of having not gotten to that functionality yet in WinRT (which is generally a factor of prioritization and a fixed amount of time/resources for building the early releases).

[Chasethebase Reporter]

I just want to be able to run Metro apps in windowed mode. That's it.

[George P Global Moderator]

 

There are zero arbitrary limits in place.

 

There are very heavily researched, considered, and debated restrictions in place for very good reasons.

 

 

What makes you think that isn't exactly what they're going to do?

 

Also "on a desktop not a tablet" isn't a meaningful statement. How do you distinguish? Why would a "desktop" PC differ in behavior from the Surface Pro 3 I'm typing this on (with a 4k monitor and separate keyboard/mouse attached).

Other than perhaps a distinction for screen size (<10" versus >=10" or so), there's not a lot to go on. Instead it's more about scenarios. When I'm at work with my "desktop" setup attached and on AC power, I want more power and flexibility at my disposal. But that's because I'm a developer using my PC for fairly advanced tasks. When I'm not working, I'm generally in apps or the browser, and in those cases I want Windows managing everything to maximize battery life (and minimize heat, fan noise, etc) while ensuring responsiveness for the things I'm doing. When it's in my bag in Connected Standby I want it able to provide push notifications and update the lock screen and such, but I don't want anything diminishing my standby battery life.

 

You have a fundamental misunderstanding of the situation. Enabling the kind of advanced scenarios you're talking about isn't a matter of flipping a switch. It takes a lot of time and thoughtful design and engineering. Decisions about how and when/where to expose greater access to developers will have repercussions for years or even decades to come. As one of the architects of WinRT I can tell you it was always the goal to over time evolve it to accommodate a broader range of scenarios. But those already well-served by the desktop/Win32/WPF world were, for obvious reasons, not the focus for the first release(s).

 

I call them limits, you call them restrictions, I see no difference here.

 

And I don't know if that's what they're going to do, all I know is that they haven't yet.

 

And again, why are we stuck on battery life when, time and again, I keep bringing up the point about NOT being an battery power for when limits/restrictions are lifted.  It's that simple, on AC power, and it's not really hard to tell it's a desktop and not something like a SP3, screen size works but heck, how about not having touch as another factor?   Or other type of hardware inside,  chipset?  CPU, what about if there's a video card as well?    It's not like they haven't/don't run hardware scans for different things, I question how hard it would be to check.

 

I never expected adding functionality was easy or said it was easy, all I said is that if you have the goal of running Windows on everything then there's no reason to place restrictions on things meant for mobile to things that don't face the same handicaps.   

[Ian W]

Currently, a big part of the reason why you can't find many useful Metro apps is that they can't do work in the background: as soon as an app is not on screen it stops whatever it's doing.

Since Microsoft is looking for feedback on how to improve the WinRT API, vote for allowing Metro apps to execute tasks in the background. If enough people show interest, Metro apps could get a lot more useful than they are now.

I thought that they already offer the option to run in the background?

[Torolol]

i see 'useful purposes' when it can still receives key-presses when not in focus ...

[Brandon Live Veteran]

I call them limits, you call them restrictions, I see no difference here.

You called them arbitrary. They are not arbitrary.

And again, why are we stuck on battery life when, time and again, I keep bringing up the point about NOT being an battery power for when limits/restrictions are lifted.

I'm not sure what this is in response to. I already explained that the system lifts many restrictions and makes more background time/resources available when on AC power.

It's that simple, on AC power, and it's not really hard to tell it's a desktop and not something like a SP3, screen size works but heck, how about not having touch as another factor?   Or other type of hardware inside,  chipset?  CPU, what about if there's a video card as well?    It's not like they haven't/don't run hardware scans for different things, I question how hard it would be to check.

I don't know what you're getting at here either. Lots of desktops have touch monitors. Many all-in-ones use the same exact chips you find in laptops. Nothing you mentioned is a useful differentiator, and my real point was why would you ever want them to work differently?

 

I never expected adding functionality was easy or said it was easy, all I said is that if you have the goal of running Windows on everything then there's no reason to place restrictions on things meant for mobile to things that don't face the same handicaps.

Most PCs are mobile these days, so clearly that's going to be a point of focus. But the things we're talking about aren't just about battery life. The user experience is far better when the system is able to manage applications more tightly. Having a "restricted by default" model with brokered contracts for escaping the restrictions makes for a more robust system. Going forward, more contracts will be made available, and more exceptions can be added where a strong enough case can be made. They need to be careful and thoughtful and deliberate in doing this, as a misstep can do significant harm to the integrity of the system (and user confidence in it).