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