More GDR3 Features

[Mike Gibson]

You can't imagine them because they don't exist.

I guess I missed the /s tag. Just wait for a little while and you'll hear all about it. The server folks want Metro gone from their product. Businesses don't want to have to retrain employees (big $$$), so that puts pressure on the Office group.

RT is failing badly because it isn't on good hardware at decent price points.

WinRT/Metro is failing because people don't want it on their laptops/desktops. And people don't want a WinRT tablet because it isn't really "Windows" and can't run any of their existing programs. However, these are relatively short term problems that MSFT could tolerate.

Developers stay away because they'd rather invest their limited dev time on platforms with established installed bases. Why would a dev completely rewrite their Win32 apps for a failed platform? This is *the* killer ... a long term problem that will end up sinking MSFT, IMHO. All they needed to do was add a scalable UI to replace USER and GDI but, no, they had to create an entirely new and crippled API. Why create an entirely new set of file access APIs (that are 250X slower than Win32), entirely new HTTP client APIs (probably the fifth attempt, btw), entirely new Socket APIs, etc., etc.??? They did all that redundant work yet forgot to include a D3D interface for those poor C# game writers! What were they thinking?

 

[a5cent]

Notification system isn't going to make the cut, it's too late.

I'm not convinced that wpdang's reporting is accurate in this regard. Maybe it is, maybe it isn't.

If the NC (notification center) is being back ported to GDR3, then that points to it being more of an "add on" to the system (i.e. app with live tile) rather than a deeply integrated feature with a lot of explicit API support etc.

 

[a5cent]

Developers stay away because they'd rather invest their limited dev time on platforms with established installed bases. Why would a dev completely rewrite their Win32 apps for a failed platform? This is *the* killer ... a long term problem that will end up sinking MSFT, IMHO.

The idea is to have metro find its way onto every Windows computer in the world by hitching a ride with the Windows Desktop OS. That virtually guarantees a huge future install base.

Developers are expected to rewrite their apps due to the monetization opportunities offered through the app store.

Success isn't guaranteed, but they have a chance, provided the metro environment can be improved aesthetically and in utility. As it is now it just won't ever be popular.

 

[Mike Gibson]

The idea is to have metro find its way onto every Windows computer in the world by hitching a ride with the Windows Desktop OS. That virtually guarantees a huge future install base.

Sounds great in theory and I'm sure the MSFT execs had $$$ in their eyes ... but there appears to be little actual demand for WinRT apps. People want desktop apps in Windows, not crippled WinRT apps.

Developers are expected to rewrite their apps due to the monetization opportunities offered through the app store.

And MSFT had big $$$ in their eyes thinking about taking a 20-30% cut of those developers sales. Again, great in theory from their viewpoint. They looked at all the billions of $$$ of Windows Desktop apps being sold and realized they weren't getting a dime from them. Then they looked at AAPL and saw them raking in billions from the AppStore developers.

I sell my Desktop apps through Fastspring.com. They take around 6%.

Success isn't guaranteed, but they have a chance, provided the metro environment can be improved aesthetically and in utility. As it is now it just won't ever be popular.

The funny thing is that I think that the Metro UI is excellent on a small screen, like a phone or tablet. It fails on the Desktop since it's full screen and *very* limited in functionality (not to mention the horrible performance). Note that I'm referring to Metro as a UI concept, not the WinRT API (which is a disaster created to force devs to go through the Windows Store). As I mentioned earlier, all MSFT had to do was add a scalable UI layer to the existing Win32 APIs. How many billions of $$$ and goodwill from users do they have to lose before they realize their mistake?

 

[Mike Gibson]

... It's API set is far superior in usability and ease of use to the desktop. ...

You realize that WinRT is just another layer on top of the Win32 Desktop, right? For example, XMLHTTPRequest2 uses the WinInet APIs, the storage APIs use the Win32 file APIs (through the file broker, which is 250X slower than the Win32 APIs themselves -- quite an accomplishment from the WinRT team!), etc. Windows has/had the best multithreading support of any major OS ... the WinRT geniuses decided to ignore it and switch to a terribly slow, glorified callback hack (Async) which solves NONE of the problems involved in writing quality multithreading code. The Async file enumeration scheme alone results in one order of magnitude of performance loss. The File Broker is 25X slower on top of the Async crap. What does this mean in real life? If I want to enumerate the names of 1000 photos my daughter took at the Taylor Swift concert, Win32 completes the task in 15-30 milliseconds (essentially instantaneously). WinRT takes 3.75-7.50 seconds. That's just to enumerate the files, imagine actually doing something with them. I sent test code to the escalation engineer illustrating the problem. They blame everything on the FB.

WinRT is a terrible API and system. A horrible design and a terrible implementation. Look, I worked on a major OS years ago. It's not easy and there are many constraints that outsiders usually don't know. But that is completely different from shooting yourself in the foot like MSFT did with WinRT. It's just baffling to me.

 

[Robert Carpenter]

