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.