Arm Development and Raspberry pi

[PascalDragon]

@BrentNewland:
I'm sorry, that I misunderstood your post regarding your knowledge about the Win32 API.

To be honest: I myself play with the thought to give ReactOS' ARM port a chance on the Raspberry Pi. I'm normally not a C programmer (I prefer Pascal, as my nickname suggests ), but I CAN read, understand and write quite a bit of C, so it might(!) be possible for me to get it to boot (maybe not to GUI, but perhaps to early userspace ). My biggest problem is that I currently don't have time for such an involving project: I have my studies and I'm also working at the Free Pascal compiler...

Regarding your emulation idea: it does indeed sound nice and as Qemu already supports such an approach on Linux one might indeed take a look how that works and implement a Windows variant as well. Afaik (at least as I've tested it last time) you need to specify a path for the guest libraries and Qemu only taps the syscall opcode when the user space talks to the kernel and converts the parameters accordingly. This implies the following:

• it should be possible to support this on Windows (though I don't say anywhere that it will be trivial )
• we'll need a complete set of x86 Windows/ReactOS DLLs, because Qemu only "listens" on the interface from user to kernel space

Of course this list only applies if my assumption about Qemu's implementation is valid.

In theory the support of Qemu's emulation on Windows and the port of ReactOS to ARM could be done in parallel, as in the former enough stuff needs to be done without ARM specific support until it can be used in the latter at all

Regards,
Sven

[BrentNewland]

*edit* I'm disappointed, I'm not even the first one on the forums to think of this. I've just gone into more detail.

Quite correct PascalDragon. Sometimes I have problems explaining advanced concepts, so I'm glad to see that I'm starting to make some sense.

I've done a bit more research and managed to break down the process needed to run x86 executables under different architectures. Note: this actually would work for ALL architectures supported by QEMU, not just ARM. Meaning you would be able to run x86 executables on any platform that QEMU can run on that ReactOS has been ported to.

First, of course, ReactOS needs to be ported to the platform (ARM in this case)

• From what I understand, ReactOS was pretty close in the past. It doesn't necessarily need to work for ARMv6 initially (although that may be a way to attract developers from the RPi community), work can continue on whatever ARM version was previously targeted. Then it should be less work to port it to different ARM architectures.
• Additionally, knowing that there's a possibility of x86 programs running on ARM machines may itself persuade developers who otherwise would've thought there would not be much point in porting ReactOS to ARM for a long time.
• Also, this does not depend on QEMU being completed, and QEMU does not depend on ReactOS being ported first - work can be done inside ReactOS x86, since API calls are dependent on the OS and not the architecture - they should be universal in that regard.

Second, a new user-space emulation module would need to be made for QEMU

• User mode emulation: In this mode, QEMU can launch processes compiled for one CPU on another CPU.
• Qemu usermode emulation is one of the most advanced forms of paravirtualization. It emulates at the syscall to kernel point. So every time application does a syscall the syscall is processed natively. Do all the NT syscalls, have them run arm, returning to the x86 emulated user-space, would help performance a little. Also this would add the means to call gate from the x86 code out to the arm version of Winelib. So reducing overheads of emulation since less x86 code would have to be emulated.
• Currently Qemu userspace operation is that it receives a system call request from a running application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers. Basically there is no guest kernel in qemu usermode emulation. Its the highest level of paravirtualization you can do. Ie no kernel and no devices emulated.
• DARWINE was working on exactly this, but stopped when Apple switched to x86.
• Unfortunately, all the existing user-mode emulation modules are for Linux only.
• On the plus side, depending on how this was coded (if it could be done by QEMU calling the Win32 API directly, like a regular program, without requiring any kernel modification) it might possibly work for Windows 8 on ARM as well (though some modifications would surely be required, it couldn't be as much work as making the module from scratch). This might result in QEMU or ReactOS getting some additional interest from developers.

After those have been done, it may require some integration into the OS (but hopefully it will require almost no integration - in the form of ReactOS modifications).

Most basic method for integration:

• Set QEMU as the default handler for executables

This would require different file extensions for Win32 on different platforms (to make it easier for the OS to run native programs)

• exe = Extension denoting an X86/X64 Executable
• eae = Extension denoting an Arm executable
• epe = Extension denoting a Powerpc executable
• So on and so forth

If it could ever get this far, you will have reduced the barrier of development for ReactOS on ARM (since a lot of people probably aren't comfortable porting operating systems and programming vitualization layers and whatnot).

Which would be useful, because at this point you need to do lots and lots of bug fixes. And then lots and lots of optimization. But it should theoretically run faster than QEMU once implemented, nearly regardless of how optimized it is, simply from the lower amount of emulation that needs to be done.



Also, any work done here would of course have the same benefit for Wine - even if all Wine did was compile the same QEMU that ReactOS used for the architecture Wine is running on (with the OS target being Win32/ReactOS for that architecture) and run x86 programs through QEMU through Wine (thus Wine takes ReactOS's position of processing API calls). That performance should be just a bit slower than doing it in ReactOS.

[hto]

The only problem is to find people who will do it. :)

[zydon]

I don't see QEMU will be running flawlessly on ARM devices any time soon. But I did saw a number of BOCHS emulator running on many ARM based devices with Windows based OS as a client. Lately, I notice there was WinXP client run on Android and if not mistaken on PSP devices also.

I assumed Raspberry Pi which is running Arm11 is similar to ARMv7 devices and Cortex A8 processors which is widely used by Android 2.3 Gingerbread devices and also by Win CE 6.0 and above. Performance wise, it will be an OK speed on using linux for ARM loader but will be speedy if it use RTOS based loader such as FreeRTOS or WinCE (RTOS alike) loader.

Most work need to be done is connecting hardware correctly to the emulator such as QEMU or BOCHS. Once the ROS load into the emulator, the rest is the same like under the x86 environment. ROS even can be updated much more often just by replacing the ROS virtual harddisk for the emulator.

[Haos]

QEMU is really slow on modern, fast x86 hardware... did anyone consider how "fast" would it be on ARM?

[Techno Mage]

BrentNewland - is not info about what the exe runs on in the header of the EXE (that's how windows determines if the exe is x86,x64 or CE, and ARM in the case of Win8), i don't think you need different extensions for each processor type of file. You just need to determine the type of CPU it needs, and pass it to the correct subsystem.

[Z98]

File extensions are an implied convention, not an enforced one. Giving a text file an extension of .exe does not magically make it a PE executable.

[Blackcrack]

some suggestions from me.. maby it is helps..

ma by support for twice... the extenions and seach in the file what it is like Linux
by seach in the header to real know what it is with dll it is need for execute...
it is good to for enhanced Subsystems like ARM even who need
wine as executeed API or other files who work with Phyton ad so on...
and maby later for a little Linux subsystem as addon.. in reactos it is all
posible and stay with open eyes for all options who can where you can ride out

i think...

why not use the direcktly NT-System for spezification Hardwaretechnology like ARM-Supporting and
wine&winnt-Single/User for supporting the executable for Win32 emulating for running Win32
on ARM an USER interface such as the win32 emu includes
and the Admin it is normaly System-Admin on ARM-System (think on System-bibliotecs(dll)-mirroring on users
but even need an new writing win32<->ARM emulator, direcktly on NT-System for User for/in reactos )
(no qemu, no VBox or other, direcktly on/in Reactos)

with the User-"win32"<->Reactos<->ARM<->User-"win32" emulator it is,
like i think possible to use other Architectures for reactos too..

(win32 mean maby programming as emulating win32-plugin direcktly as pluginsystem for
let running androideapps and other as plugin too)

The Reactos as so it s translating for Hardwarearchitecture+User-Account-Emulator(ifneedemulatorforwin32)

Translating Reactos in ARM
Translating Reactos in 64Bit
and without Win32-Emulator in 32Bit for fastest running.. but maby + Pluginsystem and add other like androideapps

in ARM and 64Bit can Win32Architecture run like in a Sandbox... just in a Win32emulator -plugin....

so it is possible to have a Emulator+pluginsystem direcktly in Reactos too..

look on other devices like cellhones with android or other
Reactos need only keyboardemulator and a addon for Phones to use on
some apperates as system or Tablets + addons for telephoning..

open you Eyes and you mind for more possibilitys as only ... a Singlecomputer

ma by only a old singlecomputer on 386 or so. no.. open you mind for all possibilitys
and the newest possibilitys just like Tables, Cellphones and.. was run on XBoxes

Therefor it is need an emulator direcktly in Reactos by side of the User-Accounts just
for Win32emu (& or other emulators as addon like an pluginsystem to let run all)..

as suggestion...... :
Take a look in the ""dos"-Window" on NT, take a look on Java, take a look on AdobePlayer
maby the Emulator drecktly in the account and system check's the haeder and use
the emulator for executing in Win32-plugin or Androide-plugin or other system plugin
direkttranslation for the singleCPU or more Core CPU's in the NT-kernelcode as pluginsystem..
like kemu ...


best regards
Blacky

[Haos]

It just doesn't work that way. Either you recompile software to the architecture you want to run it on, or you are stuck with CPU-abusive emulation. There are no magic tricks.

[Murmur]

Honestly I don't see what all the fuss is about ARM development. Like sure if ROS was stable I would have no issues with people spending a large amount of time porting it but I think there are other more important things to worry about.

[Techno Mage]

The Idea, I put up was, Cheap computer, that users can test with, and bugs can be replicated, since every one would have the same hardware. A sort of OS stability, not so much the running of existing apps.
Once the OS is stable, we the general app programmers can make test apps, to test functionality etc.
And with test apps, it would be easy to narrow down what is wrong, since the source code would be available, an not part of a very complex app.

[Peterbjornx]

R-Pi is not ARMv7, its ARMv6 and i think ARMv9 isnt even released(or designed) yet

Current ARM versions:

ARMv1 ARM1
ARMv2 ARM2, ARM3
ARMv3 ARM6, ARM7
ARMv4 StrongARM, ARM7TDMI, ARM9TDMI
ARMv5 ARM7EJ, ARM9E, ARM10E, XScale
ARMv6 ARM11, ARM Cortex-M
ARMv7 ARM Cortex-A, ARM Cortex-M, ARM Cortex-R
ARMv8 No cores available yet. Will support 64-bit data and addressing

[BrentNewland]

File extensions are an implied convention, not an enforced one. Giving a text file an extension of .exe does not magically make it a PE executable.

And no one has said that it would. Nor has use of magic been implied.

Obviously, different extensions for different architectures would:

(a) Be a way to tell which architecture an executable was compiled for

and

(b) Be a simple way to implement different architecture executables by creating a file association handler in the registry that points to the interpreter.





And again, guys, just to summarize again, it is technically possible to run programs compiled for one architecture on another architecture through paravirtualization with less of a performance hit without recompiling them, it's just very labor intensive to write. This is a proven FACT - it has been programmed for the Linux version of QEMU, it just needs to be rewritten from scratch for ReactOS. And that requires that an ARM port of ReactOS be somewhat functional.

[GUN2k]

BrentNewland wrote
And no one has said that it would. Nor has use of magic been implied.

Obviously, different extensions for different architectures would:

(a) Be a way to tell which architecture an executable was compiled for

and

(b) Be a simple way to implement different architecture executables by creating a file association handler in the registry that points to the interpreter.

Yeah, this was done earlier ... thats the Point between CMD and EXE ... at DOS Times.

BrentNewland wrote... it's just very labor intensive to write. This is a proven FACT - it has been programmed for the Linux version of QEMU, it just needs to be rewritten from scratch for ReactOS.

Just ? You're kidding, right? If you have no problems with do this and it is "just" a matter of time or finger exercise feel free and proof your information.

[DOSGuy]

That seems unnecessarily confrontational for your third post. In the interest of harmony, let's all pretend that he actually wrote the following and respond appropriately.

I think you're understating the difficulty of this proposal. I appreciate that nothing's impossible, but this indeed seems both labor intensive and exceptionally difficult even for a skilled programmer. Anyway, I love ReactOS and look forward to contributing many friendly and helpful posts in this forum for many years to come!