From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BY9EG-0002Y3-8M for qemu-devel@nongnu.org; Wed, 09 Jun 2004 15:59:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BY9EE-0002Xc-JS for qemu-devel@nongnu.org; Wed, 09 Jun 2004 15:59:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BY9EE-0002XQ-F5 for qemu-devel@nongnu.org; Wed, 09 Jun 2004 15:59:18 -0400 Received: from [62.4.22.179] (helo=mail.bbrox.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BY9DX-0005Y0-ID for qemu-devel@nongnu.org; Wed, 09 Jun 2004 15:58:36 -0400 Date: Wed, 9 Jun 2004 21:58:31 +0200 From: Lionel Ulmer Subject: Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86? Message-ID: <20040609215831.A21947@bbland> References: <955A2196-B9DB-11D8-99BE-0003934F6406@mac.com> <40C76973.3070608@bellard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C76973.3070608@bellard.org>; from fabrice@bellard.org on Wed, Jun 09, 2004 at 09:48:03PM +0200 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Darwine Devel > > 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/