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.