interesting stuff I have been finding out about DirectX
after investigating the DirectX NT dlls as part of an investigation to see if they would work on ReactOS, I discovered something. The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont seem to make kernel-mode or driver/hardware calls directly. Most of it appears to be done via other places (such as winmm.dll, some special thunks in gdl32.dll and others) If my theory is correct (remember though, its just a theory), it may be possible to not only use the directx userland dlls (like ddraw.dll & friends) with ReactOS but it may be possible (if one were to implement the lower-level stubs) in a meaningfull way) to use said dlls with WINE. If it is possible to use native versions of some of the high-level bits, that could really help get more games going... One of the main things that would be needed is a proper implementation of the GdiEntryxxx functions and the DdEntryxxx functions in gdi32.dll, they are the "thunks" that allow DirectDraw and Direct3D to talk to kernel mode. DirectSound & DirectMusic appear to go through winmm.dll to talk to the sound hardware.
The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont seem to make kernel-mode or driver/hardware calls directly. Most of it appears to be done via other places (such as winmm.dll, some special thunks in gdl32.dll and others)
Well, if you look at TransGaming DDraw code in Wine, you will see that they mimic the way DirectX is doing this (ie by somehow using an Escape in the GDI which returns a structure filled with function pointers and private datas). Now this is a debate we had in the current WineHQ D3D development team : should we base our DirectX implementation on how Windows does the separation between the DLL and the drivers or just implement the DLL and do our own driver interface. After some debate, we choose the second one : - to not be tied down to some MS APIs at both sides (ie at DLL entry points and at DLL exit points). - DLL entry points are 1) documented pretty well in MSDN and 2) easily testable by doing some simple Win32 programs. Compared to the MSDN, the DDK I read was a lot more difficult to read (and I have no idea if it's even 'legal' to implement something using the DDK without MS' aproval as it's not really a published API). - finally, as the ultimate goal of Wine is to reimplement Wine and as no applications should use these low-level calls directly, the current solution used in Wine works fine :-) Anyway, if people from ReactOS want to use our DirectX calls with Windows drivers, the way we choose is not the way to go... Lionel -- Lionel Ulmer - http://www.bbrox.org/
- DLL entry points are 1) documented pretty well in MSDN and 2) easily testable by doing some simple Win32 programs. Compared to the MSDN, the DDK I read was a lot more difficult to read (and I have no idea if it's even 'legal' to implement something using the DDK without MS' aproval as it's not really a published API). See this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui... That explains some stuff about the DdEntry and GdiEntry stuff...
See this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui... That explains some stuff about the DdEntry and GdiEntry stuff...
Oh well, they added some DDK docs in the MSDN (which were not really there last time I looked)... But it's as we feared : they explicitely tells us that this interface may change on each DirectX revision (which is normal as the driver interface need to change to accomodate more advanced graphic options). So we may have to rewrite 'old' DirectX code each time a new revision of the DDK comes out. Anyway, the current code is current not written at all with a DLL / Driver separation in mind (there are some plans about it, but nothing has been done yet from what I know). And you should speak to Raphael about this, he's the one motivated to do this (I am not, as getting more games to run is more fun than to rewrite everything :-) ). And more people to code would be welcome of course. And I think if you really want us to go the DDK way, you would need to at least do part of the work yourself :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Anyway, if people from ReactOS want to use our DirectX calls with Windows drivers, the way we choose is not the way to go...
Once the system dlls are complete, shouldn't it be possible to go both ways? e.g. delete the wine DX stuff and install some MS-DX? If all low level calls are implemented this should work too, no? bye Fabi
--- Fabian Cenedese <Cenedese(a)indel.ch> wrote:
Anyway, if people from ReactOS want to use our DirectX calls with Windows drivers, the way we choose is not the way to go...
Once the system dlls are complete, shouldn't it be possible to go both ways? e.g. delete the wine DX stuff and install some MS-DX? If all low level calls are implemented this should work too, no?
WINEs directx design is not the same as Microsofts but yes once ReactOS is ready you should be able to install the directx from M$ or from Winex. I would like to see Winehq go to the same design as Windows2000,XP,etc. The issue seems to be the lack of stablity and the need for a DDK and associated interfaces. Not to mention lack of Wine developer interest =) Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Jonathan Wilson wrote:
after investigating the DirectX NT dlls as part of an investigation to see if they would work on ReactOS, I discovered something. The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont seem to make kernel-mode or driver/hardware calls directly.
When you say NT, do you mean NT4, or any in the NT-family? (NT4 officially has only DirectX3, and there is a Direct5 unofficial beta out there.) jakob
participants (5)
-
Fabian Cenedese -
Jakob Eriksson -
Jonathan Wilson -
Lionel Ulmer -
Steven Edwards