Re: When will Wine integrate an x86 CPU emulator?

[Kelly Leahy]

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

When will Wine integrate an x86 CPU emulator?

[Ulrich Weigand]

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

When will Wine integrate an x86 CPU emulator?

[Kelly Leahy]

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" 
To: "Kelly Leahy" 
Cc: 
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
>   [e-mail]

When will Wine integrate an x86 CPU emulator?

[Lionel Ulmer]

> 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

When will Wine integrate an x86 CPU emulator?

[Dustin Navea]

--- Lionel Ulmer  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

When will Wine integrate an x86 CPU emulator?

[Francois Gouget]

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.

When will Wine integrate an x86 CPU emulator?

[Jim White]

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

When will Wine integrate an x86 CPU emulator?

[Shachar Shemesh]

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

When will Wine integrate an x86 CPU emulator?

[Francois Gouget]

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.

When will Wine integrate an x86 CPU emulator?

[Shachar Shemesh]

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

When will Wine integrate an x86 CPU emulator?

[Lionel Ulmer]

> 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

When will Wine integrate an x86 CPU emulator?

[Jim White]

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

When will Wine integrate an x86 CPU emulator?

[Lionel Ulmer]

> 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/

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

When will Wine integrate an x86 CPU emulator?

[Francois Gouget]

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.

When will Wine integrate an x86 CPU emulator?

[Anand Kumria]

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/%3E. 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

When will Wine integrate an x86 CPU emulator?

[Lionel Ulmer]

> 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

When will Wine integrate an x86 CPU emulator?

[Jim White]

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

When will Wine integrate an x86 CPU emulator?

[Francois Gouget]

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%22%3EDarwine</> 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