kernel level drivers - next try

[Saulius Krasuckas]

(I may perfectly be ignored by some recipients, but well..)

* On Thu, 12 Oct 2006, Vitaliy Margolen wrote:
> * Marcus Meissner wrote:
> >   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. 

Yes, but...

> 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.

"services.exe" name isn't very artificial.  It comes from real windows.  
Of course, ProcessExplorer shows driver modules loaded by the 
g-g-grandparent of "services.exe", by process "System" with PID=4, but 
using "services.exe" would be closer to NT platforms.

> >   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. 

I think Marcus meant "name.sys" as an argv[1] where "services.exe" is for 
argv[0].  Command line could be just some external way to give 
notification to main instance of separate process about driver loading.

> 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.

Yes, and I would like to share some observations of a noob with list.  

Today I have tried to compile ntoskrnl.exe, then checked out master 
branch, compiled stock Wine, then tried to run win32 app which do simple 
port I/O after it loads (GIVE)IO.SYS driver.  Driver simply loaded, did 
its initialization and immediatelly exited.

> I think unless Alexandre himself explain why none of this work was 
> applied, it's pointless wasting any more time on this. 

That patch is still quite large.  Maybe you (or someone else) should 
select some part of it for Alexandre to review?

BTW, I'd like to be able to get some kernel mode/WDM driver for Win32 
compiled on disk and to test loading it inside WRT suite.  Wouldn't be 
that nice?  The driver could do a pc-speaker beep by perfoming some port 
I/O, no?

Now I am thinking about Win32 port I/O mapping to I/O under linux.  Port 
I/O is used in some applications and they try to modify IOBitMap in a TSS.  
It shouldn't be too hard to map such ntoskrnl-call to ioperm()/iopl(), 
right?

> 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 this doesn't look wrong either (from a WinNT POV).

> and I'm sure we will hit some problem(s) that will require rewrite of it 
> as a separate process.

Of course.