World Wine News

All the news that fits, we print.

04/26/2002
by Brian Vincent

This is the 121st 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, 228 posts consumed 867 K. There were 78 different contributors. 38 (48%) posted more than once. 36 (46%) posted last week too.

The top 5 posters of the week were:

14 posts in 44K by Speeddymon
14 posts in 127K by Martin Wilck
13 posts in 86K by Michael Cardenas
12 posts in 28K by Steven Edwards
11 posts in 30K by Duane Clark

ALSA Driver	04/19/2002	Archive
Now that ALSA has been merged into the development kernels, a lot more projects are starting to support it natively. Marco Pietrobono asked about implementing it Wine: I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) on that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch. If there is nothing already written, I would like to discuss what kind of approach we should use with ALSA programming, since FWIK there should be two way to use it: we can use the ALSA devices directly, just like it has been done with OSS, or we can use the alsalib to avoid all direct references to the kernel devices and ioctl, but this solution will add a dependency on the alsalib library itself to wine. Of course, we could add a configure option/check to allow its use at compilation time, but... BTW, Alsalib is LGPL, so the license shouldn't be a problem. Marcus said he wasn't planning on working on it. David Hammerton corrected Marco and explained Eric Pouech was working on it, Eric has written one which is almost complete, I am in the midst of debugging it and finising it off. Contact me directly if you like. Ove mentioned that currently TransGaming had the driver and might be willing to exchange it for some LGPL'ed code. Gavriel State clarified that, although TransGaming offered to sponsor Eric's work on the ALSA driver, Eric felt other work should be sponsored. TransGaming laid no claim to "owning" the driver. Then Eric jumped in to explain the details of the driver: after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this) basically, this would allow to turn on mmap (which greatly enhances the dsound playback quality) on all soundcards (some OSS emulations for ALSA don't allow a correct mmap on the OSS mmap interface, so directly using the ALSA mmap interface should take of it) work will still be done on the installation stuff (basically, the registry must be written with either ALSA or OSS driver, depending on the installed interface on Linux) then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5. Several people questioned writing an ALSA driver for version 0.5. That ALSA API seemed to be abandoned in favor of the new 0.9 interface. However, Eric felt, the point is not whether 0.5 is technically better than 0.9 (or the other way around). The point is on the current installed base of ALSA drivers in the field, how many are 0.5 and how many are 0.9. Mandrake and SuSE (at least) have been shipping 0.5 for more than one year, whereas 0.9 is brand new. It just means that 0.9 installed base is almost 0 (in percentage). So, spending time right now on 0.9 is not the top priority (at least for me). Eric felt the ultimate solution was to have the driver detect which headers were on the system and compile in the appropriate ALSA support. Alexandre thought that was a good solution, but required some caution, That's the best solution assuming you can also compile it to support both 0.5 and 0.9 if you have all the necessary headers, and detect which version to use at run-time. If this is not possible we need two separate drivers, otherwise it won't be possible to build a binary package that works for everybody.

ALSA Driver

04/19/2002

Archive

Now that ALSA has been merged into the development kernels, a lot more projects are starting to support it natively. Marco Pietrobono asked about implementing it Wine:

I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) on that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.

If there is nothing already written, I would like to discuss what kind of approach we should use with ALSA programming, since FWIK there should be two way to use it: we can use the ALSA devices directly, just like it has been done with OSS, or we can use the alsalib to avoid all direct references to the kernel devices and ioctl, but this solution will add a dependency on the alsalib library itself to wine. Of course, we could add a configure option/check to allow its use at compilation time, but...

BTW, Alsalib is LGPL, so the license shouldn't be a problem.

Marcus said he wasn't planning on working on it. David Hammerton corrected Marco and explained Eric Pouech was working on it, Eric has written one which is almost complete, I am in the midst of debugging it and finising it off. Contact me directly if you like. Ove mentioned that currently TransGaming had the driver and might be willing to exchange it for some LGPL'ed code. Gavriel State clarified that, although TransGaming offered to sponsor Eric's work on the ALSA driver, Eric felt other work should be sponsored. TransGaming laid no claim to "owning" the driver. Then Eric jumped in to explain the details of the driver:

