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."
Apps are not running natively:
"Developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X..."
QEMU...
A house divided against itself cannot stand.
Easy question to answer, and fairness has nothing to do with it. Mac OSX applications all have windows counterparts except for the obscure ones. But only die-hard mac lovers "need" those. Besides, linux users would have to emulate the ppc instruction set, which no linux user in their right mind would consider a viable way to run a generic application that has a windows counterpart.
How many people use MacOSX? How many of them Code for GNU/Linux/X-windows with deep knowledge of the low-level stuff needed? It's got to be less than 20.
Heh... there HAS to be code to CALL these functions. This code is good old x86. Else, I could run my windows binaries on ... say Windows NT for Alpha. If that were the case, why is there a whole Visual Studio for Alpha Platform?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
"The second phase is to then integrate in WINE the QEMU binary translator."
that comes later then.
world was created 5 seconds before this post as it is.
Let me Clarify myself. If you read the article, you notice DarWINE combines WINE with a back-end emulator. The package, as it stands, is a syscall wrapper along with a back-end emulator. Hence, DarWINE *is* partially an emulator. [and the fun recursive acronym isnt as appropriate]
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
How about a way to run Max OSX apps in Linux???
Well, if you're on a PPC architecture already, there's Mac-On-Linux. Though, I'm sure that by the tone of your comment, you actually meant x86. Well, ask and you shall receive. For the x86 folks (or just about anyone on Linux), there's PearPC. And you know what? They're both open source...
that crossover has managed to overcome. When will the code be incorporated back into Wine?
Sorry to break your preconceptions, but for sometime now Crossover has been very diligent in submitting their improvements upstream into WINE. Photoshop compatibility should already be checked in...
... is on a Windows machine.
I have a Windows box with XP Pro to which I connect using Microsoft Remote Desktop Client for Mac (There's a port of the OSS RDesktop app available too).
Bearing in mind how cheaply one can acquire an x86 PC capable of reasonable performance (no app run over remote desktop will ever be *fast*), this has to be the most efficient way for users of low-powered macs to run Windows apps.
You can even full-screen it and freak out your mac-addict friends by showing them a Mac with, apparently, Windows installed on it.
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
I have Photoshop 6 running pretty well on my slack laptop with wine 20040716, but couldn't get Photoshop 7 running.
GETPKG - Package Management for Slackware
Recompile with WineLib is what they mostly have working now. They ARE integrating an emmulator to allow the execution of x86 binaries. But that is not ready for use.
NetBSD is working on Darwin binary compatibility. Something similar could be attempted by Linux.
Please correct me if I got my facts wrong.
According to their FAQ they are integrating a binary translator called QEMU. Their intention seems to be to have the wine libraries native and have them talk to the windows app (still x86) through qemu. This sounds like an interesting idea, especially if their additions to wine and qemu are integrated into the main trees. Then linux on other architectures could likely take advantage (if qemu has been/is ported to that architecture).
It is... it's called PearPC. I set up OSX this weekend on an AMD64 3200+. It's PearPC is emulating a 1ghz G4 and I must say it's pretty sweet.
Motion, iMovie, Final Cut Pro, etc...
One could argue that there are PC apps that have the same purpose as these apps, but some are merely adequate while others are near offensive.
(Shake would be included too, if it weren't for the fact it was a Linux app before it ever was a Mac OSX app. Still, the Linux version likely won't see updates anymore.)
EphPod.
There, now you can have an iPod too.
Another poster already mentioned GNUStep, so I won't talk about that. But what he didn't mention is that OS X has support for "fat" binaries, that include both x86 and PPC code (or any other arch, for that matter). This means that a fat GNUStep/Cocoa binary should be able to run on OS X and some x86 platform (like Linux or FreeBSD, or even Windows) without a recompile. All the second platform needs is support for fat binaries as well.
In light of all the excitement over C#/Mono, It's sad that nobody knows about this.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Solidworks and AutoCad come to mind.
Or any of the thousands of PC only programs out there that people need to do there jobs. Many vertical market programs only run on the PC if it became easy to write for the Mac and PC using Winelib you could see some apps become available for both platforms
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Dude, google for OpenStep and GNUStep. Your wish has been granted. That'll be five bucks.
What about iBank?
Look, it's trying to think - Albert Rosenfield
LinuxPPC users can already use MacOnLinux to run MacOS X and all its apps natively in the Linux environment, with almost perfect compatibility.
"I like systems, their application excepted", George Sand (French)
Well, GNUStep runs on top of x11. I was thinking about a project that would also replace x11 completely with Quartz backend.
Then you're not talking about cloning Cocoa, you're talking about cloning Quartz. Huge difference.
Start with GNUStep and GhostScript, and work from there.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
QEMU works just fine on the G5. VPC made some optimizations by using native x86 endian compatability which does not carry to the G5. I do not believe QEMU has these optimizations, which can be seen as a good thing or a bad thing. :)
Yes, Quicken for Mac is quite horrid. I actually don't like Quicken for Windows anymore either. For all my banking needs, I have been using (for a few years now) Quicken 8 for DOS, available as a free download from Intuit. It's the newest DOS version, and actually has most of the same features as the newest Windows or Mac versions. I run it in Virtual PC, but since it's a DOS program, there's no reason you couldn't run it in a GPL emulator, like DOSEMU or something.
I said, "a fat GNUStep/Cocoa binary." Keyword: GNUStep/Cocoa, which would be the "single UI toolkit" you're looking for. Analogy: GNUStep:Cocoa::Mono:.NET
The only real difference between GNUStep and Mono is that GNUStep apps use Objective-C instead of C#, and get compiled to native code instead of P-code (or whatever) and so don't require a virtual machine.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The most commonly mentioned difficulty is the number of registers in PPC vs. x86. RISC instruction set architectures like PPC tend to have a relatively large number of general purpose registers, vs CISC ISA's which have a smaller number of registers, some of which have special purposes. (CX for count, SI, DI for offset indices, ..., my x86 knowledge is VERY stale, so I'll be vague from here on)
..., r17..r32 available) The CISC ISA emulating the RISC will tend to
In emulation, to keep things fast, you would like to dedicate one hardware register for each emulated register, plus you need hardware registers to actually run the emulator!
A RISC ISA emulating a CISC ISA will enough registers to do so. (r1 = AX, r2 = BX,
1) need to use the most flexible registers (AX) to run the emulator (e.g. load the RISC opcode from RAM into AX, extract the opcode field, compare it to your opcode table, and dispatch, because AX has the best support for bit operations, let's say)
2) also use the special-purpose registers to run the emulator (e.g. use an index register to index into your opcode tables)
3) leaving too few registers to hold all the emulated registers (oops, we only got r1..r3 in the left over registers; what about r4..r32...)
4) having to use "weak" or wrongly-specialized registers to hold the key RISC registers which are heavily used in the actual RISC program. (E.g., your program is trying to number crunch so it wants to do a lot of floating-point math on data which is being stored in some left-over CISC register which doesn't support floating point natively.)
[note, I'm well aware that x86 is not a CISC hardware implementation under the hood, but to the assembly programmer, it presents a CISC instruction set architecture. Emulating the underlying microcode RISC engine, however, would likely need even more registers, causing the same problems, so you would tend to emulate the CISC model.]
although repeted elsewhere this should answer your question:
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.
Working for a large chain of hospital's data center we have over 210 database front ends for over 160 different locations. These are applications that my not even have source code still in existence due to the original vendors going out of business, changing owners, or just plain lost it. to recode these from scratch would be a huge undertaking.
Wine allows us to run these applications on Linux/x86. although this wouldn't be of much use for OSX wine is a very useful program and Office/Outlook are more like benchmarks rather than needed applications. with OpenOffice and evolution there is little to no need for Office and Outlook, there is a need for the hundreds of small un-replaceable un-portable applications.
I just realized this doesn't really answer your concern, but still I think it is good information so I will post it anyway.
Paying taxes to buy civilization is like paying a hooker to buy love.
(CX for count, SI, DI for offset indices, ..., my x86 knowledge is VERY stale, so I'll be vague from here on)
I can see that. Since the advent of 80386, scaled-index-base byte, non-fixed-operand multiply etc, most of the special-purposeness has been gone. Except for ESP of course.
Well it seemed really useful, but of course I followed the directions and installed the programs to run exe files on OS X, installing the necessary X11 package. So I tried all the example exe files and, no dice. All it does is say it can't find the graphic drivers I just installed, something about X Server, then quits.
I'm just gonna check back when it actually works.
I am NOT a number! I am a - oh wait, I'm number 761710. Look! 761710!