World Wine News

Here's 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.

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
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.

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:

• needs stdole32.tlb, we have a program to generate this in CrossOver and it needs to be pulled upstream as previously discussed.
• Painting problems. I've not investigated this deeply but I'm 99% sure I know what the problem is. I've even written a patch to fix it as part of investigating iTunes, but I never tried the patch with an InstallShield that shows the issue.

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 :(

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.

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.

There are plenty of signals available to applications besides SIGUSR1 and SIGUSR2. These 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):

Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes.

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.

I would like to use source code from LibTomCrypt 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 being easily upgradable?

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:

/* This file was derived from code written by Tom St. Denis with the following license: */

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 may be win32 "features" that we wish to implement... NSAKEY anybody? ;)

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:

http://www.kegel.com/wine/why.html

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:

2. once Linux's market share is above 20%, there will be a strong economic incentive to do native Linux ports anyway, because running a Windows app under Linux will always feel strange.

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 one 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 ;-) .

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: :)

http://www.eweek.com/article2/0,3959,1210083,00.asp

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!