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.
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
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...
... 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
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
Dude, google for OpenStep and GNUStep. Your wish has been granted. That'll be five bucks.
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.]
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.