I have completely hand-installed DirectX 9.0c at this time along with dxdiag.exe and additional DXMedia runtime components along with the DCOM and several other subsystems from Windows 2000 professional
Well, native DirectX (DirectDraw+Direct3D at least) requires some kernel/driver support that Wine cannot really provide. This is one reason why we have our own implemention. If you want better games support you'd be better off working on our own implementation.
the majority of this functions cleanly and as expected... however there is a number of "missing"/"undefined" functions and I would like to not only see a stub presence for these... but also would like to attempt making a functional replication of the functions concerned appear within the wine libaries for compatible completeness at least to the Windows 2000 pro release libraries I am using,
Most of these will be undocumented and very complex to reverse engineer. I would not bother.
-- Creation of DLL stub libraries in "C:/Windows/*" heirarchy --
Question...What is the problem defined here?
Wine DLL's being compiled to PE objects and usable on Windows for replacing commercial code with GPL code ? or providing a Linux based set of files to show a more "complete" "Wine" package installation ?
The latter.
why not have a "wine.dll" that is *NEVER* PE compiled and have that present itself for any "wine on linux" specific compatability calls and present any and all other loadable objects as if they were origin format native within the active runtime environment?
Yes, that's not a bad idea for if we went down that route. But I think we want to keep using ELF DLLs for as long as possible.
thanks -mike