Related
Does anyone know of any virtualization/emulation software that can run on ARM processors?
I haven't seen anything other than that WINE is being developed such that soon ARM and X86 will have interchangeble compatibility (windows ARM on x86 linux and windows x86 on linux ARM)
I'm getting one of those ARM Chromebooks and it would be cool to be able to keep ChromeOS intact by installing something through the terminal in dev mode and using something like php virtualbox to open the gui through the browser
I'm not too opposed to just putting Ubuntu on it but would like to be able to try out like the ARM version of backtrack
windows support would be assume but unexpected
QEMU?
QEMU supposedly has intermittent support for running on an ARM host, and supports both system (full OS) and user (individual application) level emulation of x86 target. However, they say on their site that ARM host support is only of secondary importance (wiki.qemu.org/Features) and so it may not work too well.
Could be worth a try anyway!
Is there anyone knows how to do jailbreak and use desktop apps on windows RT 8.1?
No. Windows desktop applications are compiled for x86 architecture. Windows RT runs on ARM.
@jeddx21: There is not a jailbreak publicly available for Windows RT 8.1 yet.
Will there be? I've seen indication that progress has been made on that front, but it's been sparse lately. It's something that's been wanted for a while (do a search - you'll find all sorts of threads and comments about an RT 8.1 jailbreak), but it's not yet available.
@Banderburg: Desktop applications are simply Windows applications compiled for the desktop environment, not the Metro / Modern / whatever-Microsoft-is-calling-it-these-days environment. They can and do exist for Windows RT - a primary example of this is Microsoft Office; others include all of the applications that are available to run under a jailbroken RT 8.0 system, such as those in this thread.
So what should i do? should i downgrade it from 8.1 to 8 so i can use jailbreak?
Hey
That depends on your device. If it's a device that shipped with RT 8.0 when released (the original Surface RT and the Asus VivoTab RT, for example), the instructions are available elsewhere in the forum (use the search function).
If it was one that came only with RT 8.1, then there really isn't much that can be done to downgrade your device - missing drivers, signatures that are unrecognized by the device firmware, etc.
irony_delerium said:
@Banderburg: Desktop applications are simply Windows applications compiled for the desktop environment, not the Metro / Modern / whatever-Microsoft-is-calling-it-these-days environment. They can and do exist for Windows RT - a primary example of this is Microsoft Office; others include all of the applications that are available to run under a jailbroken RT 8.0 system, such as those in this thread.
Click to expand...
Click to collapse
[MENTION]@irony_delerium[/MENTION] I'm sorry - what? Desktop applications aren't compiled for an "environment". They're compiled for a specific CPU architecture and in this case, applications that run on desktop computers are compiled for x86 CPUs. Applications that run on RT are compiled for ARM CPUs.
You can't jail break a device running on ARM and expect it to run x86 applications. You would need to recompile the application and target it at the ARM CPU.
So again, to the OP's question, NO there will never be a jailbreak that allows you to run a desktop application on an ARM cpu. Period.
IF you re-compile an application to run on ARM, and IF you've modified your Surface RT to run applications that aren't digitally signed by Microsoft, then yes in that case you can run the "desktop" application.
banderberg said:
[MENTION]@irony_delerium[/MENTION] I'm sorry - what? Desktop applications aren't compiled for an "environment". They're compiled for a specific CPU architecture and in this case, applications that run on desktop computers are compiled for x86 CPUs. Applications that run on RT are compiled for ARM CPUs.
Click to expand...
Click to collapse
This doesn't change the fact that *desktop* applications exist for Windows running on ARM. Unless you mean to tell me that Audacity, SumatraPDF, or Notepad++ (for example) are not desktop applications, of course.
On Windows 8, applications are compiled both for an environment - Metro/Modern or Desktop - and a CPU architecture. Metro applications run in containers and have explicit blessing from Microsoft to run on both x86 based systems and ARM based systems. Desktop applications are locked down on ARM based systems, by default, to only those with a Microsoft signature. Applications built for either Desktop or Metro will not run in the other environment. Applications compiled for x86 will not run on ARM; applications compiled for ARM will not run on x86.
bandenberg said:
You can't jail break a device running on ARM and expect it to run x86 applications. You would need to recompile the application and target it at the ARM CPU.
So again, to the OP's question, NO there will never be a jailbreak that allows you to run a desktop application on an ARM cpu. Period.
Click to expand...
Click to collapse
This is true. I never said anything about x86 applications. I said desktop - of which, Windows on ARM has a desktop and applications for that desktop.
There are applications built to run on that desktop - even provided by Microsoft, unless you consider the applications forming the Office suite to not be desktop applications. Therefore, desktop applications are available for Windows RT.
No, of course desktop applications targetting x86 or x64 will not run in that environment.
Well put, @irony_delirium. I would expand on that a little, though.
First, not even all desktop computers are x86/x64. Windows used to run on a number of other architectures, like Alpha and PowerPC, and there were desktops (workstations, really, but recognizably desktop computers) with those architectures. Apple used to build all its desktops (and laptops) with PowerPC chips, and before that they used CPUs from the Motorola 68000 family. None of these can execute x86 instructions, but they were all desktops. Of course, the code that ran on them had to be compiled for the relevant architectures, but usually it's not that hard to port software from one 32-bit instruction set to another, unless you wrote the code in Assembly or did similarly platform-specific stuff.
Second, architecture-independent software can run on any platform that supports the intermediate language. For example, Windows RT can run .NET 4.x software, including on the desktop, just fine (though if the binary isn't signed by Microsoft, either the OS will need to be jailbroken or the method of loading the application will need some other convoluted hack). Let me make this clear, though: these are the exact same binaries, produced by Visual Studio (or the command-line C# compiler, csc.exe, that ships with all recent versions of Windows including RT), that you can run on x86 desktops. There's even a .NET program which implements the Java runtime, so you can run Java-based apps on (jailbroken) RT.
Third, it's actually possible to run code written for one instruction set architecture on a CPU with a different architecture, if you have a translation/emulation layer and are willing to take the performance hit of going through it. There's a half-finished homebrew of such a layer for Win32/x86 code on Win32/ARM (RT), but nobody has been working on it for months. It'll run some software, though - Heroes of Might and Magic 3, a closed-source commercial x86 strategy game from the 90s was one of the first apps it was shown able to run, and some other programs work as well - and while it's not fast in an absolute sense it's good enough to run old games or reasonably lightweight current programs. Hopefully, work on it will resume once there's a new jailbreak out.
I've compiled portable versions of qemu-system-i386 2.1.1 both for arm and x86, I think it is possible to run in many devices with linux kernel.
I've tested them in my phone RedMi One and on the android x86 4.4 on my laptop.
In my phone(Cortex-A7 1.5GHz), it takes 4-10mins to start windows xp sp3. With enough RAM(200MB I have tested), it can load a snapshot in about 10 sec.
Network accessing is possible in guest system.
Also, I've post the package in a chinese forum, some people have test the arm version and proved it work well.
So, is anybody interested there?
Requirements:
a rooted android phone (cpu with armhf support);
a terminal app;
XServer XSDL or VNC Viewer.
Decompress the 7z files after rename them as 'filename.7z.001', 'filename.7z.002', ...
In the terminal, input like:
#cd qemu-system-i386_for_arm/bin
#chmod 755 qemu-system-i386 #(required the first time)
Then, two options:
1) using vnc
#./qemu-system-i386 -hda /sdcard/xp.qcow2 -vnc :0
Then you can connect with localhost:5900 using VNC Viewer.
2)
start XServer XSDL first, and then start qemu:
#DISPLAY=:0 ./qemu-system-i386 -hda /sdcard/xp.qcow2
more parameters of qemu can be specified, such as:
-m 128 -net user -net nic,model=rtl8139 -soundhw es1370 -vga vmware -monitor stdio
Awesome, this is really really useful, especially since Limbo PC emulator uses some super old qemu build and has been on development hiatus since spring 2014.
This is perfect, native qemu 2.1 inside of android.
Thanks a lot for sharing
Excellent build. Much faster than Bochs, Limbo, or other QEMU Android builds. So far, this is the fastest I've found, and I've tested a lot of builds.
Please be aware that the qemu system for arm 7z files in OP appear to be corrupt, will not extract. Even with rename to 001, etc. Was able to find qemu-system-i386_for_arm.zip by Google search. It appears pan.baidu.com has the file available uploaded by the same user "falonwang".
Tested Diablo, and Sim City 3000 on Win95 image. Playable with excellent FPS on AT&T Galaxy S6. :good:
This works great on my Galaxy S6, however I'm not able to get networking to work. When I use the exact same command and disk file with the original qemu in a chrooted linux environment networking does work, but not with this port.
wow!
Wow this is just perfect!!
Maybe you can also build:
qemu-system-x86_64 for android x86_64 ? (ASUS ZENFONE 2)
all the file are not opening in 7zip , any update?
On a non rooted Samsung Galaxy tab 2 7.0" I have the app GNUroot Debian installed. This is a chroot (actually it is called PRoot, see below for a description) Linux distribution - currently Debian 'Jessie' - with a terminal. I have installed the android-tools-adb package from the Debian Jessie repository. This means the chroot environment has access to the tablet's network hardware.
Now I would like to control another device (I have a non rooted Huawei Ascend Y300) from the tablet using adb inside the chroot terminal. I managed to do this through WiFi by first connecting the phone to a pc and run the terminal command 'adb tcpip 5555'. Then, on the tablet in the GNUroot Debian app terminal running the command 'adb connect xxx.xxx.x.x' gives adb control from the tablet over the phone through the local wifi network. Nice!
It would be even better to manage the adb control between two android devices from a chroot / PRoot environment without the pc, for example using an On The Go cable. Assuming non rooted devices. The tablet in question (Samsung Galaxy tab 2 7.0") has usb host capabilities. So in theory it could be done with a usb On The Go cable connecting the two Android devices.
Questions:
Is it possible to use adb within the described chroot / PRroot environment to run commands to controle another Android device, when both Android devices are connected through a USB On The Go cable?
Does a chroot / PRoot environment give access to the usb port as host?
Information:
The reason for this question is the development of an app on my tablet, using the Android IDE app, which must be tested on other (non rooted) Android devices. Preferably from the tablet, preferably without a pc.
Description of PRoot from 'proot-me' repository at github.com:
==
PRoot is a user-space implementation of ``chroot``, ``mount --bind``,
and ``binfmt_misc``. This means that users don't need any privileges
or setup to do things like using an arbitrary directory as the new
root filesystem, making files accessible somewhere else in the
filesystem hierarchy, or executing programs built for another CPU
architecture transparently through QEMU user-mode. Also, developers
can use PRoot as a generic Linux process instrumentation engine thanks
to its extension mechanism, see CARE_ for an example. Technically
PRoot relies on ``ptrace``, an unprivileged system-call available in
every Linux kernel.
The new root file-system, a.k.a *guest rootfs*, typically contains a
Linux distribution. By default PRoot confines the execution of
programs to the guest rootfs only, however users can use the built-in
*mount/bind* mechanism to access files and directories from the actual
root file-system, a.k.a *host rootfs*, just as if they were part of
the guest rootfs.
When the guest Linux distribution is made for a CPU architecture
incompatible with the host one, PRoot uses the CPU emulator QEMU
user-mode to execute transparently guest programs. It's a convenient
way to develop, to build, and to validate any guest Linux packages
seamlessly on users' computer, just as if they were in a *native*
guest environment. That way all of the cross-compilation issues are
avoided.
PRoot can also *mix* the execution of host programs and the execution
of guest programs emulated by QEMU user-mode. This is useful to use
host equivalents of programs that are missing from the guest rootfs
and to speed up build-time by using cross-compilation tools or
CPU-independent programs, like interpreters.
It is worth noting that the guest kernel is never involved, regardless
of whether QEMU user-mode is used or not. Technically, when guest
programs perform access to system resources, PRoot translates their
requests before sending them to the host kernel. This means that
guest programs can use host resources (devices, network, ...) just as
if they were "normal" host programs.
==
Basically, on the Mate site there is now a Mate download for the GPD Pocket, which does look like a cracking good machine.
Basically, has anybody had the gumption to try this on their Gemini? I have only one Gemini and don't have the skill or the courage to do this myself. If, and it is if, Mate worked on the Gemini, that would be excellent. I know people have Debian working, which is the fork for Ubuntu, which is the fork for....... which is why I'm thinking / hoping it may work.
Thoughts from anyone?
P.
GPD Pocket runs on an Intel x86 processor (like most computers and laptops), which means that it can basically run anything available. Gemini runs on ARM, which is basically the processor that powers mobile phones and some tablets. ARM is a completely different architecture and is not compatible with x86 software. Most of the desktop operating systems (like Windows, mac OS, Ubuntu, etc) focus their development on the x86 platform, since the vast majority of desktops use this architecture of processors. Because Linux is a free and open source OS, it is possible to get the kernel source code and (with a few modifications) compile it to a different architecture. That's what was done for the Gemini (and all other ARM devices that can run Linux), they got the Debian source code and compiled it for the ARM cpu. Some specific hardware settings and drivers were added for the Gemini PDA to make our custom Gemian, a Debian for the Gemini. Ubuntu is based on Debian, and not the other way around. So, to have Ubuntu Mate running on the Gemini requires one step further, to get Ubuntu source code and Gemian customization and drivers, mix it all together to make some "Ubuntian" of some sort... Honestly, I see no advantage in running Ubuntu, since Debian is the root of it. I don't know of a thing you can do on Ubuntu that you can't on Debian. But still, if you really want to have Ubuntu Mate running on your Gemini, on the Android side you can install Linux Deploy. This app only works on rooted Android, but it is totally worth it if you want to run Linux on your device. It allows you to install several distributions of Linux on top of Android, including Ubuntu Mate.