Windows 8 - Unintuitivity at its best

[VivM]

Apple declared Mac OS 9 dead about a year after OS X' release. Classic app support was part of OS X, but only though the means of emulation (similar to Windows XP mode in Windows 7 appearance-wise). This meant hardly any integration between Classic apps and OS X whatsoever, plus a noticeable performance hit. They also came up with Carbon which allowed apps to be ported over more easily from Mac OS 9 to OS X. The company also actively helped developers. A native Microsoft Office version for OS X was released after about half a year. The first native Adobe Photoshop version after about a year.

Over 90% of all PCs world-wide run Microsoft Windows. I'd say Microsoft has more than enough leverage. Instead of letting the desktop linger indefinitely they could set a clear deadline: Be sure that by 2014 your apps will be Metro.

But you're missing one big difference: OS X provided huge reliability/stability advantages that their customers were eager to adopt. Classic Mac OS was built on a creaky, 8MHz CPU/128K of RAM, 1984esque architecture that did not scale well to a modern, multitasking, Internet-connected world. And as Quark found out the hard way, if you were slow to move to OS X, your competition (Adobe) might steal a lot of your market share. (And, of course, Apple stopped selling hardware that would run OS 9, then OS 9 software, etc., though they DID have to delay that by a number of months due to customer outcry)

What problem does Metro solve, other than MS' poor tablet market share?

If you have a loyal Adobe/Autodesk customer happily getting their work done in Win7, what motivation is MS offering them to a) go to Win8/9, and b) call up their Autodesk rep and say "we pay you guys $250K/year in licensing fees, we don't want to be stuck using this Win7/desktop s**t. PORT YOUR DAMN SOFTWARE YESTERDAY."? As far as I can tell, the answer is none. But there is huge motivation to call up the Dell rep and say 'keep selling us Win7 hardware please'.

Where are you getting that from? People were forced to upgrade to OS X when they bought a new Mac. Within two years not a single new Mac could natively boot Mac OS 9 anymore.

And that date was extended due to customer outcry. Apple 'relaunched' an older Power Mac G4 configuration to accommodate customers who needed new hardware and couldn't migrate to OS X.

And the Classic environment was still supported until, oh, 10.5? So that was a further few years in which the old stuff could 'run' as customers gradually migrated to OS X apps.

More importantly, Classic Mac OS -> OS X was a technological shift, not a paradigm shift. Same as, say, Win3.1 -> Win32. Everybody who made software for 16-bit Windows eventually moved to 32-bit Windows; as soon as their customers had dropped 3.1, there was no reason not to. Metro is not a technological shift, it is a paradigm shift from keyboard/mouse windowed interfaces to full-screen, windowless, touch-oriented interfaces.

[phailyoor]

More importantly, Classic Mac OS -> OS X was a technological shift, not a paradigm shift. Same as, say, Win3.1 -> Win32. Everybody who made software for 16-bit Windows eventually moved to 32-bit Windows; as soon as their customers had dropped 3.1, there was no reason not to. Metro is not a technological shift, it is a paradigm shift from keyboard/mouse windowed interfaces to full-screen, windowless, touch-oriented interfaces.

Right. OSX was essentially better than OS9 in every way except legacy app compatibility. If your programs were available and you had the cash, there was no reason not to upgrade. There happen to be a lot of reasons not to switch to metro.

[.Neo]

But you're missing one big difference: OS X provided huge reliability/stability advantages that their customers were eager to adopt. Classic Mac OS was built on a creaky, 8MHz CPU/128K of RAM, 1984esque architecture that did not scale well to a modern, multitasking, Internet-connected world. And as Quark found out the hard way, if you were slow to move to OS X, your competition (Adobe) might steal a lot of your market share. (And, of course, Apple stopped selling hardware that would run OS 9, then OS 9 software, etc., though they DID have to delay that by a number of months due to customer outcry)

Not sure where you were during the transition period. OS X was insanely slow, severely lacking features and severely lacking app support. Most people I knew, including myself, would dual boot OS X - Mac OS 9. Spending most time in Mac OS 9. OS X was more of a gimmick. Serious usage of OS X didn't happen until around OS X Puma - Jaguar.

