*.exe files on XP compiled to Arm

[Dietmar]

Hi all, I have a small question:
Would any *.exe file, for example Quake II,
would run on a XP, compiled to Arm? I mean, the normal *.exe file, only XP compiled...
Nice idea ???, what you think, if the *.exe file does not know anything about hardware,
Dietmar

PS: Qemu works like an interpreter, this would work with XP as compiler in real-time.

[ErvKosch]

Probably not. Anything on XP would be compile to run on an X86 processor and use Windows' API set. The RasPi has an ARM processor and will use Linux so the Linux API's will be different. There are ways to get some of the Windows' API to work on Linux (through WINE) but its not perfect.

Your best bet would be to get the source code and recompile it on an ARM 7 processor. I know some of Quake engine has been open sourced.

[Dietmar]

@ErvKosch
Hm, how can the *.exe file identify, which Processor is working in underground,
when the calls reach files with the same name and entry points as before,
nice to hear from you Dietmar

[obarthelemy]

I'm not quite sure I understand your question. I think it is:
1- I'm running XP on ARM, via QEMU emulating an x86 on ARM
2- Should all Windows XP software work ?

My answer then would be: most, not all
- I'm sure there's way for the software to work around the emulation and really check what's going on. Games may do that for copy protection.
- QEMU probably isn't perfect, there must be bugs, or non-conform behaviour in some cases, or missing features. Especially games that expect to be executing shaders/code on a GPU via DX9. I'm fairly sure QEMU can't use the ARM's GPU in any effective way; so it's counting on the game or the OS to switch back to CPU-based software rendering. Some games may refuse to run in that case and *require* hardware shaders, or just be unable to run due to very poor performance.
- the performance will suck so much, that the software bugs out.

[pieter]

Usually a .exe file is a compiled and linked file.
This means it is converted from humanreadable code to machinereadable code.
The machinereadable code is only "readable" for the specific processor type it is compiled for.

Qemu emulates the processor.

Example. This piece of text you are reading now is in english. It is only readable by people (cpu's) who can read english. The text itself doesn't know if you can read english.

[abishur]

This is just like how a 64-bit Windows program will not run on a 32 bit computer. The underlying foundation of code it's relying on is all messed up. So if you did compile a XP ARM... and somehow got the video to work for it as well, you'd still have to recompile the software you wanted to use as well. This is what we're face on the linux side. While there's already a large repository of ARM packages, for anything extra we want to use it is necessary to recompile it for ARM.

[kme]

"Would any *.exe file, for example Quake II, would run on a XP, compiled to Arm?"

As I'm 100% sure you do NOT have access to the XP source, then you have ZERO chance to recompile it (XP) for ARM. Even if you did have access it would be a huge effort as the ARM platforms is very different from a x86 platform.

[Dietmar]

@kme
We will see ...
The example from abishur, that it is like to run a program, compiled for 32 Bit XP on a 64 Bit XP is a very interesting comment. This makes me just sure, that you do not need the source code to make it run but needs a lot of work,
Dietmar

EDI´T: I start to like my idea a lot. Windows NT4 on Alpha just emulates x86 code.
Windows 2000 run on Alpha. Is this slow?
Is here in the forum anybody, who tried to run a program like MS Word, written for x86 on a machine like above? I think, it would start .

[Svartalf]

Quote from Dietmar on October 7, 2011, 18:27
EDI´T: I start to like my idea a lot. Windows on Alpha just emulates x86 code.
Is this slow? Windows works on risk machines in the past.


Yes, it did. It was only slightly slower than a stock X86 machine at clock.

However, you're oversimplifying the effort here to do this sort of thing.

1) You'd need to HAVE an emulator able to do this in the first place.
2) You'd have to have it stitched into Windows if you wanted it more seamless- or have an X86 XP install to emulate against.
3) You'd have to have the CPU you're sitting on have enough oomph to emulate the other CPU architecture cleanly and quickly.

Technically, with QEMU and a copy of XP, you've got "1" and "2". With the R-Pi, you don't have "3" for anything worth mentioning. The reason they were able to do this on an Alpha is that the Alpha was so vastly faster than the X86's of the day that emulation made it close to the same performance.


Is here in the forum anybody, who tried to run a program like MS Word, written for x86 on a machine like above? I think, it would start .

Yes, I have ran stuff like that. If you've got the framework, yeah, it'd work- but you didn't run the X86 stuff directly on an Alpha, you ran it within the context of something similar to what QEMU provides today- namely you ran it inside of something like FX!32, which stitched the Windows API calls into the X86 runtime and you emulated anything within the binary's code space, thunking the transitions to native code. You couldn't directly run ANY X86 NT code on the Alpha- it's part of what crippled sales of the systems. Seriously. In theory, you could do something much like this, but you're not going to do it with XP. You might be able to do it with WINE- as WINE's really pretty much X86 only right at the moment. But that would be a MASSIVE undertaking. And, for this, you'd be providing an old PII level of performance at best.

