[Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[John Davidorff Pell]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

I was just thinking about this: It might be a good idea to CC all posts 
to this list to the main qemu list, so that a) we can get more feedback 
b) we can be more visible to other qemu maintainers b) fabrice sees 
that he should help out in the port to MacOSX (Which is likely the best 
way to get it running and happy). :-)

Also, those of you working on darwine-qemu seem to be focusing only on 
the system-emulation, not on the user-mode emulation (qemu-fast). 
Personally, I would *really* really *really* like user-mode emulation 
on MacOSX (but i'm not actually working on code, so I can't complain 
too much). I would think that it would make communication between 
darwine-wine and darwine-qemu easier if both were in the same space, 
instead of one thinking its on/is its own system.

Lastly, I was thinking about how darwine is going to actually use x86 
code from qemu in ppc code from wine. I think that making the user-mode 
emulation work might allow special hooks to be added into the 
darwine-qemu-fast so that the wine API can be called much like the 
syscalls are translated (or would be translated). Endianness is an 
issue, but if all is called from x86 code, can we trick it by just 
keeping it little-endian (or am I just being stupid)?

http://www.winehq.com/site/docs/wine-faq/index#INTEGRATE-AN-X86-EMULATOR

JP



--
Every time you share on a P2P network, God kills a kitten.
Please think of the kittens. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2426 bytes --]

Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[Pierre d'Herbemont]

Le 9 juin 04, à 08:09, John Davidorff Pell a écrit :

> I was just thinking about this: It might be a good idea to CC all 
> posts to this list to the main qemu list, so that a) we can get more 
> feedback b) we can be more visible to other qemu maintainers b) 
> fabrice sees that he should help out in the port to MacOSX (Which is 
> likely the best way to get it running and happy). :-)

For sure... ;)

> Also, those of you working on darwine-qemu seem to be focusing only on 
> the system-emulation, not on the user-mode emulation (qemu-fast). 
> Personally, I would *really* really *really* like user-mode emulation 
> on MacOSX (but i'm not actually working on code, so I can't complain 
> too much). I would think that it would make communication between 
> darwine-wine and darwine-qemu easier if both were in the same space, 
> instead of one thinking its on/is its own system.

System emulation seems to be an easier goal to reach, I might be wrong. 
In the OpenDarwin CVS tree, there is a qemu version with linux-user 
enabled on Mac OS X. It compiles fine, but in fact most of the syscall 
are just turned off, or stripped down. If you want to test it:
cvs -d :pserver:anonymous@anoncvs.opendarwin.org:/Volumes/src/cvs/od 
login
 >pass: cvs
cvs -d :pserver:anonymous@anoncvs.opendarwin.org:/Volumes/src/cvs/od co 
-P proj/darwine/related/qemu

> Lastly, I was thinking about how darwine is going to actually use x86 
> code from qemu in ppc code from wine. I think that making the 
> user-mode emulation work might allow special hooks to be added into 
> the darwine-qemu-fast so that the wine API can be called much like the 
> syscalls are translated (or would be translated). Endianness is an 
> issue, but if all is called from x86 code, can we trick it by just 
> keeping it little-endian (or am I just being stupid)?

Endiannes is definitely _the_ issue, at least for me. Since we won't 
just translate simple sycalls, but function call over library, so the 
dll can access the exe Little Endian memory. My idea was to lock LE 
memory zones (using mprotect), and as soon as a Wine ppc DLL try to 
access this block of memory catch the signal raised and do the needed 
swapping. I did test this trick while loading the PE litlle endian EXE, 
and it worked fine. Also about working directly on qemu-fast, I prefer 
doing the job directly in Wine :P But why not using Qemu for its 
initial purpose?

Pierre

Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[Fabrice Bellard]

John Davidorff Pell wrote:
> I was just thinking about this: It might be a good idea to CC all posts 
> to this list to the main qemu list, so that a) we can get more feedback 
> b) we can be more visible to other qemu maintainers b) fabrice sees that 
> he should help out in the port to MacOSX (Which is likely the best way 
> to get it running and happy). :-)
> 
> Also, those of you working on darwine-qemu seem to be focusing only on 
> the system-emulation, not on the user-mode emulation (qemu-fast). 

You mean qemu-i386 ?

> Personally, I would *really* really *really* like user-mode emulation on 
> MacOSX (but i'm not actually working on code, so I can't complain too 
> much). I would think that it would make communication between 
> darwine-wine and darwine-qemu easier if both were in the same space, 
> instead of one thinking its on/is its own system.

User mode emulation with qemu-i386 is not interesting for the darwine 
project. You should concentrate in using libqemu in wine. Look at the 
example in qemu/tests/qruncom.c.

> Lastly, I was thinking about how darwine is going to actually use x86 
> code from qemu in ppc code from wine. I think that making the user-mode 
> emulation work might allow special hooks to be added into the 
> darwine-qemu-fast so that the wine API can be called much like the 
> syscalls are translated (or would be translated). Endianness is an 
> issue, but if all is called from x86 code, can we trick it by just 
> keeping it little-endian (or am I just being stupid)?
> 
> http://www.winehq.com/site/docs/wine-faq/index#INTEGRATE-AN-X86-EMULATOR

You should add an automatic stub code generator which generates code to 
swap the arguments for all wine entry points.

Fabrice.

Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[Lionel Ulmer]

> > http://www.winehq.com/site/docs/wine-faq/index#INTEGRATE-AN-X86-EMULATOR
> 
> You should add an automatic stub code generator which generates code to 
> swap the arguments for all wine entry points.

Which would work (maybe) for Win16 applications or 'simple' Win32 ones, but
as soon as you start to use COM, you need to take great care as there is
currently no way to know which are all the 'exported' functions (as they are
stored in VTables).

Moreover, in the current Wine code, there is absolutely no difference
between some Win32 code calling a Wine function or a Wine DLL calling a
function in another DLL. So there would need to be a way to differentiate
both (and it's the same issue for COM objects, as they can be invoked either
from Win32 or from Wine code).

Lastly, there is the issue of all the 'opaque' data types - data types for
which the format is known only once some processing has been done in the
called function (for example, a bitmap, a texture or some vertex buffer).

          Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/