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...
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.
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.
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.
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?
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.
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?
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.
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.
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.
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...
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?
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!
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...
Comments
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...
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.
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
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.
Originally posted by hasapi
Still this is a VERY interesting project, its certainly has my attention. [/B]
Thanks to me! ^_^
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?
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
Originally posted by Proud iBook Owner 2k2
Thanks to me! ^_^
I read this at http://www.macwindows.com/ first, sorry!
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!
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!.
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.
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.
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
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
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?
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?
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!
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...