On Tue, 19 Sep 2000, David Howells <David.Howells@nexor.co.uk> wrote:
> Daniel Pittman <daniel@rimspace.net> wrote:
[...]
>> 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.
*blink* I confess that I can't see that much of a requirement for the
ptrace stuff, but I take your word for it. :)
> 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.
Not really something that I would have thought was needed -
specifically, the userspace libraries that the process was dynamic
linked to would have been the place to do that, I thought.
> 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.
That, however, is a convincing reason.
>> 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.
I can't, in honesty, see why you would want to do them as a GDI server.
However, if you did, yes, there would be a high cost. That would be one
of the reasons that I, personally, would have avoided that method.
> However, what I said about system handles and the registry, may also
> apply to GDI objects.
IIRC there are not any waitable GHI objects, precisely because under
Win32 the GDI is a userspace library that does most of the magic
internally and then, finally, requests that the server does something.
Like sockets, the GDI isn't actually a Win32 kernel thing, it's a Win32
userspace wrapper that makes the minimalist kernel support more
palatable.
[...]
>> 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 API.
Well, that's a point of view thing. The native NT API isn't anything
beyond kernel32, as such. Certainly, the GDI isn't part of the core API
and, in some cases, MicroSoft do release or use the NT core without the
GUI system, at the least.
Anyhow, I am hardly an expert on the area, but... I would have avoided
putting stubs into the kernel anywhere that it was possible and used the
userspace dynamic Win32 libraries to do most of the work.
OTOH, I would also have implemented the WaitFor* set as a wrapper over
select, with the kernel module providing suitable file descriptors for
adding to the set that you waited for.
We have fairly different views on how this stuff would hang together
and, in all likelyhood, mine are based on incorrect assumptions. :)
Thanks for answering the questions,
Daniel
--
"Do you kids think you're going to live forever?" I shouted at the
innocents. "Do you think life is some kind of holiday? You think that one day
you'll stop being depressed! You won't ever stop being depressed! No matter
how much sex you have!"
-- Donald Antri, _New Yorker Magazine_, 21/6/1999
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:21 EST