Need ideas about ntoskrnl
wine-devel at kievinfo.com
Tue Sep 6 11:58:36 CDT 2005
Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote:
> On Tue, 6 Sep 2005, Alexandre Julliard wrote:
>> Peter Beutner <p.beutner at gmx.net> writes:
>>> Any reasons given?
>> Stability is the obvious reason. And also of course the fact that we
>> have most of the code we need in ntdll already and none of it in
> Just trying to move things forward and understand because I'm curious:
> So the way to do it would be to have ntdll load the drivers in the
> process using them?
This obviously will not work. Drivers need their own space (i.e. kernel space).
Besides, that will complicate things a lot. Also that means adding to ntdll
something that does not belong there.
On the other hand, this allows to implement buffer method METHOD_NEITHER the
way it should be (running in the process's thread context).
> Wouldn't that cause problems if a driver expects to be able to maintain
> shared information across processes?
Yes it will. Is I understand, drivers don't have a concept of a process. So all
the information they maintain, is global to all processes.
> Do we know if this is going to be a problem with the drivers we are
> interested in?
It looks like all protection systems have some kind of loader, and the game
itself in some kind of wrapper or encrypted. A loader can set some information
up in the driver. This information will be used by the game process and/or
wrapper to do some magic/decrypt game before starting it.
All this means that we need a separate process emulating kernel internals (to
some extent) just enough for these drivers to work. Wineserver is not a suitable
place for drivers, since it's not a "windows process". We can't load drivers as
a dll to the calling process either.
This leaves only one option - dedicated process for drivers.
More information about the wine-devel