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

[Sebastian Lackner]

On 24.02.2016 15:16, Aric Stewart wrote:
> Signed-off-by: Aric Stewart <aric(a)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?

* 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

[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(a)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