[Windows RT General] GoodDayToDie:
[MENTION=868588]libbycm[/MENTION]: Despite being here even longer than I have, you appear to have no idea who you're talking to *or* what you're talking about.

I maintain the Ported Apps thread for RT, and have ported a few of them myself (and should get back into it with something more realistic than Chrome, which I still hope to get working Some Day Soon Now). I am quite *personally* familiar with the requirements of porting, the difficulties of working around missing functionality (almost all of which, it should be noted, is missing by design and not neccessity), and the realities of what an ARM processor can and cannot do.

First of all, .NET apps (including WinForms ones and even once that use COM or P/Invoke to system libraries) work just fine, no recompile needed. That's a pretty small portion of the overall Windows software ecosystem, of course, but it's a growing one and also it's one that would be seen as worth targeting by more developers if they saw an actual benefit to architecture-independent toolchains on Windows.

Second, and related to the first, .NET is far from the only architecture-independent language. Java (though IKVM, though .NET) kind of works on RT already; it wouldn't take much to make a serious platform worthy of an official port. Same for Python, and we already have Perl. Yeah, that's still miniscule next to the bulk of legacy x86 code, but it would nonetheless make RT a far more popular platform (for example, many of the Windows bittorrent clients are either Java or Python code, and some very popular games are written in those languages).

Third, even with the crippled tools that we have cobbled together to do our porting, and despite the fact that it's all done on our own time, we've managed a fair number of native ports already. There'd be far more if it weren't for the fact that we can't port closed-source programs (and many open-source ones don't happily compile under MSVC, which is the only RT-targeting compiler we have right now). Already, a growing number of programs are natively available on x64 - after all, it's just a drop-down selection and another click on "Build" in Visual Studio. Well, the same is true of RT. It wouldn't get legacy software, but there's no reason that *new* software released in the last half year - even proprietary commercial stuff - couldn't support RT. After all, it's more customer base for almost no additional work (supporting x64 is sometimes actually more work than supported ARM; at least ARM uses the same-width pointers as x86).

Fourth, legacy code is - by its very nature - older code and generally suitable for running on less-powerful systems. You mentioned Apple... but you failed to mention that when Apple went from 68k CPUs to PowerPC CPUs, and then from PPC to x86, they used mostly-transparent emulation layers to bridge those gaps. Yeah, the code ran slower, but it ran well enough for most purposes. Yeah, ARM is *less* powerful than x86, not more powerful (although you could argue that the same is true for some use cases when going from a G5 to a first-gen Core Duo), but we've also gotten better at this emulation thing. When Apple did it before, they hired the best folks in the business, and pushed the entire field of CPU emulation forward with their need to make it work. When Microsoft declined to do that, one guy on XDA took it upon himself, in his free time, with only a partial toolchain and no access to Windows internals, hacking on open-source pieces, and built a transparent emulation layer for RT. Microsoft's Windows application compatibility team almost certainly loses more man-hours in one day's bathroom breaks than [MENTION=224595]mamaich[/MENTION] has been able to spend on that project to date, and yet some of those very same people who pushed the whole industry forward at Apple, doing things like inventing what is today called dynamic recompilation, now work at Microsoft. They have the expertise to make it work if they'd wanted to.

Fifth, Windows on Itanium failed (mostly; it's still being used, just not developed) because Itaniums were targeted specifically at the enterprise market but weren't very good even there; there's plenty of software for that instruction set in the aforementioned market. Alpha (never mind Windows on Alpha, which I actually know people who used and worked on) failed because DEC wanted outrageous sums of money for it, seeking high-end margins instead of embracing the commodity market. Had they done otherwise, they might even still exist as a company today. NT on MIPS and PPC was similarly niche, targeting brand new (and poorly-merketed) segments that didn't have great penetration in the ecosystem (NT for PPC was a server/workstation OS, not a MacOS alternative). Unlike all those achitectures, though, ARM is well established in the consumer market for commodity computers, and its market share there is growing. If Microsoft is serious about succeeding with RT (and I think they are), they should look at the success story in that market... and it's not Apple anymore. Despite Apple's huge first-mover advantage with the consumer market, Android is rolling over them. Yet Microsoft seems determined to repeat many of Apple's mistakes, despite having precious few of its advantages. They need to make themselves a better Android, not a me-too Apple clone.

Sixth, while Microsoft has made no secret of their desire to move to WinRT, I don't really forsee them having much more success with that than with their prior effort to move people to .NET; lots of small developers will go, but the big programs that are the movers and shakers of the Windows world will stick with the vastly more powerful, flexible, and (frankly) useful Win32 API. Porting an app to RT is a hell of a lot harder than porting x86 native code to ARM, though...