Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #97 For 10 Jun 2001

By Brian Vincent

Table Of Contents


This is the 97th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Whew! Finally got this issue out. Between car crashes, floppy drive crashes, and very nearly some mountain bike crashes it's been an exciting week.

Last week Codeweavers announced support for Windows browser plug-ins by using Wine. A nice little article can be found at In particular it mentions support for Quicktime and Shockwave Director and the ability to use this in an embedded environment.

In the CVS tree, work is continuing on improved window manager support, various multimedia fixes including an implementation of glu32.dll, and a bunch of font handling fixes.

Also, a big thank you to Jan Evert, Thomas Viehmann, and David Martinez who've sent in fixes/suggestions/comments on the past few issues. The'yve nticed sometimes get right the issues and XML I don't.

Mailing List Stats For This Week

We looked at 153 posts in 466K.

There were 41 different contributors. 23 posted more than once. 13 posted last week too.

The top posters of the week were:

1. ActiveX Support

27 May 2001 - 29 May 2001 (10 posts) Archive Link: "some unimplemented COM stuff"

People: Malte StarostikJames Hathaway

Malte Starostik has been working on a way to get ActiveX support working in the Konqueror web browser. He's ran into some problems and posted a message to wine-devel:

For testing I'm using the Shockwave Flash OCX and experienced some problems due to unimplemented functions and features in winelib. First thing is typelib registration, which doesn't work yet as the debug output tells. Okay, did that manually. Then, for setting the control's properties, I tried the easy way via IDispatch::Invoke(), which calls ITypeInfo::Invoke() and that's only a stub :( I worked around this via evil assembler hacks to call the interface's members as given by the vtable offsets in the FUNCDESC using stdcall convention - unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).

After getting this to work, I hit the next problem: unimplemented urlmon.RegisterBindStatusCallback and when I use a native urlmon.dll it tries to call shlwapi.154, with native shlwapi it still doesn't work somehow, but that's a different story.

Anyway, what I'd basically need to get this to work properly is

What I'd like to know is if anyone is already working on any of these and if so what's the status and how I could help getting these implemented. if no one started yet, I'd still like to give it a try.

James Hathaway replied with some solutions to some of the problems:

We (Macadamian) were working on implementing oleaut32.dll, if you search the archives of WINE HQ around dec 2000 / jan 2001 you can see some of the patches that we submitted. Unfortunately, work has been shelved for the moment, but there is a starting point for you.

For IDispatch::Invoke / ITypeInfo::Invoke, there is a patch at:

As well please see discussion of patch at:
(with reasons why it wasn't committed, search for "invoke")

He also added that typelib registration just required adding some registry entries.

2. WINE Server Messages

29 May 2001 - 30 May 2001 (4 posts) Archive Link: "WINE server messages"

People: David HowellsAlexandre Julliard

David Howells has been working on a kernel module that will integrate with Wine and (hopefully!) lead to big performance increases. He wrote into the list wondering exactly how to go about integrating some of the wine server functionality into the kernel:

I'm having a little trouble deciding exactly how to emulate the "module registration" functionality in my kernel module. It occurs to me that this might be easier to accomplish with a change to the current wine server message set. My idea is:

Alexandre wondered what would be gained by getting rid of the module list. David explained:


Admittedly, these would be hard to implement fully in the current Wine userspace server I think (they can map a section handle into _another_ process's VM space). However, it's something I can do in kernel space reasonably easily.

And then there's NtQueryVirtualMemory. This can return a handle to the backing section (assuming I'm recalling this correctly) in some other process.

Actually, I see that you do maintain a view list in the client as well as the module list and section lists in the server. What I was thinking of was just consolidating the three into a single view list and a single section list in the server.

In effect, Wine'd still have the module list, it's just that there'd be non-modules in the list too.

This would mean that the debugger could query from the server what Windows VM mappings should be expected.

And, of course, it'd make writing the kernel module slightly easier:-)

But Alexandre wondered what the advantage was:

I still don't see why you want that. The fact that the section list is in the client or in the server is orthogonal to the fact that we maintain a list of modules. If you have a list of mapped views in the server you can simplify the module list a bit by making each module point to the view instead of the backing file, but you still need a module list to send debugger events and do toolhelp snapshots.

You could of course hide the module list inside the section list by adding some magic flags to the section descriptor, but all it changes is that you then need to walk the whole section list to retrieve the modules; I don't really see the point.

The thread ended there.

3. Stanford Checker

4 Jun 2001 (7 posts) Archive Link: "Stanford Checker"

People: Ove KaavenPatrick StridvallPatrick StridvalOve KåvenDavid Goodenough

On linux-kernel there have been a lot of posts over the last few months about the bug checker being developed at Stanford. It's basically an extensible compiler that "allows programmers to insert customized static analysis passes" and a language for writing the extensions. The project is being headed by Dawson Engler and several students at Stanford. David Goodenough was wondering if it was available to be used to check the Wine codebase. Several people replied that the tool was not publically available (yet) and that Wine would probably have to wait until it was released rather than having Stanford check the code themselves. Ove Kåven wrote, " From what I gather, this tool has very limited and context-dependent intelligence, and is not conceptually very different from what a glorified version of Patrik's tools/winapi_check script might be, if given enough people working on it."

Patrick Stridvall responded with a detailed explanation of the differences:

Not quite.

winapi_check is

  1. Specifically written for Wine
  2. A syntax analyzer
  3. Mostly ad hoc.

The Stanford checker on the other hand is

  1. Generalized for all C/C++ applications
  2. A semantic analyzer
  3. Formalized with a script language

The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit.

Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful.

That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies.

However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude.

If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

4. Stack Limit

3 Jun 2001 - 5 Jun 2001 (8 posts) Archive Link: "stack limit"

People: Francois Gouget

Stephan Crowley was working with some large matrices and wondered how to go about increasing the default stack size for winelib applications. He also wondered about what drawbacks he might run into working with a large stack. Francois Gouget answered that with:

The only drawback I know of is that this limits the number of threads your process can start. At least on Windows, I'm not entirely sure about Linux but it should be the true too (Linux threads are kind of weird).

What happens on Windows is that each thread gets its own stack so by default 1MB of virtual memory is reserved for each thread. Since there's a 2GB virtual memory space this means you can start a maximum of about 2000 threads. If you increase this to 10MB then you can only start 200 threads (per process).

And that's why you have all the Java developpers complaining that Java does not scale because it only support 2000 clients! Let me explain. Until JDK1.4 is out Java does not have asynchronous I/O. So all Java servers are of the 'one thread per client' type. So they all block at about 2000 clients... except for the IBM JVM which uses a smaller stack by default allowing it to support more than 2000 threads.

So that's why one might want a small stack size. Of course I doubt very much this affects your application (seems more scientific computing oriented).

One more word on Java and threads :-) All (overgeneralization, I now) Java developpers (and benchmarketers) say Linux is bad because it does not scale well when you have thousands of runnable threads. And all kernel developpers reply 'you have to be crazy to have thousands of threads, your server performance will be bad anyway if you do that' (to which I can only agree). Fortunately, as I said before, JDK 1.4 will finally have asynchronous I/O, and even memory mapped files! So maybe the Java guys will finally let the Linux scheduler off the hook.

(Hmm, more than you wanted to know, sorry :-)

Alexandre responded with a patch that adds support for a stack argument in the application spec file.

5. Using uname with Autoconf

3 Jun 2001 - 5 Jun 2001 (14 posts) Archive Link: "uname(1) on UnixWare (Solaris)"

People: Alexandre JulliardFrancois GougetPatrick StridvallBang Jun-YoungPatrick Stridval

Bang Jun-Young was working on some new configuration code and wanted to know what the returned values were on UnixWare and Solaris. It was immediately met with skepticism, as Alexandre put it, "Why do you need that? Using uname(1) in a configure script is almost certainly the wrong thing to do." After a bit of back and forth discussion on why it might be needed, Francois Gouget summed it up with:

But what if one runs this configure script on Darwin. The configure script does not know about it so it will fail although Darwin might behave exactly like FreeBSD. And what if tomorrow the Linux toolchain changes to behave like UnixWare, or something entirely different? This configure script will not work anymore, and when you detect that 'OSNAME==Linux' you'll still have to determine whether to use the old or the new flags somehow.

This is the whole point of Autoconf-style scripts: it's pointless to expect to guess how things work based on the name of the platform, i.e what uname returns.

Instead you should test features: if I compile&link a test file with the '-shared -Wl,-Bsymbolic' flag combination does it work? If yes then it does not matter whether the platform is Linux, UnixWare or FeeeBSD. We'll just use these flags since they do what we want.

Patrick Stridvall also pointed out:

However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard way to do this (which BTW happends to use uname). It can be used as below.

case $host_os in
*cygwin* ) CYGWIN=yes;;
* ) CYGWIN=no;;

IMHO you will need to provide a _really_ convincing argument that we should make another exception assuming of course we make the first one for CYGWIN which we haven't done yet either.

6. New Application Database is ONLINE

10 Jun 2001 (2 posts) Archive Link: "New Application Database is ONLINE"

People: Jeremy Newmancodeweavers

Jeremy Newman posted a note about the new Wine application database:

Hey all!

The 'shiny' new Wine Application Database is up and ready for your comments. We will be spending the rest of the day getting the initial category structure and 1st round off applications in. Once we have enough input, and we fell stable enough, I will link the AppDB to and post to wine-users.

There is one sample app in so far so you can see what we mean. in: Main > Utilities > Compression > WinZip

Use that as a guideline for how this is going to work.

Go at it guys!

After taking a quick glance, it seems pretty slick. It supports screenshots, multiple versions, and user comments.

7. Tru64 Port

8 Jun 2001 (1 post) Archive Link: "Help needed"

People: Renukaprasad, MR

A short post appeared on wine-devel on Saturday:

We are planning to port wine onto Tru64 Unix. I have some basic Questions. Can you tell me how to go about it. How do we start. How big is the task and how to start about it..

Interestingly enough the post came from There was no follow-up to it.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.