Hello List, I had a talk to the DirectX developers of reactos on their irc channel to discuss how Reactos and Wine can share efforts on DirectX. (Please leave the legal issues asside for now, let us concentrate on the technical part for now).
I didn't expect much possibility for a cooperation in such a hw-related thing as DirextX, but Greatlord told me about the gdi / win32k problem Wine is heading to with the current DirectX code.
According to Greatlord, Microsoft's DirectX implementation basically consists of a kernel-side part in gdi.dll and win32k.sys, and a user-mode part in ddraw.dll, d3d8.dll and d3d9.dll. The user dlls contain the Hardware emulation layer code, and calls to the kernel for the Hardware abstraction layer. Now that wouldn't be a problem for Wine, as applications are expected to use the user mode dlls, and using the kernel interface is highly discouraged by Microsoft. However, there are a few apps out there which access the kernel interface directly, and Greatlord told me that he knew about a few companies which plan to use it to gain speed improvement. Expectedly, such apps won't work on Wine.
My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer).
I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings.
Another thing we discussed was DirectInput. ReactOS uses wines dinput.dll, with improvements which gets the sdk demos and some nasty games working. I can see if I can merge the changes to Wine.
On 29/03/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings.
Personally, unless it really becomes an issue, I'd rather not. It think it's hard enough to figure out what a particular d3d call is supposed to do as it is.
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote:
My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer).
first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then?
on the other hand, if the interface of the kernel parts is hardly documented why not stick with the current implementation that does a good job with what it does and implement/stub the kernel things once an app crashes?
On Thursday 30 March 2006 06:51, Christoph Frick wrote:
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote:
My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer).
first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then?
Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Of course the blame is shifted to the user, but if one thinks about corporate wine deployments, they wouldn't want to do illegal things. They might as well deploy pirated Windows, you know. And mind you, Direct X is not for games only. I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet).
Cheers, Kuba
On Thu, Mar 30, 2006 at 08:29:03AM -0500, Kuba Ober wrote:
Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows.
Might be or is? Or will be like dcom? At least with dcom ms made the point clear. they just dont provide it beside the os. but i can not remember a single game in my collection, that does came with the dx-package needed to run it (i hardly remember anything that came with dcom98.exe). so does anybody knows the actual license or is there anything known what ms has in mind in the near future?
I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet).
yeah i am sure there are lots of non-game applications that utilize directx - dsound for sound apps, d3d for cad, office, 3d, ... and so on.
all in all i know close to nothing what goes on the various dlls - but from a point of view like this it seems to be a lot of work to redo the work of others if there is no real need for it, like e.g. accessing hardware or operating system stuff. license issues aside i would only a consider a massive performance gain something that is worth it (and there still remains the question, why is that original dll so much slower with the underlying framework then). and of course its a lot easier to implement something that is *cough* well documented than something that is totally unknown to mankind.
Sounds like a good project to hack on occasionally while putting the majority of effort into improving the current implementation. In other words, some effort is warranted because of the benefits of sharing code, however, wine can always transition to the new layout after it has a complete and (mostly) correct DirectX implementation.
There's no reason the GDI and win32k.sys couldn't be going into the wine tree at the same time as improvements to the current system.
--tim
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote:
My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer).
If you look back at the wine-devel archives, this point was discussed at the moment 'wined3d' was started (i.e. do we go the MS way with HAL / HEL / ... or our own way with 'wined3d').
And the conclusion was that the DDK interfaces being poorly documented (no idea if they are even *publicly* documented - thus leading to all sort of legal mess if you implement Windows' internal APIs) and that they should not be used by external applications (thus enabling MS to change them for each new DirectX revision) made us choose the other way.
Not to mention also that if the 'native' DDraw / D3D / ... DLLs were to work over this API, nobody would spend time working on them :-)
Lionel
Am Samstag, 1. April 2006 11:03 schrieben Sie:
If you look back at the wine-devel archives, this point was discussed at the moment 'wined3d' was started (i.e. do we go the MS way with HAL / HEL / ... or our own way with 'wined3d').
I searched the archives, but I didn't find anything. Well, IMO it's quite hard to find anything in the archives, I even have problems finding my own mail :-|
And the conclusion was that the DDK interfaces being poorly documented (no idea if they are even *publicly* documented - thus leading to all sort of legal mess if you implement Windows' internal APIs) and that they should not be used by external applications (thus enabling MS to change them for each new DirectX revision) made us choose the other way.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui... But I think one needs the ddk for more information. Many links give a 404 error :( . And the ReactOS developers say that a lot of this interface documentation is incorrect. Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken.
Ah, and another thing: Do not look at the ReactOS Direct3D and DirectDraw sources, GreatLord told me that they are dirty reverse engineered. (I didn't look at them eighter, luckily)
Stefan
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote:
Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken.
Of course it is documented for people in companies like NVIDIA or other IHVs, but well, it's not publicly documented (AFAIK - I would gladly be proven otherwise).
I would not be surprised to see the full DDK documentation coming with license agreements or NDAs.
Lionel
I havent seen any microsoft source or any other dirty stuff but what I know is that the DirectX dlls call functions like ddentryxx and gdientryxx in gdi32.dll. (there is a ddrawgdi.h file in the platform SDK I have and there is also documentation on MSDN for them) These then call system calls that thunk down into kernel. In the kernel mode code, I believe that a combination of code in win32k.sys, code in dxapi.sys, code in dxg.sys and code in the display driver are what actually do the work. (although I dont know for sure the relationship or what is going on here)
Also, I dont know exactly how complete it is but I know that the windows DDK and/or the DirectX SDK includes header files like d3dnthal.h and that there is documentation for the stuff in those header files in MSDN.
Am Samstag, 1. April 2006 11:53 schrieb Lionel Ulmer:
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote:
Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken.
Of course it is documented for people in companies like NVIDIA or other IHVs, but well, it's not publicly documented (AFAIK - I would gladly be proven otherwise).
I would not be surprised to see the full DDK documentation coming with license agreements or NDAs.
Hm. http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx
Didn't read that fully yet, but if I find the time I'll read it. I think the source code of the reference rasterizer comes with the driver development kit. But I know that I shouldn't try to get hold of the DDK before checking the license. Well, I guess it's a no-no for Wine developers :-|
Am Samstag, 1. April 2006 12:54 schrieb Stefan Dösinger:
Am Samstag, 1. April 2006 11:53 schrieb Lionel Ulmer:
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote:
Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken.
Of course it is documented for people in companies like NVIDIA or other IHVs, but well, it's not publicly documented (AFAIK - I would gladly be proven otherwise).
I would not be surprised to see the full DDK documentation coming with license agreements or NDAs.
Hm. http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx
Didn't read that fully yet, but if I find the time I'll read it. I think the source code of the reference rasterizer comes with the driver development kit. But I know that I shouldn't try to get hold of the DDK before checking the license. Well, I guess it's a no-no for Wine developers :-|
Just tried to read that EULA (now my brain hurts). Doesn't look too well (may only be used to write drivers for Microsoft Windows, nothing else). Probably invalid in the EU, but I'm not sure.
Anyway, the Vista WDF stuff seems to have a more suitable license (you may redistribute sourcecode, writing documentation is not forbidden, and the license even states that you may do whatever is legal with the stuff if you don't live in the United States) AFAICT:
http://www.microsoft.com/whdc/driver/wdf/default.mspx
-
Christoph Frick -
H. Verbeet -
Jonathan Wilson -
Kuba Ober -
Lionel Ulmer -
Stefan Dösinger -
Tim Schmidt -
Willie Sippel