ntoskrnl status

Vitaliy Margolen wine-devel at kievinfo.com
Thu Jun 15 21:48:01 CDT 2006

Thursday, June 15, 2006, 10:01:03 AM, Brian Vincent wrote:
> On 6/15/06, Mario Demontis <mario.demontis at email.it> wrote:
>> Any news about ntoskrnl.exe support?
>> As far as I can understand it's not yet integrated...
>> Are there any new patches?

> Read here first:
> http://www.winehq.com/pipermail/wine-devel/2006-April/047262.html

> Read here next:
> http://www.winehq.com/pipermail/wine-devel/2006-June/048583.html

> Vitaliy Margolen seems to be working on it a bit.

> Vitaliy - in your email above you wrote, "Here is last instalment".
> Did you mean, "Here is _the latest_ installment."?  I was going to
> include that post in this week's WWN and just wanted to make it
> correct.

Yes sorry. It was last at the time I sent it. Now I have one more (with
suggested fixes and against yesterday's git.

As far as state of it:
1. It runs again using new method of communications to ntoskrnl.
2. It's still more of the prove of concept stage then production quality code.
3. There are several hacks that needs to be dealt with.
4. Not yet agreed on what ntoskrnl.exe should be (a dll, or a separate process).

1) We used named pipe to talk to ntoskrnl directly from the user space. Now all
the communication is going through wineserver.

2) New ioctl code is highly experimental. wineserver needs to use already setup
objects and structures. To start with, I think user space code and ntoskrnl code
are good enough.
Driver loading looks fine, with exception of service query. We need some way to
check if driver is loaded and running (might need to add one more ioctl to the

3) ntoskrnl startup is suboptimal. It should look like explorer's startup (there
are few problems and major differences however). One more hack is associated
with process startup sequence of events. Wine differs from native in such a way
that brakes safedisc.

4) Alexandre offered an idea to make ntoskrnl.exe a dll that could be loaded by
an existent explorer process. This is an interesting approach, but there could
be some complications associated with it.

So to sum it up: we have a working prototype that's been in this state for
almost a year now. It's big project with number of different parts. Each part
could be a big project on it's own if implemented all the way. So if anyone
wants to spend some time learning the subject and getting it into Wine, they are
very welcome to jump on board.


More information about the wine-devel mailing list