kernel level drivers - next try
saulius2 at ar.fi.lt
Fri Oct 13 15:18:42 CDT 2006
(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.
> 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 where "services.exe" is for
argv. 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
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(),
> 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.
More information about the wine-devel