I understand that this is an advanced topic that I have little grasp of (though I am quoting experts in the field), and that I am not qualified to make declatory statements. Please consider what experience you have with this kind of programming and QEMU in general while posting.
Please include specifics with your comments - without specifics, you can't have constructive criticism.
I think by
Sure it works with an CPU emulator like the qemu way. I never said this is wrong, but your post sounds like you can just port the stuff around and it will run out of the box, which is plain wrong.
BTW, nice pic of Win8 on the Asus phone ^^ This was a new one to me.
- "you can just port the stuff around and it will run out of the box"
you are trying to say
- "you can just port ReactOS to ARM and x86 programs will work without effort" (and you are right, that would be foolish, except for interpreted language programs, like batch files, or PHP or something)
but it sounds like you're saying
- "you need to modify programs before they can run on ARM"
(as the quoted post below says)
My first post listed "emulator" and "native code" several times, but I apologise if I wasn't clear enough. As far as working out of the box, yes, ReactOS could be programmed to work out of the box with x86 Win32 programs on an ARM processor
. Without altering the program's binary manually.
Perhaps I can sum it up a little better (as best I understand it):
- All .exe (because I assume ReactOS will choose a different extension for non-x86 processor executables) will be loaded by a stub QEMU (that isn't emulating an entire PC, just the x86 CPU)
- QEMU will redirect any WIN32API function calls from the program to ARM ReactOS (those function calls will run in the ReactOS ARM code, so QEMU won't have to process them, which will speed it up a lot)
- QEMU will take all the DLL dependencies needed by the program and check if they have an ARM version available, and use it instead (This is a guess on my part, DLL's are effectively extensions to the Windows API, so as long as the
- API presented to the program from each DLL is the same, it doesn't matter if the DLL is compiled in the same architecture as the program, as long as the OS can translate between the non-native program and the DLL)
- QEMU will probably do a lot more checks for different types of code in the binary that can be redirected to the host OS
All the remaining code/calls/functions that haven't been redirected at this point (and hopefully there will not be much) will be processed by QEMU (how much code will that be? could be only 5% of the code needs to be run by QEMU in some programs, and 100% of code in other programs)
The result is that a program that has not been modified in any way by the user is run on a different architecture at high speeds (compared to entirely emulating that architecture - ARM emulators on X86 generally execute at around 10% of their native speed, someone estimated this process may let those programs operate at 50%+ their native speed).
You do know that this does not mean that Windows on ARM will run x86 applications? "Win32" is merely the name of the API that Windows is using and providing. It's (mostly) not dependend on the platform or bitness (Win64 also uses/provides the Win32 API in 64-Bit mode!).
Yes, I do know that (it's explained in the link as well), and Windows definitely won't support x86 natively on ARM like... ever. Whereas the open source community has tons of projects that could be useful to the task, Microsoft can't use them because of the source code license, so Microsoft would have to either buy enough companies to get the code they need to start with, or do it all from scratch. Since they seem to want to obsolete the Win32 API in favor of WinRT anyways, I don't see them ever putting in the effort.
(This wasn't posted entirely earlier, so here's what I got from the wiki, not sure how recent it is)
Currently, testing is done with the "Versatile/PB" platform, but with a modified CPU target being the Cortex A8, an ARMv7-a core, which is being used internally for BeagleBoard and ZoomII-MDK work. Although the original ARM port of ReactOS was designed for ARMv5 and ARMv4, these cores have an MMU that is incompatible with ReactOS/Windows requirements, and lacks instructions needed for synchronization done in user-mode.
Heis Spiter wrote:
ARM port targets the ARM9 processors family. Rasberry PI, IIRC, is using an ARM11 processor (ARM11 being some kind of ARM7) processor.
From my first post: RaspberryPi uses an Arm 11
(which is an armv6 processor
The ReactOS wiki says that work was being done on ARM7 cores. While there are certainly some processor specific changes, from what I've read ARMv6 and ARMv7 are very similar.
ARM11 is kind of an older architecture - the design was released in 2002. But this also means it will be easier to implement later architectures (which should be mostly similar to previous architectures as far as coding compatibility).
You cannot expect x86/x64 binaries to run on ARM, first those would need to be recompiled on new arch. Without sources, this is a moot point.
I can and I do, if you read any of the three posts you can see where I have explained how it can be done, according to the experts. No recompiling needed
. Explaining it was the purpose of making these posts.
We dont talk about the hardware needed for a port. Manpower ist expensive too, thats whats the problem here.
Z98 wrote:To rephrase EmuandCo's last statement, since the "cost" of manpower is so much higher than the "cost" of hardware, a decrease in the "cost" of hardware does not make a significant difference in the total "cost" of porting ROS to ARM.
EmuandCo wrote:Noone said its impossible, we just desperatly try to explain here, that we do NOT have the manpower to port ROS to any coffe machine out there. First one architecture bundle: i386 and amd64, then we try get it stable and useable and THEN we can discuss about the arm port again. Except you manage to get our ARM Ninjas back to their port.
First, as far as only focusing on i386 and amd64 (though from what I can see there isn't much of any focus on amd64 at this stage in development): what I read about the other attempted ports of ReactOS said that it revealed a lot of basic problems, allowed the codebase to become more portable for the future, and had other benefits as well. On top of that, the three biggest processor architectures right now seem to be X64, X86, and ARM
. (Makes me wonder what effect a Win32 compatible OS that can run x86 programs on different architectures would have on the market - if it's easier to switch, perhaps more people will choose to adopt that architecture. That may even lead to some of those hardware companies recognizing how valuable such an OS would be for their hardware and supporting its development)
The thing is, I wouldn't expect the ReactOS team to port it to this kind of device. My understanding is that it would be the RaspberryPi users/developers
who would work on a RaspberryPi port of ReactOS.
To sum it up, as far as how cheap hardware relates to manpower:
- The hardware is cheaper. Therefore, more people can/will buy it.
- The primary market for the RaspberryPi is developers; the hardware is simpler than most other ARM devices, which will encourage developers to use it.
- Therefore, more people can/will buy the RaspberryPi, and those people are more likely to be developers.
That is where you would find the manpower to port ReactOS to the RaspberryPi. By not
attempting to woo some developers in the RaspberryPi community, you may be missing out on some valuable assistance
If what I have posted about running x86 programs on ARM architecture is accurate (and I believe it is), then the major reason to not
port ReactOS is gone. If that's the case, if someone from ReactOS says "We think this is a good idea and we welcome any developers who wish to contribute to ReactOS"
, you may
get a decent response (even if only a handful of people decide to join), and someone might port ReactOS to the RaspberryPi.
And if ReactOS can boot to the GUI on an ARMv6 processor (who knows, maybe even within a year, it was close to it before), you may attract the interest of people in the Android
community (which is mostly for ARM devices, and has many developers experienced with porting operating systems and working on kernels). And that could put ReactOS in the right place at the right time.
a quad-core processor will bring to your phone a level of performance comparable to that of a desktop computer.
“People are going to consider their phones as their primary computer,” says Nick Stam, director of technical marketing at Nvidia. “Phones with a quad-core processor are really full computers that can replace many functions of your laptop or [desktop] computer. It is a level of performance that truly does rival a desktop processor.”
I've often heard about people talking about phones replacing the desktop, but that's not going to happen with current mobile operating systems (which are NOT very good for multitasking). Sure, Android and other mobile operating systems may change in the future (specifically, they need something that functions like a taskbar in Windows for fast task switching and closing unneeded programs). Or a different Linux distro may become popular.
I think that ReactOS is quite suitable for filling that niche (desktop replacement OS for a smartphone). Even if it's not fully functional, or it will be some time before x86 could run on ARM without any user intervention, even if windows code never runs faster than 50% native speeds, getting there first
(or at least early) may attract more attention
to ReactOS and lead to more assistance, more developers, more donations, and faster development.
Comments and input are appreciated. If supplying criticism, please include specifics.