Linked by snydeq on Tue 4th Jun 2013 01:46 UTC
Windows First looks at Windows 'Blue' have revealed an upgrade composed of cosmetic fixes, suggesting that Microsoft may be blowing its chance to turn the tide on Windows 8 blow back, and make good on its promise to truly 'rethink' Windows 8 with the release of Windows Blue. As a result, InfoWorld has issued an open letter to Microsoft to consider Windows 'Red' -- what InfoWorld is calling a 'serious plan' to fix the flaws of Windows 8, one that could rescue Microsoft's currently flagging promise to deliver a modern computing experience on both PCs and tablets.
Thread beginning with comment 563596
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: I don't think so
by Nelson on Tue 4th Jun 2013 14:06 UTC in reply to "RE: I don't think so"
Nelson
Member since:
2005-11-29


I don't think many disagree that the old Win32 API is a pain to work with. However I am not really sure the popular opinion of rewriting the framework in one go is the correct solution. Joel on software has a nice article explaining why complete rewrites are almost always the wrong answer.


They certainly didn't rewrite the framework in one go. WinRT is in its infancy compared to Win32. They have a long way to go.


Microsoft has been replacing many of the old win32 APIs with COM APIs over the last ten years, and now they seem to continue the trend with WinRT.

The problem with Modern is that any UI in any older app has be rewritten completely. A task sometimes so big that Apple had to make an exception for Finder for 64 bit (still carbon based), and Microsoft the same with Office for Windows RT tablets.


I agree that it is a problem for very large apps, but I don't think Microsoft expects those to be ported over particularly quickly.

Windows 8 includes the Desktop because Win32 will take years, possibly a decade to phase out. Windows RT is Microsoft's clean break that they're hoping accelerates this transition.


Microsoft also didn't help on the matter by only supporting the WinRT runtime on Windows 8. That makes any new UI not work on older versions, forcing developers to now maintain two UI codebases for years. Same problem with D3D10 and Vista back in the day.


This is partially going to be offset by the larger addressable markets that tablets and hybrids enable.

The Windows Store is now ramping up quite nicely in terms of app catalog selection and downloads, revenues are also steadily increasing MoM for me at least.

So its definitely an investment that you make in being an early adopter, if you don't want to make that bet you don't have to, but this is the way forward and will only get better with time.


As a user, my issue with Windows 8 is simply that I do not want a mobile UI on my 30" monitor. And 8.1 shows no sign that Microsoft "gets" why using the same UI for tablets and desktop wont work. And this has nothing to do with what framework renders the UI.


Actually, Windows 8.1 allows a larger variety of snap states (especially on large, high resolution monitors where I think you can snap 4 or more apps at once). There is definitely some better multitasking support there.

There is also better DPI scaling on the Desktop side of things, the ability to launch multiple instances of the same Metro App (think two snapped IE tabs at once), etc.

So it is clear they are doing some work to enable a better work flow for people that are so inclined. Personally it's never been that big of an issue, I don't use Metro apps like that yet, so when I need heavy duty multitasking I use my heavy duty apps on the Desktop.

Reply Parent Score: 3

RE[3]: I don't think so
by dpJudas on Tue 4th Jun 2013 14:50 in reply to "RE[2]: I don't think so"
dpJudas Member since:
2009-12-10

They certainly didn't rewrite the framework in one go. WinRT is in its infancy compared to Win32. They have a long way to go.


Correct, but the reason I do not consider WinRT a (full) rewrite is because the most important earlier Win32 APIs are still available. This means porting can be done gradually where newer code can use the new better API, while older code can coexist with it.

That WinRT isn't supported in any form (i.e. not even the System namespace in C++/CX) on Vista and Windows 7 somewhat ruins the possibility to take advantage of their new APIs until Windows 8+ becomes the dominant version of Windows.

I agree that it is a problem for very large apps, but I don't think Microsoft expects those to be ported over particularly


That unfortuantely becomes a problem for Modern because apps from the "hwnd" world does not properly coexist with Modern desktop apps. The poor user experience switching between them is probably Windows 8's biggest problem.