And that date was extended due to customer outcry. Apple 'relaunched' an older Power Mac G4 configuration to accommodate customers who needed new hardware and couldn't migrate to OS X.

And the Classic environment was still supported until, oh, 10.5? So that was a further few years in which the old stuff could 'run' as customers gradually migrated to OS X apps.

More importantly, Classic Mac OS -> OS X was a technological shift, not a paradigm shift. Same as, say, Win3.1 -> Win32. Everybody who made software for 16-bit Windows eventually moved to 32-bit Windows; as soon as their customers had dropped 3.1, there was no reason not to. Metro is not a technological shift, it is a paradigm shift from keyboard/mouse windowed interfaces to full-screen, windowless, touch-oriented interfaces.

By 2003 not a single new Mac could natively run Mac OS 9. It was over and done with. OS X Tiger for PPC was the last release to support Classic. Hardly anyone still used it by then though.

Let's not turn this into a OS X was more important than Metro thing argument though, because I completely agree with you there. Metro is less relevant. I'm just saying that if Microsoft really wants to push Metro there are better ways to go about it. Keeping the desktop alive won't motivate any major app developers to rewrite their software, something Calum does expect to happen.

[Ottawa Gamerz]

windows 8 people there must be some thing else to talk about

[PGHammer]

Developing functional apps takes time. He has to switch to Desktop in order to use Microsoft Office because there isn't currently a "Metro" version of Microsoft Office. I'm pretty confident one of the reasons for that is because they haven't had time to create a "Metro" version of Microsoft Office that is either just as functional as the Desktop version or nearly as functional as it, and I can think of a few reasons as to why they would have decided against releasing a much-less-functional version.

I don't think you can reasonably slam the new experience for being "less functional," in terms of what developers are capable of producing, until developers have had time to develop versions of their apps that are just as functional as the current Desktop versions. It's possible that Photoshop could be created for the new experience, but many people are assuming that is impossible. I say, wait and see exactly how powerful the new platform could be for developers to develop functional and useful productivity apps. I may be wrong, but I feel it's wrong to assume when none of us know for sure.

This!

For those of us that have been around the block a few times (especially those of us that go back to the early days of Win32) have we forgotten the early lack of Win32 applications and games? (I was a beta-tester of Windows 95, and went through the entire chain, and migrated fully to the RTM; however, other than Microsoft Office and a few games, over half my Win32 applications were either 1.0 applications, or came from Windows NT.) Most WinRT apps (from most developers - not just Microsoft) are either ports from other OSes - such as Android or iOS - or are clearly aimed at screens with lower resolutions than a typical *notebook* - not a desktop. Have I cut them any slack? No - in fact, I've whacked them quite hard for tha *crime*. In other words, right now, WinRT is no better than the early days of Win32. (It's also why I wouldn't touch WindowsRT with a ten-foot fork.)

Win32 backward compatibility, on the other hand - despite there no longer being a Start menu - is more than solid; it's the best I have EVER experienced migrating from an earlier version of Windows - period. (Not even the critics of Windows 8 are finding fault there, which may actually be part of the problem; the critics can't blame the lack of a Start menu for application breakage for the rather obvious reason that there isn't any of that (application breakage, that is). The UI/UX changes radically, yet Win32 applications don't even bend, let alone break?)

That same supremely-solid backward compatibility is why I'm using Windows 8 today - not the WinRT API or even the lack of a Start menu.

