Dan Kegel wrote:
Brian Vincent (C) wrote:
This issue has been discussed several times. If you
dig in the WWN archives you'll find mentions of it
going back a few years. Much more interesting was
this post:
http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html
The approach is a shared memory wineserver.
I beg to differ. IMHO the kernel module approach
is the best. The PEACE team, for instance, is
going this route in their implementation of win32
on BSD.
Each approach has its own merits - you'll note in our paper that we also
posted sources and design documentation for KWine, an alternative wineserver
kernel module design that keeps Win32 HANDLE objects in a Linux file system.
We spent some time on that as well before working on the ShmServer approach.
With a kernel module approach, hosting multiple wineserver environments
becomes more difficult. A kernel module also brings with it a number of
packaging issues, and would require significant work to be moved to
non-Linux OSes. Lastly, the kernel module approach requires an all-at-once
rewrite of the wineserver interactions, whereas the ShmServer can be
implemented on a call-by-call basis. About the only thing a kernel module
would have over the ShmServer on the performance front would be the ability
to do PE relocation fixups at page-in time, like Windows does. The value
of that feature is limited, IMHO. A kernel module may also have some
benefits from the security perspective.
Regardless of which one is better, it would be nice to see more interest
in this topic from other developers. If anyone else is interested in
collaborating on the ShmServer or kernel module approaches, that would
be great.
Take care,
-Gav
--
Gavriel State, CEO & CTO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
http://www.transgaming.com/
Let the games begin
