[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Wine speedup through kernel module

Daniel Pittman <> wrote:
> Hrm. It would seem more sensible to me that the registry, like the GDI,
> live outside the kernel. This would have some cost in terms of
> performance, I admit, but I don't think it's significant enough to care.
> This is, I confess, based on my personal experience with Win32
> development and may not represent the real state of affairs for all
> developers.
> Having registry access be performance critical or for large data is also
> against the MicroSoft best practice for software, which makes the costs
> lower - no multiple calls to ship large quantities of data. :)
> Anyway, why did you see the need for the registry stubs in this case, if
> I may ask?

Firstly, in wine the registry is handled by the wineserver process. This means
it can be shared between all the wine processes running for a particular
used. So when wine wants to access the registry, it has to do an RPC call to
the wineserver (sending a request across a UNIX socket and then, I think, a
bit of ptrace()'ing to get at the data). This provides a hopefully more
suitable RPC mechanism.

Secondly, the client (wine) just has to issue a syscall that looks exactly
like a Win32 registry function, how it is handled is hidden by the kernel.

Thirdly, registry functions should issue system handles, as is done on
Windows. If system handles move into the kernel, then registry handles should
do too. This also means registry change notifications can be implemented by
system handles that WaitFor*() functions can deal with.

> Well... wont the GDI calls be RPC anyway - specifically, across the X11
> pipe?

Yes, but if I implement them to go to a GDI server, which then talks X11 out
the back, that's two lots of RPC calls.

However, what I said about system handles and the registry, may also apply to
GDI objects.

> In any case, I would have expected (personally, from assumptions) that
> the GDI would live inside the process space and pay the same cost as
> existing X11 applications to do it's display.

Yes, that is my current plan.

> I can't see any sensible reason for implementing anything extra in the
> kernel to support it. Now, adding an X11 protocol extension to make some
> of the Win32 stuff work better...

Now there's an idea... Have the local X server as an RPC server, handling wine
GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall
stubs in the same way. This would allow me to implement a lot of the NT Native

David Howells
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.059 / U:7.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site