WWN Issue 207

This is the 207th issue of the Wine Weekly News publication. Its main goal is to go to WineConf. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

This week, 218 posts consumed 748 K. There were 75 different contributors. 42 (56%) posted more than once. 35 (46%) posted last week too.

The top 5 posters of the week were:

19 posts in 47K by Dmitry Timoshkov
14 posts in 39K by Robert Shearman
12 posts in 43K by Fabian Cenedese
10 posts in 53K by Abdul-Haseeb Ahmad
8 posts in 19K by Dimitrie O. Paun

News: C4 Update	01/24/2004	Archive
News Last week we announced the creation of CodeWeavers' C4 project. After just one week it's interesting to go back and look at the database statistics . There is some serious money being offered for working applications. Right now Lotus Notes 6 / 6.5 has a reward of $4326.50.

WineConf & Remote Participation 01/29/2004 Archive

WineConf & Remote Participation	01/29/2004	Archive
WineConf 2004 In case you hadn't heard, WineConf 2004 is this weekend in St. Paul, Minnesota. Over thirty developers are expected to attend. Almost everyone will be arriving tomorrow, if they're not there already. Part of the reason this week's WWN is so small is because people are en route. The other reason is I'm rushing out the door myself. Next week there will definitely be some form of update posted in the WWN. I'll probably wait a few days to allow everyone to put together some nice collections of pictures, slide topics, etc. Jeremy White has set up some remote participation capabilities for those unable to make it: It looks as though through the kind help of some folks that we will be able to have video streaming for WineConf. We'll also be maintaining an irc channel for the conference; #wineconf on freenode (said channel is already open for business, and will be active throughout the weekend). We've got a test stream up if you want to try your viewer: http://www.winehq.org/wineconf/stream.html I'll point it to the live stream on Saturday morning. We've had success with mplayer (the following was found by Art to work well): `mplayer -rtsp-stream-over-tcp rtsp://wine.codeweavers.com/wineconf-test.sdp` You can also use QuickTime, and the Player from QuickTime 6.3 should run under Wine. I haven't had time to nail down a version of Wine that runs it reliably; I had one working a few weeks ago, but now our CVS tip doesn't work for beans. Hopefully I'll get enough time to push one out. If someone else wants to take a poke, the key is to snag QuickTime 6.3 (it's a bit hard to find, but is out there), and make sure you use a Wine that is recent enough that it has the REUSEADDR badness in socket.c reverted. For more info on accessing Wine's IRC channels, see the IRC instructions on WineHQ. Please use the #wineconf channel for conference related questions. For more information on WineConf happenings, see the website or read the recent mailing list archives . Kevin DeKorte gave a pointer toward a little bit of browser integration for viewing Jeremy's video stream: Shameless promotion here. If you install mplayer with the realplayer codecs and get the below link working, but you want you see it in the browser do the following. Get the CVS version of http://mplayerplug-in.sf.net and install it. Then in the `$(HOME)/.mplayer/mplayerplug-in.conf` file (create the file if missing) set "enable-real=1" and "rtsp-use-tcp=1", delete `$(HOME)/.mozilla/pluginreg.dat` and restart mozilla and the video should work in the browser window. At least it does for me.

WineConf 2004

In case you hadn't heard, WineConf 2004 is this weekend in St. Paul, Minnesota. Over thirty developers are expected to attend. Almost everyone will be arriving tomorrow, if they're not there already. Part of the reason this week's WWN is so small is because people are en route. The other reason is I'm rushing out the door myself. Next week there will definitely be some form of update posted in the WWN. I'll probably wait a few days to allow everyone to put together some nice collections of pictures, slide topics, etc.

Jeremy White has set up some remote participation capabilities for those unable to make it:

It looks as though through the kind help of some folks that we will be able to have video streaming for WineConf.

We'll also be maintaining an irc channel for the conference; #wineconf on freenode (said channel is already open for business, and will be active throughout the weekend).

We've got a test stream up if you want to try your viewer:

http://www.winehq.org/wineconf/stream.html

