[PATCH 2/2] Programs: Load device drivers of the same group into the same winedevice process

[Aric Stewart]

Thank you for looking over my patches.


On 2/25/16 11:30 PM, Sebastian Lackner wrote:
> On 24.02.2016 15:16, Aric Stewart wrote:
>> Signed-off-by: Aric Stewart <aric at codeweavers.com>
>> ---
>>   programs/services/services.c | 124 ++++++++++++++++++++++++++++
>>   programs/winedevice/device.c | 191 ++++++++++++++++++++++++++++++++++++-------
>>   2 files changed, 286 insertions(+), 29 deletions(-)
>>
> 
> Although the general idea seems fine, the patches are still very hacky, and I fear
> we need a better method to communicate between services and winedevices - a separate
> mailslot communication doesn't seem like a good idea. The main issues I still see:
> 
> * Instead of two separate communication channels, we should implement marshalling of
>    data structures, and return them for example in the ServiceCtrlHandler callback.
>    Depending on the exact mechanism, special care has to be taken to ensure the
>    process is up and running before sending control commands.
> 
> * Currently wine supports loading of both 32-bit and 64-bit drivers. This needs
>    special care in both patch 1 and patch 2. A winedevice process with the wrong
>    architecture will not be able to load the driver.
> 
> * programs/services should be able to track the services correctly. Unfortunately
>    it seems like the advapi32 functions do not offer any nice method to add additional
>    services after startup. Maybe we could add a wine-specific extension here?

I have a few follow-up patches that I have not sent yet that basically do this.

I modified winedevice to use IoCreateDriver instead of creating the DRIVER_OBJECT itself. Then ntoskrnl.exe can track all drivers created by IoCreateDriver and programs can use ObReferenceObjectByName using the '\Driver\<something>' path to find loaded drivers. 

> 
> * Proper locking is required before accessing the database or services structures.
>    Those are technical issues though, and can be fixed of course.
> 
> I'm currently trying a couple of own ideas, and will share them as soon as they do
> something useful. ;)
> 
> Regards,
> Sebastian
> 

My basic requirements are that I need to be able to load a number of .sys drivers into the same process space, and Plug and Play drivers are installed with a start type of 3 (On Demand) So the plug and play manager needs to be able to do a StartService or something similar on the no currently loaded driver and have it go into the right process.

Alexandre was the one who suggested doing it by LoadOrderGroup, which I like.

-aric