World Wine News

WHAT'S NEW with Wine-20040408: (see ChangeLog for details)

• DOS devices and drives are now configured through symlinks.
• Many shell32 improvements.
• New task manager merged from ReactOS.
• First version of wineprefixcreate tool for initial setup.
• Lots of bug fixes.

Before everyone gets sidetracked by the Open Source implications, let.s talk about exactly what WiX is. WiX is a toolset composed of a compiler, a linker, a lib tool and a decompiler. The compiler, called candle, is used to compile XML source code into object files that contain symbols and references to symbols. The linker, called light, is fed one or more object files and links the references in the object files to the appropriate symbols in other object files. Light is also responsible for collecting all of the binaries, packaging them appropriately, and generating the final MSI or MSM file. The lib tool, called lit, is an optional tool that can be used to combine multiple object files into libraries that can be consumed by light. Finally, the decompiler, called dark, can take existing MSI and MSM files and generate XML source code that represents the package.

So, me and Mike have been discussing some ideas for window management in Wine. Currently it hasn't turned into code, but I thought I'd write up what our thoughts were so others could comment and maybe be inspired to write patches.

The problem:

Currently Wine decides whether to make a window managed or not based on a series of heuristics, in is_window_toplevel in dlls/x11drv/window.c

Unfortunately these heuristics are frequently wrong, as they have only limited information to work with (window styles, mostly). In CrossOver, is_window_toplevel is easily the most hacked function in the entire codebase. This manifests itself in a variety of ways:

• Windows are marked unmanaged when they shouldn't be. For instance, see WinAmp, Trillian, the Counter-Strike CD Key screen etc: there are tons of examples of this problem. This at best means the window is "nailed" to the screen, at worst it makes the program unusable.
• The classic "my game starts but I can't type" problem where keyboard input goes to the terminal instead of the window, due to the lack of focus management in unmanaged windows.
• Some programs display splash screens and then pop up errors or question dialogs underneath them. Unmanaged windows are always-on-top -> you cannot get to the underlying managed window and the app appears to hang.
• Fullscreen windows are really hard to do properly because they must be managed to work correctly in KDE/GNOME.

We currently make certain windows unmanaged typically because we need to control their position or rendering with a high degree of accuracy. Unfortunately some X window managers ignore positioning hints, even when we ask them not to. There is no way to make things like menus and tooltips work correctly with these WMs, so we take the window out of the usual window management mechanism entirely.

Unfortunately due to the design of the win32 API there is no simple way to tell the difference between a large menu and the Trillian main window. We could mark our own menus specially to make them unmanaged and have everything else be managed, but we then run into problems with programs that draw their own menus and tooltips, of which there are a truly shocking number.

So what is a possible solution?

Well, one way forward is to implement another mode, in which Wine makes all windows managed and uses a variety of WM hints to get the desired behaviour. For instance, the PPosition flag asks the WM to place the window where the application requests it to. Some WMs respect this, others do not, in yet others it's a toggleable option. For people with WMs that meet the requirements of Wine all windows could be made managed, and for people that don't use such WMs the old way can still be used.

IIRC it's possible to ask the WM for identification which means this setting could be largely autodetected by having blacklists of WMs to use the old mode for (or vice-versa).

Unfortunately there's no way to know how well this approach would work, or even if it would work at all, short of trying it.

I personally think we should not care about non-compliant WMs. You use one of those, you suffer the consequences. We can't operate in a vacuum, there are standards, and we must be able to rely on something.

But this, I'm afraid, besides the point. This entire discussion assumes that the Win32 windows are mapped to X windows. If IIRC, Alexandre was saying that we need to switch back to the old ways, where we handle most of the windowing code. In which case I guess a lot of this will go away.

Well, it's not really a rewrite, more the continuation of the address space separation work, to make all of the window management instead of just half of it behave properly across processes.

The managed/unmanaged thing is really a different issue, but the inter-process stuff will change a lot of things in x11drv, that hopefully will then make it easier to deal with the managed stuff (for instance by making it easier to recreate a window on the fly to switch to managed mode); so that's why I think the inter-process support should be finished before we start making big changes in the X11 WM support.

Has anybody started implementing CryptoApi in WINE?? If no maybe someone can give me some clues how to start... I am not bad in C++ I think, but I have never make thing like that. I don't promise I will do that, but I can try... :)

Hi Jacek, take a look at Wine's rsabase.dll, that DLL doesn't do very much yet. All its functions (CPAcquireContext, etc) are described here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cryptography_functions.asp

If you have access to a Windows box it's easier: you can load the DLL itself and call all the functions and try to reproduce what it's doing.

It depends on which part you are trying to implement. For the Certificate Store functions I would recommend implementing the "OID support functions" first, as it is indicated by [ same link Juan had above ] that a number of other functions depend on them. The OID's are looked up from a set of builtin types (see CertOpenStore reference) and from the registry key: HKLM\Software\Microsoft\Cryptography\OID. Some other tips: MSDN is a good resource for information. Try to implement functions using other Win32 functions. Write test programs to run against the Wine and Microsoft versions of the DLLs.

I am intermittently trying to get Wine to play nicely with a big EDA tool, and it is doing not too badly today with the 20040309 snapshot on Fedora Core 1.

The thing that I think is stopping it working is that whatever is done to stack-shield by the prepending "setarch i386" on invocation is not inherited by the .exe that the program calls. Net result is that I get the "..... security-patched kernel ?" error message from the child process instead of the parent. Progress of a sort.

Is there anything, short of turning off exec-shield entirely, that can be done about this?

I'm not familiar with the using "setarch i386" to solve the problem...

