kernel level drivers - next try

[Saulius Krasuckas]

* On Wed, 11 Oct 2006, Marcus Meissner wrote:
> - Services are handled and registered by ADVAPI32.
> 
>   Currently we handle process type services correctly,
>   which are started using CreateProcess().
>   These are marked with SERVICE_WIN32 or similar flags.

Right, probably this type is handled correctly, but I guess whether 
SERVICE_KERNEL_DRIVER type cannot be handled in similar way?  I've 
winedumped *.sys files of some drivers (GIVEIO.SYS was primary target) and 
saw their dump doesn't contain DLL keyword while EXECUTABLE_IMAGE is still 
present here.

> - Kernel drivers use SERVICE_DRIVER (or SERVICE_KERNEL_DRIVER
>   specifically).
>   Q: How should those be loaded and where?
>      Alexandre seems to suggest we start a seperate services.exe
>      and load them in there?
>      Is this the way to go?

Why not?  Very similar is a conclusion that Vitaliy Margolen has wrote up 
to wine-devel during a discussion [1].  Only difference is that in patch 
[2] from him Ntoskrnl.exe is started instead of Services.exe.

>   Q: How to start them?
>      CreateProcess(services.exe name.sys) on commandline?
>      Or via some kind of other control mechanism?

Sounds like an elegant solution to me.  But probably some IPC operations 
will be needed for every non-first instance of Services.exe.

In the patch [2] seems some pipe reading/writing is used for that inside 
NtLoadDriver()/driver_managment() after the Ntoskrnl.exe was started via 
NTOSKRNL_connect() <- NtLoadDriver() <- StartServiceW() chain.

I may sound a bit arogant here, but I cannot imagine some very different 
mechanisms right now :p

> - Filehandles ...
>   The whole issue of handling the HANDLEs that are necessary
>   is unclear to me.

Marcus, are you talking about an I/O Alexandre has mentioned in the same 
thread [3] or about typed handles mentioned in the Mike-vs-Damjan 
discussion [4] ?

Also I'm sorry to not sit on irc and to don't know latest news on this 
topic.


[1] http://www.winehq.com/pipermail/wine-devel/2005-September/039862.html 
[2] http://www.winehq.com/pipermail/wine-devel/2006-January/044250.html 
[3] http://www.winehq.com/pipermail/wine-devel/2005-September/039910.html 
[4] http://www.winehq.com/pipermail/wine-devel/2005-September/039905.html