interesting stuff I have been finding out about DirectX

[Lionel Ulmer]

> 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/