I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
What are the technical issues with putting WINE on the PowerPC? So someday we could run WINE with native Windows apps on Linux for PPC or even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible to put a x86 emulator in there, so Win32 apps will think they're on a standard x86 processor?
I've got visions of Windows exes running on Linux for PPC or a running Windows applications on a Mac... I know WINE is far from being done even for Linux x86, but I'd appreciate everyones' knowledge on his question.
Thanks,
Adam Ernst
--- Adam Ernst adam1234@athenet.net wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
Ok, I dont want to sound rude, but you should be glad anyone is replying... Its not really off-topic as there arent any set topics and it certainly doesnt not belong here.
What are the technical issues with putting WINE on the PowerPC? So someday we could run WINE with native Windows apps on Linux for PPC or even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible to put a x86 emulator in there, so Win32 apps will think they're on a standard x86 processor?
Do you know all of the routines for an x86 processor? Neither do any of us ;). If we put in x86 emulator in there then we need a hardware emulator also so that it translates the codes from x86 hardware codes to mac ones. And the only hardware emulator I know of (even for x86) is vmware and it royally sux.
I've got visions of Windows exes running on Linux for PPC or a running Windows applications on a Mac... I know WINE is far from being done even for Linux x86, but I'd appreciate everyones' knowledge on his question.
It really wouldnt be possible, at least not any time within I would say the next 20 years. This has been debated before, and probably will be again ;) but believe me, if it were possible to translate x86 codes into mac or PPC ones relatively easily, (i.e. like it is to translate windows routines into linux ones) then it probably would have been dont already. Now they are working on a PPC port of winelib so you can still run winelib-based windows apps on PPC once that is released.. I'm not sure of the bug number but just go to http://bugs.winehq.com and search for PPC and you will find it, that will tell you more about the status of the port..
-Dustin
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
On Saturday 02 November 2002 07:26 pm, Dustin Navea wrote:
--- Adam Ernst adam1234@athenet.net wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
Ok, I dont want to sound rude, but you should be glad anyone is replying... Its not really off-topic as there arent any set topics and it certainly doesnt not belong here.
What are the technical issues with putting WINE on the PowerPC? So someday we could run WINE with native Windows apps on Linux for PPC or even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible to put a x86 emulator in there, so Win32 apps will think they're on a standard x86 processor?
Do you know all of the routines for an x86 processor? Neither do any of us ;). If we put in x86 emulator in there then we need a hardware emulator also so that it translates the codes from x86 hardware codes to mac ones. And the only hardware emulator I know of (even for x86) is vmware and it royally sux.
Not really. It's not THAT difficult to emulate x86 - after all, many emulators (like snes9x, snes9x.com) do the same thing with very poorly-documented consoles. In fact, there IS an open-source x86 emulator (Bochs, http://bochs.sourceforge.net/).
The real challenge is making it efficient - the Super Nintendo runs at about 5MHz but requires a 300MHz processor to emulate it with decent speed. Unless you want your 800MHz Mac to perform like a 486, you will probably want a more efficient way to emulate it. This is a big challenge, and Wine quite frankly has bigger fish to fry.
Besides, why would you want to run stuff under wine on the Mac? Virtual PC is much better for most things. If you really want to go 100% Windows-free, you could run Linux inside a Bochs session and run Wine on top of that. If you don't use MacOS on your Mac, just get an x86 PC - it will work better with Linux anyway.
El dom, 03 de nov de 2002, a las 08:19, Igor Izyumin escribio:
The real challenge is making it efficient - the Super Nintendo runs at about 5MHz but requires a 300MHz processor to emulate it with decent speed. Unless
It is not a good example, the snes has 2 different cpus, gpu engine, sound dsp engine ..., besides it is necessary a very accurate emulation in order to sync the cpus. It does that it is changing from one cpu to other very continually, around to every 2 or 3 opcodes. A simple 65816 emulation will be very fast in a old 486. Besides the snes emulators uses interpreter cpu emulation, and it is very inefficient, the last-generation emulators uses dynarec emulation, what is X times faster. (good examples are ultrahle, corn or vgs).
Regards, Carlos.
On Sunday 03 November 2002 08:47 am, Carlos Lozano wrote:
El dom, 03 de nov de 2002, a las 08:19, Igor Izyumin escribio:
The real challenge is making it efficient - the Super Nintendo runs at about 5MHz but requires a 300MHz processor to emulate it with decent speed. Unless
It is not a good example, the snes has 2 different cpus, gpu engine, sound dsp engine ..., besides it is necessary a very accurate emulation in order to sync the cpus. It does that it is changing from one cpu to other very continually, around to every 2 or 3 opcodes. A simple 65816 emulation will be very fast in a old 486. Besides the snes emulators uses interpreter cpu emulation, and it is very inefficient, the last-generation emulators uses dynarec emulation, what is X times faster. (good examples are ultrahle, corn or vgs).
Yes, I'm aware of that, but the PC has nuances, too. You can't just write a simple x86 emulator for Wine and expect it to work seamlessly. It won't. I was just trying to make a simple analogy. UltraHLE is substantially more complex than a simple emulator, and implementing good x86 support in wine would take substantial time from a talented developer who could otherwise improve it in more important aspects (such as running more applications). You have to face the facts that Macs have a small market share, are relatively expensive, and that few people want to use them to run the same old buggy apps that they used on Windows. Most of them don't run under wine anyway.
The main focus for wine right now is implementing the API and making a substantial amount of the major Windows programs work flawlessly. Most of them already run on the Mac. Most people who have a Mac and want windows can afford a copy of VirtualPC. This is simply an issue of priorities.
On Sunday 03 November 2002 02:26, Dustin Navea wrote:
--- Adam Ernst adam1234@athenet.net wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
Ok, I dont want to sound rude, but you should be glad anyone is replying... Its not really off-topic as there arent any set topics and it certainly doesnt not belong here.
What are the technical issues with putting WINE on the PowerPC? So someday we could run WINE with native Windows apps on Linux for PPC or even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible to put a x86 emulator in there, so Win32 apps will think they're on a standard x86 processor?
Do you know all of the routines for an x86 processor? Neither do any of us ;). If we put in x86 emulator in there then we need a hardware emulator also so that it translates the codes from x86 hardware codes to mac ones. And the only hardware emulator I know of (even for x86) is vmware and it royally sux.
There is bochs (bochs.org) which is a true hardware emulator of x86 machines. It runs on many architectures (AFAIK it runs on PPC). It has stable releases and it is open source. The only drawback is that it is really slow, because all x86 instructions have to be emulated. The installation of windows 9x takes some hours.
I've got visions of Windows exes running on Linux for PPC or a running Windows applications on a Mac... I know WINE is far from being done even for Linux x86, but I'd appreciate everyones' knowledge on his question.
It really wouldnt be possible, at least not any time within I would say the next 20 years. This has been debated before, and probably will be again ;) but believe me, if it were possible to translate x86 codes into mac or PPC ones relatively easily, (i.e. like it is to translate windows routines into linux ones) then it probably would have been dont already. Now they are
You could try to merge wine with bochs, and you would get a windows emulator on PPC. But it would be really slow, so there is no use for it. If there will be use (like if the hardware will be fast enough, and architecture other than x86 will be more common) the merge will occur pretty quickly...
Regards Zsolt
Zsolt Rizsanyi wrote:
On Sunday 03 November 2002 02:26, Dustin Navea wrote:
--- Adam Ernst adam1234@athenet.net wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
Ok, I dont want to sound rude, but you should be glad anyone is replying... Its not really off-topic as there arent any set topics and it certainly doesnt not belong here.
What are the technical issues with putting WINE on the PowerPC? So someday we could run WINE with native Windows apps on Linux for PPC or even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible to put a x86 emulator in there, so Win32 apps will think they're on a standard x86 processor?
Do you know all of the routines for an x86 processor? Neither do any of us ;). If we put in x86 emulator in there then we need a hardware emulator also so that it translates the codes from x86 hardware codes to mac ones. And the only hardware emulator I know of (even for x86) is vmware and it royally sux.
There is bochs (bochs.org) which is a true hardware emulator of x86 machines. It runs on many architectures (AFAIK it runs on PPC). It has stable releases and it is open source. The only drawback is that it is really slow, because all x86 instructions have to be emulated. The installation of windows 9x takes some hours.
Does bochs employ JIT compilation? I know that even modest JIT support provides great runtime improvement.
You could try to merge wine with bochs, and you would get a windows emulator on PPC. But it would be really slow, so there is no use for it. If there will be use (like if the hardware will be fast enough, and architecture other than x86 will be more common) the merge will occur pretty quickly...
I believe you are wrong. Sure, emulation is not as fast as native code, but that's exactly why a merged wine+bochs may be much much faster than installing Windows in a VM.
In the former case, you find that only the native app requires actual emulation. As soon as OS code (wine, in this case) is called, you switch to native mode, and take it from there using native calls.
What is required in order to do that: 1. Winelib must be fully supported on that platform. 2. Endianity conversions must be performed on all >1byte values. This means that the native code must work with structures that are little endian. Personally, I'm not sure why that does not hold true to winelib apps as well. 3. The CPU emulation need to be extracted from your emulator, as that is the only thing necessary for such a setup. There is no need for any kind of hardware emulation, as all hardware access is translated to native OS calls.
It is, in fact, point #3 that makes this combination faster than running a full blown emulator. It also holds true to the Wine name - the wine code is not used (is not) as an emulator.
Regards Zsolt
It is, in fact, point #3 that makes this combination faster than running a full blown emulator. It also holds true to the Wine name - the wine code is not used (is not) as an emulator.
Just to point out that EXACTLY the same discussion took place here not that long ago (in August precisely) with the 'Wine Ma os X port' subject :-)
Lionel
On Sun, 3 Nov 2002, Shachar Shemesh wrote: [...]
Does bochs employ JIT compilation? I know that even modest JIT support provides great runtime improvement.
AFAIK (i.e. not much) Boch does not support just-in-time compilation. It would certainly be a nice addition to it but I am told it requires a lot of work.
[...]
I believe you are wrong. Sure, emulation is not as fast as native code, but that's exactly why a merged wine+bochs may be much much faster than installing Windows in a VM.
Here I disagree. If the emulator is fast enough to run the application, then it should be fast enough to run the application plus Wine. Reciprocally, if it is too slow to run Wine, then I think you will find that it is too slow to run your application too.
Even so I think it should be faster than running Windows in an emulator because you will not run two filesystem layers, two graphics engines, and you should be able to dispense with a full virtual machine, i.e. you should not have to set apart memory for the virtual machine which means you share the disk cache, etc.
[...]
What is required in order to do that:
- Winelib must be fully supported on that platform.
- Endianity conversions must be performed on all >1byte values. This
means that the native code must work with structures that are little endian. Personally, I'm not sure why that does not hold true to winelib apps as well. 3. The CPU emulation need to be extracted from your emulator, as that is the only thing necessary for such a setup. There is no need for any kind of hardware emulation, as all hardware access is translated to native OS calls.
There is a lot more: * you must keep track of the status (x86 or PPC) of all callbacks so that you can convert parameters if necessary * you must keep track of the status of all winprocs for the same reason * you must also take care of the alignment issues (in addition to the endianness)
And I am sure there are quite a lot of other issues that may crop up. This is as much work but probably more than supporting the 16/32bit dichotomy, or supporting both Ansi and Unicode functions.
I really think that the rational thing to do is to run Wine inside the emulator (which should work for all Linux x86 applications).
On Sat, Nov 02, 2002 at 05:37:13PM -0600, Adam Ernst wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering...
What are the technical issues with putting WINE on the PowerPC?
Native PowerPC (using WINELIB) works. For the other issues see the other mails.
Ciao, Marcus
-
Adam Ernst -
Carlos Lozano -
Dustin Navea -
Francois Gouget -
Igor Izyumin -
Lionel Ulmer -
Marcus Meissner -
Shachar Shemesh -
Zsolt Rizsanyi