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 http://browserwatch.internet.com/news/stories2001/news-20010605-4.html. 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.
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 (
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
- typelib registration
RegisterBindStatusCallback()and probably asyncronous bind contexts
- probably a "real" URL Moniker, not just
CreateURLMoniker()using a File Moniker
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.
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.
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:
- Have the server only deal with NT Section objects and views of Sections.
- Have no separate module table attached to a process.
- Implement NtQuerySectionInformation/NtSetSectionInformation calls (or whatever they're called) as wineserver messages.
- Add an extra Wine-specific information class for the purpose of recording the extra module information.
- The wineserver process structure can then be changed so that rather than keeping a separate list of process_dlls, they can just keep a list of section views, some of which will be images/modules.
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.
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:
- Specifically written for Wine
- A syntax analyzer
- Mostly ad hoc.
The Stanford checker on the other hand is
- Generalized for all C/C++ applications
- A semantic analyzer
- 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.
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.
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.
Jeremy Newman posted a note about the new Wine application database:
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 Winehq.com 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.
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 digital.com. There was no follow-up to it.