Wine Traffic #178 For 11 Jul 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 178th release of the weekly Wine Weekly News publication. It's main goal is to just be thankful for warm summer days with bright blue skies. It also serves inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 146 posts in 662K.

There were 55 different contributors. 33 posted more than once. 28 posted last week too.

The top posters of the week were:

1. News: Wine-20030709, AutoCAD Tips, Linux Refresher Course

5 Jul 2003 - 11 Jul 2003 (2 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardNews

It's that time of the month again. Wine-20030709 is out:

WHAT'S NEW with Wine-20030709: (see ChangeLog (http://cvs.winehq.com/cvsweb/wine/ChangeLog?rev=1.73&content-type=text/x-cvsweb-markup) for details)

I stumbled across some links last weekend that were interesting. First, Stephanie Yoder figured out how to get AutoCAD LT 2000 to run on with Wine. Instructions (http://www.flatmtn.com/cad/linux-lt2k.html) can be found on her web site. Needless to say, it doesn't sound that intuitive. I did find another site (http://pages.sbcglobal.net/mycroft/linux/) that describes a different set up. Like many things in Wine, you can make it work if you're willing to put some time into it.

Another site I ran across is "Linux Refresher Course (http://linuxrefresher.com/) ". Their top two pages reference Wine. The first discusses migrating from Windows (http://linuxrefresher.com/intro/migrate.htm) to Linux; the other is strictly an introduction (http://linuxrefresher.com/additional/wine.htm) to Wine.

2. Viva la Kernel Module Idea

7 Jul 2003 (7 posts) Archive Link: "Speeding up wineserver (again)"

Topics: Integration, Architecture

People: Troy RolloOve KaavenOve KåvenDavid Howells

About every six months or so someone brings up the topic of a kernel module for Wine. This time, Troy Rollo brought forth some specific ideas how to do it:

I've been looking at the various efforts over the years to speed up wineserver or eliminate it altogether (by substituting a kernel service). Certainly the current degree of reliance on a separate process that is scheduled according to the operating system's own priorities creates significant speed problems. Some of this migh be alleviated by boosting the priority of the wineserver process or by making it a real time task, but there are still some operations it appears to be performing some operations that result in a yield and hence subject it to another wait in the queue for at least one time slice.

Even if the wineserver itself could be sped up in this way, individual processes would stull be subjected to time waiting in the queue after they make a request of wineserver. The problem becomes more severe on a heavily loaded system.

The approaches suggested so far:

Shared memory
Suffers from reliability problems which may allow one process to put the system in an inconsistent state.
Kernel module
The only effort so far seemed to put way too much into the kernel, and was abandoned over two years ago.

Other possible approaches that I haven't seen directly discussed on the wine-devel list:

An exokernel using the x86 multiring capability
Not portable to non-x86 architectures.
Cross-process calls
Also referred to under other names. This mechanism would allow one process to call into another process without giving up part of its time slice. Would require modifications to the kernel's scheduler and to standard kernel data structures, hence would have to be considered "rude". It would have one advantage in that the interface differences between this mechanism and the current mechanism could be transparent.

Have I missed any?

Anyway, I'm thinking that perhaps the kernel module approach was the right basic approach, but that the particular attempt made was merely too broad. A better approach would be to define a set of kernel calls that could be used to implement all of the other stuff (and there are currently 176 types of wineserver request, so I haven't taken the time to see if I've covered them all yet) in an in-process library.

Transparency substitution for wineserver would, I guess, be achieved by having the kernel module and its supporting library implement the wineserver requests using the wineserver data structures, and perhaps having wineserver use a non-kernel version of these facilities.

The following are things I could see immediately would be part of the kernel module:

There would be other things that would be in the "nice to have" category too (I'm thinking specifically about path name translation being done in a way that requires less seeks through the file system).

The way I see this working is that Wine kernel objects are stored (strangely enough) in kernel memory. This effectively amounts to a shared memory approach but with the kernel module able to clean up after a misbehaving process. In the event that cleanups after a misbehaving process were to be too complex, there would still be room for a server process that does this, and the kernel could simply assign ownership of the objects from the bad process to the server process, which gets notified via another set of calls when it receives the objects. The object name would be of the form "namespace:name", so as to have:

A process could allow the kernel to assign the name within the namespace, so that, for example:

The idea behind the "wine_attach_to_kernel" call would be to allow for the kernel to serve either multiple different users or multiple different Windows operating system types without the objects from all of them being intermingled.

His email was met with an underwhelming response. I think at this point a lot of developers don't consider the speed up offered by a kernel module as being a high priority project. The basic idea for what should be done has been outlined in the past as well as what not to do. If a kernel module dropped out of the sky and worked well enough it would probably be incorporated. For more background on a Wine kernel module see the following WWN issues, be sure to click on the WWN Archive link for a complete discussion:

#59 (http://www.winehq.com/index.php?issue=59#A%20way%20to%20speed%20up%20Wine) :
Post by David Howells about a Wine kernel module he implemented
#60 (http://www.winehq.com/index.php?issue=60#A%20way%20to%20speed%20up%20Wine) :
Alexandre's thoughts on how a kernel module should work
#86 (http://www.winehq.com/index.php?issue=86#Wine's%20speed%20up%20(cont'd)) :
Discussion of David's kernel module and more ideas on communicating with wineserver
#91 (http://kt.zork.net/wine/wn20010415_91.html) :
Update on David's work
#83 (http://kt.zork.net/wine/wn20010219_83.html) :
Initial idea for shared memory and preliminary design considerations.
#148 (http://www.winehq.com/index.php?issue=148#Shared%20Memory%20Wineserver) :
Announcement of a shared memory wineserver.
#154 (http://www.winehq.com/index.php?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited) :
Discussion of the shared memory approach
#159 (http://www.winehq.com/index.php?issue=159#Threading%20Work) :
Why Alexandre doesn't like the shared memory idea.

Ove Kåven replied to Troy's idea:

Which operations are you really concerned about? Just synchronization (WaitFor*, SetEvent, etc), file requests (get_unix_fd), or "all of them" in general?

It seems that when trying to run some of the latest 3D games under WineX, about half of the cpu time is spent on wineserver communication, on average.

And then there's the approach that Alexandre suggested when he saw that big kernel module. Currently I have a design in mind that would implement something along those lines, but since Gav seems in love with the shared-memory approach, I don't know if I'd get that much time to work on it.

Basically this module I'd like to write would not change too much in the existing wineserver. But instead of unix sockets (AF_UNIX), we'd make the wineserver use a "wine socket" type (AF_WINE) implemented in the module, which would work a bit like unix sockets, but which would intercept wineserver requests from wine clients and process the most time-critical types straight in the kernel. It'd pass any request it doesn't implement on to the regular wineserver. The regular wineserver could do ioctls for stuff like "signal this object" to tell the module when it should satisfy wait requests handled by the module and such. And each wineserver listening socket would be its own namespace.

While it's probably going to be hard to get all the details and races right, this would accelerate many server requests while also avoiding any kind of user-space shared memory, which has always been the main concern. And it wouldn't be trying to do too much.

3. RPC Via Windows Messages and Other OLE Fun

8 Jul 2003 - 9 Jul 2003 (14 posts) Archive Link: "MS OLE questions"

Topics: RPC / COM / OLE

People: Mike HearnOve KaavenChristian CostaKelly LeahyOve Kåven

Mike Hearn had some rants ..er.. questions about OLE:

I was wondering whether anybody with experience working with microsofts ole implementation (win98 version) could answer these questions:

Firstly, does anybody know what it does during thread detach? Its behaviour seems to vary according to, i dunno, the alignment of Mars and Jupiter or something. With a test app it destroys the hidden windows it seems to use for IPC, and terminates cleanly. With my IE-in-java app, it goes into a message loop, processes some messages then blocks waiting. It never drops out of the message loop.

Secondly, does anybody know what is missing from Wines built in OLE implementation for it to be used for IE embedded? I've tried using it, and other than a couple of bugs in the GIT (which I will try and send a patch for soon), it seems to get stuck in ITypeInfo::Dispatch() and ends up with an E_NOTIMPL exception.

Thirdly, why does MSOLE use hidden windows for communication? I've come across lots of gnashing of teeth in OLE/DCOM forums about this, people wondering why their app (and sometimes the whole system!) deadlocks if they don't service the message queue in threads that use OLE. Windows has had other forms of IPC for years, I can't see the logic behind using the limited and broken message passing scheme for it.

Wierdly enough, wines built in OLE seems to work OK for iexplore.exe itself, which iirc simply embeds the ActiveX control like any other program. So, maybe it's just a strange little bug that is stopping it from working.

anybody got some insight?

With regard to the first question, Ove Kåven replied, " I think it will also try to disconnect any proxies and stubs that were created in the apartment about to be destroyed, but I don't remember exactly. But I know it's mentioned somewhere, perhaps in the book I've read." Mike wanted to know which book (thus far no answer).

Christian Costa took a stab at the third question, " IFAIK, this is how apartments are implemented and this comes from Windows 3.1. " Mike researched a bit and came across an MSJ article describing when it's used (http://www.microsoft.com/msj/0596/activex0596.aspx) . When the RPC connection is only on the local machine (that is, you're not doing RPC over the network) it uses private windows messages. Mike wanted to know why they would ever do it that way. Ove had some thoughts:

"

DCE RPC is in its heart an interprocess protocol, not an interthread protocol. This distinction does not necessarily matter, though, it can be used as both if done "right". RPC needs a transport layer, however, and which transport is used for communication depends on the context. Thread pools servicing network sockets is used for inter-machine (and perhaps inter-process) communication. For inter-process communication, NT LPC (something like that, don't remember anymore) is used. For inter-thread communication (including dispatching inter-machine requests to a particular thread), the most reliable system communication path with thread affinity is used: window messages.

Yes, Windows's implementation of DCE RPC implements window messages as a transport protocol. So they probably *did* move fully to DCE RPC, they just moved the old cruft in there too...

"

Kelly Leahy saw a potential problem, " in order to avoid the blocking RPC system call, the thread enters a message loop and makes the RPC system call on another worker thread (when a call is made within the channel implementation). If this pool of threads and worker-made-call functionality is not currently implemented in the standard IRpcChannelBuffer implementation in WINELIB, then we probably need to implement it somehow. "

Ove replied he'd already implemented that and posted a rough patch (http://www.winehq.com/hypermail/wine-devel/2003/07/0179.html) . Mike worked on his project a more, but this is where the thread ended.

4. Structured Exception Handling Support for GCC

7 Jul 2003 (1 post) Archive Link: "Fwd: [MinGW-dvlpr] Snapshot of SEH enabled GCC released"

Topics: Build Process

People: Casper HornstrupSteven Edwards

Steven Edwards forwarded an email to wine-devel about support for Structured Exception Handling in gcc:

A snapshot of GCC 3.4 20030701 with Structured Exception Handling support has been released. It can be downloaded from:

No new features. This is just a port to GCC 3.4. The release includes only the C compiler.

Steven asked, " Is there anyway this could be of use to WINEgcc? I figure not but I wanted to ask as it might not ever get merged in to GCC-HEAD. I dont think so but if anyone is still interested in SEH for WINE and Winelib its worth a look at least."

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.