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..."
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.
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.)
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
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.]