WWN Issue 165

This is the 165th release of the Wine's kernel cousin publication. Its main goal is to remind me that I'm enjoying daylight savings time too much and getting out WWN updates a little later now. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).

This week, 229 posts consumed 705 K. There were 70 different contributors. 42 (60%) posted more than once. 27 (38%) posted last week too.

The top 5 posters of the week were:

20 posts in 54K by Mike Hearn
18 posts in 44K by Alexandre Julliard
15 posts in 40K by Dimitrie O. Paun
15 posts in 42K by Dmitry Timoshkov
11 posts in 21K by Eric Pouech

News: Wine-20030408, Distro Reviews 04/05/2003 Archive

News: Wine-20030408, Distro Reviews	04/05/2003	Archive
News Look mommy, we got Slashdotted . This week Dimi Paun got grilled about his work with Wine. Head over to WineHQ to check out the interview. Wine-20030408 fell out of the tree: WHAT'S NEW with Wine-20030408: (see ChangeLog for details) Some reorganizations of the source tree. File change notifications. Support for all variants of glibc 2.3. Many documentation updates. Lots of bug fixes. Also in there is IP Multicast, though I'm not sure how many people use that. You may need to run configure with `--with-nptl` if you have one of the new distro's with glibc 2.3 and a kernel using NPTL-style threads. Michael Barnes reviewed several Linux distributions over at DesktopLinux.com. Wine integration was an important criteria in his evaluations. In particular he gave high marks to Xandros and ELX for their ability to run Windows apps: I got an e-mail telling me that ELX had an enhanced version of Wine that allowed ELX Powerdesktop to support many Microsoft Windows applications. One of the applications they claimed to support was Adobe Photoshop 7.0. At first, I could not find my Photoshop 7.0 so I tested Photoshop 5.5. This installed with absolutely no problems. I was then motivated to look harder for Photoshop 7.0. Photoshop 7.0 also installed with no problems. One distribution not reviewed was TopologiLinux . Never heard of it? Neither had I until I found the page on SourceForge. It's unique in that it installs under Windows onto a FAT or NTFS filesystem and then boots from CD. Last week version 3.0 came out; Wine is included with it.

News

Look mommy, we got Slashdotted . This week Dimi Paun got grilled about his work with Wine. Head over to WineHQ to check out the interview.

Wine-20030408 fell out of the tree:

ChangeLog

Some reorganizations of the source tree.
File change notifications.
Support for all variants of glibc 2.3.
Many documentation updates.
Lots of bug fixes.

Also in there is IP Multicast, though I'm not sure how many people use that. You may need to run configure with --with-nptl if you have one of the new distro's with glibc 2.3 and a kernel using NPTL-style threads.

Michael Barnes reviewed several Linux distributions over at DesktopLinux.com. Wine integration was an important criteria in his evaluations. In particular he gave high marks to Xandros and ELX for their ability to run Windows apps:

I got an e-mail telling me that ELX had an enhanced version of Wine that allowed ELX Powerdesktop to support many Microsoft Windows applications. One of the applications they claimed to support was Adobe Photoshop 7.0. At first, I could not find my Photoshop 7.0 so I tested Photoshop 5.5. This installed with absolutely no problems. I was then motivated to look harder for Photoshop 7.0. Photoshop 7.0 also installed with no problems.

One distribution not reviewed was TopologiLinux . Never heard of it? Neither had I until I found the page on SourceForge. It's unique in that it installs under Windows onto a FAT or NTFS filesystem and then boots from CD. Last week version 3.0 came out; Wine is included with it.

Debugging Threads 04/08/2003 Archive