[Dietmar]

@Svartalf
Thank you very much for your answer. This can be a very powerfull and interesting talk here.
kernel.cpp which just gives compiled ntoskrnl.exe,
that starts my XP, from where I am writing. And there exists compiler from x86 to ARM on the market. My question is not, if XP can start from any ARM hardware, because it can.
My question is, what is with all the programs that are written for x86 XP.
Is it possible, may be with some small modification, to make them run on that ARM XP?
Dietmar

[Huulivoide]

The biggest problem here is that .exe/.dll file is for ONLY for Windows. Every exe/dll uses some some parts of the Windows' programming interface. Meaning that you would hav to rewrite the whole thing to use the Linux versions of all those functions.

Another problem is directly in the file format. Linux uses ELF files and not the 'Portable Execuatble' [exe/dll] used in Windows. The actual data of the program is stored differendly in these 2, so Linux can't load and run code, even if it were native Linux code if its inside exe file. Same for Windows.

Third problem is that practically any app that does somesort of compute intense crunching of data usually has some optimization that are made to use the features presented only X86 family of processors. (SSE/SSE2/MMX....).

So.... You need the source code. You need to strip it off from EVERY single piece that is not pure platform independed code, and replace it with something that is compitable with Linux. Then you also need to strip it off of any x86 spesific code.

Rewriting the app from scrach would be faster XD

[Svartalf]

ARM XP? Is there such a beast outside of Microsoft's software labs?

As for being able to run them, NO, you're not going to be able to do that without doing the very thing I just told you with my previous post. There's some info that you'd have to change to tell the .EXE it can be loaded like any other DLL on it's CPU type. The problem lies in that the guts of the application are in the machine language of the machine architecture that they were compiled for- unless it's a "managed" application. At that point, if you've got all the right runtimes in hand in ARM, you could get it to run launched from Mono. If it's not a CLI interpreted binary, you're going to have to emulate like I described or not at all.

This, really, is kind of a moot point, isn't it? Unless you've got source code for XP Embedded, you're not getting ARM XP, now are you?

[Dietmar]

Hi Svartalf,
in a week I have holidays and we will see, if Video on Youtube appears.
You can build your own Kernel, just look at
http://kernelexplorer.net/blog.....ernel.aspx

What do you think: If you have a full, with agreement from Microsoft , compiled version of XP on ARM, with a lot of dll's. Can, or with small modifikation, most available programs for x86 architecture run on it? And when you think not, why not,
now you Dietmar

[abishur]

The answer is still no I fear, even if somehow you were able to overcome the fact that the software isn't compatible with the processor, you'd still face the issue of no GPU driver

[tufty]

Is it possible, may be with some small modification, to make them run on that ARM XP?
Short answer : Not realistically

Long answer : You need a significant amount of things to do this, and the result will be bloody awful at best.

The first thing you need is a way to make X86 code work on an ARM processor. That's (to put it mildly) non-trivial, but such things do exist. The processor "hit" that you will take is significant if you want to do this on the fly (i.e. you want to be able to run J. Random Virus^H^H^H^H^HXP App on your RPi), you'd be lucky to get emulated performance anywhere close to 50% of your nominal CPU speed. Realistically, for a 700Mhz ARM, you'd be looking at emulating something like a 200Mhz Pentium.

You could probably get better performance by *statically* recompiling to an ARM executable "offline", but that's a lot harder to do than recompiling on the fly, and certain things are close to impossible to statically decompile.

Secondly, you need a license for XP. I'm not certain, but I'm fairly sure decompiling is explicitly disallowed in the Windows license terms - I'm not sure where that would put you in terms of running it on an emulator. It would almost certainly disallow static recompilation.

Then you need something that bridges the Win32 API to your host system API. That's also far from trivial - WINE tries to do this under x86 (i.e. without the recompilation phase), but still fails to run everything.

Other issues you might well hit are the memory and storage overheads of running Windows emulated on a machine with, at best, 256MB of memory.
My question is not, if XP can start from any ARM hardware, because it can.
Not as anything other than a guest operating system running on an emulated platform, it can't.

[Dietmar]

@tufty
Hi, no easy thing at all, this is clear for me.
I remembered, that there was an NT4 SP2 for Arm. With very small modification, this should run on real Raspberry Pi hardware. And running a dependency check on a normal XP for a programm compiled for x86 gives you a chance, to see what is going on,
Dietmar

[jamesh]

I don't think NT4 has ever run on Arm, SP2 or not.

[obarthelemy]

Wikipedia tells of Windows for PowerPC, MIPS and Alpha, not ARM.

Maybe we can ask the guys to switch CPUs ?

[tufty]

