macOS can WINE be used like Carbon?

[GregA]

Hi,
I was wondering if anyone knows if WINE can be used like Carbon.

Is this hypothetical situation possible:
1) Company has a program for standard (Win32/"Classic") WindowsXP and decides they want to have it run on Linux
2) Company ports the application to run using WINE, on Linux (some APIs wouldn't be supported I guess)
3) Finally, a single binary now runs on WINE and/or WindowsXP (perhaps with some OS dependent branches?)

If this was possible, it could mean that an Apple-supported WINE would be an excellent option for porting from Windows to Mac. "Just port your app to WINE and have the best of both worlds."?

I assume this has been discussed at length already so my question has a simple answer?

 

[alex_ant]

Wine is too low-level. The apps would not have a native Mac look & feel, and would be slow and unstable (unless Apple could *massively* improve Wine). It's the "we have to try to catch up to Windows and be compatible with it" attitude that hurts Linux - always playing catch-up, and to a mediocre OS no less. The Mac needs to forge its own path, stand on its own and not worry about Windows developers.

 

[GregA]

The apps would not have a native Mac look & feel

I agree with that and the rest of what you say - and that's something I'd also like to ask about...

But first, are you saying it IS possible to write a WINE binary that works on both? (even though the interface would be ugly and functionality limited since you'd never have the latest Win32 options). Or (I guess) is it possible to have a windows souce code with 2 compile options (like Xcode) - WINE and Windows?

 

[Nermal]

CodeWeavers, a Wine distributor, has announced that they plan to release a Mac version next year. It'll require an Intel system.

 

[cbiffle]

Windows compatibility, the Mac experience, and the death of OS/2

*nod* The same binary would work on both, since that's the exact goal of WINE -- to run Windows binaries unmodified.

Now, if the company were interested in porting the app to Unix, they could use Winelib, a product of the WINE project. Winelib is basically the WIN32-API-faking layer of Wine, rolled into a separate Unix library -- you can compile a native Unix app using the standard Windows calls you know and don't love.

This is closer to the Carbon example, I think.

However, I for one am sort of mortified about the prospect of people bringing Windows apps over to Mac unmodified. It's what killed OS/2, in many ways: it could run Windows apps, so (nearly) nobody bothered to support it natively. Sure, the apps were ugly, didn't integrate with other programs, and crashed more often than native apps -- but they ran!

As the user of several programs that are just baaaaarely supported on Mac already (Citrix, a VPN client, some time-tracking apps), I hope it doesn't go this way.

Update: I should clarify. Windows apps running through WINE will not be clunky and ugly because WINE lacks the latest Windows features; even if WINE were positively state-of-the-art, the apps would still stick out like a sore thumb, because of the degree of consistent feel and integration we expect from Mac apps. (Think of how many apps can access the Address Book for various reasons, or read your iPhoto library to insert photos, or even just use the native Mac font or save dialog. None of those features would be available.)

 

[GregA]

*nod* The same binary would work on both, since that's the exact goal of WINE -- to run Windows binaries unmodified.

Now, if the company were interested in porting the app to Unix, they could use Winelib, a product of the WINE project. Winelib is basically the WIN32-API-faking layer of Wine, rolled into a separate Unix library -- you can compile a native Unix app using the standard Windows calls you know and don't love.

This is closer to the Carbon example, I think.

However, I for one am sort of mortified about the prospect of people bringing Windows apps over to Mac unmodified. It's what killed OS/2, in many ways<snip>

Thanks for the info. The use of Winelib does seem to be a better opportunity - as it offers developers an easier way of porting their app but it does require their involvement and support of a separate package.

I guess I'm just wondering how Apple could entice developers over, and yet retain the OSX interface guidelines. Apple once said to classic Mac developers "we'll help you move your classic code across with an API we've called 'carbon', 85% of the work is done for you".
- Could Apple use Winelib to get developers writing on Xcode? (writing to Mac interface standards of course).
- Could they make some version of Xcode that would compile apps for OSX or WindowsXP?

 

[7on]

Personally when I buy my first x86 Macintosh, I'll also be purchasing a recompile VPC for x86 (if the port is done by then). I wonder if even then VPC would even allow the option of using the direct hardware, because one of the appeals of VPC is that you can open the same disk image on many computers and not have to change drivers because the hardware looks the same to the virtual machine... perhaps it could be a check box in the VPC prefs?

 

[GregA]

Personally when I buy my first x86 Macintosh, I'll also be purchasing a recompile VPC for x86 (if the port is done by then). I wonder if even then VPC would even allow the option of using the direct hardware, because one of the appeals of VPC is that you can open the same disk image on many computers and not have to change drivers because the hardware looks the same to the virtual machine... perhaps it could be a check box in the VPC prefs?

Wouldn't that be a choice of either
1) use the same disk image and same drivers on a purely "virtual" machine
or
2) use the direct hardware (and different drivers and disk image)

