* 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