Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote: > On Tue, 6 Sep 2005, Alexandre Julliard wrote: >> Peter Beutner <[EMAIL PROTECTED]> 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