You realize that WinRT is just another layer on top of the Win32 Desktop, right? For example, XMLHTTPRequest2 uses the WinInet APIs, the storage APIs use the Win32 file APIs (through the file broker, which is 250X slower than the Win32 APIs themselves -- quite an accomplishment from the WinRT team!), etc. Windows has/had the best multithreading support of any major OS ... the WinRT geniuses decided to ignore it and switch to a terribly slow, glorified callback hack (Async) which solves NONE of the problems involved in writing quality multithreading code. The Async file enumeration scheme alone results in one order of magnitude of performance loss. The File Broker is 25X slower on top of the Async crap. What does this mean in real life? If I want to enumerate the names of 1000 photos my daughter took at the Taylor Swift concert, Win32 completes the task in 15-30 milliseconds (essentially instantaneously). WinRT takes 3.75-7.50 seconds. That's just to enumerate the files, imagine actually doing something with them. I sent test code to the escalation engineer illustrating the problem. They blame everything on the FB.

WinRT is a terrible API and system. A horrible design and a terrible implementation. Look, I worked on a major OS years ago. It's not easy and there are many constraints that outsiders usually don't know. But that is completely different from shooting yourself in the foot like MSFT did with WinRT. It's just baffling to me.

Good thing it's designed well. Because guess what? EVERY SINGLE THING you just mentioned can be improved/fixed without you having to worry about ANYTHING. That's the whole point of layers....

Win32 might be an amaing API, but is has HORRIBLE maintainability. Maintainability is something that has become a more important aspect of an applications life cycle.

Have you tested the File Broker in Windows 8.1? Because every single problem you just mentioned could be fixed. You might be rambling about pointless topics.

Also, ASYNC callback was implemented for GUI performance only. You know how complicated it was to program a Windows Forms application and implement multiple GUI output updated without the entire windows freezing? Sure, it's probably easy for you to accomplish now, but it was something you have to spend time learning.



All you seem to be doing is referencing the past. Open your eyes, and start referencing the possibilities that will come in the future. WinRT is designed with the future in mind. Win32 was not prepared for it and that's why the maintainability of it SUCKS.

So far, all I see in you is an old man who is scared of becoming obsolete. I'm sorry, but your arguments are silly and pathetic.

 

[Mike Gibson]

Good thing it's designed well. Because guess what? EVERY SINGLE THING you just mentioned can be improved/fixed without you having to worry about ANYTHING. That's the whole point of layers....

There's no fixing the Async pattern, it's baked into the API and application design.

Win32 might be an amaing API, but is has HORRIBLE maintainability. Maintainability is something that has become a more important aspect of an applications life cycle.

Win32 isn't an "amazing" API. It does its job and ,most importantly, is battle-tested. MSFT can add whatever framework they want on top for C#/VB/JS devs but they shouldn't have roped off the existing Win32 API from C++ devs (like they did with WinInet even though it's used by XHR2 and the other WinRT http client APIs).

Also, ASYNC callback was implemented for GUI performance only. You know how complicated it was to program a Windows Forms application and implement multiple GUI output updated without the entire windows freezing? Sure, it's probably easy for you to accomplish now, but it was something you have to spend time learning.

Really? All the Async mess doesn't prevent MS's own Solitaire app from stuttering and lagging on mouse clicks on my Samsung Series 7 Slate. Seems to be getting worse with each update of Solitaire. It also revs up my Slate's fan when doing nothing. I can run my "old man" Win32 app that performs complex GPU operations on that same device without the fan revving or the UI stuttering. My point is that it is not the API that controls whether the UI stutters or not, it's the application code.

So far, all I see in you is an old man who is scared of becoming obsolete. I'm sorry, but your arguments are silly and pathetic.

Stop it, you're killing me! You might be surprised to learn that I have an app in the WP8 store right now. It uses all the latest WinPRT tricks: C# and XAML for the UI along with a C++ and Direct3D for the DrawingSurface control (oh, and the Motion, Geolocator, SkyDrive/Live, etc APIs).

 

[a5cent]

The idea is to have metro find its way onto every Windows computer in the world by hitching a ride with the Windows Desktop OS. That virtually guarantees a huge future install base.

Sounds great in theory and I'm sure the MSFT execs had $$$ in their eyes ... but there appears to be little actual demand for WinRT apps. People want desktop apps in Windows, not crippled WinRT apps.

As long as you concede that the theory isn't completely divorced from potential reality, then we are in agreement. I didn't say making that a reality would be easy.

I certainly would admit that Microsoft could be doing a better job of it. I do think their general direction and strategy are spot on though.

I would love a shot at that CEO spot. ;-)

 

[lippidp]

If they add seperate volume controls for different apps or audio sources I sincerely hope they make it optional. After using so many Android and iOS devices, it's very refreshing to have a volume control that predictably controls the volume of my phone.

Edit: In fact, through what official channel can I provide this feedback to Microsoft?

I've never understood this complaint, either. The volume controls are suitable to me. If you're on the phone, you can change the volume of the phone. If you're not on the phone, you change the volume of everything else. I've always liked this. Then again, I have no use for a notification center or Instagram and prefer keyboards to soft keyboards, so I don't fit in with the crowd these days I suppose. I like it that way.

 

