Here a status report on Wine (Windows compatibility layer without emulating an entire computer) for non-x86 hardare (PowerPC, ARM, MIPS).
PowerPC does not seems attracting any interest, it is nearly there to be dropped, maybe we can show some interest!

Here the status report by André Hentschel, a Wine developer
PDF slides

Last edited by virgolamobile on 28-Sep-2015 at 09:14 PM.

@virgolamobile
Wine on raspberry pi
https://www.youtube.com/watch?v=aXnXWXrfNzs
Hmm seems i accidently deleted a video

Last edited by phoenixkonsole on 28-Sep-2015 at 09:39 PM.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@virgolamobile

Yes the best way is contact the Wine alternative developer and write "PLS support PPC!"
Right now wine on ppc is really in pre alpha status from ages ... this why there is not interest of it... many users try to use wine with the qemu-user for have it running on ppc hw

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@virgolamobile

Well it seems PPC works according to it. But it only has PPC32 and no mention of PPC64 so a bit dated. In any case Wine on any non x86 hardware is not as efficient since it still has to emulate the CPU. I take it there is no JIT? That would make it on the level of ExecSG emulaton or Petunia. And similar to 68K on AROS x86.

@virgolamobile

where can I get a copy of wine for my PI 2 ?

@Hypex

check this one guy was did it in spare time

https://www.youtube.com/watch?v=eBSYPze-1qU

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

Write the program and film it!?

I'm wondering what this GC thing is. Should Google it. But the term is too general.

@Hypex

Quote:

Wine on any non x86 hardware is not as efficient since it still has to emulate the CPU

Actually, Wine doesn't need any X86 emulation. But then, you're restricted to native Windows software available for your host CPU (if you ever thought that the Amiga software situation is bad, think again )

@Jupp3

Quote:

Actually, Wine doesn't need any X86 emulation.

In this context it would as simply emulating the API but not the CPU of the binary wouldn't run Windows software on PowerPC!

@tlosm

Yes cool stuff this guy is doing but we can't contact him

_________________
- AmigaX1Ooo with OS4.1FE // CD32/SX32Pro/SX1/CD32Shuttle
- A600-Vampire600 FPGA // A4KT/CSPPC233,144MB,PCI, AOS4.1.6FE
- MACmini 1.5GHz // Pegasos 2 1GHz // Efika
- ATARI Falcon/060/SuperVidel // ATARI Falcon MK X

@virgolamobile

Who had previously wanted, and who had worked on Wine-PPC in the past? I remember Darwine (for MacOSX-PPC) kindof went poof when Apple changed from PPC to Intel. The mass market for Wine-PPC vanished quickly at that point.

And at that point, PPC became known as a network router chip, a car engine controller chip, an Airplane chip, an industrial chip, etc. My car, airplane, and router don't really have a useful use for Wine or MS Windows apps.

Who remaining uses Linux-PPC in a desktop context, to have a useful need for Wine?


In what context is it about to be dropped? Because no Mac users remain, and they don't know or care about we AmigaOne XE/uA1/x1000/x5000 users?

What do any remaining Wine-PPC developers use for hardware?

Might the Linux/BSD PPC notebook people be interested in reviving Wine-PPC? That group might be interested in this as well, and sound like a more fruitful target for Wine-PPC devs that AmigaOS usually sounds to anyone outside of our community.


Then there are more technical questions.

What host OS API(s) does Wine-PPC support? Linux, OSX, BSD?

What needs done to support OS4? (probably a lot) And who is available and willing to do that?

What x86 emulation does non-x86 Wine use? I think I remember Bochs in that role in the past, but it's been several years since I've read about it. I think it would be nice if it moved to Qemu.


Which brings us to more technical questions.

Do we have a working port of the correct version of Bochs or Qemu or whatever the x86 emulation side uses today? Who is available and willing to maintain this?

Does this emu, on PPC today, support the right x86/x64 features to be useful today? Or would it let us run up to Win88 apps? Is that useful and worth bothering with?

If the current level of Windows apps possibility would be too obsolete to care about, then what needs worked on to make this worthwhile? Enhancing x86 emulation to support newer MS Win features? Adding 64bit support to which side of the emulation? Such as adding x64 for more modern MS apps, and/or ppc64 support for a more complete x64 universe? Can an x64 app live comfortably in a ppc32 host, or would that be too cramped of a memory space to work?