Quote from Dietmar on October 8, 2011, 13:13I remembered, that there was an NT4 SP2 for Arm.
You remembered wrong. But even if it were the case...
Quote from Dietmar on October 8, 2011, 13:13With very small modification, this should run on real Raspberry Pi hardware.
NT4 was released ~1996/7, so the ARM chips it might hypothetically have run on would be, at best, ARMV4 (i.e around the power of Apple's Newton 2100 or so). As such, "very small modification" is liable to mean :

- Changing all the coprocessor calls, which will have changed (this is binary level futzing around, and liable to mean rewriting anything that deals with video, sound or other peripherals). If you don't got source, or *at least* a detailed description of how the copro calls happen on both architectures, it's simply not gonna happen.
- Changing all the hardcoded timing loops, interrupt handlers and other low level crap.

There's also the possibility that ARMV4 code is actually ARMV4T, i.e. code that uses the 16 bit "Thumb" instruction set. Whilst a modern(ish) ARMV6 core will run ARMV4 32-bit instruction set code (albeit suboptimally), a modern(ish) ARMV6 core will not run original Thumb code (Thumb <-> Thumb2 are not interoperable).

So. Best case, as there are no (as far as I'm aware) ARM binaries of the NT kernel floating about, is that you have the source to the NT kernel and associated libraries. Let's assume NT3.x rather than 4 or greater, as at least the video driver is out of kernel space. You have a significant porting job to do (and one that you don't have documentation for much of) before you can compile. Once you've compiled it, what do you have? An out of date kernel that still won't run x86 binaries, nor, in all probability, WinMo / PocketPC binaries.

Quote from Dietmar on October 8, 2011, 13:13And running a dependency check on a normal XP for a programm compiled for x86 gives you a chance, to see what is going on,
It gives you nothing. Nada. Zilch. Zip. Rien.

It would be trivially easy to cut down a 12" vinyl disc to fit in a CD drive, but it ain't gonna play in it, no matter what you do.

[Dietmar]

@tufty
I like to do things, which are impossible
Dietmar

[Dietmar]

This gives you a nice chance, to test if your XP works
http://maemo.org/packages/pack.....ne/1.3.25/
When I understand right: Normal Wine makes Windows programs in x86 run on Linux x86. This special Wine makes Windows programs compiled to Arm run on Linux Arm, right?
Dietmar

[jamesh]

Quote from Dietmar on October 9, 2011, 13:42
This gives you a nice chance, to test if your XP works
http://maemo.org/packages/pack.....ne/1.3.25/
When I understand right: Normal Wine makes Windows programs in x86 run on Linux x86. This special Wine makes Windows programs compiled to Arm run on Linux Arm, right?
Dietmar

Correct. You will need to compile the Windows program for Arm for this to work. Although I have never seen that done. You would need source code for the Windows app for starters, so you would be limited to OSS software.

[Dietmar]

Hm, I wonder why Qemu says to me during compiling for i386 from ArmDebian, where cat /proc/cpuinfo shows to me ARM1176 CPU, that it sits on an armv4l machine.
This would simple mean, that qemu ONLY generates code for the Arm 4 family and that must be compatible with Arm1176, in other case I would not see the desktop.
What do you think about this? Is there in Qemu a switch like --enable-sdl to tell qemu on which prozessor it just sits at the moment??? That would be a little bit crazy
Dietmar

Edit: I found this:
ARMv5 can run ARMv4, ARMv6 can run ARMv5, and so on. Each new
architecture is a superset of the old ones, and the only reason to compile
for newer platforms is speed. (ARMv5 code runs about 25% faster than
ARMv4 code on hardware that can handle it.) The oldest architecture this
goes back to is ARMv3 (which introduced 32-bit addressing), but that
hardware is obsolete (not just no longer being sold, but mostly cycled out
of the installed base).

[Dietmar]

Yes, this is true. I looked on the Arm homepage. An XP compiled for ARMv4 will also run on a Cortex-A15 Platform. This is really interesting. When there is an NT4 out for ARMv4, so it can be used for everything. Also very interesting for the coming Win8 on ARM: If they do not want, that this is used on ARMv4 architecture, they have to do something against binary compability ,
nice to hear from you Dietmar

[obarthelemy]

There are new features with each ARM version, some core, some optional. That Cortex can run v4 does not mean that v4 can run Cortex. New stuff includes Thumb2, VFPv3 (optional), NEON (optional), Jazelle, Trustzone... Windows 8 only has to use one of those to be incompatible with v4... and even with current CPUs that wouldn't implement optional parts required by Win8. Saying v4 can run Cortex code because Cortex can run v4 is like saying 8086 can run Core code because Core can run 8086.

I'm guessing Win8 will use at least some of those new features, for performance or functionnality reasons, regardless of whether MS really want to break backwards compatibility. Plus the chance of a left-over ARMv4 system having 1 GB of RAM is slim ^^