Wine Traffic #121 For 25 Apr 2002
Table Of Contents
This is the 121st release of the Wine's kernel cousin publication. It's main
goal is to distribute widely what's going on around Wine (the Un*x windows
Mailing List Stats For This Week
We looked at 228 posts in 867K.
There were 78 different contributors.
38 posted more than once.
36 posted last week too.
The top posters of the week were:
- 14 posts in 127K by Martin Wilck <Martin.Wilck@fujitsu-siemens.com>
- 14 posts in 44K by Dustin Navea <email@example.com>
- 13 posts in 86K by Michael Cardenas <firstname.lastname@example.org>
- 12 posts in 28K by Steven Edwards <Steven_Ed4153@yahoo.com>
- 11 posts in 30K by Eric Pouech <email@example.com>
- Full Stats
18 Apr 2002 - 19 Apr 2002
Archive Link: "ALSA driver"
Marco Pietrobono, David Hammerton, Eric Pouech, Alexandre Julliard, , TransGaming, Gavriel State
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:
Marcus said he wasn't planning on working on it. David Hammerton corrected
Marco and explained Eric Pouech was working on it,
I'm starting to work on a native ALSA driver for wine. Since I
remember that Marcus was working (or was planning to work) an 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,
BTW, Alsalib is LGPL, so the license shouldn't be a problem.
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"
Then Eric jumped in to explain the details of the driver:
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,
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.
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.
22 Apr 2002 - 24 Apr 2002
Archive Link: "New Winsock2 patch series - now tested"
Martin Wilck, Rein Klazes, , Michael Cardenas
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
Since then Martin has went on to submit even more patches after
Rein Klazes and Michael Cardenas found some problems with the first ones.
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
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
- 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()
- 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!),
17 Apr 2002 - 24 Apr 2002
Archive Link: "PATCH: Unit test for winsock2"
Martin Wilck, Jakob Eriksson, Mike McCormack, , Bill Medland, Eric Pouech
Some submissions came in this week from people who have been building
tests for various Wine functions. Martin Wilck
some for his IO work:
Jakob Eriksson submitted a test with the note,
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
First attempt at unit testing. Victim of choice: _hread()
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
simple test set for window classes
And Eric Pouech's
discussed last week made it into CVS.
Bumps in Wineinstall
22 Apr 2002
Archive Link: "tools/wineinstall problems"
Bill Medland, Alexandre Julliard, Chuck Crayne, Dustin Navea,
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:
Along similar lines, Alexandre rejected another wineinstall patch and
In the wineinstall script correct the following two lines:
- Where it mentions "ldconfig" explicitly state "/sbin/ldconfig/index.html"
- Where it says su -c"$sucommand" put su -c "$sucommand"
Then run it again and that should solve it.
It appeared there was a problem with Wine calling ldconfig.
Chuck Crayne explained the problem was actually
with a library changing names:
$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).
Dustin Navea thought setting WINEDLLPATH was not correct:
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
The line in wineinstall which controls this behavior is:
if [ -f /etc/ld.so.conf ] && ! grep -qs "$libdir" /etc/ld.so.conf
But Alexandre corrected him,
users need to set
and The latest wineinstall patch I submitted removes
addition and instead always runs
ldconfig (just in case of modules being renamed)
No, WINEDLLPATH is correct. You must *not* set LD_LIBRARY_PATH to
$libdir/wine, nor add it to ld.so.conf. ld.so will never load
libraries from that directory, only Wine does, and it uses WINEDLLPATH
22 Apr 2002
Archive Link: "The Euro symbol"
Bill Medland, Huw Davies,
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
22 Apr 2002
Archive Link: "IE5.x and Toolbars"
Guy Albertelli, , Guy Alberte
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
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
Since we don't support comctl32.410, .411, .412, and .413, this
doesn't work (and will never work till we do support those
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.
Wine Not Releasing CDROM
21 Apr 2002
Archive Link: "Wine not releasing CDROM"
Oliver Sampson, Lawson Whitney, Duane Clark, , Eric Pouech
Oliver Sampson ran into a problem with his CD-ROM not releasing:
Oliver also included some output that showed Wine trying to access
the floppy drive too. Lawson Whitney suggested,
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."
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
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
24 Apr 2002
Archive Link: "WINE XIM Patch"
Aric Stewart, , Ulrich Czekalla, Mike McCormack
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!
Sharon And Joy