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.