[crav4speed]

I've never understood this complaint, either. The volume controls are suitable to me. If you're on the phone, you can change the volume of the phone. If you're not on the phone, you change the volume of everything else. I've always liked this. Then again, I have no use for a notification center or Instagram and prefer keyboards to soft keyboards, so I don't fit in with the crowd these days I suppose. I like it that way.

I do agree the volume control is nice and simple compared to the other OS's. The only other separate volume control I believe is truly needed is for the ringer. I put my phone in my back pants pocket and sometimes it's very hard to hear especially when there's loud sound or I'm outdoors. Windows Mobile had this exact setup and I wish they'd bring it back.

1) System Volume
2) Ringer Volume
3) In-call volume

 

[smoledman]

Quick Settings = Android Quick Toggles. I love this feature!

The problem is if GDR3 is feature-packed what does that mean for "Blue"?

 

[envio]

I worry that if Microsoft try and pack more into GDR3, it's going to delay WP8.1 even further. Some people are still waiting for GDR2 which has been tortuously slow from a testing and roll-out perspective.

If Microsoft are still trying to decide (and bake-in) back-ported features from 8.1 into GDR3 if the rumours are correct, then we're not likely to see it this side of Christmas and that'll have a knock-on effect for 8.1, for sure. This feels like a slow-motion train wreck, I just don't understand how it has come to this - that this was the plan all along?!

There seems to be very little cohesion between MS, the OEMs and the carriers and not much has changed since the launch of WP7. If anything, it's gotten slightly worse as the ecosystem stakes have raised. Is it lack of poeple, lack of/wrong focus and priorities, lack of leadership, I just don't know.

 

[jlzimmerman]

I mean if they are able to implement the top 15 requested features
Feature Suggestions: Top (33417 ideas) I would be super happy.

Indeed, even the top 10. I must be an anomaly though, because not once in my 4 or 5 years of smartphone ownership have I had to need or desire to use rotation lock.

 

[X0LARIUM]

The third or the fourth guy commented "Photoshop" and I think I agree with him..

 

[tk-093]

Indeed, even the top 10. I must be an anomaly though, because not once in my 4 or 5 years of smartphone ownership have I had to need or desire to use rotation lock.

you're not the only one. I don't think I ever used it either, and I use the heck out of an iPad (well did before I got a surface)

 

[SanjitVignesh]

My take on GDR3 is that MS has heard our voices and changed their roadmap for WP. I think 8.1 was an intermediate step between 8 and a merger with RT that was to have lots of added features as well as smoothing the way for that merger. They decided to scrap 8.1, put the majority of the most requested features into GDR3, not waste time coding 8.1 and jumped straight to 9 that will merge with Windows RT and bring in a common app store across tablet and mobile. Thus the delay of the "next big" release of WP to Q2 or later.

Now, if this were true, I'd say, "Hats off, Microsoft!!!".

 

[Bob Shiska]

I worry that if Microsoft try and pack more into GDR3, it's going to delay WP8.1 even further. Some people are still waiting for GDR2 which has been tortuously slow from a testing and roll-out perspective.

If Microsoft are still trying to decide (and bake-in) back-ported features from 8.1 into GDR3 if the rumours are correct, then we're not likely to see it this side of Christmas and that'll have a knock-on effect for 8.1, for sure. This feels like a slow-motion train wreck, I just don't understand how it has come to this - that this was the plan all along?!

There seems to be very little cohesion between MS, the OEMs and the carriers and not much has changed since the launch of WP7. If anything, it's gotten slightly worse as the ecosystem stakes have raised. Is it lack of poeple, lack of/wrong focus and priorities, lack of leadership, I just don't know.

I think their main ground rule for back porting is that it has to be done, with no impact to the stuff that was in the original scope to GDR3, by the GDR3 RTM date. So if it slips three days, they can rip it out and still go forward with GDR3 on schedule. GDR3 is coming in about a month (max) ahead of the original WP8.1 launch date, so it makes sense that some of the features that were being developed for that would be ready by now. There's no way they'll slip GDR3 because of rotation lock.

 

[Bob Shiska]

Now, if this were true, I'd say, "Hats off, Microsoft!!!".

I'd be upset, because it would mean another 9 months without a bunch of features that are critical to the growth of WP. Lack of VPN support has been huge since the launch of WP7, they can't have afforded to put it off as long as they have, another 9 months would be crushing. That's just one thing. There's no way they're skipping WP8.1. What we're seeing being brought up to GDR3 is the easy stuff that doesn't go that deep into the OS.

 

[Bob Shiska]

Quick Settings = Android Quick Toggles. I love this feature!

The problem is if GDR3 is feature-packed what does that mean for "Blue"?

This isn't feature packed, this is a few things that sit on top of the OS. Nothing that goes that deep into the OS functionality or impacts how different parts of the phone interact with each other is coming up. You'll notice nothing about a notification center, VPN, system apps, etc. They're just throwing a cherry on top of the Snapdragon 600/800 support and 1080P support.

 

[grizzlyaddams]

I want my volume controls left alone.