Wine Traffic #247 For 5�Nov�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 247th issue of the Wine Weekly News publication. Its main goal is to grab the boards and slide on snow. 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 (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 185 posts in 667K.

There were 71 different contributors. 42 posted more than once. 33 posted last week too.

The top posters of the week were:

1. Windows Update Region Changes

2�Nov�2004�-�3�Nov�2004 (4 posts) Archive Link: "Update region patch"

Topics: Graphics

People: Alexandre Julliard,�Rein Klazes,�,�Dimi Paun,�News,�Rein Klaze

Alexandre came up with a large patch for something that's been planned for a while - moving the update region management into the Wine server. There's lots of reasons for it, not the least of which is wrapping up the DLL separation:

Here's (http://www.winehq.com/hypermail/wine-devel/2004/11/att-0048/01-wm.diff.gz) the first step of moving the update region management to the server. The refresh on window moves is not optimized yet, so it will probably flicker quite a bit, but things should still be painted properly in the end. If you feel like giving this a try, I'm interested in hearing about any case where things don't repaint correctly.

Rein Klazes took it for a test drive an reported some problems:

  1. Newsbin pro gets into an apparently endless loop when building up its main screen. I've uploaded a +relay,+server trace to http://www.xs4all.nl/~rklazes/temp/nbhangs.log.bz2 (http://www.xs4all.nl/~rklazes/temp/nbhangs.log.bz2)
  2. the 'tool tips' windows of Agent news reader do not close until another tool tip is made to appear. They stay open also when switching to other X windows, or even other work spaces.
  3. Calling up a dialog and moving it using the mouse causes lots of repainting of the dialog, it does not without the patch. Just try wine's notepad and the font dialog to see.

Dimi Paun reported some problems he had reported a long time ago still persisted even with the patch. Alexandre pointed out that could be expected, " No, it's not supposed to fix anything; at this point the goal is to avoid introducing too many new bugs. Fixing the old ones will come later..."

2. InstallShield Status

31�Oct�2004�-�2�Nov�2004 (3 posts) Archive Link: "COM / Installshield status?"

Topics: Status Updates

People: Dan Kegel,�Mike Hearn,�Tony Lambregts,�

Installers can be a pain to run under Wine. Often it's harder to make the installation program run than the actual program after it gets installed. Support has certainly improved over the past few years and we've gone from no-chance of installation to, well, a chance. It led Dan Kegel to wonder what the current status on all this is, " what's the current status of Installshield support, and how much work would it be to fully support Installshield-based installers? I don't see any open Installshield bug reports, maybe I should file one against the apps I have that don't install at the moment. (Or would that be overkill?)"

Tony Lambregts pointed out Bugzilla does have reports of failures. If you look in the AppDB under InstallShield extractor (http://appdb.winehq.org/bugs.php?appId=995) there are instructions for tracking down the related Bugzilla entries (http://bugs.winehq.org/buglist.cgi?product=Wine&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_file_loc_type=allwords&bug_file_loc=appdb%20995) . Mike Hearn followed up with a detailed explanation of where InstallShield stands:

Rob and I did some work on InstallShield for iTunes a few months ago, since then AFAIK no work has been done.

Status back then was that the InstallShield 7/MSI hybrid installers worked pretty well, the bug I chased for nearly a week was refcounting related (the backend wasn't shutting down) and since that was fixed I believe it works pretty well.

The other main problems I'm aware of are:

Apart from those two there are mostly just generic issues - InstallShield contains its own scripting language which heavily exercises the variant APIs, so it sometimes shows up problems with them. I believe Marcus found an issue with them thanks to InstallShield recently.

In other words, InstallShield should work though it might not be pretty.

There may be installers out there which don't work, I'd like to start nailing them once I get back to Wine hacking. I don't know if I'll get time however. Also, Murphy continues to smack me down w.r.t internet connection, the ISP sent me the wrong type of modem and yesterday I discovered the phone socket I was going to connect the modem to doesn't actually work :(

3. Fun With Signals

3�Nov�2004�-�5�Nov�2004 (8 posts) Archive Link: "Re: ez-cdda sleep"

Topics: Architecture

People: Mike Hearn,�Alexandre Julliard,�Dimitrie Paun,�Andreas Mohr,�Michael Stefaniuc,�

A few weeks ago Mike Hearn analyzed a debugging trace (see WWN issue #242 (http://www.winehq.com/?issue=242#Analyzing%20Debug%20Traces) ). He came to the conclusion there was a problem resuming a suspended thread. After some work this week, he came up with a patch to fix it, but mentioned, " This feels like the sort of patch Alexandre will rewrite to his liking anyway"

Alexandre replied, " Actually I already did a similar hack in the Crossover tree; it's not merged because it's full of races (which at first glance seems to be the case with yours too). "

Mike wanted to know what the race conditions were and the discussion moved over to irc (#winehackers for anyone interested). He reported back on wine-devel:

The first race he was thinking of is not a problem with this patch as Get/SetThreadContext loop until the context is uploaded. The second race is setting the context after the suspend context has been released but before SIGUSR2 returns.

Long term the plan is to use SIGUSR2 to implement SetThreadContext, with SIGUSR1 uploading the sigcontext to the server for GetThreadContext like in the patch.

That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out how to overload SIGUSR2).

Alexandre isn't going to apply the patch for now, on the grounds that it needs to be done properly and the current code does at least work for debug registers.

This does leave the question of OpenGL/D3D thread affinity open, the plan was to use a signal for that but we only have 2!

If anybody wants to run with this, be my guest. I won't be working on it anytime soon. It might be worth adding a comment to the source explaining the situation.

Oh and finally for Mike, it turns out our guess was wrong: SIGSTOP isn't used because it's process-wide on NPTL.

Most people are used to signals and sending signals to processes - using kill is a common example. In general, POSIX signals are used to for processes to communicate synchronously or asynchronously with other processes. However, one traditional limitation is the lack of signals that applications can define on their own. POSIX defines just two application specific signals, SIGUSR1 and SIGUSR2. Right now Wine uses both, though as Mike mentioned SIGUSR2 could be reused if the old DOS part was modified. Dimi wondered though, " Sorry if I'm way off (haven't looked at the problem myself), but can't we include a command-byte or so with the payload (in the case the context), so we can multiplex multiple requests on the same signal? "

Mike didn't think that was an option but tossed out some other ideas:

Well, that's what I meant by figuring it out. As far as I know signals cannot contain payload information. The fact that they arrive *is* the information.

Actually that's not quite true. You get the context of the thread at the time of signal arrival, if you use lots of OS specific code. Problem is the nature of signals is that they're async, so you can't use the context to carry information. Or I can't think of how.

The most obvious way is to have a new server request which lets the thread ask what it's supposed to do. That's a bit heavy but would work.

Another way would be a global variable but that'd be prone to races too.

Andi Mohr asked whether signals could be muxed, " If we only have two signals (SIGUSR1, SIGUSR2), then a good idea would be to implement some sort of signal multiplexing mechanism, since we damn sure will want to use this resource for any future signalling tasks, too.... But I'm sure that within fractions of a second you will tell me that this certainly isn't possible :-\ "

Above I mentioned that traditionally POSIX signals only allow for an app to define two. Michael Stefaniuc described the caveat and also answered Andi's question:

There are plenty of signals available to applications besides SIGUSR1 and SIGUSR2. This are the real time signals in the range SIGRTMIN ... SIGRTMAX specified by POSIX 1003.1-2001. The only main difference to the "normal" signals is that these signals can be queued.

>From man signal(7):

And btw. you could easily do signal multiplexing with the real time signals: you can send additional data with the signal if you use sigqueue(2).

The question now is how portable this is. Linux has SIGRTMIN ... SIGRTMAX at least in the 2.4 and 2.6 kernels, Solaris and Irix (from Google hits) seem to have it too, but i don't know about the *BSD variants including Darwin.

It remains to be seen if that becomes solution. If not, it will likely be because of portability concerns.

4. Incorporating Public Domain Code

4�Nov�2004�-�5�Nov�2004 (5 posts) Archive Link: "Public domain source in wine"

Topics: Licensing

People: Michael Jung,�Mike McCormack,�

Michael Jung wanted to know about the legal and ethical aspects of including code written by others in Wine:

I would like to use source code from LibTomCrypt (http://libtomcrypt.org) in my implementation of rsaenh.dll (which I still hope has a remote chance of being accepted into wine ;-), in order to get rid of the OpenSSL dependencies. LibTomCrypt is in the public domain. I have two questions:

  1. What is the legaly correct way to do this? As I understand it, public domain source can simply be taken as is and re-licensed under the LGPL. Is this correct? Am I allowed to remove the headers in the original file, which state that the code is public domain? How do you generally acknowledge the original author?
  2. A more technical question: LibTomCrypt's original sources are highly customizable (A lot of conditional compilation and hook-functions). Since we have fairly special requirements for rsaenh, I could cut down the source code a lot. However, this would make it harder to incorporate code from a newer version of libtomcrypt, once it becomes available. Which way is preferable? Having less code or beeing easily upgradeable?

(On a side note, Michael's rsaenh.dll, covered last week in WWN issue #246 (http://www.winehq.com/?issue=246#MS%20Enhanced%20Provider%20Library) was committed to CVS shortly after he sent that email.)

With regard to the first question, Mike McCormack described what he's done before:

I think the way is to leave the original headers on there, and add the LGPL header above it, perhaps with a note saying something like:

With regard to cutting down code, Mike explained:

My approach when incorporating code from other libraries has been to modify as little as possible, but remove all the #ifdefs and code that isn't relevant to the WIN32 platform.

It's likely that the code will diverge from libtomcrypt over time anyway, and there maybe be win32 "features" that we wish to implement... NSAKEY anybody? ;)

Alexandre thought removing any unnecessary code was desirable as a long as it was a noticable amount.

5. Advocating Wine

30�Oct�2004�-�1�Nov�2004 (10 posts) Archive Link: "Countering arguments against Wine"

People: Dan Kegel,�Holly Bostick,�

Years ago Wine was often criticized and the argument usually sounded something like, "Windows is evil therefore Wine is evil.". Hearing that gets boring pretty quick and a few years ago we put together two article about why Wine is important (http://www.winehq.com/site/why) and debunking Wine myths (http://www.winehq.com/site/myths) . Dan Kegel decided to put together something similar:

I've run into people several times who dislike the fact that I advocate or even work on the Wine project, because they feel that it takes focus away from working on the Linux desktop. I beg to differ, but I've never had a really snappy comeback for them. It happened again today, and this time it occurred to me I should write a page on the topic to organize my thoughts. Here it is:

Holly Bostick had some thoughts on it:

Dan, first of all, thanks for writing that dowm. I agree with what you say, until you reach the "But doesn't Wine take away the incentive for native ports?" section.

I actually appreciate this reason, as it clarifies a 'feeling' that I've been unable to clearly express about this issue:

But I wonder if this is in fact true.

I am a pure Linux user; I began my migration a year and a half ago, moving from a dual-boot, to a multi-boot (2 versions of Windows and 5 distributions of Linux on one system), and finally ditched all alternate boots except the Linux a few months ago.

So I'm not all that far from the migration mindset, since I used Windows for over 10 years, but as a pure Linux user, I'm not all that close to it anymore, either.

I've got Wine running, and installed several programs I was familiar with under Windows, mostly to perform tasks that I couldn't figure out how to do under Linux, but which I either knew how to perform using Windows apps, or could find HOW-TOs for that specified Windows apps. I find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine program_name from a terminal, or having to write a little start script in order to make a panel shortcut to it).

Once the program is running, though, it doesn't "feel" strange at all; after all, the reason I'm running it is most likely because I'm familiar with it. This of course, assumes that the program in question runs well under Wine, which we will assume for the sake of this discussion, if you don't mind ;-) .

I have admittedly found that it's ultimately "easier" (for me) to re-encode a video with transcode and mplex than it is to do so using TMPGEnc under Wine, which was a surprise given that I know squat about re-encoding video (I know somewhat more, now, though). I also found that given a choice between equivalent Linux native programs and Windows programs under Wine (Aisle Riot and Pretty Good Solitaire), I'll often choose the Linux native program simply because it's easier to *start* (not because I prefer it, per se).

Maybe that's what you (and I) mean by "feeling strange", but since I'm not sure what causes this feeling, I am not certain that migrating XP users, who are used to and have no complaints with XP functionality but rather are migrating because they don't like the Windows security model (or lack therof)-- meaning, for practical reasons such as increasing cost for less value, rather than philosophical ones such as a deep objection to Windows' design philosophy or business practices-- would feel the same way after switching to Linux.

All of those "a computer is just a tool" people who find it more strange and painful to use the command-line, or get confused if they have to read --help output or a man page "just to get something done" may well find that their relief at having these familiar tools available swamps any "strange" feelings of (guilt,irritation?) that they may (or may not) experience when running Windows programs under Linux.

After all, you'll only have those feelings if you *care*-- and many, many users don't.

If I come up with a "better" reason #2, I'll let you know ;-) .

6. Wine in the Spotlight

28�Oct�2004�-�30�Oct�2004 (5 posts) Archive Link: "Success Stories?"

Topics: WineHQ

People: Hiji,�Brian Vincent,�Scott Ritchie,�eweek,�CodeWeavers,�,�WineHQ

Lots and lots of people use Wine. We know that because we have about a hundred thousand downloads a month off Sourceforge, we see tons of hits to the website, and Alexandre is still getting a paycheck from CodeWeavers. What we don't hear about often are success stories, especially those of people using Wine in an enterprise environment (and having a 19" rack in your bedroom closet doesn't make you an enterprise user, it just lets you add a few plus signs to your geek code.) It led Hiji to ask this week:

Are there any plans to spotlight Wine-use success stories on the WineHQ home page? I always think of how Disney used Wine to run Photoshop 7 so they could move to a Linux platform. I'm sure it could draw additional attention/ support and provide additional credibility to non-Wine users.

I know this article is a year old, but I think it's the type of thing that should be shown to the world: :)

I thought it would be a nice addition to the website, " Nope, there's no plans. Are you volunteering? It would be great if you could do it. Rather than just provide links, I think it would be nice to put together short summaries and short interviews about it. In other words, create original content rather than regurgitate an article. "

Hiji wrote back and said he would try to put something together. Scott Ritchie gave a pointer to another source for success stories, " This exact story is on the CodeWeavers page somewhere, as an advertisement for Crossover. At the least, read it first :) "

Anyone out there have a success story they'd like to share? If you don't want to share things like the business name that's ok. See Hiji's original email (http://www.winehq.com/hypermail/wine-devel/2004/10/0619.html) for an address to send it to. You could even mail it to the wine-devel list (wine-devel -at- winehq.org); I'm sure some developers wouldn't mind hearing such stories.

7. Patches Galore

29�Oct�2004 (1 post) Archive Link: "We hit 5mb for 3 months running!"

Topics: Patches

People: Mike Hearn,�,�Mike McCormack

Wine development typically slows in summer, or rather, it slows during the summer in the northern hemisphere. Not so coincidentally, almost every Wine developer lives in the northern hemisphere. The resident Aussie, Mike McCormack, happens to live in South Korea. Mike Hearn pointed out development is picking up:

Here's a great excuse for a party: wine-patches has had 5mb of traffic per month for the last three months now. Apart from a short dip over the summer, it looks like we've been consistently generating 5mb/month for most of the year!

2003 was mostly hovering around the 4mb level, and 2002 was mostly 1-2mb (apart from when Dimi had his listview hackfest and we got 6mb!) so we seem to be doing something right :)

Let's see if we can keep it up and who knows, maybe 2005 will be averaging at 6mb/month!

October narrowly missed 6MB with the final total coming in at around 5.8MB.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.