FORUMS
Remove All Ads from XDA

[Release] RT Jailbreak Tool

886 posts
Thanks Meter: 565
 
By netham45, Inactive Recognized Developer on 10th January 2013, 12:01 PM
Thread Closed Email Thread
14th January 2013, 06:47 PM |#111  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,947
 
More
"Modified in some way" is generically accurate but almost meaningless. Quite simply, when any software is built, the developer chooses the type of processor (more technically, the instruction set architecture) it will run on. Until now, there was no reason for anybody to target ARM for a Windows desktop app, so they didn't.

All existing Windows desktop software is built (compiled) for x86 (name comes from the 286, 386, etc. but applies up through all the current ones like Core i7) or x64 (sometimes called AMD64, as AMD developed it) which is a 64-bit extension to Intel's x86. There's a trivial amount of older stuff still around for other ISAs that Windows supported in the past, I guess (Itanium most recently, MIPS and Alpha before that), but desktop Windows has never before been available on ARM.

In theory, once you have the source code for an app, re-compiling it for a new ISA is trivial. In practice, that's only true if the app itself is trivial, because complex software tends to have a lot of fancy stuff going on "under the covers" to make it perform better on specific systems. For example, compiling Firefox 1.0 for ARM would be a *lot* easier than compiling Firefox 4.17... but yes, people are working on it.

It's also possible to (very slowly) execute some legacy x86 programs on Surface using an app that translates the app's machine code (the binary, or "ones and zeroes", that a processor actually understands as instructions) from x86 to ARM, but that process has terrible performance. Apple was able to do it when they moved from PPC to Intel (x86) ISAs some years back, but that worked (sort of - it was still slow) for two reasons:
1) Most of the time, the new x86 CPUs were much more powerful than the old PPC ones they replaced, so software written for the less powerful chips still ran acceptably. This is not true on x86-to-ARM, where the best ARM processors available today are less performant than a typical x86 processor from some years ago. Add the overhead of emulation, and the performance sucks.
2) Apple could devote a massive amount of resources to producing highly optimized "dynamic recompiling" software that translated the PPC programs to x86 and ran the result directly, rather than taking the simple and easy (but very slow) approach of writing a program that fully emulates another CPU. We're a hacker community here; people are already working on getting the emulators to use dynamic recompilation instead... but we've had a total of a few days to do so thus far, none of us are paid to do this (we have lives, jobs, and other hobbies), most of us won't be anywhere close to experts in this field (i.e. nobody in their right mind would hire me to port software to ARM: I'm a security guy, not a computer architecture expert), and even leaving all that aside, this stuff takes time.
The Following 5 Users Say Thank You to GoodDayToDie For This Useful Post: [ View ] Gift GoodDayToDie Ad-Free
 
 
14th January 2013, 07:18 PM |#112  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by GoodDayToDie

"Modified in some way" is generically accurate but almost meaningless. Quite simply, when any software is built, the developer chooses the type of processor (more technically, the instruction set architecture) it will run on. Until now, there was no reason for anybody to target ARM for a Windows desktop app, so they didn't.

All existing Windows desktop software is built (compiled) for x86 (name comes from the 286, 386, etc. but applies up through all the current ones like Core i7) or x64 (sometimes called AMD64, as AMD developed it) which is a 64-bit extension to Intel's x86. There's a trivial amount of older stuff still around for other ISAs that Windows supported in the past, I guess (Itanium most recently, MIPS and Alpha before that), but desktop Windows has never before been available on ARM..

Would .NET 4.5 AnyCPU (and non C++) apps theoretically run on ARM without modification, or does that only apply to compatibility between x64 and x86 only?
14th January 2013, 07:43 PM |#113  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,947
 
More
Good question. The answer is "Yes, they run fine - so long as they are pure .NET, no reliance on third-party native code."