I have a vague idea at the moment of what we've been told to expect for OS4.x multiprocessor and 64bit support. It's been a while since I've read on that, and I'm very sleep deprived this weekend...

Would the planned OS4 64bit support allow what would be required for a proper x64 emulation layer?

I understand (please correct me if needed!) that each CPU core will run an independent copy of AmigaOS.

In a multiprocessor system, such as x1000 or x5000, could this emulation be placed onto its own dedicated CPU core, possibly in a different mode than the main or other cores? (Such as if running Amiga apps in 32bit mode, and run Wine-PPC as a special thing on a 64bit mode core, if they can be set independently?)


I'm not really sure how well an Rpi port can represent an OS4 port or a Linux-PPC port. The Linux stuff at least shares the Linux API to share more code. An OS4 port would be foreign, and likely require a lot of from-scratch work for it all to plug into our OS API. Maybe use ixemul/amicygnix types of tricks along the way.


Thinking of the 32bit vs 64bit mode thing above, that gets me thinking about how one might sandbox classic Amiga 32bit apps onto a 32bit mode core, while "new" 64bit-native apps in general could go onto a 64bit mode core. But this is probably a separate thread topic.

_________________
All glory to the Hypnotoad!

Quote:

In this context it would as simply emulating the API but not the CPU of the binary wouldn't run Windows software on PowerPC!

Well, there's source-compatibility, if we can recompile the MS app to link to PPC-native implementations of the MS API. No x86 emulator needed here.

Then there's binary compatibility, for those things we do not have source code for to recompile... Then yes, x86 emu is required.

_________________
All glory to the Hypnotoad!

@billt: there's absolutely no 64-bit support on OS4, and it never will be added, since the lack of resources, and in general because they want to keep backward-compatibility with the existing applications.

So, the OS4 doom is to stick on the 32-bit PowerPC mode, even if the CPU is 64-bit capable. And the only way to get benefits from memory >2GB is through the horrible 8-bit-like bank-switching mechanism that they already provided.

I don't think that, in such conditions, a WINE port can have chances to support Windows x64 application with their 64-bit pointers (unless you want to restrict them to the lower 2GB of memory).

Last but not least, Windows supports DLLs which share memory using the MMU. It'll be tricky (not impossible) to support such mechanism.

@billt

if ... the qemu-user-i386 will ported to amigaos you will be able to run wine on amigaos.
what is needed are dev libs for qemu that we dont have right now.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm
Wrong.
Wine translates Windows API calls to Linux API calls.
Amigaos is not Linux so wine will not work.

You could use a combination of amicygnix(minimum Linux)

Qemu-usermode would allow to run Amigaos x86 apps on amigaos ppc.

As a hint:
Qemu-user mode plus wine worked for older version of wine.. The last combination was from ther wine 8.xx series. They changed something regarding ptthreads back then which broke compatibility.

It was in the Debian 5.0 times. Sometimes it is better to stay with old software on old hardware ; )

Last edited by phoenixkonsole on 05-Oct-2015 at 07:48 AM.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@billt

Quote:

Well, there's source-compatibility, if we can recompile the MS app to link to PPC-native implementations of the MS API. No x86 emulator needed here.

Yes you could do that if there is no Linux native port. And it would be an efficient means of doing so. But it's unlikely that an open source program can't be compiled to run natively on Linux. And AFAIK Wine is best with closed source programs that cannot be ran any other way except on Windows.

There is also a flaw even with being able to compile Windows programs for runing on PPC. Windows binaries are lttle endian. And most codes are ignorant or oblivious of their code not working on another CPU. So unless the code exclusively uses lttle endian PPC instructions you've got a good chance it will break before it left the starting line. So a customised compiler as well as a Windows clone link libs will be needed. And given the API is little endian on the ABI that would make sense.

The endian problem isn't helped by compilers either. I see a lot of examples where the programer is looking for an ID in a file header and searches for "DAEH" indtead of "HEAD". Where the file actually begins with "HEAD". This shouldn't matter. The x86 CPU should read "HEAD" into a register reversing it as "DAEH" and the programmer should be able to check for "HEAD" since the compiler should have reversed it to lttle endian coding to "DAEH". But for some reason they didn't do it that way.

@Hypex: it's not up to the compilers (unless there's specific support endianess), but to the coders the endianess issues.

@cdimauro

Endianess are no more PowerPc now is little endian too

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm: endianess problems can happen even if a processor supports (and has enabled) a certain endianess.