or Connect
AppleInsider › Forums › Software › Mac Software › Darwine! WINE for Mac OS X is coming
New Posts  All Forums:Forum Nav:

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

post #41 of 91
Quote:
Originally posted by SilentEchoes
Err Yeah it will be rootless but the apps are still emulated.. Regardless of what WINE stands for...

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
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
post #42 of 91
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...
post #43 of 91
Thread Starter 
Since at the moment Darwine can only really be useful if you compile your own Win32 apps from source, has anyone been successful with that? Though it's in the works as a native OS X app, I'd like to see DC++ running under Darwine. That would be cool. If anyone wants to try compiling DC++ you can DL the source here: http://dcplusplus.sf.net.
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #44 of 91
Quote:
Originally posted by mmmpie


WINE translates windows api calls to linux api calls. This can still be done natively.

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.
post #45 of 91
Quote:
Originally posted by LowB-ing
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
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
post #46 of 91
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.
post #47 of 91
Thread Starter 
Quote:
Originally posted by hasapi

Still this is a VERY interesting project, its certainly has my attention. [/B]

Thanks to me! ^_^
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #48 of 91
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?
post #49 of 91
Quote:
Originally posted by hasapi
Unless bochs has dramatically improved their code since July 03, qemu or valgrind would be preferred?

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
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
post #50 of 91
Quote:
Originally posted by Proud iBook Owner 2k2
Thanks to me! ^_^

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! \
post #51 of 91
Quote:
Originally posted by Proud iBook Owner 2k2
When linking to a site don't put a double http://. The link you posted about why WINE is needed looks like this when clicked: http://http://www.winehq.org/site/why. One HTTP'll do. ^^

I apologise!, didnt paste the link in properly!, agreed its damm annoying for non functioning link!.
post #52 of 91
Quote:
Originally posted by FrenchMac
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...

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.
post #53 of 91
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.
post #54 of 91
Quote:
Originally posted by FrenchMac
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 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
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
post #55 of 91
Thread Starter 
They've released a binary!!!! Check it out at http://www.sf.net/projects/darwine !!!!
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #56 of 91
Thread Starter 
OK so I installed it... but now I can't get it running... I'll install X11 but I don't think that'll help because it's looking for the Windows drive... I don't know where the config file is to set that and I can't find a WineTools that'll work... Can anyone help? Would I need the previous version? CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...

Here's what happens (in terminal.app) when I try and start wine:

Last login: Thu Jan 29 16:14:36 on ttyp2
Welcome to Darwin!
[Gaspar-Hellers-Computer:~] gasparhe% wine
dlopening /usr/local/lib/wine/ntdll.dll.so
done /usr/local/lib/wine/ntdll.dll.so
dlopening /usr/local/lib/wine/kernel32.dll.so
done /usr/local/lib/wine/kernel32.dll.so
Warning: no valid DOS drive found, check your configuration file.
Warning: could not find wine config [Drive x] entry for current working directory /Users/gasparhe; starting in windows directory.
Invalid path L"c\\\windows" for L"windows" directory: does not exist.
Perhaps you have not properly edited your Wine configuration file (/Users/gasparhe/.wine/config)

Oddly enough after I installed X11 just now X11's Xterm says it can't find wine when I type it:

Gaspar-Hellers-Computer:~ gasparhe$ wine
bash: wine: command not found
Gaspar-Hellers-Computer:~ gasparhe$

How do I get this to run under X11.app? I know once I get it started that it'll need some sort of Windowing environment and display method...

I've rehashed several times... Can anyone help?
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #57 of 91
Quote:
Originally posted by Barto
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.

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?
post #58 of 91
Quote:
Originally posted by Proud iBook Owner 2k2
OK so I installed it... but now I can't get it running... I'll install X11 but I don't think that'll help because it's looking for the Windows drive... I don't know where the config file is to set that and I can't find a WineTools that'll work... Can anyone help? Would I need the previous version? CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...

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!
-- Denis.
Reply
-- Denis.
Reply
post #59 of 91
There is a shell script that sets it up someplace but I cannot remember where right now.
"It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill
Reply
"It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill
Reply
post #60 of 91
Thread Starter 
Quote:
Originally posted by jido
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!

