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.
Permalink for comment 563659
To read all comments associated with this story, please click here.
RE[5]: I don't think so
by dpJudas on Tue 4th Jun 2013 19:38 UTC in reply to "RE[4]: I don't think so"
dpJudas
Member since:
2009-12-10

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.

Yes, even simple things like a LoadLibrary call is blocked. But once again I feel that it falls back on Microsoft, since if the porting work gets too extensive most companies decides to simply not do it until absolutely forced to. Microsoft cannot get a nice new consistent user interface if all the classic productivity apps keep their old UI.

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.

With C++/CX the problem is that I cannot even instantiate a simple System.String. This part of their framework doesn't really require anything unique to Windows 8 and would demand no special compromises.

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?

Mostly to support calling into Windows 8 APIs when they are available, and fallback to earlier code when they are not. Then slowly over the years retire old code as Windows versions get too old.

Now you can only do such a thing with defines and build configurations and different executables for desktop Windows 7 and Windows 8.

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.

Visual Studio still relies (although increasingly less so) on old Win32/hwnd parts that they are slowly rewriting as they revisit them for new updates anyway. This won't work for Windows 8 as you cannot have any hwnd parts in a Modern app.

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.

I agree, they could fix these problems if they are truly aware of them and feel they are important. Maybe they are even doing it as we speak. Personally I think they will continue to see little interest in porting applications to WinRT until they are resolved though.

Reply Parent Score: 2