Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote:
On Tue, 6 Sep 2005, Alexandre Julliard wrote:
Peter Beutner p.beutner@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 wineserver.
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.
Vitaliy