I have no clue but I just wrote to the developer asking him how to get it working. On the Darwine Project home page (http://darwine.sf.net) they have a screenshot posted there. I really want to know how to get that far. As it is now the program that runs it doesn't find it and the one that finds it doesn't run it. In other words Terminal.app almost loads up, and X11.app doesn't find the command at all...
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #61 of 91
In x11 make sure you CD to the directory and put a ./ in front of wine
"It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill
Reply
"It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill
Reply
post #62 of 91
Thread Starter 
Quote:
Originally posted by SilentEchoes
In x11 make sure you CD to the directory and put a ./ in front of wine

Didn't work... but I'll wait for either Jim White (the project admin) or SE to find the shell script.
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #63 of 91
Quote:
Originally posted by Proud iBook Owner 2k2
CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...

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?.
post #64 of 91
Quote:
Originally posted by PB
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?

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
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
Self Indulgent Experiments keep me occupied.

rotate zmze pe vizspygmsr minus four
Reply
post #65 of 91
Thread Starter 
hmmm that sucks... I guess we gotta be careful then. heh

OT: My stupid mail provider died so I gotta use another email address which is why I'm posting..to get this other addy into the system......
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #66 of 91
Quote:
Originally posted by Proud iBook Owner 2k2
Since at the moment Darwine can only really be useful if you compile your own Win32 apps from source, has anyone been successful with that? Though it's in the works as a native OS X app, I'd like to see DC++ running under Darwine. That would be cool. If anyone wants to try compiling DC++ you can DL the source here: http://dcplusplus.sf.net.

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....
post #67 of 91
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
Please ask me to clarify what I have said if it doesn't make sense.
Reply
Please ask me to clarify what I have said if it doesn't make sense.
Reply
post #68 of 91
Thread Starter 
Quote:
Originally posted by Alexander the Great
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

-_- Can anyone straighten him out? I'l try but... *sighs*

Alexander: WINE stands for WineIsNotanEmulator. It's a compatibility layer that allows Linux users to run Windows applications. Until now it was only available for people using x86 based hardware. The Darwine team is using an emulator, or as they call it a binary translator, to run the x86 binaries. It's called QEmu. This will allow Mac OS X and Darwin PPC users to run WIndows apps, without having an installation of Windows present. There is no "port of Darwin x86". Darwin is written for both the PowerPC processor as well as x86 processor. Darwine uses Apple's Xfree86 Window/X server called X11 to display these programs. For more information go back to the first post of this thread to visit the Darwine project home page. That's all I can say off the top of my head on this. Anyone else want to collaborate?
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #69 of 91
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."
Please ask me to clarify what I have said if it doesn't make sense.
Reply
Please ask me to clarify what I have said if it doesn't make sense.
Reply
post #70 of 91
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
Please ask me to clarify what I have said if it doesn't make sense.
Reply
Please ask me to clarify what I have said if it doesn't make sense.
Reply
post #71 of 91
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.
Code:

Windows Application
||||||||
Windows API
||||||||
WINE---------------------------Windows
||||||||
QEmu---------------------------VPC Emu
||||||||
PPC Code


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
post #72 of 91
Thread Starter 
Quote:
Originally posted by macserverX
[B]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, .....

Thank you for helping me MacserverX. I hope Alexander knows what Darwine is now...
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #73 of 91
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.
post #74 of 91
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.
post #75 of 91
Thread Starter 
Quote:
Originally posted by macserverX
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.

Same here. It's annoying but I guess that's what you have to deal with when messing with Alpha software.... I hope they improve it soon. What we need to get it going properly is something like WINETools.. but I think their planned System Prefs Pref pane is gonna act as that. What's odd for me is that when I type wine into Terminal.app it sorta works but then it asks for the fake C drive...... then again in X11.app it doesnt work at all... WTF....
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #76 of 91
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!
post #77 of 91
Quote:
Originally posted by hasapi
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?
post #78 of 91
Quote:
Originally posted by Brad
I earnestly hope that Apple never endorses such a project and never includes it with its computers.

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 \
post #79 of 91
Thread Starter 
Odd.. The Darwine Team released an uninstaller and when I try and run it in Terminal.app it keeps saying command not found.. But it's a text file (a Perl script I think) and you can see what it would do for you if it was run. Can anyone get it to work? And why do you think they've released an uninstaller? Could they be readying the first real release with QEmu built in?
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
http://www.angelfire.com/anime5/erro...amxsigflat.jpg
Above is a link to my sig pic.
If you'd like to send me an email please use gheller@hellermedia.com. The email listed in my profile is for...
Reply
post #80 of 91
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).
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac Software
AppleInsider › Forums › Software › Mac Software › Darwine! WINE for Mac OS X is coming