Marcus Meissner wrote:
Hi,
I want to tackle the problem of loading and accessing kernel drivers again.
Since the previous tries were met with design concerns, lets try to clarify design issues first.
I would say there are 4 issues: 1. We need ntoskrnl.exe - it is more of the DLL that all drivers import functions from. As simple as that. There is also hal.dll but most drivers that import it, most likely won't work on Wine. 2. We need a separate process to run this drivers in. It really needs to be a separate process because lots and lots of things are different in user space and kernel space. 3. Need a way to start this new process and tell it to load a driver. 4. Communication between user process and our "fake" kernel.
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.
Kernel drivers use SERVICE_DRIVER (or SERVICE_KERNEL_DRIVER specifically).
Well it's just a hack IMHO that drivers are the same as services. They are really treated differently on windows and they run in different environments.
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?
Doesn't really matter. It have to be separate process and it we still have to have ntoskrnl.exe. It seemed more straight forward to me and Ivan to combine both. I'm personally against any artificial "services.exe" that has nothing to do with drivers, but more with services. However it's really up to the men to say what goes. Too bad he never said why.
Q: How to start them? CreateProcess(services.exe name.sys) on commandline?
Or via some kind of other control mechanism?
No you can't use CreateProcess. Kernel drivers have nothing to do with other programs and require totally different startup mechanism. They more of the dlls then real process. In my patch you can see how much stuff is actually bypassed for kernel driver and that it's loaded as a dll and not a process.
Filehandles ...
The whole issue of handling the HANDLEs that are necessary is unclear to me.
File handles are done and don't require anything special. It's already in place. What is required is a "device" object. That's the only way how driver can "expose" itself to a user program. Again see my patch, it has all the relevant pieces that I sent numerous times to wine-patches.
I think unless Alexandre himself explain why none of this work was applied, it's pointless wasting any more time on this. It's just another project that will play dead for few more years until it will be totally useless.
The only parts of the conversation that I recall was about being able to use whatever we come up with for "Wine drivers". I'm not entirely sure what is meant here. And I don't see why can we compile "Wine driver" the same way ntoskrl.exe was compiled - which makes it loadable as-is into what I wrote. It will still have to go through all the required stuff for the real kernel driver.
Also Alexandre mentioned something about being able to use win32api instead of native. Well I'm not sure if this is good idea or not, but again I don't see any problems with that. Of course it have to fit properly into kernel infrastructure.
Of course we can make ntoskrnrl.exe a loadable dll and make it part of user process. However this doesn't look right to me and I'm sure we will hit some problem(s) that will require rewrite of it as a separate process.
Vitaliy Margolen.