Darwine's purpose isn't to be an emulator per-say, but to be a Windows compatibility layer. If you want to run your other OSes, I'm certain that all the code changes to QEmu they make will be put back into the tree and you can go there.
I'm not sure about the thing with DLLs. I'm looking at the sites now to see if they mention it.
How about this from the FAQ:
Quote:
3.10. If Wine completely replaces MS Windows, will it duplicate all of the functions of MS Windows?
Wine's goal is to make it possible to run Windows applications on Unix. To this end it will provide replacements for just those DLLs and APIs that are needed by these Windows applications. This means that Wine will not provide replacements for DLLs that are not shipped with Windows or are always shipped with Windows application (e.g. the Visual Basic run time). This also means that implementing an API that no application ever uses is not a priority. Similarly, until there are applications out there that use the Win64 API, it will not be a priority. That being said, we will certainly try to keep our options open and to improve our API coverage as we can.
I'm not sure if that actually answers the question, but seems to fit.
Spot on, if you want Windows, buy VPC or even OpenOSX's WinTel (Bochs). But the DarWINE project is targeted towards a Windows compatibility layer. Its sometimes preferrable to run apps (incl emulated ones) on just one OS.
I have it on good authority that the binary emulation will be available in Feb.
I thought it was interesting to read MOSR (Yeh, I know?) about Apple including some windows compatibility layers in 10.4?, again its MOSR.
You mean Linux don't you, not Windows, in 10.4? There already is some, I guess, POSIX stuff in 10.3, so it isn't really that far fetched at all. A Windows compatibility layer would sound like MOSR but that's not what they said.
So I installed the new Darwine package and then started looking up how I could use it to perhaps compile some Windows code or even better, to run a Windows program. I found some instructions that looked pretty straight forward, but it didn't work for me. If any of you get a program working, be sure to share how to do it. From here, I read the following:
Quote:
I don't know much about the terminal but I managed to compile and install wine, but now how do I open an application? Please help!
Having just installed Darwine, I figured any help that this person got might be useful to me. There was a reply to that posted as follows:
Quote:
open the X11 terminal (should be in mac HD -> Applications -> Utilities -> X11) and type "winemine" or "notepad" and press return. Native Windows apps don't work yet, but work is being done to port some Opensource windows stuff... (slowly)
So I tried that and it didn't work.
Well, now that I look at the page, there is somebody that replied within the afformentioned url that seems to be in my same boat.
Ok, now I'm not too sure of the importance or point of my post, but I've already written it, so dagnabbit, I'm going to post it.
A lot of people seem to be having issues getting darwine to work.
As far as I can tell, it is panther only.
Reading the sourceforge forums raised this interesting possiblility... At one point there was a real port of Windows NT to PPC, and with it some MS applications, word etc. If someone can dig up a copy of them, then it will provide an excellent test for getting darwine going.
If anyone doesnt get what darwine is doing, Ill try to explain:
When you write a windows application, it makes use of operating system services. These services are contained within dll's ( libraries ). Because the dll's rely upon the existence of the underlying windows kernel, it is not possible to just use them directly in, eg: linux, to run window applications. However, by rewriting the dll's so that instead of relying on the windows kernel, they use the linux kernel, it is possible to get windows applications to run. Windows applications are in a special format, and linux has to support that format, so that the application and the dll's can find each other.
OS X's kernel interface looks a lot like the linux kernel interface ( freebsd to be picky ), so it is possible, with a little work to compile the dll's from wine on OS X. These dll's translate things like windowing commands into X 11 windowing commands, and in general, pass through as much as possible to other, already existing, services.
This doesnt do much for us, without any applications to run. OS X doesnt understand the windows application format, and even if it did, windows apps are x86 code, not PPC code. However, we can take an application that we have the source code for, and recompile it on OS X, using the wine dll's. What we end up with is a PPC native ( fast ) app, running on the wine dll's ( native ), on OS X. This is, of course, only handy for people who have the source code for the application. Doesnt help much for games and the like.
The next trick is to use an x86 emulator. The emulator has to be modified, so that when the x86 application it is running makes a call to windows dll, instead of emulating the dll ( like VPC would ), it passes the call out to the appropriate wine dll, which is native. Some windows apps spend more of their time using the OS services than others, so it wont mean that games and things run magically faster. But, for example, in the case of games, directx could be wine dll that maps onto opengl. Then we would get native rendering using the video card in your mac, not software emulated rendering. This would certainly speed up games compared to running them in VPC.
You did clarify the DLLs, but what you said doesn't really corralate to what Wine says they do, because they said you can use native ones, which brings up the question, Why would there be native, "call translators"?
That's kinda confusing, but I can't say it better.
You did clarify the DLLs, but what you said doesn't really corralate to what Wine says they do, because they said you can use native ones, which brings up the question, Why would there be native, "call translators"?
That's kinda confusing, but I can't say it better.
How about this:
you can have - native dll's
emulated dll's
native app's
emulated app's
currently native apps calling native dlls work. Not only that, but they are going to be running at full speed ( sort of, we'll ignore any inefficiencies in wine's translation of windows calls to linux calls ).
With qemu, they should be able to, 'quite' easily, have emulated apps calling emulated dlls ( slow, as slow as vpc sort of thing ), and emulated apps calling native dlls ( faster, depends how much time an app spends in the dlls ). And hopefully some mix of the two. That should give us the ability to use emulated windows codecs ( for example ).
The ultimate, would be native apps calling emulated dlls. I dont know if they'll bother. It would be pretty cool to have visual basic apps compiled for PPC, but using an emulated dll for all the vb stuff.
At any rate, the functionality that most users want is emulated apps calling native dlls. It will be much faster than using vpc, and better integrated with the system ( no windows disc images ).
Comments
I'm not sure about the thing with DLLs. I'm looking at the sites now to see if they mention it.
How about this from the FAQ:
3.10. If Wine completely replaces MS Windows, will it duplicate all of the functions of MS Windows?
Wine's goal is to make it possible to run Windows applications on Unix. To this end it will provide replacements for just those DLLs and APIs that are needed by these Windows applications. This means that Wine will not provide replacements for DLLs that are not shipped with Windows or are always shipped with Windows application (e.g. the Visual Basic run time). This also means that implementing an API that no application ever uses is not a priority. Similarly, until there are applications out there that use the Win64 API, it will not be a priority. That being said, we will certainly try to keep our options open and to improve our API coverage as we can.
I'm not sure if that actually answers the question, but seems to fit.
I have it on good authority that the binary emulation will be available in Feb.
I thought it was interesting to read MOSR (Yeh, I know?) about Apple including some windows compatibility layers in 10.4?, again its MOSR.
Get it here:
http://sourceforge.net/project/showf...ease_id=213245
You'll need the X11 SDK installed to use it though...
I hope this one works better...
I don't know much about the terminal but I managed to compile and install wine, but now how do I open an application? Please help!
Having just installed Darwine, I figured any help that this person got might be useful to me. There was a reply to that posted as follows:
open the X11 terminal (should be in mac HD -> Applications -> Utilities -> X11) and type "winemine" or "notepad" and press return. Native Windows apps don't work yet, but work is being done to port some Opensource windows stuff... (slowly)
So I tried that and it didn't work.
Well, now that I look at the page, there is somebody that replied within the afformentioned url that seems to be in my same boat.
Ok, now I'm not too sure of the importance or point of my post, but I've already written it, so dagnabbit, I'm going to post it.
Alexander the Great
As far as I can tell, it is panther only.
Reading the sourceforge forums raised this interesting possiblility... At one point there was a real port of Windows NT to PPC, and with it some MS applications, word etc. If someone can dig up a copy of them, then it will provide an excellent test for getting darwine going.
If anyone doesnt get what darwine is doing, Ill try to explain:
When you write a windows application, it makes use of operating system services. These services are contained within dll's ( libraries ). Because the dll's rely upon the existence of the underlying windows kernel, it is not possible to just use them directly in, eg: linux, to run window applications. However, by rewriting the dll's so that instead of relying on the windows kernel, they use the linux kernel, it is possible to get windows applications to run. Windows applications are in a special format, and linux has to support that format, so that the application and the dll's can find each other.
OS X's kernel interface looks a lot like the linux kernel interface ( freebsd to be picky ), so it is possible, with a little work to compile the dll's from wine on OS X. These dll's translate things like windowing commands into X 11 windowing commands, and in general, pass through as much as possible to other, already existing, services.
This doesnt do much for us, without any applications to run. OS X doesnt understand the windows application format, and even if it did, windows apps are x86 code, not PPC code. However, we can take an application that we have the source code for, and recompile it on OS X, using the wine dll's. What we end up with is a PPC native ( fast ) app, running on the wine dll's ( native ), on OS X. This is, of course, only handy for people who have the source code for the application. Doesnt help much for games and the like.
The next trick is to use an x86 emulator. The emulator has to be modified, so that when the x86 application it is running makes a call to windows dll, instead of emulating the dll ( like VPC would ), it passes the call out to the appropriate wine dll, which is native. Some windows apps spend more of their time using the OS services than others, so it wont mean that games and things run magically faster. But, for example, in the case of games, directx could be wine dll that maps onto opengl. Then we would get native rendering using the video card in your mac, not software emulated rendering. This would certainly speed up games compared to running them in VPC.
You end up with something like this:
Windows App : x86
--------------------
Qemu emulator -> dlls with no wine version - x86
--------------------
Wine : PPC + recompiled windows apps
--------------------
OS X / X 11 : Doing the hard work, PPC
You did clarify the DLLs, but what you said doesn't really corralate to what Wine says they do, because they said you can use native ones, which brings up the question, Why would there be native, "call translators"?
That's kinda confusing, but I can't say it better.
1) WINE is supposed to be able to use your existing installation of Windows BUT it really stuffs up when trying to
2) Only a minority of games actually work, and those that do are a LONG way from bug free.
Me, I'll continue to boot into Windows when I want to play games.
Barto
Originally posted by macserverX
Didn't I just say that.
You did clarify the DLLs, but what you said doesn't really corralate to what Wine says they do, because they said you can use native ones, which brings up the question, Why would there be native, "call translators"?
That's kinda confusing, but I can't say it better.
How about this:
you can have - native dll's
emulated dll's
native app's
emulated app's
currently native apps calling native dlls work. Not only that, but they are going to be running at full speed ( sort of, we'll ignore any inefficiencies in wine's translation of windows calls to linux calls ).
With qemu, they should be able to, 'quite' easily, have emulated apps calling emulated dlls ( slow, as slow as vpc sort of thing ), and emulated apps calling native dlls ( faster, depends how much time an app spends in the dlls ). And hopefully some mix of the two. That should give us the ability to use emulated windows codecs ( for example ).
The ultimate, would be native apps calling emulated dlls. I dont know if they'll bother. It would be pretty cool to have visual basic apps compiled for PPC, but using an emulated dll for all the vb stuff.
At any rate, the functionality that most users want is emulated apps calling native dlls. It will be much faster than using vpc, and better integrated with the system ( no windows disc images ).