One thing I kept firmly in mind (and something I think a lot of Windows 8's critics may have let slip) is that, first and foremost, Windows 8 is still, despite the addition of the WinRT API, an upgrade/replacement for Windows 7. The base hardware for Windows 8 is still not merely similar hardware to what Windows 7 has been running on for the past year, but the same hardware. Windows 8 is meant to run the same (pretty much) Win32 applications that Windows 7 has for the past year. What's happening with the WinRT API matters more to users of WindowsRT than Windows 8, for the quite-understandable reason that WindowsRT users don't have Win32 to fall back to - the Win32 API isn't supported on WindowsRT. The WinRT API, and even WindowsRT itself, is basically icing - it's a sideshow, albeit an important one in the short and medium run. The *cake* of Windows 8 is, quite honestly, no different than that of Windows 7, generally -

1. The UI/UX.

2. Backward compatibility - and especially with Win32 and .NET.

Yes - the UI/UX is radically different; nobody is disputing that. However, said UI/UX being so radically different matters not at all to applications - not even Win32 applications. Users, yes; applications, not at all.

That is also why I call the UI/UX differences - despite their vastness - a quibble.

If it affected how applications themselves worked, it would be more than a quibble. That's the point, though - it doesn't.

However, the very reality that it DOES make so little difference (as in none) to how applications themselves work makes it (despite the insistence from critics otherwise) a crutch. (Most of the critics - albeit grudgingly - will admit that; however, it's like pulling teeth to get that much.)

And that's the real issue with Windows 8; we, as users, have had this crutch (the Start menu) to rely on for nearly two decades; now, we find out that we not only don't need it, but we may not have needed it for a while - if at all.

I will admit - that is a very bitter "horse-pill" to swallow.

I can even understand the anger at Microsoft - after all, they originally provided said crutch.

From what I see, we, as users, can either remain on the Royal Barge on the Egyptian River, calling out the strokes to the Oarsmen, or we treat this discovery as a SIDO situation (SIDO = Screw It/Drive On).

I am doing the latter, leaving the crutch behind, and am driving on.

[VivM]

By 2003 not a single new Mac could natively run Mac OS 9.

Yet Apple launched an OS 9-capable Power Mac G4 config in June 2003. http://www.lowendmac.com/ppc/mdd-power-mac-g4-1.25-ghz.html .

EveryMac (http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_1.25_mdd.html) says it was discontinued in June 2004. So that's an extra year that they had to continue providing one OS 9-booting machine for people with legacy workflows...

[PGHammer]

The problem is that you are insisting that they have to remain separated. The question begs - why?

While it's not exactly cheap *today* to add touch support to desktop PCs, it's doable, and has been in fact doable since Windows 7 went RTM. Every month, the cost to do so goes down. (That sort of thing tends to happen as technology matures.)

Worse, you are also apparently insisting that Google is capable of doing something that neither Microsoft OR Apple are capable of - creating a multiple-input UX. Android is multi-input - it supports touch AND keyboards AND mice.

Win32 predates the birth of the touch-screen input method - adding support for it to Win32 may well be the technical limitation that Microsoft has spoken of; hence the need for a new API to support a new input method.

Multiple APIs aren't even new in Windows; most versions of Windows have, in fact, supported multiple APIs at once.

Even OS X (let alone iOS) is quite capable of supporting multiple APIs at once.

The API *stratification* is artificially created in the case of iOS and OS X - Apple is worried to an extent that iOS will steal sales from the low end of OS X.

Google has no such concerns for the understandable reason that there is no reason why Android can't go after the low end of Windows, iOS, *and* OS X with devices capable of using any UX that Android supports - which is all of them - even at the same time.

You are basically insisting that Windows' multiple-API approach - the same approach that it has used over the past two decades - is no longer workable.

Again, the question begs - why isn't it?

Nobody is saying - not myself, not most of us that are running Windows 8 today, and *especially* not Dot Matrix - that Win32 has no place.

What we HAVE been saying is that the Start menu *itself* is broken - not that the Win32 API is broken.

Windows 8's Win32 capability - despite the lack of a Start menu - is just fine; not even most of you are saying otherwise.

It is the users that are Start menu-dependent. The Win32 API compatibility in Windows 8 is not.

While the Start menu is - and has been for those same two decades - the most obvious sign of the Win32 API, the API itself doesn't depend on it.

In fact, the API predates the Start menu - remember, Windows NT 3.x didn't have a Start menu. (It used the Windows 3.x UI and UX, despite the Win32 API.)

In other words, there is NO connection between the API and the UX. None whatever.

That is why the Start menu's excision didn't bend, let alone break, Win32 application compatibility in Windows 8.

User compatibility is not the same as application/hardware/software compatibility - no less than Windows 7 is the biggest example of that. It had a far smaller UI/UX change than Windows 8 - yet it had far greater application breakage compared to Vista or XP, let alone Windows 8.

And let's tackle .NET - specifically .NET 3.0 and later. It practically took a grav-jack to pry developers into using it. Yet once they have, they have been able to create solid applications - and games - that use it. Even more surprising, .NET is cross-platform - .NET is no obstacle to cross-platform development (despite the naysaying of game developers at first). In fact, if you are going to leverage multiple input types, .NET is the best method for doing so today. The reason that is the case is rather easy - .NET is not API-restricted. (It leads to the following question - how many of the various "Start menu add-ins" are written in .NET, or leverage it?)

If any - or all - of those add-ins do, in fact, leverage .NET, then congratulations; they took advantage of a more modern toolkit than the original developers of the Start menu did. However, because all of these various add-ins are so new, we still have no idea whether they will have new issues that the original Start menu did NOT have (which could very well be why Microsoft chose to toss the Start menu entirely, as opposed to rewriting it).

The jury remains out on the various add-ins - I'll let their users evaluate them and give feedback.

Okay - by cross-platform I indeed mean for platforms OTHER than Windows. Most games, if they exist for Windows *at all* are multi-platform, and that is especially true for games released in the past year. Here's the surprise; on the Windows side at least, over half the games (and an even larger percentage of the applications) leverage Win32, .NET, or both. You can certainly use .NET in OS X, in Linux distributions, or even in Oracle Solaris - and that is today. (I would say that the biggest obstacle to non-Windows use of .NET is political, not technical - which has also been the biggest obstacle to the use of .NET within Windows application development itself.)

[Dot Matrix]

What's the first version of keyboard/mouse applications you've used?

First version of MS Excel I used was 1.0 on a Mac. First version of MS Word I used was 4.0, also for Mac. (Then switched to Windows lateish with Office 4.2, which was the last version before the move to Win32. Ahhh, the days of DOS/Win3.1...)

Both are now ~25-30 years old now, but were extremely functional. Sure, I like Excel 14 a lot more than Excel 1, but Excel 1 on a one-year-old platform let you do serious work.

In fact, these applications were all very featured many years before moving to Win32...

My rents got their first machine when I was around 4 or 5. It ran Windows For WorkGroups 3.1

[Rickkins]

well if everyone whos complaining about 8 would wait i bet a hacker will fix everything u hate about windows than noobs have the desktop power users have it 2 and us the comon user on this board will never have to hear anything again i would love to come here and not have to read about people bitching on a copy of windows leaked on the net it would be nice

Already done. Avoid all the metro nonsense with http://classicshell.sourceforge.net/

[@Leo]

Apple declared Mac OS 9 dead about a year after OS X' release. Classic app support was part of OS X, but only though the means of emulation (similar to Windows XP mode in Windows 7 appearance-wise). This meant hardly any integration between Classic apps and OS X whatsoever, plus a noticeable performance hit. They also came up with Carbon which allowed apps to be ported over more easily from Mac OS 9 to OS X. The company also actively helped developers. A native Microsoft Office version for OS X was released after about half a year. The first native Adobe Photoshop version after about a year.

Over 90% of all PCs world-wide run Microsoft Windows. I'd say Microsoft has more than enough leverage. Instead of letting the desktop linger indefinitely they could set a clear deadline: Be sure that by 2014 your apps will be Metro.

I have to say here, that Apple at the times of the OS9 -> OSX transition had a very small userbase, giving them leeway to do these "drastic" changes with little to no fallback, because most of the users they had were tech aficionados and fans, which would have upgraded anyway.

With Microsoft, their huge legacy and marketshare, that works to their disadvantage (not that I want them to succeed in their current money grabbing vision, of course). They cannot decide they do not support the desktop anymore - they just can't - the bulk of their wealth still comes from their business customers - consumers are small potatoes.

[neo1911]

Does anyone find "We're Getting Your PC Ready" screen highly annoying while creating new user?

[Calum Veteran]

Does anyone find "We're Getting Your PC Ready" screen highly annoying while creating new user?

I enjoy it. I like the animation and how the colours change. What about it annoys you?

[.Neo]

Yet Apple launched an OS 9-capable Power Mac G4 config in June 2003. http://www.lowendmac...4-1.25-ghz.html.

It was purely for those who were still using older software versions. That PowerMac G4 wasn't considered mainstream by any means, had outdated hardware and was already outpaced by the faster G5. Other models, including my eMac (late 2003 model), couldn't boot Mac OS 9 natively.

[neo1911]

I enjoy it. I like the animation and how the colours change. What about it annoys you?

The colors and animation makes it feel that it is wasting time and makes first boot considerably slower than RP or CP.

[Calum Veteran]

The colors and animation makes it feel that it is wasting time and makes first boot considerably slower than RP or CP.

I think the reason that first boot is slower, though, is because it has to be, due to what it's setting up. I gathered that the reason for that screen is because they needed to place something there while it's setting more things up than the CP or RP did. I could be wrong, though.

[PGHammer]

Does anyone find "We're Getting Your PC Ready" screen highly annoying while creating new user?

And that is different from Vista's "Getting it done" slideshow while setting up? Or XP's text-mode blurbishness (which originated with Windows 98)? What is annoying is that it gave me flashbacks to Windows ME (the kaleidoscope effect from ME's OOBE).

[Brandon Live Veteran]

I do my user management old-school from the Computer Management interface now (I still use local accounts because that works much better with connecting to my myriad of other computers using SMB, and I can always manually associate individual apps to my Live accounts, even different Live accounts for different apps). In part to escape the Metro way of doing it, but also to escape that obnoxious you-must-provide-a-hint password silliness.

Do you use more than one computer? If so, you're missing out on some of my favorite features (i.e. automatic roaming of system and app settings, WiFi and web form passwords, etc).

[code65536]

Do you use more than one computer?

Yes.

If so, you're missing out on some of my favorite features (i.e. automatic roaming of system and app settings, WiFi and web form passwords, etc).

I tried it, but noticed that it simply did not play well with accessing other my Windows computers over SMB. Which I do a lot of. I have Gigabit Ethernet and 5GHz WiFi, I map the C drives of all my computers (e.g., computer #1's C drive is always network-mapped to "J:" on every computer on my network, including computer #1 itself, computer #2's C drive is always mapped as "K:" on every computer, etc., and I also use NTFS mount points, so if I wanted to access the second optical drive of computer #2, I can just punch in K:\Mount\F from any computer on my network) Makes for a nice and consistent way to easily access all the file systems no matter which computer I'm using... and it seems to not work very well if I use Live accounts. I get mysterious (and sometimes intermittent) connection and login problems, all of which disappear when I switch to using local accounts. That's the primary reason I don't use Live accounts.

The second reason is that I'm one of those old-school people who grew up with DOS and Windows 3.1 and like to know exactly what's going on and doesn't trust "automatic". E.g., exactly what does and doesn't get sync'ed (I think it's safe to assume that my rather large Firefox profile in %AppData% doesn't get sync'ed), how do I know when things are in or out of sync, how conflicting settings get resolved (e.g., if I set an option to A in computer 1 and to B in computer 2, what exactly gets synced?). So I personally feel much more comfortable handling things manually and deterministically so I know exactly what is going on and exactly what the state is.

In any case, I do concede my choice to avoid Live accounts is very much tied to my specific (and probably unusual) way I do things--it's just not for me.

[phailyoor]

Do you use more than one computer? If so, you're missing out on some of my favorite features (i.e. automatic roaming of system and app settings, WiFi and web form passwords, etc).

Firefox can roam passwords and stuff for the webI think I can handle typing in the wifi password for each computerOther than that, I usually set aside a few hours to "set up" each new computer I get. I uninstall bloatware, install some utilities, change up the startup, tweak the VM a bit, and basically set up the computer how I want it. After that, I rarely touch my system settings. Automatic settings syncing might save me a few minutes during the entire life of each computer, but it's not worth all of the "live account" hassle.

Also, my settings are different on each of my computers. I think it's natural that I use different programs and settings on my laptop, tablet, and multi-monitor desktop.

[PGHammer]

Exactly. To the person saying Android supports mouse, keyboard, and touch, are there any mouse/keyboard Android devices widely available? I'd think Android would suck used by a mouse.

The Eee Transformer *series* - especially the Prime. (It is, in fact, the example I've been using since the Consumer Preview of why WindowsRT makes sense, and why Ultrabook-based tablets, slates, and convertibles now have Intel's active backing and development support, as opposed to being resisted mightily.)

If you are talking Froyo (Android 2.2), your point would be quite valid, as Froyo and earlier were primarily designed for smartphones - not even tablets. Android 3.x was, first and foremost, designed for larger devices than smartphones, and specifically tablets and netbook-type devices - including the original Eee Transformer TF-101, which would ship with Android 3.0. However, developers complained about having to develop for different versions of Android (3.x was basically a fork - albeit an official one) - hence the re-mergence of the two with 4.0 (Ice Cream Sandwich) which was, in fact, much ballyhooed as the return of the One Android. (Yes - VERY Sauronish; however, the reasoning makes sense.)

[Dashel]

So, what are your key reasons for preferring WinRT (ARM) over Android PG? What intrinsic advantages do you think it has over iOS/Android once you remove the Win32 crutch?

Android sucks donkey with a mouse, its only marginally better than using one on a game console which is abysmal.

[PGHammer]

So, what are your key reasons for preferring WinRT (ARM) over Android PG? What intrinsic advantages do you think it has over iOS/Android once you remove the Win32 crutch?

Android sucks donkey with a mouse, its only marginally better than using one on a game console which is abysmal.

I asked *which version* (in the case of Android), and stated *why* - Android 2.x (Froyo and earlier) did not play well with mice because it largely was not designed with anything OTHER than touch in mind. Android 3.x (Honeycomb) was designed specifically for tablet and larger formfactor deployment (and was not meant to be deployed on smartphones, though ROM modders DID create Android 3.x ROMs for smartphones). Android 4.x (Ice Cream Sandwich and successors) was supposed to specifically merge the issues created by the 2.x/3.x fork in Android code.

The WindowsRT *advantage* is primarily for those that are running Windows 8 on their desktops - no having to relearn anything simply due to using WindowsRT. (In other words, if you don't use touch on your desktop - and most don't - you don't necessarily HAVE to use touch in WindowsRT either, though you can if you want to AND your device supports touch.)

The critics of the Modern UI are thinking devices first - NOT desktops first. That transition curve is bass-ackwards, and especially for those that have both a PC and a device (regardless of OS on either). The file transfer is either from PC to device (making a copy) or round-trip (from PC to device and back) - that's why there is a transition in the first place.

While the default desktop on the Transformer (which is Android 3.0) *looks* like Windows (or even openSuSE), the apps themselves look like nothing on either (which is a major issue for Android users that also have a PC running either a Linux distribution or Windows), so there is still a transition issue between Android and either Linux or Windows. WindowsRT, on the other hand, is identical (in terms of UX) to Windows 8, hence the transition is zero. My issue with the WinRT API (the only API that Windows RT supports) is app-specific (and I have NOT seen OfficeRT to compare it to Office 2013, which I am running today). Until I see how OfficeRT acts, I won't be touching WindowsRT with a ten-foot fork.

The Surface PRO, on the other hand, has everything Windows 8 does - because that, not WindowsRT, is the OS in question. Windows 8 is a superset of WindowsRT *and* the successor to Windows 7 - and, other than CPU-native code (which is actively discouraged in WinRT API apps), WinRT code is CPU-neutral by default. Because I actually expected a dearth of WinRT apps initially (and why anyone that remembers the early days of Win32 didn't expect the same to happen with WinRT is beyond me), I evaluated Windows 8 strictly as a Windows 7 successor - not as WindowsRT, let alone an alternative to WindowsRT (or even Android).

The other reason I brought up the Transformer is because the hardware is identical to that of the WindowsRT reference platform - in other words, via firmware swap, you COULD see a Transformer running it. The Transformer is also popular - primarily due to the long battery life, and a price no more than a netbook. That is why I referred to the Transformer and Transformer Prime - regardless of OS - as netbook-killers. If WindowsRT on a Transformer-type device has an identical UX to a Windows 8-based device (and given that the only difference is the apps on each, that means that it's up to developers, not Microsoft, to ensure that there is as little CPU-native code in Modern UI/WinRT API apps as possible) Android's only attractiveness will be based on price, and if WinRT is superior to Android in terms of app quality, that will be a value-add all its own. (Quality CAN trump price - as Win32 on the desktop has proven year after year.)

There WILL be a battle between the WinRT API and Android. That is a certainty. However, it won't begin in earnest until six months from now (after Christmas). Developers will fight it, but users will decide.

And as far as to whether Microsoft is leveraging the Win32 installed base to grow WinRT API development, of course they are; hasn't Google leveraged Android on smartphones to extend Android to tablets? (There's that trend again.)

[phailyoor]

I asked *which version* (in the case of Android), and stated *why* - Android 2.x (Froyo and earlier) did not play well with mice because it largely was not designed with anything OTHER than touch in mind.??Android 3.x (Honeycomb) was designed specifically for tablet and larger formfactor deployment (and was not meant to be deployed on smartphones, though ROM modders DID create Android 3.x ROMs for smartphones).??Android 4.x (Ice Cream Sandwich and successors) was supposed to specifically merge the issues created by the 2.x/3.x fork in Android code.

The WindowsRT *advantage* is primarily for those that are running Windows 8 on their desktops - no having to relearn anything simply due to using WindowsRT.??(In other words, if you don't use touch on your desktop - and most don't - you don't necessarily HAVE to use touch in WindowsRT either, though you can if you want to AND your device supports touch.)

The critics of the Modern UI are thinking devices first - NOT desktops first.??That transition curve is bass-ackwards, and especially for those that have both a PC and a device (regardless of OS on either).??The file transfer is either from PC to device (making a copy) or round-trip (from PC to device and back) - that's why there is a transition in the first place.

While the default desktop on the Transformer (which is Android 3.0) *looks* like Windows (or even openSuSE), the apps themselves look like nothing on either (which is a major issue for Android users that also have a PC running either a Linux distribution or Windows), so there is still a transition issue between Android and either Linux or Windows.??WindowsRT, on the other hand, is identical (in terms of UX) to Windows 8, hence the transition is zero.??My issue with the WinRT API (the only API that Windows RT supports) is app-specific (and I have NOT seen OfficeRT to compare it to Office 2013, which I am running today).??Until I see how OfficeRT acts, I won't be touching WindowsRT with a ten-foot fork.

The Surface PRO, on the other hand, has everything Windows 8 does - because that, not WindowsRT, is the OS in question.??Windows 8 is a superset of WindowsRT *and* the successor to Windows 7 - and, other than CPU-native code (which is actively discouraged in WinRT API apps), WinRT code is CPU-neutral by default.??Because I actually expected a dearth of WinRT apps initially (and why anyone that remembers the early days of Win32 didn't expect the same to happen with WinRT is beyond me), I evaluated Windows 8 strictly as a Windows 7 successor - not as WindowsRT, let alone an alternative to WindowsRT (or even Android).

The other reason I brought up the Transformer is because the hardware is identical to that of the WindowsRT reference platform - in other words, via firmware swap, you COULD see a Transformer running it.??The Transformer is also popular - primarily due to the long battery life, and a price no more than a netbook.??That is why I referred to the Transformer and Transformer Prime - regardless of OS - as netbook-killers.??If WindowsRT on a Transformer-type device has an identical UX to a Windows 8-based device (and given that the only difference is the apps on each, that means that it's up to developers, not Microsoft, to ensure that there is as little CPU-native code in Modern UI/WinRT API apps as possible) Android's only attractiveness will be based on price, and if WinRT is superior to Android in terms of app quality, that will be a value-add all its own.??(Quality CAN trump price - as Win32 on the desktop has proven year after year.)

There WILL be a battle between the WinRT API and Android.??That is a certainty.??However, it won't begin in earnest until six months from now (after Christmas).??Developers will fight it, but users will decide.

And as far as to whether Microsoft is leveraging the Win32 installed base to grow WinRT API development, of course they are; hasn't Google leveraged Android on smartphones to extend Android to tablets???(There's that trend again.)

The only issue is that the primary Windows 8 GUI is Desktop, and the primary Windows RT GUI is Metro. Even though Metro exists on Windows 8, and Desktop exists on Windows RT, both GUIs are almost completely separate and have their largest utility on the respective platform. In the end, the common parts of the OS are almost completely worthless.

[PGHammer]

The only issue is that the primary Windows 8 GUI is Desktop, and the primary Windows RT GUI is Metro. Even though Metro exists on Windows 8, and Desktop exists on Windows RT, both GUIs are almost completely separate and have their largest utility on the respective platform. In the end, the common parts of the OS are almost completely worthless.

The only *common* part of the respective OSes is the WinRT API - period. The WinRT API itself is CPU-neutral and is input-neutral; that is why it's important going forward. (Neither is true of the Win32 API, which is both x86-biased and lacks all but the most primitive touch support.)

However, that presents a problem for application developers going forward - do they embrace touch as an optional input mechanism? If they don't (that is still a choice on Win32), they do nothing - the application will still support input methods that Win32 supports.

Users, on the other hand, need do nothing - they can use touch support, or not.

The separation between WinRT and Win32 is far smaller than the separation between Windows XP Professional and XP Tablet PC Edition - if anything, the separation between WindowsRT and Windows 8 Pro is that between XP Professional and XP Media Center Edition - remember, XP Media Center Edition was basically a superset of XP Professional.

Yes - the primary GUI (for now) in Windows 8 *is* the desktop, and I stated why - that's where the application base is. (The same was, in fact, what did eventually kill non-niche usage of OS/2, and why it took Windows 9x for Windows NT to *eventually* replace it; Microsoft used Windows 9x to grow the Win32 hardware base, which in turn grew the Win32 *software* base.)

Whether the primary GUI will *remain* Win32 will be a battle fought by developers, and decided by users - for once, IHVs will be bystanders (which wasn't the case at the very end of the Win16 API - that is what begat the disaster that was Windows ME).

There is no *battle* between WinRT or Win32 as such - any more than there was between Win32 and .NET; notice that increased usage of .NET did not kill Win32.

In other words, developers - and users - have greater choice, not less choice.

[PGHammer]

So, what are your key reasons for preferring WinRT (ARM) over Android PG? What intrinsic advantages do you think it has over iOS/Android once you remove the Win32 crutch?

Android sucks donkey with a mouse, its only marginally better than using one on a game console which is abysmal.

The crutch I referred to is the Start menu - not Win32; the Win32 API doesn't require the Start menu, as it, in fact, predates it.

The reason for the Start menu was to provide a common UX/UI between 9x and NT; that function is provided by the WinRT API (and is the only commonality between WindowsRT and Windows 8).

Win32 applications/games/etc. don't require the Start menu - if they did, Win32 compatibility in Windows 8 would be broken.

The issue viz. the lack of a Start menu in Windows 8 is entirely user-driven - not application-driven; name an application that absolutely requires the Start menu to even work.

There have been alternative shells to the Start menu for as long as there has been a Start menu, in fact - the *appeal* of the Start menu has been far from universal, even at its inception. (The growth of Stardock itself is plenty of evidence of that.)

Going forward, there MAY be a sideshow between Win32 and WinRT; there are some applications - from a single company - that, other than which API is in use, are common to both APIs; I mentioned the Kindle e-reader as being one that exists today. However, that's an exception, not the rule.

You are thinking of a conflict where none exists - or even is planned to exist.