Debugging Threads	04/08/2003	Archive
Debugging Mike Hearn asked for some help debugging a threaded program: I'm a bit stuck. I have a DLL that does a FindWindow on DLL attach, and as part of that it does a GetWindowText which tries to send a message to another thread, using send_inter_thread_message. Other threads then attempt to load a DLL and the loader section prompty deadlocks. In gdb, if I attach at this point I can see a nice backtrace of the thread waiting for the reply to its WM_GETTEXT message, along with the thread ID. I'd quite like to see what the thread it sent the message to is doing, but for some reason in gdb "info threads" doesn't do anything and "thread 18" says, thread ID not known, despite it clearly being there in the backtrace: #5 `0x40abd0cf in send_inter_thread_message (dest_tid=18, info=0x4072187c, res_ptr=0x40721874) at message.c:1719` So, I'm wondering if this is due to the funny games Wine plays with threads, I'm on a standard glibc 2.2 system by the way. For some reason I can't use winedbg because it stops with a load of exceptions inside the DLL that seem to be red herrings. Is there any way of switching to a wine thread using gdb to get a backtrace? Is there a sneakier approach I can use to find out why thread 18 has apparently deadlocked? There is probably a race condition here - this program will start some times but not others :( Has anybody got any tips on how to debug this sort of thing? Later in the day he replied to himself, I figured out that you can start winedbg and then use a wine process id to attach - I was trying to attach using unix pids and was wondering why it didn't work. The winedbg help screen seems a little out of date, it doesn't show you that the bt command accepts a tid as a parameter for instance, and I can't see any way to switch the current thread Several people still suggested some different ideas, Alexandre mentioned, You can attach to a specific thread with gdb, but you have to specify its unix pid, you can't use the wine thread id of course, gdb doesn't know about that. You can see the unix pid of a thread with +server, or simply attach to each thread until you find the right one Eric Pouech suggested another way to use gdb, another solution for this would be using gdb thru winedbg (run `winedbg -- --gdb` ) you'll get gdb as a front end, but communicating thru winedbg to the wineserver using gdb commands, you might be able to control a bit more the threads

Debugging

Mike Hearn asked for some help debugging a threaded program:

I'm a bit stuck. I have a DLL that does a FindWindow on DLL attach, and as part of that it does a GetWindowText which tries to send a message to another thread, using send_inter_thread_message. Other threads then attempt to load a DLL and the loader section prompty deadlocks.

In gdb, if I attach at this point I can see a nice backtrace of the thread waiting for the reply to its WM_GETTEXT message, along with the thread ID. I'd quite like to see what the thread it sent the message to is doing, but for some reason in gdb "info threads" doesn't do anything and "thread 18" says, thread ID not known, despite it clearly being there in the backtrace:

0x40abd0cf in send_inter_thread_message (dest_tid=18,
    info=0x4072187c, res_ptr=0x40721874) at message.c:1719

So, I'm wondering if this is due to the funny games Wine plays with threads, I'm on a standard glibc 2.2 system by the way. For some reason I can't use winedbg because it stops with a load of exceptions inside the DLL that seem to be red herrings.

Is there any way of switching to a wine thread using gdb to get a backtrace? Is there a sneakier approach I can use to find out why thread 18 has apparently deadlocked? There is probably a race condition here - this program will start some times but not others :(

Has anybody got any tips on how to debug this sort of thing?

Later in the day he replied to himself, I figured out that you can start winedbg and then use a wine process id to attach - I was trying to attach using unix pids and was wondering why it didn't work. The winedbg help screen seems a little out of date, it doesn't show you that the bt command accepts a tid as a parameter for instance, and I can't see any way to switch the current thread

Several people still suggested some different ideas, Alexandre mentioned, You can attach to a specific thread with gdb, but you have to specify its unix pid, you can't use the wine thread id of course, gdb doesn't know about that. You can see the unix pid of a thread with +server, or simply attach to each thread until you find the right one

Eric Pouech suggested another way to use gdb, another solution for this would be using gdb thru winedbg (run winedbg -- --gdb ) you'll get gdb as a front end, but communicating thru winedbg to the wineserver using gdb commands, you might be able to control a bit more the threads

Change in nm Symbol Output 04/09/2003 Archive

Change in nm Symbol Output	04/09/2003	Archive
Utilities Piotr Pawlow reported a problem with the new binutils package: There is a change in "nm -u" output format in the new binutils, now it outputs "U " before every symbol name. It looks like this: `$ nm -u d3d8.dll.tmp.o U cos U CreateDCA U DeleteDC U ExtEscape U GetClientRect U GetDC U GetDesktopWindow U GetDeviceCaps U GetModuleHandleA U GetProcAddress U GetPropA (...)` Winebuild parser is not prepared for that. It does not find proper symbol names, creates spec.c files with no imports, and the result is that linking fails on unresolved symbols, as reported in "--with-nptl and glibc-2.3.2" thread. A quick fix: `Index: tools/winebuild/import.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/import.c,v retrieving revision 1.48 diff -r1.48 import.c 664a665,667 > if (*p == 'U') { > if (p[1] == ' ') p+=2; > }` Shouldn't winebuild, however, use libbfd where available, instead of relying on nm output? The next day Alexandre committed a similar patch to fix it (so you won't find it in wine-20030408). Regarding using libbfd, it doesn't seem like much of an option. Dmitry Timoshkov pointed out that it has a GPL license, unlike Wine's LGPL. Then, Mike Hearn wanted to know if it really mattered. After all wouldn't it be ok to license some of the tools under GPL? Dmitry explained why that hasn't been done, Having the whole tree under a single licence saves a bit of hassle, time, hairs, nerves...

Utilities

Piotr Pawlow reported a problem with the new binutils package:

There is a change in "nm -u" output format in the new binutils, now it outputs "U " before every symbol name. It looks like this:


$ nm -u d3d8.dll.tmp.o

         U cos

         U CreateDCA

         U DeleteDC

         U ExtEscape

         U GetClientRect

         U GetDC

         U GetDesktopWindow

         U GetDeviceCaps

         U GetModuleHandleA

         U GetProcAddress

         U GetPropA


(...)

Winebuild parser is not prepared for that. It does not find proper symbol names, creates spec.c files with no imports, and the result is that linking fails on unresolved symbols, as reported in "--with-nptl and glibc-2.3.2" thread.

A quick fix:


Index: tools/winebuild/import.c

===================================================================

RCS file: /home/wine/wine/tools/winebuild/import.c,v

retrieving revision 1.48

diff -r1.48 import.c

664a665,667

>    	if (*p == 'U') {

>       if (p[1] == ' ') p+=2;

>    	}

Shouldn't winebuild, however, use libbfd where available, instead of relying on nm output?

The next day Alexandre committed a similar patch to fix it (so you won't find it in wine-20030408). Regarding using libbfd, it doesn't seem like much of an option. Dmitry Timoshkov pointed out that it has a GPL license, unlike Wine's LGPL. Then, Mike Hearn wanted to know if it really mattered. After all wouldn't it be ok to license some of the tools under GPL? Dmitry explained why that hasn't been done, Having the whole tree under a single licence saves a bit of hassle, time, hairs, nerves...

XFree86 Keyboard Mapping Issues 04/07/2003 Archive

XFree86 Keyboard Mapping Issues	04/07/2003	Archive
Internationalization Tim Ruehsen upgraded XFree86 and ran into a new problem: With XFree86 4.3.0 I experience the message `fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping.` Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine). Shachar Shemesh thought he recognized the problem, I don't know whether it's relevant in this case. XFree 4.3.0 introduced a total disconnection of the different keyboard groups. If before, the IL keyboard contained a US keyboard as the first group, and an IL keyboard as the second group, now I have to define "US,IL" to get the same effect. This is, on the whole, a good thing (even - a very good thing). This does mean that the keyboard detection in wine will now only work if you have your keyboard defined in exactly the same way as the 4.2 keyboards. Tim pointed out that his keyboard configuration hadn't changed between 4.2 and 4.3 and wondered if anyone had any tips for how it might need to be updated. Dmitry Timoshkov suggested: If you will add "us" to the "XkbLayout" setting in your XF86Config like this `Option "XkbLayout" "us,de"` it might help. That still didn't work for Tim, Thank you, Dmitry. But it doesn't help. In this case I have US layout which drives me crazy... I read some XFree READMEs. They are talking about a possibility to configure keyboard layout 'backward compatible' - but I could not find out how (it might help). If there is anybody who got the keyboard variant '`nodeadkeys` ' working with wine: please tell me how, maybe a snapshot from your configuration helps. Tim went on to report some more tests he did: I tried to cheat wine with "`us,de` " together with "`,nodeadkeys` " and "`grp:ctrls_toggle` " (toggle between us and de with pressing both ctrl keys). Doing so resulted in a screwed keyboard, e.g. a-z keys now had special meanings in KDE, running wine did not give me access to '{[]}' keys. KDE itself has been screwed (maybe since I pressed lots of keys for testing while they had special meaning). I made tests with several different toggle keys and configurations, but no success... meybe there is no easy solution.

Internationalization

Tim Ruehsen upgraded XFree86 and ran into a new problem:

With XFree86 4.3.0 I experience the message


 fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not 
 found!

 Using closest match instead (German keyboard layout without dead keys) for 
 scancode mapping.

Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information.

This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine).

