Darwine! WINE for Mac OS X is coming - Page 2

At this point in time, there is no emulation involved in Darwine. All it does right now is translate instructions from Windows API calls to Linux API calls.

And EVEN IF they manage to shim BOCHS into WINE, it's still very, VERY unlike VirtualPC. The individual instructions may be converted to PowerPC like in VPC, but whereas VirtualPC is a virtual machine WINE is a translation engine.

Barto

Do you remember in 1994 when the first 68k emulator appeared in MacOS 7. At that time it was really slow. And then a new version of the emulator bring a huge improvement to the speed of the emulation.

In the interim, an article in MacTech (September 1994 Volume 10No9) explains how the Apple emulator works and offer some way to improve the first version. I was wondering if it was not possible to build on this principle to create a new and faster x86 emulator in PPC assembly language (and not in C like Bochs)...

I think it could be interesting... This combine with the native speed of the Win32 Lib could bring a new level of emulation...

Of course, there will always be the problem that WINE bring not the full Win32 library but a subset of them...

Wouldn't the point of DarWINE (being separate from WINE) be to convert the windows api calls to darwin api calls instead? (which are then converted again by bochs, of course)

Haven't read the story, so i might very well be wrong, but it would kind of makes sense. Otherwise one might just as well use standard WINE.

WINE simply translates the calls, and rewriting it to use the Darwin/Mach calls would be hard work, when Mac OS X supports most Linux calls anyway (and many calls are the same across Linux/BSD/Darwin).

Better to get a working product out now, then improve the speed of BOCHS, rather than do some not totally necessary rewriting of WINE.

Barto

Why Bochs?, its VERY SLOW!

Check this out - x86 emulator

Unless bochs has dramatically improved their code since July 03, qemu or valgrind would be preferred?

Still this is a VERY interesting project, its certainly has my attention.

There is only one obvious, though not good enough, advantage to using Bochs. It's already ported. qemu does look an order of magnitude better than Bochs, and from the looks of their website, though not entire obvious or clear, it will run on PPC.

I was browsing the Mailing List Archives for "mac os x". In the first message I read (Oct 06 03), someone said they had some things comiling, and something about ELF binaries. The next message (Oct 27 03) notes that Panther now emulates the calls. If you search a little more in the list, you'll find that it now mostly compiles (from relatively old messages and pages). I wonder why they don't use this instead, since if it's not done, it's really close. Is it a license issue?

qemu certainly looks VERY interesting, more like VPC speed than BOCHS speed.

I checked Valgrind's web page, and it "finds memory-management problems by checking all reads and writes of memory are checked, and intercepting all calls to malloc/new/free/delete."

Looks like Valgrind isn't an emulator as such but can be used for development work in the same way an emulator can, so it's not relevant to Darwine.

Barto

I read this at http://www.macwindows.com/ first, sorry! With the WINE effort and qemu, the Darwine group "simply" make the two efforts work together.

Now this is something I hope Apple would advance some of its talent to make the x86 emulator 'optimised for the G5'.

I would guess this would be very strategic for Apple, which Apple 'for obvious reasons' may be supporting this effort covertly and for the same reasons the Linux community supprts WINE Why?

Just my 2 cents

Edit: FIXED! \

I apologise!, didnt paste the link in properly!, agreed its damm annoying for non functioning link!.

The original release of the PPC version of MacOS 7.1.x ran a very large portion of its code through the 68k emulator because the OS still contained large portions of 68k code. The major reason that subsequent versions of the emulator grew faster is that it had less to do. Another reason is that Apple made major improvements to ToolBox ROM functions. There has been very little improvement in the 68k emulator itself.

It may be a nice fantasy that a magic emulator will substantially increase the execution speed of x86 code on the Mac. However, it will not happen.

qemu seems to do what the second version of the 68k emulator of MacOS does back in old days: dynamic translation. The foreign code is translated into native code and then keep in memory. It's that new translated chunk of code which is natively run on the processor. This way a code must be convert only when even if it's executed several times.

In the case of MacOS, the fact that strategic APIs have been ported to PPC over time have also increase the overall speed of the emulation process (like a complementary use of WINE can do on a x86 emulator) but the core of the emulation engine also improved at this time (System 7.5).

That would be great if some talented Apple developer could work on a project like qemu to bring it to maturity more quikly.

In the past years X11 has been successfully integrated to the MacOS X to ease the port of Unix application. It would be cool to see another step like this with x86/WIN32 application compatibility... It recalls me the rumored "Red Box" project.

This is how VirtualPC's recompilation engine works, which would be a big reason why qemu appears to be about the same speed as VPC.

