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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. > >
