Correct but we don't have it in Wine. If we added the Drv functions, while I have the parts of the DIB engine unimplemented, I could forward back to the driver alot easier. There is maybe another way, but having Drv functions make sense in my mind.
That would be perfect (IMHO), when our Drivers (winex11, wineps) use DDI as API. I dont know our Driver-Code in this Area good enough, but I expect that this big change need a lot of testing.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing
The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface).
Do the Eng functions have to be based on DDI? Or can we use it with my DIB engine?
The DIB-Engine on Windows are the main Part behind Eng* and Friends and MS defined DDI as API for that. I had no time yet to look in your DIB-Engine.
Moving to DDI could mean huge changes. The DDI is documented (for a part on msdn) but for the rest I think in driver docs. Transgaming for instance also used the DDI for their DirectX support but at some stage they didn't continue with it because of changes in licensing. So I would watch out with it.
Second if you are interested in this area, I would say skip DDI and start doing things the Vista-way. I'm not sure how DDI works there but in the end everything is layered on top of directx. (of course not the standard ddraw/d3d functions) I would check how Vista is doing things.
Roderick