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.

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.

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.

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.

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.

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

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.

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