* 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
