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

• typelib registration
• IDispatch::Invoke()
• 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.

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:
http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2000-12/date/article-196.html

As well please see discussion of patch at:
http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-01/date/
(with reasons why it wasn't committed, search for "invoke")

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.

NtMapViewOfSection/NtUnmapViewOfSection.

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:-)

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.

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.

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 :-)

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.

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.

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


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.

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 Winehq.com and post to wine-users.

http://wine.codeweavers.com/appdb/

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!

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..