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



-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/