I considered including "write once, run anywhere" frameworks in the description above, because it is relevant. In addition to .NET, which compiles to a binary intermediate language and is then "just in time" compiled further to the native ISA of whatever processor it runs on, there's also scripting languages ranging from the venerable .BAT to JS and Powershell, all of which should run unmodified on Windows RT so long as they don't require third-party software. Unfortunately, such languages require "runtimes" which load the uncompiled script or partially compiled IL and turn them into something the CPU can understand, and those runtimes are among the hardest things to port. Most (though not all!) of .NET 4.5 is already present on Windows RT, and a Windows app written to target that runtime will work as-is after jailbreaking, with no additional work needed. Similarly, the command-line environments (CMD.exe and Powershell) native to Windows are also present on RT, and we can execute unmodified scripts written for those environments even on stock (un-jailbroken) RT systems.

However, I decided it was more important to focus on what would *not* work, and what is being done about it. There have been too many people coming up with ridiculous requests for software to be ported, or even just to run as-is, already. Things ranging from Photoshop to Diablo 3 have all been requested. That indicates a serious lack of understanding of how computers work, and in particular of how software interacts with them. I don't expect people to understand how a CPU actually works (well, not all people... they actually are a lot less complex than you might think at the basic level, the complexity is once again in the optimizations) any more than I expect everybody to understand how a car engine works (which is even simpler). However, I do expect that people will understand that putting "energy drinks", or even diesel, into the fuel tank of a gasoline engine car isn't going to work. For some reason, the analogous understanding around computers is missing from too many people.
14th January 2013, 08:14 PM |#114  
OP Inactive Recognized Developer
Flag Denver
Thanks Meter: 565
 
Donate to Me
More
Just a point of clarification, powershell is restricted from accessing most assemblies that it's permitted to access on x86, therefore not all powershell scripts will work.

This restriction is lifted with the jailbreak, though.
14th January 2013, 09:29 PM |#115  
Dadstar's Avatar
Senior Member
Flag Royersford, PA
Thanks Meter: 10
 
More
What would using this jailbreak allow us to do with our device? In other words, what does it change on the device? Because I found something in the mmc.exe that allows me to always install with elevated permissions. Isn't that what you're doing?
14th January 2013, 10:32 PM |#116  
OP Inactive Recognized Developer
Flag Denver
Thanks Meter: 565
 
Donate to Me
More
Quote:
Originally Posted by Dadstar

What would using this jailbreak allow us to do with our device? In other words, what does it change on the device? Because I found something in the mmc.exe that allows me to always install with elevated permissions. Isn't that what you're doing?

That's not at all what we're doing. There are code signing restrictions on all .exe's made on the system, and with these restrictions in place no non-MS .exe's can be ran.
The Following User Says Thank You to netham45 For This Useful Post: [ View ] Gift netham45 Ad-Free
16th January 2013, 01:51 PM |#117  
Senior Member
Thanks Meter: 58
 
More
Really nice... fun to play with until the exploit is patched
16th January 2013, 06:47 PM |#118  
Junior Member
Thanks Meter: 0
 
More
Just wanted to report the script failing on the Lenovo Ideapad Yoga 11 (Tegra) and the Dell XPS 10 (Snapdragon S4). Can provide dump files to OP if desired.

Thanks for your work on this!!
16th January 2013, 08:56 PM |#119  
OP Inactive Recognized Developer
Flag Denver
Thanks Meter: 565
 
Donate to Me
More
Quote:
Originally Posted by mwy23

Just wanted to report the script failing on the Lenovo Ideapad Yoga 11 (Tegra) and the Dell XPS 10 (Snapdragon S4). Can provide dump files to OP if desired.

Thanks for your work on this!!

Have you verified that they're fully updated?
16th January 2013, 10:48 PM |#120  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by netham45

Have you verified that they're fully updated?

My apologies. I went back and reread through the thread and discovered the Yoga was NOT updated. After letting it update (and a couple hours later) I re-ran the script and it worked perfectly.

However, the Dell was updated but the script causes the system crash. Is there any information I can provide to assist in discovering a fix for this platform?
17th January 2013, 01:54 PM |#121  
Member
Thanks Meter: 5
 
More
First off, thanks Netham45 and those who made this jailbreak possible.

But I just gotta ask, when do you think the Vivotab 3G is gonna get a patch. I hope we get it real soon.

/eagerly waiting and refreshing page every few hours
Thread Closed Subscribe to Thread

Tags
hack, jailbreak, windows, windows rt, winrt
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes