This is the 252nd issue of the Wine Weekly News publication. Its main goal is to wear a tux and go to a wedding. 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
One big item on the Wine
to do list
involves window management and how visible regions are managed.
Last year at Wineconf there was some discussion of it, but
everyone pretty much agreed it was a project only Alexandre
could tackle. Over the past few weeks he's put quite a lot
of work into it and this week committed a patch that simply
said,
Moved update region handling to the server.
A couple people immediately expressed their enthusiasm on wine-devel. Dimi Paun took it out for a test ride and reported:
OK, here are the first impressions after testing this patch:
- Good news: bug 1091 seems to have been fixed
- Bad news: it is *very* slow now. The repaint on wine List\ View.exe from the MS Control Spy is painful. Similarly, menus are slow, dialog boxes, etc. I have a fast machine (3GHz, 1GB RAM), and it takes 2-3 seconds to open the File Open dialog. Is this expected?
Buttom line: painting looks great, somehow it seems a bit better then before (in terms of correctness, but I can't quite put my finger on it). If we can solve the speed issue, we have a winner.
Alexandre posted a preview a few weeks ago and noted
that performance could definitely be improved. This week
he again reiterated that,
Part of it is probably because the window moves are not optimized at
all, there is currently no attempt to take into account valid bits so
any window show/move/resize operation forces a repaint of the whole
window. This will be fixed in a subsequent patch.
Mike Hearn has revisited his patch to add system tray support to help integrate Wine with the underlying desktop. This could be a really useful patch for many users. In the past, Alexandre has rejected it because of how it worked. Mike went back to the drawing board and a couple weeks ago sent in the patch:
Here it is, at last, just what the doctor ordered. All in a separate wineshell process, and with cleaner code to boot. No thread safety needed. Hopefully this is now satisfactory and can go in.
The intention is that wineshell becomes a generic explorer-alike process in terms of responsibility. For now, I have it being started automatically by shell32 (to avoid the startup penalty), and shutting down a few seconds after the last icon is gone like the wineserver. If we start putting more stuff in there like a DDE server, we may have to rethink that strategy.
ChangeLog:
- Add a new wineshell process, and put system tray handling in there
- Rewrite the shell32 systray handling to be out of process
- Support the freedesktop.org XEMBED protocol
This week he wondered why it hadn't been committed yet since it seemed
to have met all of Alexandre's previous requirements. Alexandre went
through and picked out a couple of technical problems but also added,
It would be nice to do the XEMBED stuff as a separate patch. Also I
was hoping you would get rid of WS_EX_TRAYWINDOW instead of adding
even more uses of it.
Thet went back and forth a bit, then Mike agreed to make the changes.
Jon Griffiths often goes weeks or months without posting patches and then pops up with something new. This week he started a series of patches to clean up header inclusion and announced:
On the suspicion that my hacking on header files was causing too many files to be rebuilt, I whipped up a quick perl script to identify unneeded header files. This series of patches is the result.
There are a large number of uneeded includes, so these patches should reduce your build time for those trying to stay current with cvs.
I have split the patches up on a per-dll basis to avoid merge conflicts. Don't forget to re-run 'make depend' after applying.
Andi Mohr asked Jon to supply a copy of the script and
then cautioned,
Note that some removed include files might be needed for different systems,
so some breakage might/may/will follow this patch.
(Gerald Pfeifer will *love* your "nice" work, I'm sure ;-)
But I'd still vote strongly for including it, since it will remove lots of
cruft.
Gerald is the resident FreeBSD guru who fixes a lot of patches that break portability. Jon took that into account and described what his changes were limited to:
I deliberately made my script remove only Wines own headers for this reason. It will not remove system header files. I also manually checked that nothing within an #ifdef block was deleted. So this shouldn't cause any problems for other *nices.
If there is an issue it will be with mingw or VC++. But that would point out an incompatability in our headers with theirs, and that would be a good thing, IMHO.
Yes, its a little crufty as-is. My reasoning is that anything that reduces my compile times after updates is good, and my laptop takes quite a while to rebuild Wine, Minimising dependencies helps that.
On a related note, would anyone object to a patch that auto-split config.h into multiple files during the build process, and changing makedep to generate dependencies only on the generated config-value file?
This would be a big win whenever config.h changes. Currently when config.h changes, 980 files are rebuilt. Using a smarter method would only rebuild the files that depend on the HAVE_ option that was changed (which is bound to be a significantly smaller number).
The Linux kernel process does this already, check out /usr/src/linux/Documentation/smart-config.txt for details.
Andi thought another good approach for speeding up
compiles would be to implement gcc 3.4 support for
precompiled headers. Juan Lang thought one of the patches
looked suspicious, so Jon explained a bit more about what
he did,
The script I wrote basically comments out the
includes one at a time, and restores any that caused a compile
failure when missing. The worst that could happen is that a new
warning could be generated, but I rebuilt all the files, check the
build logs and believe I got them all.
Alexandre looked things over and realized there was a problem with this approach:
The problem with that approach is that you remove a lot of headers that are included anyway so it doesn't make any difference in build time, and many of them will have to be added again once we finish the header cleanup. For instance you remove winuser.h everywhere win.h is included because win.h brings it in already, but once we get rid of win.h we'll have to go back and re-add winuser.h.
What you should do is limit the changes to the cases where it makes an actual difference in the dependency tree. You'll get the same performance gain with a much smaller set of changes.
Jon said he would update his script to get that result:
It might be better to clean up the headers first then. By clean up I take it you mean removing any header that aren't part of the platform SDK? If that is the long term plan then it could be handled in 2 steps a) remove all #includes from non-sdk headers and add them to the files that need them, then b) start removing the non-standard headers (possibly much later).
If so, thats probably a worthwhile project.
Alexandre explained a problem with that too,
No, I don't think we want to do that in two steps, since we don't want
to add headers that are only needed to build a private header. For
instance many private headers still contain 16-bit stuff, and we
definitely don't want to start including Win16 headers all over the
place.
Jon corrected what he meant earlier:
Right, but the 16 bit header are non SDK headers. what I'm talking about as the first step is removing SDK headers included from the non SDK headers in include/. With your example of not removing winuser.h since it will need to be added in again to the files that use the private headers, I am suggesting removing the inclusion of winuser.h from e.g. winpos.h and win.h, and including them in the files that need them directly. If we hide the source files dependencies in header files its impossible to remove any uneeded dependencies from them.
I'll post the script I'm using to clean up the headers and as the private headers are removed (or periodically) it can be run to weed out any uneeded dependencies remaining.
In the meantime, I've updated my script to only remove headers that reduce a files dependencies and will be posting the revised patches shortly.
Lots of work has been done on the AppDB lately by Tony Lambregts, Chris Morgan, and a newcomer, Jonathan Ernst. It's actually picked up even more steam now that Chris has CVS access to WineHQ. This week Tony posted another patch and asned for comments:
Over two years ago this was discussed and the concensus at the time was that integrating the AppDB and Bugzilla would be a Good Idea (TM). This patch is my attempt to get it started.
I am submitting this to wine devel first because I KNOW this patch can be controversial. I have tried to make this patch as small as possible but it still covers quite a few files. I am using Globals and that should be improved. and I am sure there are other things that are wrong with it. ;^) Also the code in preferences.php does not do anything except show that this works.
Please try it out and get back to me..