Anyway, I agree if MS releases VirtualPC for the Intel Mac it'll be the most compatible way to go. I'm surprised MS hasn't integrated the interface more even in the current version (instead of having a separate screen) in fact, it would seem they have no need for having WindowsXP on virtual x86 on OSX when they could simply make a "Windows on OSX" product.

edit: Did you read that Yonah is supposed to allow multiple OSes running side by side on the chip? I don't know how that works, but on Freescales new dual-core chip they say they can have a different OS on each core.

 

[RacerX]

I'm surprised MS hasn't integrated the interface more even in the current version (instead of having a separate screen) in fact, it would seem they have no need for having WindowsXP on virtual x86 on OSX when they could simply make a "Windows on OSX" product.

I guess you didn't realize how hard it was just to get Classic to run as the current semi-integrated GUI with the rest of the system.

Originally, Blue Box was a completely different environment (booted from a disk image). It took Apple a few years to make the changes needed (and they were not able to get passed the need for a rooted start up)... and this was Apple (maker of both Mac OS X and Mac OS 9). Microsoft doesn't have that kind of access to Mac OS X... and I wouldn't think that the development cost would justify it.

As for the question in the topic of the thread... no, WINE can not be used like Carbon. Carbon is an integrated set of APIs. At best, WINE would be like X11... in fact, it will most likely have to be run within X11. WINE (to my knowledge) is closely tied to the X Windows system... which is completely different from Apple's Aqua environment.

 

[dongmin]

Personally when I buy my first x86 Macintosh, I'll also be purchasing a recompile VPC for x86 (if the port is done by then).

Personally, I wouldn't put too much faith in MS. They've done jack with VPC since buying Connectix. VPC for Mac was always a marginal product for them. MS could easily come down on the side of "What's the point of keeping supporting a virtual machine when you can just dual boot?"

 

[GregA]

I guess you didn't realize how hard it was just to get Classic to run as the current semi-integrated GUI with the rest of the system.<snip>
Microsoft doesn't have that kind of access to Mac OS X... and I wouldn't think that the development cost would justify it.

Actually I thought MS might justify it more from the basis of convincing developers not to bother with the Mac as Windows apps run pretty integrated anyway.

As for the question in the topic of the thread... no, WINE can not be used like Carbon. Carbon is an integrated set of APIs. <snip> WINE (to my knowledge) is closely tied to the X Windows system... which is completely different from Apple's Aqua environment.

My analogy with Carbon was based partly on the fact that Carbon only helped with 85% of code, and required changes to be a true OSX app, as well as interface updates. The reverse engineering used in WINE could help Apple do that IF THEY WANTED.. (a BIG IF), but as you say WINE as it stands is of little help.

Personally, I wouldn't put too much faith in MS. They've done jack with VPC since buying Connectix. VPC for Mac was always a marginal product for them. MS could easily come down on the side of "What's the point of keeping supporting a virtual machine when you can just dual boot?"

They could just as easily come down on the side of "well, let's make VirtualPC run really well so we can abandon Office-for-Mac.... we can keep the Mac interface perhaps too"

 

[Fukui]

However, I for one am sort of mortified about the prospect of people bringing Windows apps over to Mac unmodified. It's what killed OS/2, in many ways: it could run Windows apps, so (nearly) nobody bothered to support it natively. Sure, the apps were ugly, didn't integrate with other programs, and crashed more often than native apps -- but they ran!

Well, apple could just leave out the GUI portions of the library and include only the MFC and stuff, so developers that have thier business logic tied to windows could port very easily while only needing to rebuild the GUI in a native way.

I think that would be a reasonable compromise...

 

[GFLPraxis]

Off topic; what would happen if VPC was run on OS X/x86?

Imagine.

Rosetta runs VPC in PowerPC emulation. VPC emulates x86. Install OS X/x86 in VPC and repeat the cycle...

 

[caveman_uk]

Off topic; what would happen if VPC was run on OS X/x86?

Imagine.

Rosetta runs VPC in PowerPC emulation. VPC emulates x86. Install OS X/x86 in VPC and repeat the cycle...

Isn't it slow enough already?

 

[jcgerm]

Why not just run Windows natively?

 

[GFLPraxis]

Isn't it slow enough already?

Yeah but it'd be some kind of world record!

 

[Nermal]

Don't forget that guy who installed OS X on his Centris