Slashdot Mirror
Interview - Jim White of the Darwine project
Kelly McNeill writes "The Darwine project intends to port and develop Wine as well as other supporting tools that will allow Darwin and Mac OS X users to run Windows Applications. It is an open source project led by a growing number of developers including Emmanuel Maillard, Pierre d'Herbemont and Sanjay Connare. osOpinion/osViews had the privilege to speak to with the project's administrator, (Jim White) to tell us more about Darwine and where the project is headed. For those that don't know, Darwine is Wine (Wine Is Not an Emulator) for OS X on PPC. The following is the transcribed dialog of their conversation which is also available in an audible format on osRadio.com."
From the website: "We are currently working on integrating an x86 emulator in wine in order to run Win32 exe on a PowerPC Box. But on Darwin-x86 a Win32 .exe should run within wine" http://darwine.opendarwin.org/faq.php#5
:-)
So yeah it will involve an emulator on PPC but remember that Darwin is also on x86. So WINE will still be NE but will be used in conjunction with something that IE (is an emulator).
I thought wine only simulated the Windows API calls, so you still need to be running the program on the native windows cpu, x86. Can someone explain how this works on PPC?
Do you realize that in less time than it took for you to write your questions, you could have clicked the link and saw that it uses QEMU to map x86 to PPC instruction calls.
It didn't even require a 'googling' on your part, just a click.
Wine emulates Win32 function calls. A second application QEMU emulates the Intel 386 instruction set and hardware environment. So a Mac can emulate an Intel PC.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
...it'll most likely be limited to Linux PPC. The problem is emulating a PPC processor on x86 hardware. It is much harder than the other way around.
Kjella
Live today, because you never know what tomorrow brings
If you've got the source code, then it's probably not that hard to port it to GNUStep. You'll need to translate the .nib files (UI definitions), but you'll probably need to tweak the UI when not running on a Mac anyway if you want it to have a consistent look and feel with the rest of the platform. Currently GNUStep's implementation of Foundation and AppKit are fairly complete, and applications that only depend on these can be moved fairly easily between GNUStep and OS X. The biggest problem is that the non-Apple version of gcc doesn't support Objective-C++, so if your application mixes Objective-C and C++ (as is the case in WebKit, where the core is C++ but the interface is Obj-C) then you will not be able to compile it.
I am TheRaven on Soylent News
Its bad enough that Metal and Aqua are mixed interchangably without any rhyme or reason...mix in X11 apps and now Windows apps and I think we can safely say that visual consistency in OSX is gone.
There is actually supposed to be some rhyme and reason to the Aqua/Metal looks in OSX:
Apple Human Interface Guidelines
See the section on Windows -> Window Appearance -> Brushed Metal Windows
However, if developers choose not to adhere to these guidelines, there's little that can be done, unless the apps get hacked. Turning on metal is as simple as toggling a switch in XCode and Interface builder. You can disable the metal look in Safari by editing it's preferences as well...
And this helps them sell Apple hardware, how, exactly?
[
Well, it would help them sell iPods to me, since I have no Mac and refuse to use Windows.
The idea for as I understand it is this:
... overhead city), Darwine allows applications to run essentially linked to native code - Wine/WineLib for PPC.
When the project is complete, OS X users will be able to open EXE files with Darwine. Darwine will use QEMU to execute the x86 instructions, however when the program makes calls to the Windows API, Darwine calls those functions in WineLib compiled natively for PPC.
So, where Bochs and VirtualPC and others like them emulate the entire operating system environment (Emulated BIOS, emulated hardware, emulated Windows, and finally the emulated x86 application
Thus for most Windows applications, the GUI and event handling and everything else the Windows API is good for will be executed in native PPC code. QEMU will then emulate an x86 processor for all the compiled code in the application.
Imagine some internal corporate application that uses all standard Windows widgets to let a user interact with some data: all those widgets plus the menu and root pane will be handled by the native WineLib code except when the programmer has included some special functions or number-crunching routines that are emulated on QEMU's fake x86.
Think about it -- It's a lot better than having an entire emulated instance of Windows 98 (and maybe even an actual x86 box) to do the same thing.
There are quite a lot of people that used to be Linux users, but have adopted OS X as a better form of Unix. I'd imagine a fair proportion of them are programmers.
My parents won't switch to the Mac because their stock charting software (from some tiny company in Michigan) only runs under Windows. Probably not representative of most people's needs, but then again, maybe a lot of people have one or two obscure apps they need to run?
It is sad that even on slashdot this question is still ask.
Why do they do it?
Because they can.
People will start understanding good UI when they realize that a skin!=good UI.
The OS X Metal look is rarely good UI, unfortunately.
Why yes, I AM a rocket scientist!
Like what? What is there that easily allows people to create databases that exist as a single file, which can be sent to others in email and opened without any setup at all?
Rather than be able to run an emulated X86 app on a Mac, wouldn't it be better to make it easy to build a native mac app using winelib?
A few tweaks here and there for byte ordering stuff, and presto, a native Mac app. Plus you could have conditional logic to be even more mac-like. No drive letters, etc.
Any good reason not to take this approach?
Posted from my Android phone. Oh, I can change this? There, that's better...
Even Microsoft realizes Access is a piece of shit. In the MSDN article on pricing software from Friday, the guy used Access as an example of a program that would be VERY valuable if replaced by a better interface with plugins to an open source database.
And yes, there is an open source JDBC driver for Access. But it is so poorly supported (by developers that have no time to even write documenation of how to use it and who don't speak English) that you are much better off dropping $100 or so on one of the commercial replacements or writing your own.
Hey freaks: now you're ju
wine is split into two parts.
wine the program loader - the part you use to run windows binaries on linux is close to an emulator. Really just more like a binary format like elf or a.out that is run in user space rather than kernel space.
libwine is the library used to port the windows api to Linux. it is similar to gtk or qt in that it allows a program to make winapi calls and they get translated to the appropriate X calls similar to any of the other Linux GUI libs.
wine the program loader wouldn't be very useful on OSX because there probably isn't many apps for the windows ppc port. libwine on the other had will allow the easy porting of windows applications to OSX or Linux. So far this hasn't been exploited as much as it should be, mainly due to the wine folks wanting a perfect 1.0 release, when they may be better off getting what they have so far as stable as they can and doing a 1.0 release with X features supported and Y features not supported. then go from there. (their project their decision though)
Paying taxes to buy civilization is like paying a hooker to buy love.