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.

-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
           Demander si un ordinateur peut penser revient à demander
                          si un sous-marin peut nager.