Can WINE Be Ported to OS X?

geek asks: "With all the buzz around Darwin running XFree86, is there any hope of porting WINE to OS X? This could be a major factor for some people to move over to the platform. Since OS X has some FreeBSD roots my guess is it wouldn't be terribly hard to get WINE working under it. Now that Apple has an OS with UNIX in the floor boards the possibilities seem endless."

processor compatibility

[zarqman]

because wine is a reimplementation designed to support running native windows code and because os x is generally running powerpc machines, i would suspect the answer is no. 99.9% of windows programs are written for i386 and won't run on a powerpc, regardless of os. yes, you probably could get wine itself ported, but you'd have nothing to run on it. you would need a full emulator to deal with the i386 instructions -- a bit more than wine offers.

# cat .sig

What I want to know is...

[phr1]

Can WINE be ported to Win32?

BOCHS is probably more likely but...

[Time Kills]

WINE is not an emulator. This is actually important as WINE doesn't emulate for instance an Intel processor, its more what I'd call a mapping layer and a set of libraries to implement chunks of Windows. As mentioned, WINE could probably be ported but it wouldn't be helpful. <p> Something like BOCHS which actually emulates the processor as well is more likely. When OSX takes off I'd expect Connectix to be release a commercial Windows emulator though, just as they have for many years now.

What was the question?

[DougM]

If the question means:

Could WINE be ported to Darwin?

Then the answer is yes but it would only actually work under Darwin for Intel and would require quite some effort

If the question means:

Could WINE run under MacOS X on my PPC?

Then the answer is no -- unless you want to run it under an OS running inside an x86 emulator!

WINE no, but WINE+Bochs?

[BRTB]

WINE by itself wouldn't help much on a PPC, since it's only acting as a translator for the Win16/32 API calls, not the x86 machine code. Now if you could graft bochs to it, so you'd emulate both the x86 processor and the Windows API's, it might work.

Of course at this point I'm thinking of the old saying about thing being easy to those who don't actually have to do it...
BRTB

Wine over VPC

[arete]

You can port wine. (as stated above)
You can't run i386 code on a PPC using only Wine (as stated above)

You can already run Connectix VPC on a PPC to emulate an i386 machine, and it works pretty impressively, imo.

The disadvantage of this (and bochs) is that it requires a copy (legal or otherwise, of course) of a windows operating system. And windows backdoors, etc, will still be present. Which is why running Wine OVER VPC might be a good idea... I thought I saw linux VPC the other day, although perhaps I was hallucinating. This would be a totally free legal solution... I only worry about the speed hits... I'd guess not too bad, though.

Answering two questions

[kcarnold]

Wine on WIN32 -- yes people are trying with cygwin. It may work soon. Currently there's only linking problems left AFAIK.

Wine on OSX powerpc -- nope, it's a powerpc. But winelib yes -- there has been lots of talk and no action from reading the Wine lists, but it can and probably will happen. It might have to wait for the OSX (darwin) development platform to get a little more friendly (e.g. some important libraries are in different places or nonexistant in the public beta's developer CD). I'm sure help would be welcome if you want to try -- there are already OSX Xservers, so there a major stumbling block falls (though a native version would be nice and probably run faster, not to mention being more useful for developers porting over apps for users, not developers, to use).

Re:processor compatibility

[Grond]

I believe what the question was getting at is that could WINE be made to function on top of Darwin running on x86 with XFree86 as the X server. I can't think of any reason why this couldn't be done (WINE is, to my knowledge, POSIX compliant...at least enough that it runs under the BSDs as well as Linux). However, what real benefit this would serve (until x86 Darwin is useful for something other than being technically interesting) is not clear. It would seem more practical to just run WINE under Linux, thus benefitting from the many as of yet unported Linux applications (unless someone duplicates the BSD Linux emulation under Darwin; I apologize if they have already).

Re:Answering two questions

[kcarnold]

nope, sorry.

I'm sure...

[Wakko Warner]

...once (if ever) OS X arrives, there will soon be plenty of commercial Win32 emulators -- there's already a wealth of them for OS9.

- A.P.

--
* CmdrTaco is an idiot.

Re:Ummm... why?

[spectatorion]

A non-windows, non-vpc solution is better than than because (to address your three points):

• It's just a matter of time until free software overtakes proprietary, buggy software, so maturity doesn't matter. WINE and LinuxPPC can be upgraded continuously until they perform better than VPC
• Emulating the entire system is unneccessary, when you are already running an entire system (i.e., MacOS). WINE a much more elegant solution, translating the system calls. Underneath, you would need an emulator for the processor instructions, but this is still better than the overhead of running an entire OS on top of another OS (in addition to emulating the processor). Any compatibility problems can be taken care of with ease, since the source is available. There are people who maintain the project and whose job is to add functionality.
• Just wanted to point out that in comparing VirtualPC to WINE ro LinuxPPC, you said that VPC is "relatively cheap," which means that relative to WINE or LinuxPPC, VPC is cheap. This is obviously not true. WINE and LinuxPPC are both free as in both can be obtained at zero cost. LinuxPPC is free as in speech, and WINE has source available, though is not GPL, which means it does not necessarily have to stay open, although, there will always be archives on the unlikely chance that the source becomes closed (not this is very, very unlikely, but I felt I should address it as a possible counter to my argument.). VPC costs ~$150 plus the cost of the OS you run on top of it (usually Windows which is $180+ for a full copy). Technically speaking, VPC+WIN is infinitely more expensive than WINE or LinuxPPC, not relatively cheaper.

Eventually, the better product will triumph, and it is easier to make free software better than it is to make prorietary software better (in the long run).

-----
# cd /

Ummm... why?

[HerrNewton]

Other than having it for free. I'm going to go out on a limb here and guess that Connectix isn't going to let VirtualPC fall by the wayside, nor is the maker of BlueLabel, etc. Ports are likely, in other words. Yea they're closed, commercial solutions but, for the time being, they've got a few advantages over WINE on MacOS X or LinuxPPC:

* They're available now and VPC has 4.0 maturity

* They emulate an entire Win-32 system, not just bits and pieces. More overhead, but I'd gather less compatibility problmes.

* Relatively cheap.

Patience grasshopper. Who knows how well VirtualPC will run under MacOS X if it's made into a cocoa app?

----

Virtual PC

[Microsift]

Maybe I'm missing something but wouldn't you just want to use Virtual PC(assuming it gets Carbonized)

Re:Ummm... why?

[HerrNewton]

I agree with you in that eventually WINE or some WINE-like package will be the best solution. But for the immediate future, VPC will continue to be the best available option if not just becuase it's the only option.

"Relatively cheap"---relatively cheap compared to the cost of another computer, not to WINE. WINE doesn't factor into my cost comparissons as its not yet available for MacOS X or, to my knowledge, LinuxPPC. Of course when it becomes available and feature-equal to VPC it becomes the better option.

----