Slashdot Mirror
Now That It's Here, Is There a Place For Windows RT?
concealment sends this quote from Ars:
"The argument back then was this: Windows on ARM would mean discarding the thing that makes Windows entrenched and important: Windows applications. Tablets need all-new applications, and if you're going to run all-new applications then you don't really need Windows. ... In the time it has taken Microsoft to bring Windows on ARM to market, ARM's once overwhelming battery life advantage has been erased. The ARM CPUs may still have a slight power use edge, but the difference will typically be dwarfed by the power consumption of the screen. The Intel processors, in turn, bring CPU performance that is probably best in class (or close to it), and most importantly of all the ability to run the full version of Windows 8 and existing Windows applications. The hardware could look identical to the user, but if it has Intel inside, the user experience will be quite different. ... With these constraints and limitations, it's hard to see who exactly Windows RT is for. I acknowledge that there are certainly some users who will be content to use the browser, mail app, and perhaps type the occasional letter in Word or balance their checkbook in Excel: people for whom the Windows Store's current gaps do not matter. But I think a much wider selection of users will be ill-served by Windows RT."
Hint: there is.
Let's be specific about it. The place for Windows RT is to occupy the void formerly filled by Windows CE, with similar success. A Windows that isn't really Windows. Just the thing to irritate the same sheeple who once raised Microsoft up to the dizzying heights of world's most valuable company.
Just a historical note apropo to nothing in particular: when Alaric I marched into Rome to sack it in 410 AD, much of the city had already reverted to swampland. The aquaducts had long since silted up and the sewers weren't working. What Romans remained were living in squalor. So much for former glory.
When all you have is a hammer, every problem starts to look like a thumb.
The only way that future windows applications will work on both ARM and x86 is if people start developing for that now. They need just enough marketshare to warrant the added development time* for developers to make both an ARM and x86 version so that windows 9 or windows 10 on both will actually be appealing
No. You see, C# uses a virtual machine. It's MS's version of Java. That's their strategy for cross platform. Thats how XNA code runs on my PC and on the XBox without change. They call it "Managed Code" -- Bytecode in a Virtual Machine. Hint: Android uses the Java language, and Davlik VM for cross platform.
MSVC is not what developers really need to be using to ensure future relevance. OSs are becoming Irrelevant (actually have been for a long time). We developers only care about getting our software running on as much hardware as people want it too. There's no reason at all to limit our marketshare needlessly.
With an entrenched code base tied to a proprietary compiler suite you're at the OS vendor's mercy. What's smart is to use a cross platform framework like Qt, GTK, or another OS abstraction layer and compiler toolchain, for any new projects. A minimal OS abstraction can be created in a weekend (I know because that's how long it took me to make my own GLUT replacement)... In this way I don't have to do ANY extra work to get code additions to compile for x86, x64, ARM, PPC on GNU/Windows, GNU/Linux, GNU/OSX, etc.
I "git pull & make" and I'm done "porting" from any supported platform to another -- And this is for 3D Game Code (programs notorious for being hard to port). For any other programs it should be a no brainer. Cross platform toochain or bust. Ah but C# really only works well on Windows, so MS is pushing that hard -- Native compiled code instead of MS byte-code means they can't be your exclusive platform as easily.
VMs are OK, but they're slow for things that actually need performance of running on the metal. What we need is a cross platform object code format that the OSs then link into binaries at install time... (Gee, someone ought to make such a compiler / OS) Since we don't have such a system the next best thing is either a VM with JIT compiling, or building binaries for each target platform.
I gave up trying to create code that I could compile with all the popular toolchains: MS/Windows and LLVM/OSX & BSD as well as GNU/Linux. I could have gone with LLVM over GCC, but I'm more familiar with GAS, so I picked a GNU based userland & toolchain. An MS compiler wasn't even on the table -- They have no cross platform OS agnostic compiler (publicly) available. A brand new processor can come out tomorrow, say, a 48 core AMD 128 bit processor with a totally new instruction set: LEG. As soon as it runs GCC (read: Linux) all of my code can run on it.
W8? An OS? ... OS?! ... Screw OSs. They're just the platform you use to get your software on. Your OS choice shouldn't affect what software you can run -- We solved that problem in the 70s, now it's time to actually start using the damn solution already. Not servicing market segments due to compiler choices is like throwing away perfectly good money.