I've also been working on the exec-shield problem over the last couple of days. My solution is similar to Mike Hearn's approach, but faster and more compact, since it doesn't require loading of libc twice or static linking with glibc. The idea is to use a statically linked ELF object, reserve memory and then load the target dynamically linked object.

It seems to do what I want, but will require a patch or two to wine to use MAP_FIXED when mapping the first megabyte of address space, and to make sure newly forked processes are forked with it as the (pre)loader.

I've attached the source code. The idea is to run it like this:

wld /home/mike/wine/loader/wine-pthread my.exe

First up, I get two instances of the following:

unknown header type 6474E551

It makes the first load work, - giving the same result as the setarch idea (I know (or at least I *think* I know) it is by a different means), but it doesn't solve the inheritance/forking problem. I assume that is what the patches you mention would do.

To make this a bit clearer, A creates children B then C. With setarch or wld when exec-shield is ON, A loads, but B doesn't. With exec-shield OFF, B loads, but C doesn't! I don't understand the latter at all.

In case it is relevant, I suspect that the child processes are created by a built-in scripting language engine.

If wld knew (hardcoded or from an environment variable) where to find wine (the binary), no script would be necessary and it would be even simpler. At configure/compile time Wine could know/detect/be told whether the default loader had to be wine (the binary) or wld.

Thinking further, why not, if wld is needed, call what is now wine something else (e.g. winefoo for this discussion) and wld be called wine. Then no source modification is needed to existing wine code and invocation using wine rahter than wld is possible, maintaining users' mental compatibility and script compatibility (IYSWIM).

Hey guys,

http://www.winehq.org/hypermail/wine-patches/

Check that out - 5mb of patches for the last 3 months running. A meg of patches just 6 days into the new month already!

It seems Wine is moving faster than ever before.

$ find wine -type f|xargs cat |wc -lc
1611362 55483397

Yes, about 1.6 million lines. This includes the autofoo build magic though, sloccount gives a lower number (a bit less than a million).

The website stats are interesting too:

Skipping to the KBytes and Hits columns, things are up. Even more interesting is in Feburary we got Slashdotted and in March we didn't. So it appears people are interested.

In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a thin wrapper 32bit around 4 functions in SETUPX.

So this is just for documentation purposes, and in case anybody is curious or finds a real need for this DLL.

At Dimi's request, I've added a new script to the root of the gateway tree.

The genpatch program takes a series of patch ids as parameters and can generate and send an email to wine-patches with the combined diff of all the given commits.

For example: let's say you are working on a feature. You do 3 commits, to keep the changes physically separate, however you decide the commits are too fine grained to submit all at once, so you want to submit them together.

Genpatch makes that easy. Say you commit patch-4, patch-5 and patch-6:

./genpatch -m 4 5 6

will compute the combined differential of all those commits, take the commit log and summary of the first and generate an email from them. The patch will include and new files that were added.

Here are the formal instructions for compiling Wine with bidi support. When doing so, it is recommended that you use a fairly recent version of ICU (2.6 and up), or else there is going to be a runtime soft dependency on some ICU files in the resulting Wine. No big deal - if these files are not there, Wine will work just fine, only without BiDi support. Still, this is not necessary.

Instructions:

1. If you use a precompiled package (relatively rare for ICU, unfortunately), make sure it has the static libraries as well. ICU does not have these by default. If they are there, you may skip to step 8. Please note, however, that this will add about 7MB to the size of the resulting gdi.dll.so.
2. Grab ICU from the web http://oss.software.ibm.com/icu .
3. Extract the sources file.
4. CD into the ICU directory, and then into the "source" subdirectory.
5. Delete all files with the "mk" extension under icu/source/data. e.g. run "find data -name \*.mk -exec rm \{\} \;". Please trust me on this one, it's ok to do it. This step saves the aforementioned 7MB.
6. ./runConfigureICU LinuxRedHat --enable-static. If you are only building this for use with Wine, you can also add "--enable-shared=no --enable-64bit-libs=no --prefix=~/icuinstall". If not, you may wish to skip the previous step as well.
7. run "make" and "make install". Grab a lunch. Just one will do.
8. If your ICU library files are installed in /usr/lib and /usr/include, compile wine as usual. If they are installed anywhere else, you will need to set the "ICU_LIB_DIR" environment variable to wherever it was that they are installed. You will also have to add the include path. For example, if you compiled and installed icu according to my example above, you will need to set ICU_LIB_DIR to "~/icuinstall/lib", and also CPPFLAGS to "-I~/icuinstall/include".
9. Make sure that including "ubidi.h" and the following linking step passes in "configure". Also check whether include/config.h has "HAVE_ICU" set.
10. To be really sure that your wine supports BiDi, run the program given in this email.

A few things to note:

• The above assumes that your Wine already has http://www.winehq.org/hypermail/wine-patches/2004/04/0088.html integrated.
• If you are compiling Wine on Debian, and want to use the Debian supplied ICU library for whatever reason (for example - because the packaging system pretty much requires you to), the above procedure needs to be slightly altered. ICU changed their static library naming scheme over some recent version. The Debian packaged ICU (2.1) still uses the old scheme. Either use Wine without the aforementioned patch, or set ICUUC_LIB and ICUDATA_LIB to the full path to libicuuc.a and libicudata.a respectively (they are called "libsicuuc.a" and "libsicudata.a" in newer version of ICU). Please note that this means there is a runtime dependency on some ICU files for BiDi to work, as explained above.

Instead of reposting the program for testing whether Win32 supports reordering, the link to the file in the list's archive is at http://www.winehq.org/hypermail/wine-devel/2003/08/att-0175/01-biditest.c .