Actually, Windows 8.1 allows a larger variety of snap states (especially on large, high resolution monitors where I think you can snap 4 or more apps at once). There is definitely some better multitasking support there.


What I do not see them address is the key problem: that if a user has 50% win32 apps, and 50% modern apps, then the user experience will be very poor. And it will stay this way for a decade unless they find a proper way to address it. Carbon to Cocoa took this long with slackers like Adobe. ;)

Reply Parent Score: 2

RE[4]: I don't think so
by Nelson on Tue 4th Jun 2013 15:41 in reply to "RE[3]: I don't think so"
Nelson Member since:
2005-11-29


Correct, but the reason I do not consider WinRT a (full) rewrite is because the most important earlier Win32 APIs are still available. This means porting can be done gradually where newer code can use the new better API, while older code can coexist with it.


I'm not particularly excited about the existing Win32 support in WinRT. At best it has some nice things, but at worse it's just a temporary shim until they write proper WinRT APIs.

If you have a reasonably complicated code base, the chances of you running into a roadblock with a restricted API is pretty high, especially given that most people used and abused Win32 for ways outside of what Microsoft thought.

Do any IPC and you're SOL on WinRT, any kind of dynamic execution is forbidden, threading stuff is a non starter, etc. Its pretty annoying to be honest.


That WinRT isn't supported in any form (i.e. not even the System namespace in C++/CX) on Vista and Windows 7 somewhat ruins the possibility to take advantage of their new APIs until Windows 8+ becomes the dominant version of Windows.


My problem with the back porting efforts are the architectural compromises that must be made. I still have nightmares about the absolute BS we had to deal with because Microsoft got pressured into backporting WPF to Windows XP. Layered Window performance fell off of a cliff, a bunch of things jumped into software rendering, ugh.

I just don't know if anyone would bother if it was just the non-UI bits backported. Its like, why should I use that vs the Win32 counterpart?

WinRT is also much more than the API/ABI its the entire catalog apparatus which includes with it the sandboxed RuntimeBroker and all of the changes to Windows that it brought.

I saw a Channel9 video about the architectural changes they had to make to deep subsystems to enable the app container model and it made my head spin.

Sometimes when you're on a tight release schedule its very hard to justify back porting something for limited impact, at best they'd port some of the Desktop capable WinRT APIs, which really isn't a lot.


That unfortuantely becomes a problem for Modern because apps from the "hwnd" world does not properly coexist with Modern desktop apps. The poor user experience switching between them is probably Windows 8's biggest problem.


Right, they have a bunch of work to do. You can see where the trend is going though, and its a multi-year thing they have.

Big suites like Adobe, IE, Office, etc. will take a while purely because the code bases are so incredibly massive and in some cases, WinRT is too immature.

However there isn't that big of a gap before large applications can be brought into the fold -- look at Visual Studio. Its a mixed mode C++/CLI app with a WPF front end. Thats not too much of a far shot from WinRT.

I can see maybe in the next major client release the WinRT platform maturing to the point where medium to large scale apps are possible.

In the meantime it will be a problem for people living in both worlds, but for people who purchase something like a Surface RT, a lot of their needs are suited by Metro apps which are getting increasingly better.

For the rest of us there's the Desktop, and with Blue its been made easier to live in both worlds.



What I do not see them address is the key problem: that if a user has 50% win32 apps, and 50% modern apps, then the user experience will be very poor. And it will stay this way for a decade unless they find a proper way to address it. Carbon to Cocoa took this long with slackers like Adobe. ;)


They can do a number of things to ease the transition for sure, some of which they're not currently doing. I think given feedback they'll continue to make more changes into post-Blue releases.

I'm just glad we're getting these changes yearly instead of every three years.

Reply Parent Score: 3

RE[3]: I don't think so
by Lurking_Grue on Fri 7th Jun 2013 16:25 in reply to "RE[2]: I don't think so"
Lurking_Grue Member since:
2013-03-15

Call me when snap states can overlap and act like windows.

Oh and give me some indication of what is running.... Say some sort of bar that can give me notifications and show the running software.

Even better! It could have the time in the corner.

Reply Parent Score: 1