WWN Issue 63

This is the 63rd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 69 posts consumed 184 K. There were 29 different contributors. 14 (48%) posted more than once. 13 (44%) posted last week too.

The top 5 posters of the week were:

6 posts in 32K by David Howells
6 posts in 44K by Alexandre Julliard
5 posts in 59K by Andreas Mohr
4 posts in 22K by Uwe Bonnes
4 posts in 20K by Eric Pouech

Window Manager woes	20 Sep 2000 00:00:00 -0800
Dmitry Timoshkov posted a patch which ) attempts to prevent resizing of disabled windows by a Window Manager. Most (if not all) windows applications don't expect to be resized while popup or dialog is currently displayed and interacts with user. The least damage to the app's widow that could be done is just a misbehavior in painting, but it can also lead to another unexpected results. My patch makes disabled window to temporary behave like a dialog, then when window gets enabled its behavior is restored. In a course of the discussion, Dmitry pointed out another problem: WinEdt exhibits some flaws in the way Wine manages windows. For instance main WinEdt window has only close box on it, though in Windows all three standard buttons showed. My patch adds another "feature": after any dialog box was shown, bitmap on the system menu along with the sole close box on the main window caption disappear and don't get restored after the main window was enabled back. Analyzing KWM 1.1.1 code, Gérard Patel found the source of the issue in the KDE code: What I understand from the Kwm code is that once reconfigured, a transient X window loses the menu and close buttons. I may be wrong but I think Kwm has not hit this bug too often because it is probably not common for X program to reconfigure transient windows. It's only in Wine that transient windows are alive for the entire duration of the program I guess :-) Note: a transient window in X11 words is close to dialog boxes in Windows. However, Dmitry patch also triggered on Gérard's side that Dmitry couldn't reproduce (even if both used the same WM: KWM 1.1.1). As a conclusion (where more questions have been raised than points have been answered), Gérard advise not to fight too hard with windows managers; or owned popups should not be transient windows. It's a difficult problem, you'll see that Corel has a completely different solution in their tree. I am not sure there is a good solution, in fact.

Window Manager woes

20 Sep 2000 00:00:00 -0800

Dmitry Timoshkov posted a patch which ) attempts to prevent resizing of disabled windows by a Window Manager. Most (if not all) windows applications don't expect to be resized while popup or dialog is currently displayed and interacts with user. The least damage to the app's widow that could be done is just a misbehavior in painting, but it can also lead to another unexpected results.

My patch makes disabled window to temporary behave like a dialog, then when window gets enabled its behavior is restored.

In a course of the discussion, Dmitry pointed out another problem: WinEdt exhibits some flaws in the way Wine manages windows. For instance main WinEdt window has only close box on it, though in Windows all three standard buttons showed.

My patch adds another "feature": after any dialog box was shown, bitmap on the system menu along with the sole close box on the main window caption disappear and don't get restored after the main window was enabled back.

Analyzing KWM 1.1.1 code, Gérard Patel found the source of the issue in the KDE code: What I understand from the Kwm code is that once reconfigured, a transient X window loses the menu and close buttons. I may be wrong but I think Kwm has not hit this bug too often because it is probably not common for X program to reconfigure transient windows. It's only in Wine that transient windows are alive for the entire duration of the program I guess :-)

Note: a transient window in X11 words is close to dialog boxes in Windows.

However, Dmitry patch also triggered on Gérard's side that Dmitry couldn't reproduce (even if both used the same WM: KWM 1.1.1).

As a conclusion (where more questions have been raised than points have been answered), Gérard advise not to fight too hard with windows managers; or owned popups should not be transient windows. It's a difficult problem, you'll see that Corel has a completely different solution in their tree. I am not sure there is a good solution, in fact.

Module loading and default directories	27 Sep 2000 00:00:00 -0800
Marcus Meissner proposed a patch to make use of the -rpath directive for building Wine's .so files (this directly embeds inside the .so files, where to look for the .so module dependencies - other .so files where to look for functions/variables -). With the patch, Marcus claimed to be able to run the wine binary emulator and the wineserver without a proper /etc/ld.conf configuration. Ove Kåven reacted: Is there a particular reason why libwine_unicode.so can't just be in the same directory as libwine.so, since it's not really a "DLL"? Shouldn't take a special rpath to find it... For wine itself, I don't see a need for rpath in the emulator binary either... the EXTRA_LD_LIBRARY_PATH in wine.conf should work to find the .so files, after which the rpath compiled into the .so files are enough to find their dependencies. Ove also had in mind to be able someday to choose different DLL builds by just changing the EXTRA_LD_LIBRARY_PATH but using the same wine binary... if the rpath is embedded in wine, that won't be possible. Is there a reason you need to do so? Alexandre Julliard explained how he liked things to be: libwine_unicode.so will definitely be in the same directory as libwine.so; but this can be a non-standard place, which is why we need rpath. In fact libwine and libwine_unicode are the only libraries that need it, because they are (should be) the only ones loaded implicitly by ld.so. At the moment we have the problem that dlls import one another at the ELF level, which is why they have to be installed in the same directory and with the same rpath as libwine.so. But once import tables are working, dlls will only import each other through an explicit dlopen using EXTRA_LD_LIBRARY_PATH. Basically the final situation should be: libwine.so and libwine_unicode.so in $(prefix)/lib all dlls .so in $(prefix)/lib/wine rpath set to $(prefix)/lib EXTRA_LD_LIBRARY_PATH set to $(prefix)/lib/wine Current solution is a compromise between simplicity, and the ability to packagers to install all modules in any place using configure --prefix=/usr/mydir without having to tweak heavily users' config files.

Module loading and default directories

27 Sep 2000 00:00:00 -0800

Marcus Meissner proposed a patch to make use of the -rpath directive for building Wine's .so files (this directly embeds inside the .so files, where to look for the .so module dependencies - other .so files where to look for functions/variables -). With the patch, Marcus claimed to be able to run the wine binary emulator and the wineserver without a proper /etc/ld.conf configuration.

Ove Kåven reacted:

Is there a particular reason why libwine_unicode.so can't just be in the same directory as libwine.so, since it's not really a "DLL"? Shouldn't take a special rpath to find it...
For wine itself, I don't see a need for rpath in the emulator binary either... the EXTRA_LD_LIBRARY_PATH in wine.conf should work to find the .so files, after which the rpath compiled into the .so files are enough to find their dependencies.

Ove also had in mind to be able someday to choose different DLL builds by just changing the EXTRA_LD_LIBRARY_PATH but using the same wine binary... if the rpath is embedded in wine, that won't be possible. Is there a reason you need to do so?

Alexandre Julliard explained how he liked things to be: libwine_unicode.so will definitely be in the same directory as libwine.so; but this can be a non-standard place, which is why we need rpath. In fact libwine and libwine_unicode are the only libraries that need it, because they are (should be) the only ones loaded implicitly by ld.so.

At the moment we have the problem that dlls import one another at the ELF level, which is why they have to be installed in the same directory and with the same rpath as libwine.so. But once import tables are working, dlls will only import each other through an explicit dlopen using EXTRA_LD_LIBRARY_PATH.

Basically the final situation should be:

libwine.so and libwine_unicode.so in $(prefix)/lib
all dlls .so in $(prefix)/lib/wine
rpath set to $(prefix)/lib
EXTRA_LD_LIBRARY_PATH set to $(prefix)/lib/wine

Current solution is a compromise between simplicity, and the ability to packagers to install all modules in any place using configure --prefix=/usr/mydir without having to tweak heavily users' config files.

World Wine News