Re: When will Wine integrate an x86 CPU emulator?
Not sure I agree with paragraph two of the answer... While writing an x86 emulator (and integrating it into wine) would be quite difficult, I don't see how the complexity has anything to do with the data types and API functions... A true emulator has no concept whatsoever of data types (except the very basic data types of the cpu - x-bit word, x-bit IEEE number, for instance), so its complexity cannot possibly depend on the high-level data types used by the compiler generating the machine code... Kelly ----- Original Message ----- From: "Francois Gouget" <fgouget(a)free.fr> To: <wine-patches(a)winehq.com> Sent: Wednesday, August 20, 2003 3:42 PM Subject: FAQ: When will Wine integrate an x86 CPU emulator?
Changelog:
* documentation/faq.sgml
Add an entry answering the eternal question: When will Wine integrate an x86 CPU emulator?
Index: documentation/faq.sgml =================================================================== RCS file: /home/wine/wine/documentation/faq.sgml,v retrieving revision 1.13 diff -u -r1.13 faq.sgml --- documentation/faq.sgml 28 Jul 2003 19:06:10 -0000 1.13 +++ documentation/faq.sgml 20 Aug 2003 20:37:51 -0000 @@ -130,6 +130,58 @@ </qandaentry>
<qandaentry> + <question id="Integrate-an-x86-emulator"> + <para>When will Wine integrate an x86 CPU emulator so we can + run Windows applications on non-x86 machines?</para> + </question> + <answer> + <para> + The short answer is 'probably never'. Remember, Wine Is Not a + (CPU) Emulator. The long answer is that we probably don't want
or
+ need to integrate one in the traditional sense. + </para> + <para> + Integrating a CPU emulator in Wine would be extremely hard, + due to the large number of Windows APIs and the complex + datatypes they exchange. It is not uncommon for a Windows API to + take three or more pointers to structures composed of many fields, + including pointers to other complex structures. For each of these + we would need a conversion routine to deal with the byte order and + alignment issues. Furthermore, Windows also contains many callback + mechanisms that constitute as many extra places where we would have + to handle these conversion issues. Wine already has to deal with + 16 vs. 32 bit APIs and Ansi vs. Unicode APIs which both + introduce significant complexity. Adding support for a CPU emulator + inside Wine would introduce at least double that complexity and + only serve to slow down the development of Wine. + </para> + <para> + Fortunately another solution exists to run Windows applications + on non-x86 platforms: run both Wine and the application inside the + CPU emulator. As long as the emulator provides a standard Unix + environment, Wine should only need minimal modifications. What + performance you loose due to Wine running inside the emulator + rather than natively, you gain in complexity inside of Wine. + Furthermore, if the emulator is fast enough to run Windows + applications, Photoshop for instance, then it should be fast enough + to run that same Windows application plus Wine. + </para> + <para> + Two projects have started along those lines: <ulink + url="http://fabrice.bellard.free.fr/qemu/">QEMU</>, an + open-source project, and <ulink + url="http://www.transitives.com/tech_overview.htm">Dynamite</>, + a commercial CPU emulator environment from + <ulink url="http://www.transitives.com/">Transitives Technologies</> + which has been <ulink + url="http://www.transgaming.com/news.php?newsid=37">paired + with Wine</>. + </para> + + </answer> + </qandaentry> + + <qandaentry> <question id="Why-would-anyone-want-Wine-Windows-suck"> <para>Why would anyone want Wine? Doesn't Windows suck?</para> </question>
-- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
Kelly Leahy wrote:
While writing an x86 emulator (and integrating it into wine) would be quite difficult, I don't see how the complexity has anything to do with the data types and API functions... A true emulator has no concept whatsoever of data types (except the very basic data types of the cpu - x-bit word, x-bit IEEE number, for instance), so its complexity cannot possibly depend on the high-level data types used by the compiler generating the machine code...
This is true when you run the whole application, i.e. the Wine parts together with the Windows binaries, under an emulator. However, to do so you don't need to integrate the emulator into Wine, but you can just run the whole Wine process under an external emulator like qemu. The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries. However, for this to work means that on every cross-call from Wine to Windows code or vice versa we need to transition into or out of the emulator; and this involves converting all arguments and return values of such calls between the Windows/x86 format and the native format of the host. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
Ok. I can agree with that. I'm not sure that "emulator" is the best term for this, but it'll have to do unless someone has an alternative. I don't think this would be as hard as it sounds, if the .spec files could be used to describe all of the parameters and calls to the API functions. The "emulator" (probably better termed an interpreter) would need to intercept all CALL instructions and JMP instructions and have some way of knowing the difference between native and x86 code (for the purpose of determining where the CALLs are going to). A better way to do this would be to write an emulator that is invoked by wine when a binary is targeted to x86 and is loaded for running on a non-x86 machine. The emulator could, when resolving dynamic links to the dlls, provide an x86 implementation of the function that merely packages the parameters up for calling to the native "real" implementation of the function. It would even be possible to write a "proxy" wine-x86 for running under an emulator that implements the really simple stuff (that would be slow to implement natively, due to cross-CPU (emulator vs. native) issues) in x86 code, but makes native calls for more complicated stuff using some non-CPU-specific method (like RPC, sockets, etc.) that is supported by both the emulator and the host system. Kelly ----- Original Message ----- From: "Ulrich Weigand" <weigand(a)i1.informatik.uni-erlangen.de> To: "Kelly Leahy" <kellyleahy(a)swbell.net> Cc: <wine-devel(a)winehq.org> Sent: Wednesday, August 20, 2003 4:36 PM Subject: Re: When will Wine integrate an x86 CPU emulator?
Kelly Leahy wrote:
While writing an x86 emulator (and integrating it into wine) would be quite difficult, I don't see how the complexity has anything to do with the data types and API functions... A true emulator has no concept whatsoever of data types (except the very basic data types of the cpu - x-bit word, x-bit IEEE number, for instance), so its complexity cannot possibly depend on the high-level data types used by the compiler generating the machine code...
This is true when you run the whole application, i.e. the Wine parts together with the Windows binaries, under an emulator. However, to do so you don't need to integrate the emulator into Wine, but you can just run the whole Wine process under an external emulator like qemu.
The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries. However, for this to work means that on every cross-call from Wine to Windows code or vice versa we need to transition into or out of the emulator; and this involves converting all arguments and return values of such calls between the Windows/x86 format and the native format of the host.
Bye, Ulrich
-- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
I don't think this would be as hard as it sounds, if the .spec files could be used to describe all of the parameters and calls to the API functions.
Well, the big problem is that .spec files are so 'passé' now :-) Correct me if I'm wrong, but I think that most new APIs are now exported through COM objects and not 'standard' APIs (I could do a check on the current Wine DLLs, but well, a lot of stuff is using COM nowadays). So you would need to have a way to describe all COM inputs / outputs. Then there is the matter also that Wine uses the COM objects internaly exactly like the program does.. So you cannot say 'hey, let's put converting functions in this COM vtable' as this will break when called from X86 code. Finally, you will have the problems of 'non-trivial' argument passing (ie data which are not described by C structures). For that, you will have to rewrite the C code parsing this for each call (and thus have a emulator-specific path). This is the case for bitmaps, a lot of DirectX stuff, ... It's exactly the same issue for '...' functions. And you will have to rewrite most of Wine's OpenGL code too :-) So, yes, it's doable. Now is it pratical to do so and acceptable to rid a lot of Wine code with if (emulated) { .... } else { .... } ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
So, yes, it's doable. Now is it pratical to do so and acceptable to rid a lot of Wine code with if (emulated) { .... } else { .... } ?
Well, anyone up for maintaining a "macwine" fork, etc? ;) How do I put this? It could be that instead of having if (emulated) { ... } else { ... } just remove he if (emulated) and the else so that it only runs the emulated code.. (if someone were to start up a fork to be run only on non-x86 cpu's) ===== -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...]
The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries. [...]
Not only it would be extremely complex but I am not even sure it would be more efficient. The situation would be similar to what happens to DIBs. Whenever we are asked to perform an operation on a DIB such as draw a line, we convert it to a pixmap and invoke X to perform the operation. This allows us to reuse X's highly optimized and potentially hardware accelerated routines. That should be optimal, right? The problem is that if the application then accesses the image directly, which is often the goal behind DIBs, then we have to convert the pixmap back to the DIB format. Enough of this ping-pong between the DIB and the pixmap format will completely kill performance (10x slowdown or more depending on the size of the DIB and the frequency of th eping-pong, hence the various calls for a DIB engine). How does that apply to the emulator case? Well, let's take InflateRect: BOOL InflateRect(LPRECT lprc, int dx, int dy); lprc points to this structure: typedef struct { LONG left; LONG top; LONG right; LONG bottom; } RECT; Obviously Winelib applications are going to assume the structure fields use the platform's native byte ordering, big endian for instance. And so will Wine's code. So for each call to InflateRect we will need a wrapper that: 1 - copies the structure pointed to by the lprc pointer fixing the byte order 2 - fixes the byte ordering of dx and dy 3 - calls Wine's native (big endian) InflateRect implementation 4 - copies the resulting rect structure back to the location pointed by lprc, fixing the byte ordering again Now, will the overhead of the 2 copies and byte-swapping operations be lower than simply running the little endian version of InflateRect in the emulator? I'm not sure it will be the case. This is not a fringe case. Copying stuff back and forth will be the norm more than the exception and with much bigger structures too. For instance PolyLineTo takes an array of POINT structures which will need to be entirely copied and byte swapped before the native implementation can use it. Same thing for DIBs: Winelib applications (and thus native Wine code) may expect 16 and 32 bit DIBs to be in big endian format while Windows applications will expect them to be in little endian format. Now we're talking about converting kilobytes of data back and forth with each call... In other words, not only integrating an emulator in Wine is going to be awfully complex, but it may turn out to provide lower performance than simply running Wine plus the Windows application in an emulated x86 environment. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Francois Gouget wrote:
On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...]
The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries.
[...]
Not only it would be extremely complex but I am not even sure it would be more efficient. ... How does that apply to the emulator case? Well, let's take InflateRect: ...
I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy. The point of integrating the x86 emulation is not necessarily to get into the interface between Wine and the Windows applications. The point is to avoid a whole layer of OS emulation. I have no problem even with the idea that some of Wine's code remains x86 in order to avoid switching modes excessively. Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation and an attendant extra file/device mapping layer. Also while it is obvious that an intermediate stage will be to use X, a futher improvement could be to use the native toolkit. And especially attractive from the x86 emulator's standpoint is the ability to identify read-only code resources with defined entry points that can be JIT compiled to native code rather than simply interpreting. The opportunities for doing that at the machine level for hosting an OS are much more limited. So while integrating x86 emulation with Wine certainly adds another whole set of complexity, the performance gains are easily attained because of the reduction in emulation layers which can readily run into order-of-magnitude performance penalities in all kinds of places as you illustrated. Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net. And there is no conflict here. Wine has more than a big enough chunk of work carved out for itself, and it is it's sucess there that brings the attention from other perspectives with interests in leveraging that value into other areas. We have a strong common interest in free and open software. Otherwise we'ld just buy Windows (and for Mac OS X, Virtual PC). Jim -- "I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams
To add to Jim's idea: What if the entire Wine code runs natively, but in little endian (possibly for winelib too - that would actually help with binary compatibility between the Unix and the windows versions of programs)? If this sounds absured to you, then you have never done TCP/IP programming ;-) This way, the conversions are avoided, and only performed when you have to communicate with the underlying OS. Converting integers for inside use cannot be, no matter what you do, as inefficient as emulating the entire instruction set. Shachar Jim White wrote:
Francois Gouget wrote:
On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...]
The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries.
[...]
Not only it would be extremely complex but I am not even sure it would be more efficient. ... How does that apply to the emulator case? Well, let's take InflateRect: ...
I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy.
The point of integrating the x86 emulation is not necessarily to get into the interface between Wine and the Windows applications. The point is to avoid a whole layer of OS emulation. I have no problem even with the idea that some of Wine's code remains x86 in order to avoid switching modes excessively.
Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation and an attendant extra file/device mapping layer. Also while it is obvious that an intermediate stage will be to use X, a futher improvement could be to use the native toolkit.
And especially attractive from the x86 emulator's standpoint is the ability to identify read-only code resources with defined entry points that can be JIT compiled to native code rather than simply interpreting. The opportunities for doing that at the machine level for hosting an OS are much more limited.
So while integrating x86 emulation with Wine certainly adds another whole set of complexity, the performance gains are easily attained because of the reduction in emulation layers which can readily run into order-of-magnitude performance penalities in all kinds of places as you illustrated.
Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net.
And there is no conflict here. Wine has more than a big enough chunk of work carved out for itself, and it is it's sucess there that brings the attention from other perspectives with interests in leveraging that value into other areas. We have a strong common interest in free and open software. Otherwise we'ld just buy Windows (and for Mac OS X, Virtual PC).
Jim
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
On Fri, 22 Aug 2003, Shachar Shemesh wrote:
To add to Jim's idea:
What if the entire Wine code runs natively, but in little endian
Here's the code of InflateRect: void WINAPI InflateRect16( LPRECT16 rect, INT16 x, INT16 y ) { rect->left -= x; rect->top -= y; rect->right += x; rect->bottom += y; } Please rewrite it so that it takes a little endian RECT struct on a both big endian architectures and little endian architecture. Then, tell me what you would do about the approximately 70 places in Wine where we call it. For instance (from dlls/comctl32/toolbar.c): myrect.left = lpRect->left; myrect.right = lpRect->right; myrect.top = lpRect->top + (lpRect->bottom - lpRect->top - 2)/2; myrect.bottom = myrect.top + 1; InflateRect (&myrect, -2, 0); Rewrite the above code snippet so that myrect contains integers in the little endian format expected by InflateRect. Finally, make sure the -2 and 0 parameters arrive in little endian format in InflateRect. When all the above is done, tell me honestly: is the code still readable? Is it still maintainable? Would you do the same for the 15000 other API calls now?
(possibly for winelib too - that would actually help with binary compatibility between the Unix and the windows versions of programs)?
Further exercise: how are you going to explain to Winelib users that they have to do the same modifications in their application code? This way lies madness. PS: Please accept my apologies if this was a joke. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Francois Gouget wrote:
PS: Please accept my apologies if this was a joke.
No, not a joke. I plead temporary insanity. It does sound saner to let use double interfaces, or to emulate the Wine code itself. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net.
Well, I looked at the site and did not see much there... Is there any design diocuments / roadmaps on how you plan to go forward that we could read so as to know how you plan to actually tackle the issues raised by all the people here ? Ie something that would tell : - how you plan to go forward (complete Wine fork rewriting big chunks of the code or 'parameter translation' layer with Wine code mostly untouched) - how some specific issues would be handled (exceptions, '...' functions, ...) For the moment, the only thing I see is making Winelib working on OS/X (which is a nice thing but has not much to do with running Win32/X86 applications on OS/X). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net.
Well, I looked at the site and did not see much there... Is there any design diocuments / roadmaps on how you plan to go forward that we could read so as to know how you plan to actually tackle the issues raised by all the people here ? ...
The most useful part of the web site is the email list archive: http://sourceforge.net/mailarchive/forum.php?forum_id=26200 As you note, the substantive work to date has been that Pierre has made progress (to the point of running WinMine) in porting Winelib to OS X. My personal roadmap for Darwine-related activity is to try out the Winelib stuff myself and make a suitable Freshmeat announcement. Updating the web site a bit with some current status and some of this discussion is also a "to do". I don't expect to be a development leader for any of this Wine-related stuff as I don't have much interest in running or porting Windows applications. I certainly have no interest in debating anybody on what or how to do anything. I do like communicating with others with whom I have a common interest. The most interesting activity on Wine with x86 emulation is QEMU. If that had existed last year then there wouldn't have been a Darwine. QEMU now has a mailing list: http://mail.gnu.org/archive/html/qemu-devel/ Jim -- "I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams
The most interesting activity on Wine with x86 emulation is QEMU. If that had existed last year then there wouldn't have been a Darwine. QEMU now has a mailing list:
What is 'fun' is that QEMU resulted from a discussion I had with its author about how to best run Wine on a non-X86 system and the resulting conclusion we reached (after some time late in the night :-) ) : the easiest and most robust way to do that was to emulate at the syscall level. Note also this post (http://mail.gnu.org/archive/html/qemu-devel/2003-08/msg00058.html) where Fabrice agrees with my post about Wine on OS/X :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Thu, 21 Aug 2003, Jim White wrote: [...]
I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy.
Because I think it's not realistic and it keeps people from spending time where it counts, i.e.: 1. making it possible/easy to run Wine in an emulated x86 environment 2. making sure the emulator has a good JIT compiler so that performance is good. And this second point is needed even if you integrate the emulator into Wine otherwise the performance of things like PhotoShop and games will suck. [...]
Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation and an attendant extra file/device mapping layer. [...]
You don't need to run a second OS. When I'm talking about emulators I'm not talking about something like VMWare that runs an OS inside the emulated environment. You can have something much more lightweight that does not involve a kernel, emulated filesystem or anything. What you would do is intercept system calls that the emulated software makes and translate/forward them to the native kernel. So the transition between the emulated and native environment would be at the kernel interface level rather than at the hardwaer level. This is exactly what Transitive's Dynamite does. Also, what is awfully hard to do for Windows applications due to the API design and its sheer size, is feasible for Unix: you can switch from emulated to native code when the Unix application makes a call to a system library. You do this by writing sort of proxy libraries that will convert the calls made by the emulated application into calls to the native library. In that case the emulated/native transition is not done at the kernel interface level, but at the system library level. I believe this is also something that is done by Transitive's Dynamite (see 'How does Dynamite interface between the legacy code and nex code?' in http://www.transitives.com/tech_faq.htm). So to take Lionel's example, if OpenGL performance was critical, you could write a proxy OpenGL library that converts the emulated OpenGL calls into calls to the native OpenGL library. The same thing can be done for the X library, the C library, etc. To sum up, it seems your world view (1) was: Application \ System libraries | Emulated Kernel / =============== Emulator } Native But the following (2) is possible, i.e. it has been done already: Application \ Emulated System libraries / =============== Kernel \ Native Emulator / And this (3) is possible too: Application \ Emulated Some libraries / =============== C library, others \ Kernel | Native Emulator / What I would like is to see people develop something such as 2 or 3 and make sure Wine runs within such an environment. If the environment already exists, then I think Wine can be made to run in it within months. That would be a great 'marketing' coup for Wine and would provide something usable now. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
Jim, On Fri, 22 Aug 2003 12:41:42 +1000, Jim White wrote:
Francois Gouget wrote:
On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...]
The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries.
[...]
Not only it would be extremely complex but I am not even sure it would be more efficient. ... How does that apply to the emulator case? Well, let's take InflateRect: ...
I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy.
The point of integrating the x86 emulation is not necessarily to get into the interface between Wine and the Windows applications. The point is to avoid a whole layer of OS emulation.
There is no layer of OS emulation if you use an x86 emulator. An example of an x86 emulator is QEMU. You run "qemu wine <windows program>" and that is it. You seem to be thinking that an x86 system emulator (e.g. VMware, VirtualPC, Bochs, etc.) is required. They aren't.
Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation
No, it doesn't.
And especially attractive from the x86 emulator's standpoint is the ability to identify read-only code resources with defined entry points that can be JIT compiled to native code rather than simply interpreting.
Which is exactly what QEMU does. QEMU already works on PowerPC hardware. <URL: http://fabrice.bellard.free.fr/qemu/>. All that is needed is for someone with access to port it to Mac OS X. That someone could be you, and you'd have achieved what you want. Anand
Not only it would be extremely complex but I am not even sure it would be more efficient.
Well, one case where the performance gain may be significant is gaming. Basically, if you run your GL library emulated, you will use the GLX network protocol to communicate with the X server to a pretty heavy performance penalty compared to any direct rendering architecture (especially for texture uploads and such). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Kelly Leahy wrote:
Not sure I agree with paragraph two of the answer... ...
I don't care for the answer much myself. Certainly "never" is not reasonable as Wine for non-x86 systems is desireable and eventually enough effort will be expended to get the job done. Now the time frame might be rather long, and for many folks the answer to "When will Wine be finished?" is effectively "never" because it is more than a year and the integrated emulation business is well beyond that. It would be nice to mention Darwine in connection with these Wine-for-other-systems FAQs as progress has been demonstrated with Winelib for Mac OS X and the stated goal is an eventual integrated x86 emulator. http://darwine.sourceforge.net/ That said, I do agree that before the integrated solution appears we will see Wine running on emulated X86/Linux. I'm particularly interested in seeing Linux on Darwin's Mach kernel which should benefit from the prior work of MkLinux. Jim -- "I love deadlines. I love the whooshing sound they make as they fly by." -- Douglas Adams
On Wed, 20 Aug 2003, Jim White wrote:
Kelly Leahy wrote:
Not sure I agree with paragraph two of the answer... ...
I don't care for the answer much myself. Certainly "never" is not reasonable as Wine for non-x86 systems is desireable and eventually enough effort will be expended to get the job done.
I think it's reasonable as there are much better solutions from a complexity and maintainability point of vue. Thus it's better to say never and direct efforts towards these other solutions rather than wait for an elusive solution the superiority of which is not even very clear. [...]
for many folks the answer to "When will Wine be finished?" is effectively "never" because it is more than a year [...]
It's a sure bet that Wine won't have an integrated emulator in a year. I would even go so far as to say it won't happen within the next 15 years.
It would be nice to mention Darwine in connection with these Wine-for-other-systems FAQs as progress has been demonstrated with Winelib for Mac OS X and the stated goal is an eventual integrated x86 emulator.
Yes, definitely. I propose the patch below. By the way, does anyone out there know what's the status of: * Wine on NetBSD Currently we say that Wine does not work due to threading problems. Is this still true? Also I have heard that it's possible to run Wine on NetBSD using NetBSD's Linux emulation code. If so then it should be mentioned here. * Wine on OpenBSD / UnixWare Any change in status? * Wine on OS/2 is not mentionned though Wine on BeOS is. However Wine on OS/2 is mentioned in the Wine developper's guide (http://www.winehq.com/Docs/wine-devel/os2-wine.shtml). Yet both projects seem rather dead. So should we mention the OS/2 project here, remove both or what? Index: documentation/faq.sgml =================================================================== RCS file: /home/wine/wine/documentation/faq.sgml,v retrieving revision 1.13 diff -u -r1.13 faq.sgml --- documentation/faq.sgml 28 Jul 2003 19:06:10 -0000 1.13 +++ documentation/faq.sgml 21 Aug 2003 11:07:50 -0000 @@ -520,12 +631,17 @@ </question> <answer> <para> - Wine is being developed specifically to run on the <emphasis>Intel x86</emphasis> class of CPUs under certain UNIXes that run on the x86 platform. - Winelib however is capable of porting Windows program <emphasis>source code</emphasis> to other platforms also, not only x86. + Wine is being developed specifically to run on the <emphasis>Intel + x86</emphasis> class of CPUs under certain UNIXes that run on the + x86 platform. Winelib however is capable of porting Windows + program <emphasis>source code</emphasis> to other platforms also, + not only x86. </para> <para> - Thus running Windows programs via Wine on other platforms (e.g. MacOS X) is <emphasis>not</emphasis> possible; the only way to run Windows code - on MacOS X would be to take Windows program source code and recompile it for e.g. MacOS X using Winelib. + Thus running Windows programs solely via Wine on other platforms + (e.g. Mac OS X) is <emphasis>not</emphasis> possible. You would + have to either run Wine in an emulated x86 environment or take + the Windows program source code and recompile it using Winelib. </para> <para> The following will list the x86 operating systems supported by @@ -533,7 +649,7 @@ so it's not specifically listed here. </para> <para> - NetBSD, OpenBSD, Unixware, and SCO OpenServer 5 worked at one time, + NetBSD, OpenBSD, UnixWare, and SCO OpenServer 5 worked at one time, but Wine now requires kernel-level threads which are not currently available (or understood by the Wine team) on those platforms. </para> @@ -542,9 +658,18 @@ commercial UNIX and UNIX clone vendors as well. </para> <para> - BeOS: porting efforts used to be pretty strong, but BeOS has severe - limitations in Unix call support, so a port will probably never - happen. + BeOS: porting efforts (BeWine) used to be pretty strong, but BeOS + has severe limitations in Unix call support. The demise of BeOS + further hampered the project though it might come back one day on + one of the open BeOS projects. In any case a functional port seems + unlikely to ever happen at this stage. + </para> + <para> + Mac OS X / Darwin: The <ulink + url="http://darwine.sourceforge.net/project.html">Darwine</> is + currently working on porting Wine to the Darwin/x86 platform. Their + goal is to eventually make it possible to run x86 Windows + applications on Darwin/PPC and then Mac OS X by using Bochs. </para> <para> FreeBSD: Should work, with limitations in specific areas (mainly -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
participants (8)
-
Anand Kumria -
Dustin Navea -
Francois Gouget -
Jim White -
Kelly Leahy -
Lionel Ulmer -
Shachar Shemesh -
Ulrich Weigand