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