I'll point it to the live stream on Saturday morning.

We've had success with mplayer (the following was found by Art to work well):

mplayer -rtsp-stream-over-tcp rtsp://wine.codeweavers.com/wineconf-test.sdp

You can also use QuickTime, and the Player from QuickTime 6.3 should run under Wine. I haven't had time to nail down a version of Wine that runs it reliably; I had one working a few weeks ago, but now our CVS tip doesn't work for beans. Hopefully I'll get enough time to push one out.

If someone else wants to take a poke, the key is to snag QuickTime 6.3 (it's a bit hard to find, but is out there), and make sure you use a Wine that is recent enough that it has the REUSEADDR badness in socket.c reverted.

For more info on accessing Wine's IRC channels, see the IRC instructions on WineHQ. Please use the #wineconf channel for conference related questions. For more information on WineConf happenings, see the website or read the recent mailing list archives .

Kevin DeKorte gave a pointer toward a little bit of browser integration for viewing Jeremy's video stream:

Shameless promotion here.

If you install mplayer with the realplayer codecs and get the below link working, but you want you see it in the browser do the following.

Get the CVS version of http://mplayerplug-in.sf.net and install it. Then in the $(HOME)/.mplayer/mplayerplug-in.conf file (create the file if missing) set "enable-real=1" and "rtsp-use-tcp=1", delete $(HOME)/.mozilla/pluginreg.dat and restart mozilla and the video should work in the browser window. At least it does for me.

Wine Status Updates	01/29/2004	Archive
Status Updates Dimi wondered why we hadn't told anyone about the updated status pages on WineHQ: How about a news item about the status being updated? Tom just finished a big status update, and people that don't follow wine-{cvs,devel,patches}@winehq.org have no way of knowing. In general, I think any big site update should make it as news items. Ha! I just told everyone. However, I haven't updated all of the references to WWN issues. I should complete that next week and then I really will splash a new item across the front page. However, that's really quite minor compared to the work Tom Wickline did putting this together. The format is slightly reorganized, including a whole new page for DirectX work.

Wine Status Updates

01/29/2004

Darwine Update	01/29/2004	Archive
Ports The Darwine folks have been keeping busy. The goal of Darwine is to port Wine to Mac OS X and allow Windows programs to run on it. This week Sanjay Connare announced: I have created and released a binary for wine on Mac OS X available at http://prdownloads.sourceforge.net/darwine/Darwine.pkg.tgz?download this binary is part of the Darwine project. Thanks for all of your help in helping the Darwine team, especially Pierre to bring wine over to Mac OS X. One of the goals of Darwine is to integrate an x86 emulator such as Bochs or QEMU. I think that currently only Winelib applications compiled natively will run. By adding in the x86 emulator they'll be able to natively run Windows programs out of the box.

Graphs of CVS Changes	01/23/2004	Archive
Documentation Last week I mentioned Rein Klazes put together a graph showing Wine commits over the past five years. I commented that it would be nice if there were a graph of the size of Wine's source code. Well, Rein put one together and the numbers are pretty impressive: You can find it here: http://home.wanadoo.nl/~wijn/wine/cvssize.png Notes: All files in the cvs wine tree are included, not just the sources. I excluded the (libs/)unicode directory. That is almost 5 MByte of mostly generated source files creating an ugly step in an otherwise smooth curve. The trend quite accurately represents the growth in the first 3 years. The last 2 years the rate of growth is clearly increasing. The number of cvs commits in October '98 was corrected to 258 commits. A quick look at a clean source directory shows everything to be about 53MB right now, including the generated source Rein mentions. Another interesting stat to look are the increases in mailing list messages. Over the same period where the amount of source code has grown quicker than the 5 year trend we've seen a corresponding increase in posts to both wine-patches and wine-devel. Until recently, CodeWeavers' patches haven't really appeared on wine-patches. Alexandre did the merges directly. Does that make us the largest open source project without an official release?

Archive

Documentation

Last week I mentioned Rein Klazes put together a graph showing Wine commits over the past five years. I commented that it would be nice if there were a graph of the size of Wine's source code. Well, Rein put one together and the numbers are pretty impressive:

You can find it here: http://home.wanadoo.nl/~wijn/wine/cvssize.png

Notes:

All files in the cvs wine tree are included, not just the sources.
I excluded the (libs/)unicode directory. That is almost 5 MByte of mostly generated source files creating an ugly step in an otherwise smooth curve.
The trend quite accurately represents the growth in the first 3 years. The last 2 years the rate of growth is clearly increasing.
The number of cvs commits in October '98 was corrected to 258 commits.

A quick look at a clean source directory shows everything to be about 53MB right now, including the generated source Rein mentions. Another interesting stat to look are the increases in mailing list messages. Over the same period where the amount of source code has grown quicker than the 5 year trend we've seen a corresponding increase in posts to both wine-patches and wine-devel. Until recently, CodeWeavers' patches haven't really appeared on wine-patches. Alexandre did the merges directly.

Does that make us the largest open source project without an official release?

Some Patches That Appeared This Week 01/24/2004 Archive

Some Patches That Appeared This Week	01/24/2004	Archive
Patches As I was putting this issue together I felt guilty because I didn't really cover a good technical thread. I'll take this opportunity to cover some patches sent to wine-patches this week. This is a pretty random sampling of some of the work going on. First, Alex Pasadyn submitted a patch to make some changes to Wine's desktop mode: ChangeLog: Make a separate process for the Wine desktop window In desktop mode, all applications share one desktop window Ensure system metrics are accurate for all processes after resolution changes This is an updated version of this patch that I originally sent a couple months ago. To test it, you must run both autoconf and tools/make_requests. While several applications work fine, there are some issues I have not been able to resolve. The problems have to do with trying to call WIN_FindWndPtr across processes, especially from the windows/painting.c file. I am sending this now as several people were interested in it, and the old version I posted no longer applies cleanly to the CVS Wine version. I am hoping someone with more knowledge of the painting and region code could spot some obvious way to get around the issue. Otherwise it will be tough. I had tried replacing some of the WND* uses with server calls to get rectangles and style flags, but that does not handle everything that's being read out of those structures. Unless there's some shortcut I don't see how to do it without moving more of that data into the server. The other problem related to this is that some functions are supposed to fail if the window is in another process, while others would work better if they got the data from the server, and it's not always obvious which way a particular function should work. From Mike McCormack : The richedit control is currently not thread safe due to extensive use of global variables. This patch removes almost all global variables from the control. ChangeLog: remove global variables from the richedit control From Mike Hearn : Here's a first cut at allowing wine to be installed to any prefix at runtime and still work nicely. I have implemented this for some customers who are finding it a bit tricky to work with the source tarball I sent them, so I want to make a binary tarball and let them extract it to wherever so it can be installed side-by-side with a pre-existing wine. It is unfortunately Linux specific, though that's more because I know how to do this on Linux but not on any other platforms. It'd not be too hard to adapt to other platforms if they provide the same information Linux does to userland. Here's how it works: A configure test is added that checks for the existence of /proc/self/maps, so you will need to run "autoheader && autoconf" to make this work. A new file is added to libs/wine, prefix.c, which looks up the base address of libwine by using dladdr on an empty string (ie an entry in the data segment). We then scan /proc/self/maps looking for that base address, from which we can then get the absolute path of the library. This file is a stripped down form of a generic kit, which is why it might look a bit strange at first. The dynamically derived absolute path of the dlls directory is appended to dll_paths We set an RPATH on the wine binaries: wineserver, wine-glibc, wine-pthread and wine-kthread using the ELF ${ORIGIN} feature, so they can locate libwine without needing LD_LIBRARY_PATH or /etc/ld.so.conf set. These changes combined mean you can do the following: `./configure make depend && make make install prefix=/opt/wine1 /opt/wine1/bin/wine (works) mv /opt/wine1 /opt/wine2 /opt/wine2/bin/wine (still works)` Before Wine would not be able to find libwine nor ntdll.so, now it can. I hope this patch is OK, as I think this is a useful feature that far more free software should support. The list of use cases is big. Robert Shearman worked on INI file processing: Initially, I just wanted to add Unicode support, but ended up redoing most of the parsing and saving. It now doesn't use Unix functions for files, doesn't needlessly peek into DOSFS internals and fully processes files in Unicode. I've also added Unicode file detection as detailed here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_42jv.asp Changelog: Use Win32 instead of Unix file functions Process files fully in Unicode Add Unicode file detection

Patches

As I was putting this issue together I felt guilty because I didn't really cover a good technical thread. I'll take this opportunity to cover some patches sent to wine-patches this week. This is a pretty random sampling of some of the work going on. First, Alex Pasadyn submitted a patch to make some changes to Wine's desktop mode:

ChangeLog:

Make a separate process for the Wine desktop window
In desktop mode, all applications share one desktop window
Ensure system metrics are accurate for all processes after resolution changes

This is an updated version of this patch that I originally sent a couple months ago. To test it, you must run both autoconf and tools/make_requests. While several applications work fine, there are some issues I have not been able to resolve. The problems have to do with trying to call WIN_FindWndPtr across processes, especially from the windows/painting.c file.

I am sending this now as several people were interested in it, and the old version I posted no longer applies cleanly to the CVS Wine version. I am hoping someone with more knowledge of the painting and region code could spot some obvious way to get around the issue. Otherwise it will be tough. I had tried replacing some of the WND* uses with server calls to get rectangles and style flags, but that does not handle everything that's being read out of those structures. Unless there's some shortcut I don't see how to do it without moving more of that data into the server. The other problem related to this is that some functions are supposed to fail if the window is in another process, while others would work better if they got the data from the server, and it's not always obvious which way a particular function should work.

From Mike McCormack :

The richedit control is currently not thread safe due to extensive use of global variables. This patch removes almost all global variables from the control.

ChangeLog:

remove global variables from the richedit control

From Mike Hearn :

Here's a first cut at allowing wine to be installed to any prefix at runtime and still work nicely. I have implemented this for some customers who are finding it a bit tricky to work with the source tarball I sent them, so I want to make a binary tarball and let them extract it to wherever so it can be installed side-by-side with a pre-existing wine.

It is unfortunately Linux specific, though that's more because I know how to do this on Linux but not on any other platforms. It'd not be too hard to adapt to other platforms if they provide the same information Linux does to userland.

Here's how it works:

A configure test is added that checks for the existence of /proc/self/maps, so you will need to run "autoheader && autoconf" to make this work.
A new file is added to libs/wine, prefix.c, which looks up the base address of libwine by using dladdr on an empty string (ie an entry in the data segment). We then scan /proc/self/maps looking for that base address, from which we can then get the absolute path of the library. This file is a stripped down form of a generic kit, which is why it might look a bit strange at first.
The dynamically derived absolute path of the dlls directory is appended to dll_paths
We set an RPATH on the wine binaries: wineserver, wine-glibc, wine-pthread and wine-kthread using the ELF ${ORIGIN} feature, so they can locate libwine without needing LD_LIBRARY_PATH or /etc/ld.so.conf set.

These changes combined mean you can do the following:

./configure make depend && make make install prefix=/opt/wine1 /opt/wine1/bin/wine (works) mv /opt/wine1 /opt/wine2 /opt/wine2/bin/wine (still works)

Before Wine would not be able to find libwine nor ntdll.so, now it can.

I hope this patch is OK, as I think this is a useful feature that far more free software should support. The list of use cases is big.

Robert Shearman worked on INI file processing:

Initially, I just wanted to add Unicode support, but ended up redoing most of the parsing and saving. It now doesn't use Unix functions for files, doesn't needlessly peek into DOSFS internals and fully processes files in Unicode. I've also added Unicode file detection as detailed here:

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

Changelog:

Use Win32 instead of Unix file functions
Process files fully in Unicode
Add Unicode file detection

World Wine News