Shachar Shemesh thought he recognized the problem, I don't know whether it's relevant in this case. XFree 4.3.0 introduced a total disconnection of the different keyboard groups. If before, the IL keyboard contained a US keyboard as the first group, and an IL keyboard as the second group, now I have to define "US,IL" to get the same effect. This is, on the whole, a good thing (even - a very good thing). This does mean that the keyboard detection in wine will now only work if you have your keyboard defined in exactly the same way as the 4.2 keyboards.

Tim pointed out that his keyboard configuration hadn't changed between 4.2 and 4.3 and wondered if anyone had any tips for how it might need to be updated. Dmitry Timoshkov suggested:

If you will add "us" to the "XkbLayout" setting in your XF86Config like this


	Option       "XkbLayout" "us,de"

it might help.

That still didn't work for Tim, Thank you, Dmitry. But it doesn't help. In this case I have US layout which drives me crazy... I read some XFree READMEs. They are talking about a possibility to configure keyboard layout 'backward compatible' - but I could not find out how (it might help). If there is anybody who got the keyboard variant 'nodeadkeys ' working with wine: please tell me how, maybe a snapshot from your configuration helps.

Tim went on to report some more tests he did:

I tried to cheat wine with "us,de " together with ",nodeadkeys " and "grp:ctrls_toggle " (toggle between us and de with pressing both ctrl keys). Doing so resulted in a screwed keyboard, e.g. a-z keys now had special meanings in KDE, running wine did not give me access to '{[]}' keys. KDE itself has been screwed (maybe since I pressed lots of keys for testing while they had special meaning).

I made tests with several different toggle keys and configurations, but no success... meybe there is no easy solution.

World Wine News