Darwine is intended to run Windows applications as Mac OS X applications, or at the least X11 applications (which with Apple's utterly fantastic X11 window server and manager feature graphics acceleration - a huge plus).

If they actually get everything working, and it doesn't end up being dog slow, Darwine would probably not replace VirtualPC.

Darwine might be a real option for everyday users wanting to "protect their investment" in Windows applications... unlike VirtualPC you don't actually run Windows and the applications appear like native (or at least native X11) applications, so it is infinitely more attractive for more regular home use.

However, that is also a downside in that WINE is less compatible than actually running Windows inside a Virtual Machine, and so VirtualPC would remain the product of choice for obscure business and hardware support applications that are Windows only.

Barto

If you are running VPC, a Windows virus can ruin your VPC disk image like a real PC, but nothing outside this one. Now, does what you are saying about Darwine means that a Windows virus can damage the OS X installation?

Yes, I saw that in the FAQ page: they went with QEMU instead of Bochs.

If I understand well, Darwine means that I can recompile an application using (a subset of) the Win32 API to run under MacOS X/X11? This is awesome!

I wonder if Darwine is PPC-native, that is that it doesn't use the QEMU emulator itself? It would make sense. The x86-specific code in the application would be handled by QEMU, and the remaining would run at native speed.
How much of a PC program is stuff that is already implemented in the Wine library? How much of it needs QEMU to run on a Mac?

Imagine in the future, installing X11 would install Darwine as well, giving instant access to a range of (fast!) Windows applications!

There is a shell script that sets it up someplace but I cannot remember where right now.

In x11 make sure you CD to the directory and put a ./ in front of wine

Wow!, they must have just updated their site. Im curious?, I hope they didnt JUST discover QEMU!, sorry, Im rarely cynical. That said, QEMU is using some of Bochs bios.

One test might be to see how fast QEMU runs under x86 - its suppose to be about 4 times slower (integer) and 10 times (floating point) - translated to some real world experiences?.

Add WINE for x86, and this might give some indication on the type of performance we could expect?.

From the look of the following article

http://www.vnunet.com/News/1125594

WINE is not very susceptible to virii, but it CAN happen. Rarely. Unlike VirtualPC, which is just as suceptible to Windows.

Barto

I'm thinking about it. As a Pocket PC developer we do have source for our own windows apps. I've been wanting WINE for OS X since we moved back to the Mac. I don't care about emulation...just WINE so I can recompile against it. When I have time I guess....

Doesn't the emulator need to run an operating system? It seems like Wine on a PC doesn't just run on x86 hardware, it instead runs within an Operating System which is running on x86 hardware. So it would seem that Darwine would need to run on an emulated x86 OS. If that is the case, which OS are thy emulating? It would be interesting if it ran on a port of Darwin x86. If an OS doesn't need to be emulated, please explain plainly why it doesn't.

Alexander the Great

Let me see if I've got this straight. I can see Darwine working in two different ways. It seems like you are describing the first way I'll now try to describe to see if I've got it straight.

Method One: Darwine (a program that needs to be run inside an OS, just like any other program) will run in PPC Darwin, but it will translate many of it's instructions using an x86 emulator.

Method Two: Darwine will run in Linux (or another OS) which is being run in an x86 emulator.

Alexander the Great

P.S. I understand how wine works when run on x86 hardware. I know that it doesn't need Windows to run programs. And yes there are x86 ports of Darwin. At least by how I define a port, a compiled binary for some particular hardware. There are Darwin binaries compiled for x86, which sure seems like a port to me. If my definition of a port is wrong than there's no disagreement. It's not a big deal any way, that's why it's in a "P.S."

Or wait, even better, if Darwine could run Windows applications that are compiled for PPC natively and applications that are compiled for x86 would be run using the emulator/code translator. That way if something is compiled for PPC, then it would run real fast, but if it wasn't, it would still be able to be run.

Alexander the Great

VPC works by emulation an x86 processor. Doing so, you can run any x86 OS on top of it. For Windows applications, you run a version of Windows with all its system files and everything. A Windows application, works with the files describing the WIndows API. (This is what I gather from the Wine site.)

Darwine = Wine + QEmu. QEmu emulates the x86 processor. In theory, you could run anything x86 on top of it, but thats not the goal of this project. Wine, is used to translate (not emulate) system calls to their Linux equivalents (again what I gather from the Wine site). QEmu takes these instructions and converts it to PPC code for execution. Now, I assume for this project, that the middle conversion to Linux code will be eliminated. Im goin to try to visualize this.


Initially, the Windowing would have to be done in an X11 environment. Though eventually, you might be able to put an Aqua face on it.

With additional development of the Windows APIs available to Wine. Things will become much easier to run. Currently, I believe, you must build from sources for Wine. Im not sure if the additions will eliminated that, but it will definently enhance the available options.

---
Neither method is correct if I'm reading them correctly. Method 1 is close. I've made a few changes:

Method One: Darwine (a program that needs to be run inside an OS, just like any other program) will run in PPC Darwin, but it will translate Windows instructions using using Wine, which are translated into PPC instructions with an x86 emulator.

I think I have all this right. And to make the websites available easily on this page and from my post.
Wine
Darwine
QEmu

You're welcome. The Home page for WINE states in its first paragraph that you can use DLLs if they're available. I'm exactly sure what they are, but I assume that if you have some Windows files, things might work a little better. I guess.

Has anyone gotten this to work yet? The binary I downloaded as well as the original source distribution aren't working for me in any capacity. Actually, none of the commands that I've tried to use to even get it to run have worked (X11 Terminal) and a search for anything involving the app on my hard drive only turns up the package and the package receipt.

Speaking from an Integration perspective, this project would have to rate as one of the most important open source projects going around!.

I hope developers get behind this! (are you listening Apple!).

I could sell a ton MORE Apple boxes if those 'pesky' few windows apps would work without running windows OS.

Darwine on a G5 15" iMac - for the businesses is my humble request!

I earnestly hope that Apple never endorses such a project and never includes it with its computers.

Such a move would say to developers, "Why bother writing a native version of your titles when the Windows version will run fine?"

Unwise.

Like VirtualPC, this would be fine for third-parties to work on and ship. That'll mean the majority of users probably still won't have it.

You may think this is good from your perspective. In fact, it may be good in the present. Look at it from the developers' perspective, though. The same issue existed with Classic, even. I cite the length of time it took for Quark to get XPress running natively on Mac OS X. Developers won't port for fun; they'll need a damn good reason to do it. If an existing version will work, why bother rewriting a lot of it from the ground-up for Macs?

The reason why alot of firms reject the Mac platform, is because there is almost ALWAYS a few industry specific apps that are required for day to day business. The majority of computing requirements are taken care of the Mac. As a result Apple misses out on alot of potential business, even Linux recognises this here

This is why, IMO, this is SO important. I understand that Apple promotes developers of native OSX code, and I NEVER stated that Apple would include this as a integrated OS capability, that could be political suicide and like you said, may send the wrong message to developers.

The reality is such that there are literally hundreds of windows apps that will NEVER be ported to the Mac, because 1. it most likekly cost prohibitive to do so. 2. Whats the point if the market share for Mac is 3%?, and 3. They likely to be too industry specialised.

Lastly, your absolutely right in an ideal world, but unfortunately this is reality and MS has 90%+ of the computing mindshare!, Sorry \

I don't see Darwine working exactly like it's described above. As I understood it from a developer point of view, WINE (and so Darwine) is a set of libraries that match the WIN32 libraries. When they run on Linux x86, they allow a WIN32 application to work on Linux without the need of Windows.

From what is described on the Darwine site, the WINE Lib has been ported to native PPC code on MacOS X. So a WIN32 application for which the source code is available (or the developper of an application) can choose to compile it under Darwine to make it avaible to the MacOS X community.

As such it is already really interesting to accelerate the port of a particular form of applications to MacOS X: games. But it will be really interesting for this purpose when the Darwine project will have a Direct3D support (on top of OpenGL).

The next step in that project is to include the x86 binary translator Qemu in Darwine so that x86 WIN32 applications could be run without modifications. That could achieve a high level of performance because all the time the application time passed in the WIN32 APIs will be running native code. The only x86 code that will remain will be the code of the application itself. This operating mode will be closed to the one of the MacOS 68k emulator.

As it is described on the WINE web site, this is a huge work due to the fact that the binary memory format of the data manipulated by WINE on PPC is not the same as the format provided by the x86 part of the application (due to litte endian/big endian and memory alignment). So the Darwine project must include the necessary convertions here (which will be costly in term of execution time). It's really a huge work due to the complexity of the WIN32 APIs (which contain a lot of structures).

So even if today the WINELib is available on MacOS X, there is still a long road to a full WIN32 application compatibility. But it's definitely a step in the right direction.

And no, I don't think that it will be a bad think for Apple on the long term because an application running into WINE will never be as good as a native MacOS X application. It will only do what's does the X11 layer in MacOS X: open the operating system to more users. I don't think that the big names in software development (Adobe, Macromedia, etc...) will use Darwine to reduce the cost of dev of their applications. And there is already very little WIN32 app that are ported to MacOS X... It could only encourage a wider used of our platform by removing a part of the software incompatibility image it has among PC users (on the long run of course).