Windows RT Jailbroken To Run Third-Party Desktop Apps 178
An anonymous reader writes "We all knew it was just a matter of time, now it looks like Windows RT has been Jailbroken. From the article: 'The hack, performed by Clokr, exploits a vulnerability in the Windows kernel that has existed for a long time — since before Microsoft ported Windows from x86 to ARM, in fact. Basically, the Windows kernel on your computer is configured to only execute files that meet a certain level of authentication. There are four levels: Unsigned (0), Authenticode (4), Microsoft (8), and Windows (12). On your x86 Windows system, the default setting is Unsigned — you can run anything you like. With Windows RT, the default, hard-coded setting is Microsoft (8); i.e. only apps signed by Microsoft, or parts of Windows itself, can be executed.'"
Re:Non Sequitir (Score:4, Insightful)
Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s.
Yeah, it's all about freedom from backwards compatibility and legacy code!
Wanting to be like Apple and get paid every time a customer installs any software has nothing to do with it.
Re:Is there a way to use this to install Linux? (Score:4, Insightful)
Theoretically you could run some kind of shell on there, so yes, you could run android or linux, but it'd still be running within windows.
And yes, you'd need to flip this bit each time you booted.
What is more interesting is the fact you maybe able to completely rewrite the whole thing; getting rid of windows entirely...
Crack, Rip, Hack, Jailbreak ... (Score:5, Insightful)
"Windows RT Gains Solution to Allow Customers to Run Any Software They Choose"
And we wonder why people don't "get" Software Freedom. Somebody please remember to name the next software-freedom work-around "murder" just to keep the bad PR going.
Comment removed (Score:5, Insightful)
Re:Non Sequitir (Score:2, Insightful)
And how many of those would choose Windows in the first place?
Quite a few, if you count how many F/OSS applications are available on Windows. Majority of customers are not even in control of what OS they are running. If GIMP or Dia or OpenOffice are not available on Windows then it's like they are not available at all. Developers generally care about their customers, even though they may express no joy about the need to compile their product using a not quite compatible toolkit. It's always simpler to publish a tarball with sources and call it done. But that's not how most people install the software.
Re:Non Sequitir (Score:5, Insightful)
If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge
We are talking specifically about Windows RT running on ARM here. There's no legacy compatibility story to begin with, even if the restriction on MS-signed-only desktop binaries weren't there in the first place.
You may have failed to realize that Win32 doesn't mean 32 bit windows API. It simply means "Not the old 16 bit API" I write all my widgets from scratch, and I talk to OpenGL directly, no SDL, no freeglut3, no MFC, just straight Win32 and OpenGL to make the lightest weight most efficient programs, even on 64 bit systems. It's crazy as hell to do this, yes, yes, I'm glutton for punishment, ha ha, you jest, "re-invent every wheel", I know, but game developers are allowed to throw away every best practice in the name of performance... Besides, you don't see wagon wheels on a formula-1 car, eh?
That is to say, Win32 can be compiled on ARM, and then I compile my code that uses the Win32 API to get a window and event loop, and the "legacy" compatibility isn't an issue. Event pumps and windowing callbacks are going to exist no matter what API they build. If you're talking cruft, then it's that COM stuff and .NET and MFC and all the other stuff that's built on top of win32, not win32 itself.
IMO, Win8 is about MS trying to sandbox programs via VM (C#) and simultaneously provide cross platform support while taking a cut of every software sale made. Now, I'm not going to eat that app-store cost. You are. I'll just raise my price accordingly on MS's market to offset those fees... Sucks, but C'est la vie. If MS continues allowing "side-loading" then they can't force developers like me to sell programs in their store -- C/C++ is cross platform, and so is my code, so I just rebuild the binary for each target platform, it's not a big deal. Rebuilding everything in C# and suffering that vendor lock-in cluster fsck is really off-putting, considering my C code runs across the board on every chipset, even MIPS, and every OS (thanks to OS abstraction layer, and a bit of meta-programming for iOS and Android)... No such luck with C#, yet.
That's where MS wants to take their market -- Incompatibility land. IMO, I wouldn't play their shenanigans unless I had to, I don't think OS choice should limit software choice (and I don't think hardware choice (beyond performance) should limit OS choice. This is shit we had well and good SOLVED in the 70's. MS sees the road ahead: The bright future where all programs are cross platform -- The road to OS irrelevance -- they hate that future, they hate your freedom to choose to run any OS on your hardware. Hence SecureBoot (Which I've said time and again is Pointless), Hence C# only in App Store & XBL Indie Games, hence blocking any apps that aren't signed by MS, and not allowing users to add their own trust certs to the OS / Hardware. The jig is up. W8 is just one more battle in the Vendor Lockin war.
I don't mean to pick on MS, Apple is going down the same road with an app-store route for their desktop too. GNU/Linux, BSD, Android, and other FLOSS OSs are the only ones that get the software repository system done right, and not even stock Android allows user installing a new / additional cert trust (recompile). This is a fight over developers, it's the applications that matter, OSs have been irrelevant for quite some time now. It's only a matter of time -- MS can't win this one, they couldn't write secure code to save their ass, which is exactly what they'd need to do.
Re:Non Sequitir (Score:4, Insightful)
You may have failed to realize that Win32 doesn't mean 32 bit windows API. It simply means "Not the old 16 bit API"
I don't fail to realize anything - I know perfectly well that Win32 is a cross-architecture API. My point was that, from users' perspective (and especially for enterprise users, which is what GP was referencing), the compatibility story is nil because there are no existing apps that would run. Sure, most apps are just a recompile away, but someone would have to make that recompile.
IMO, Win8 is about MS trying to sandbox programs via VM (C#) and simultaneously provide cross platform support while taking a cut of every software sale made. Now, I'm not going to eat that app-store cost. You are. I'll just raise my price accordingly on MS's market to offset those fees... Sucks, but C'est la vie. If MS continues allowing "side-loading" then they can't force developers like me to sell programs in their store -- C/C++ is cross platform, and so is my code, so I just rebuild the binary for each target platform, it's not a big deal. Rebuilding everything in C# and suffering that vendor lock-in cluster fsck is really off-putting, considering my C code runs across the board on every chipset, even MIPS, and every OS (thanks to OS abstraction layer, and a bit of meta-programming for iOS and Android)... No such luck with C#, yet.
Just FYI, Store apps are not required to be managed. You can write 100% native apps in C++ for it [microsoft.com] - no VM, no GC.
(Yes, it does use language extensions for system APIs, although even those are optional. And yes, those extensions do look like C++/CLI. Nevertheless, they work differently, and they don't compile to managed code.)
Hence C# only in App Store & XBL Indie Games
Store apps don't support XNA. In fact, pretty much the only way to write a game for Win8 Store right now (unless it's something so basic that you can make do with XAML or HTML5) is to use C++ and Direct3D.