after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this)

basically, this would allow to turn on mmap (which greatly enhances the dsound playback quality) on all soundcards (some OSS emulations for ALSA don't allow a correct mmap on the OSS mmap interface, so directly using the ALSA mmap interface should take of it)

work will still be done on the installation stuff (basically, the registry must be written with either ALSA or OSS driver, depending on the installed interface on Linux)

then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5.

Several people questioned writing an ALSA driver for version 0.5. That ALSA API seemed to be abandoned in favor of the new 0.9 interface. However, Eric felt, the point is not whether 0.5 is technically better than 0.9 (or the other way around). The point is on the current installed base of ALSA drivers in the field, how many are 0.5 and how many are 0.9. Mandrake and SuSE (at least) have been shipping 0.5 for more than one year, whereas 0.9 is brand new. It just means that 0.9 installed base is almost 0 (in percentage). So, spending time right now on 0.9 is not the top priority (at least for me).

Eric felt the ultimate solution was to have the driver detect which headers were on the system and compile in the appropriate ALSA support. Alexandre thought that was a good solution, but required some caution, That's the best solution assuming you can also compile it to support both 0.5 and 0.9 if you have all the necessary headers, and detect which version to use at run-time. If this is not possible we need two separate drivers, otherwise it won't be possible to build a binary package that works for everybody.

Winsock2 Patches	04/23/2002	Archive
Martin Wilck was back with a bunch more IO patches. In part these are to fix earlier issues from some of his other patches. Martin wrote: I will now start to submit a new series of patches for Winsock2-related issues. Most of it is for overlapped IO, but there are some other issues, too. I have done a fair bit of testing with 16 and 32 bit network-oriented Windows apps, and found no regressions (well some apps wouldn't install or run with either the CVS version or my patched version of wine). Among the tested apps are Opera (v5.12, 32bit, and 3.62, 16bit) FreeAgent (news reader, 16bit) Solstice Internet Mail (16bit) Hamster local news server (32bit, interesting because it's using ReadFile()/WriteFile() for overlapped socket IO) My evil overlapped testing server/client app I spotted a number of bugs with the "big" patch I sent to wine-devel last Friday. These are fixed in the version I'll submit now. The patch is now split into parts again (one bug fix for an earlier patch of mine that is already in CVS, and 7 "real" parts). Most of the testing has of course been done with the full patch set applied. I have tried to separate logically independent units, but I cannot swear that all is fine if only part of them is applied, and the later patches do fix some important problems. The main reason for splitting the stuff up is to make it easier for people to review. I honestly think that these patches are now ready for being applied to CVS and tested in the field. Here is the overall patch summary (for detailed explanantions see the patches thenmselves): Correct handling of deferred WSAAccept() operations, Change register_async() and the queue_async() method to allow more flexibility, needed for sockets, Server support for overlapped IO on sockets, Fix problem with FD_CLOSE never being delivered in some situations, Wait for POLLIN if FD_CLOSE event notification is requested to catch grateful close or shutdown by the peer (empty recv(), no POLLHUP), Implement overlapped WSARecvFrom()/WSASendTo() and WSAGetOverlappedResult(), Change shutdown() to account for pending overlapped requests, Change ReadFile() semantics for overlapped reads on sockets (return even if buffer is not yet full), Improve error reporting for asynchronous requests (files and sockets) Account for the SO_OPENTYPE socket option on a per-thread basis. I plan to look into the regression-testing code and also supply a few tests for the new socket functionality. Cheers (and please test this stuff with your apps!), Since then Martin has went on to submit even more patches after Rein Klazes and Michael Cardenas found some problems with the first ones.

Winsock2 Patches

04/23/2002

Archive

Martin Wilck was back with a bunch more IO patches. In part these are to fix earlier issues from some of his other patches. Martin wrote:

I will now start to submit a new series of patches for Winsock2-related issues. Most of it is for overlapped IO, but there are some other issues, too.

I have done a fair bit of testing with 16 and 32 bit network-oriented Windows apps, and found no regressions (well some apps wouldn't install or run with either the CVS version or my patched version of wine).

Among the tested apps are

I spotted a number of bugs with the "big" patch I sent to wine-devel last Friday. These are fixed in the version I'll submit now.

The patch is now split into parts again (one bug fix for an earlier patch of mine that is already in CVS, and 7 "real" parts).

Most of the testing has of course been done with the full patch set applied. I have tried to separate logically independent units, but I cannot swear that all is fine if only part of them is applied, and the later patches do fix some important problems. The main reason for splitting the stuff up is to make it easier for people to review.

I honestly think that these patches are now ready for being applied to CVS and tested in the field.

Here is the overall patch summary (for detailed explanantions see the patches thenmselves):

I plan to look into the regression-testing code and also supply a few tests for the new socket functionality.

Cheers (and please test this stuff with your apps!),

Since then Martin has went on to submit even more patches after Rein Klazes and Michael Cardenas found some problems with the first ones.

More Tests	04/18/2002	Archive
Some submissions came in this week from people who have been building tests for various Wine functions. Martin Wilck posted some for his IO work: This patch introduces a unit test for winsock2 functionality. It is not complete yet, but I have found it useful already. The most important part (for me), tests for overlapped IO, have yet to be added. The test code implements a simple echo protocol over the loopback device. Servers and clients are started as threads, so that differently implemented servers/clients can be used. It should be easy to add more server and client routines to get extensive testing. Jakob Eriksson submitted a test with the note, First attempt at unit testing. Victim of choice: _hread() Bill Medland posted tests for wsprintfA and wsprintfW. (After he spent a lot of time debugging wsprintfW only to have a bunch of people point out he missed a comma in a function call). Mike McCormack added a simple test set for window classes And Eric Pouech's CreateProcess test discussed <kcref>last week</kcref> made it into CVS.

More Tests

04/18/2002

Archive

Some submissions came in this week from people who have been building tests for various Wine functions. Martin Wilck posted some for his IO work:

This patch introduces a unit test for winsock2 functionality. It is not complete yet, but I have found it useful already. The most important part (for me), tests for overlapped IO, have yet to be added.

The test code implements a simple echo protocol over the loopback device. Servers and clients are started as threads, so that differently implemented servers/clients can be used. It should be easy to add more server and client routines to get extensive testing.

Jakob Eriksson submitted a test with the note, First attempt at unit testing. Victim of choice: _hread()

Bill Medland posted tests for wsprintfA and wsprintfW. (After he spent a lot of time debugging wsprintfW only to have a bunch of people point out he missed a comma in a function call).

Mike McCormack added a simple test set for window classes

And Eric Pouech's CreateProcess test discussed <kcref>last week</kcref> made it into CVS.

Bumps in Wineinstall 04/23/2002 Archive

Bumps in Wineinstall	04/23/2002	Archive
Due to some recent changes in wineinstall, some people were having problems. Bill Medland explained some quick workarounds for anyone who might have pulled the source from CVS during the few hours it had typos in it: In the wineinstall script correct the following two lines: Where it mentions "ldconfig" explicitly state "/sbin/ldconfig" Where it says su -c"$sucommand" put su -c "$sucommand" Then run it again and that should solve it. Along similar lines, Alexandre rejected another wineinstall patch and explained, `$libdir/wine` must not be added to ld.so.conf. Users have to set the `WINEDLLPATH` variable if Wine is not installed in the directory that was specified with `--prefix` (which shouldn't happen with wineinstall). It appeared there was a problem with Wine calling ldconfig. Chuck Crayne explained the problem was actually with a library changing names: What actually happened is that $libdir was already in ld.so.conf, so the script did NOT add it, and therefore, it did NOT run ldconfig. This strategy works when one upgrades modules with identical names, but not when modules are renamed, as was the case with libntdll.dll.so replacing libntdll.so. The line in wineinstall which controls this behavior is: `if [ -f /etc/ld.so.conf ] && ! grep -qs "$libdir" /etc/ld.so.conf` Dustin Navea pointed out setting WINEDLLPATH was not correct: users need to set `$LD_LIBRARY PATH` and The latest wineinstall patch I submitted removes the `$libdir/wine` addition and instead always runs ldconfig (just in case of modules being renamed)

Due to some recent changes in wineinstall, some people were having problems. Bill Medland explained some quick workarounds for anyone who might have pulled the source from CVS during the few hours it had typos in it:

In the wineinstall script correct the following two lines:

Then run it again and that should solve it.

Along similar lines, Alexandre rejected another wineinstall patch and explained, $libdir/wine must not be added to ld.so.conf. Users have to set the WINEDLLPATH variable if Wine is not installed in the directory that was specified with --prefix (which shouldn't happen with wineinstall).

It appeared there was a problem with Wine calling ldconfig. Chuck Crayne explained the problem was actually with a library changing names:

What actually happened is that $libdir was already in ld.so.conf, so the script did NOT add it, and therefore, it did NOT run ldconfig. This strategy works when one upgrades modules with identical names, but not when modules are renamed, as was the case with libntdll.dll.so replacing libntdll.so.

The line in wineinstall which controls this behavior is:

if [ -f /etc/ld.so.conf ] && ! grep -qs "$libdir" /etc/ld.so.conf

Dustin Navea pointed out setting WINEDLLPATH was not correct:

users need to set $LD_LIBRARY PATH

and The latest wineinstall patch I submitted removes the $libdir/wine addition and instead always runs ldconfig (just in case of modules being renamed)

Euro Support	04/23/2002	Archive
Bill Medland wondered, I am looking into getting the Euro symbol (Cp1252 0x80 ie U20ac) to display (and print) from Wine programs. I am running RedHat 7.1. From my quick literature search it looks to me like it isn't going to be easy. Am I being too pessimistic? Are there people out there who have been using it for ages? Huw Davies replied, If you're using client side TT fonts and the euro symbol glyph is in the fonts then displaying on the XServer should just work. As for printing, I'm working on downloading TT fonts to the printer at the moment which will mean we'll be able to print the thing as well.

Euro Support

04/23/2002

Archive

Bill Medland wondered, I am looking into getting the Euro symbol (Cp1252 0x80 ie U20ac) to display (and print) from Wine programs. I am running RedHat 7.1. From my quick literature search it looks to me like it isn't going to be easy. Am I being too pessimistic? Are there people out there who have been using it for ages?

Huw Davies replied, If you're using client side TT fonts and the euro symbol glyph is in the fonts then displaying on the XServer should just work. As for printing, I'm working on downloading TT fonts to the printer at the moment which will mean we'll be able to print the thing as well.

Favorites Menu in IE	04/23/2002	Archive
Guy Albertelli, who's done a lot of work on the shlwapi library used extensively in Internet Explorer (and Explorer), noted the following behavior with IE 5.x: This note is just to document what happens in IE5.5 when using the "Favorites" dropdown menu. With the native control, if the mouse hovers over a folder, IE will expand the folder. The expansion is accomplished by the following steps: IE will set a timer on the Toolbar window with id=8001 WM_TIMER message for id=8001 on the Toolbar window occurs. Since the Toolbar window is subclassed via comctl.410 (and friends), the subclass WndProc (in native comctl32) somehow calls a part of IE which issues a KillTimer and a PostMessage of message 0xc057 against the main window. When message 0xc057 is dispatched, it issues a few TB_... messages and then eventually issues a CreateWindowExA for the next "BaseBar" window. This then drives the creation of the pop-out window. Since we don't support comctl32.410, .411, .412, and .413, this doesn't work (and will never work till we do support those undocumented routines). <rant> The reason MS can't make a modular Windows is because apparently no one there understands what modular means. Maybe they should work a summer building double wide trailers. </rant>

Wine Not Releasing CDROM	04/22/2002	Archive
Oliver Sampson ran into a problem with his CD-ROM not releasing: I'm seeing a strange behavior and I thought I'd let the Devel community know about it: While using Agent v1.8, and while having a CD in my CD tray (although unmounted!), if I start agent under wine, I'm able to open and close my CD tray. However, if I try to use the attachment window to attach something, the CD-ROM drive spins up, and I'm unable to open it. Even if I attach nothing, the CD-ROM drive is claimed by wine so that I can't eject the Drive. Once I exit agent, the drive is released so that I can open the drive. Note that the CD-ROM was never mounted. Even a check during the blocked period shows no mounted device, even though the "eject' command says "device busy." Oliver also included some output that showed Wine trying to access the floppy drive too. Lawson Whitney suggested, If you don't want Wine to attempt raw device access, don't give it a "Device" = in the [Drive X] entry, I think. Your average Windows app is inquisitive and tries to look at all drives that have defined devices. Duane Clark thought this was a new problem because he had started experiencing it over the weekend. Duane couldn't eject his CD until after he exited Wine. Eric Pouech posted a patch that ensured the file descriptor is closed when reading the super block. Duane reported success, Fixes it for me. And the behavior with CDROMs is now significantly improved over what it used to be. I used to have to click through a couple of dialogs to switch CDs. But now when I am asked to insert a new CD, I can unmount the old one, mount the new, click OK, and the program immediately finds it.

Wine Not Releasing CDROM

04/22/2002

Archive

Oliver Sampson ran into a problem with his CD-ROM not releasing:

I'm seeing a strange behavior and I thought I'd let the Devel community know about it:

While using Agent v1.8, and while having a CD in my CD tray (although unmounted!), if I start agent under wine, I'm able to open and close my CD tray. However, if I try to use the attachment window to attach something, the CD-ROM drive spins up, and I'm unable to open it. Even if I attach nothing, the CD-ROM drive is claimed by wine so that I can't eject the Drive. Once I exit agent, the drive is released so that I can open the drive. Note that the CD-ROM was never mounted. Even a check during the blocked period shows no mounted device, even though the "eject' command says "device busy."

Oliver also included some output that showed Wine trying to access the floppy drive too. Lawson Whitney suggested, If you don't want Wine to attempt raw device access, don't give it a "Device" = in the [Drive X] entry, I think. Your average Windows app is inquisitive and tries to look at all drives that have defined devices.

Duane Clark thought this was a new problem because he had started experiencing it over the weekend. Duane couldn't eject his CD until after he exited Wine. Eric Pouech posted a patch that ensured the file descriptor is closed when reading the super block. Duane reported success, Fixes it for me. And the behavior with CDROMs is now significantly improved over what it used to be. I used to have to click through a couple of dialogs to switch CDs. But now when I am asked to insert a new CD, I can unmount the old one, mount the new, click OK, and the program immediately finds it.

XIM Internationlization Patch	04/25/2002	Archive
Some languages require a very complex input method. For example, some Asian languages require first an input of a words' pronunciation, then a character may need to be selected from a list. In X this is done with an "Input Method" (XIM). Aric Stewart announced: Myself, Mike McCormack and Ulrich Czekalla have been working like mad to get XIM into Wine. We have a very early and unclean patch for people to try and help improve. This patch applies to the winehq tip as of today and probably changed a bunch of things it does not need to. If you use XIM input and can work with this please give it a try. I know it works with Japanese input with kinput2 on my redhat 7.2 machine. Since i do japanese that is what i have been testing but i have not idea for any other input methods or languages. Some known issues. The xim box does not appear in the right place, and i cannot see what i type as i type it in. the input does not always go to the correct edit window. Presently it probably only works for edit controls... Hope this helps people!

All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.