Wine Traffic #166 For 18 Apr 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 166th release of the Wine's kernel cousin publication. It's main goal is to some how escape the confines of a hard drive going bad and be thankful for ancient boot floppies that still work. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 231 posts in 803K.

There were 55 different contributors. 32 posted more than once. 33 posted last week too.

The top posters of the week were:

1. News: WineX 3.0, TransGaming Updates, Interview with Marcus Meissner

12 Apr 2003 - 18 Apr 2003 (6 posts) Archive Link: "News"

Topics: News

People: TransGamingGav StateNewsMarcus Meissner

TransGaming made some big announcements this week. First off, we have the release of WineX 3.0! Noted changes include:

The detailed notes for the WineX 3.0 release are available here (http://downloads.transgaming.com/files/winex-3_0_releasenotes.txt) .

TransGaming's April Voting Report and Development Status (http://www.transgaming.com/showthread.php?news=66) came out on Thursday. It discusses more of the technology found in WineX 3.0, including the new Point2Play (http://downloads.transgaming.com/files/Point2Play_beginners_guide-1.01.txt) management tool. The games receiving the most votes to concentrate development on were Battlefield 1942, Morrowind, Command and Conquer: Generals, Any racing game, Unreal II: The Awakening, and SimCity 4.

And finally, we've got a slew of other TransGaming news. Gav State wrote about nice behind the scenes (http://www.transgaming.com/gavstates.php) article discussing WineX and glibc threading issues, support for new copy protection and better graphics support. TransGaming's Vikas Gupta wrote a boring update (http://www.transgaming.com/presmsg.php) about how great TransGaming is. It's probably justified though, TransGaming made the Top 25 Up and Comers (http://www.branhamgroup.com/branham300/2002/index.php) of the Branham300 - a list covering the Canadian IT industry. If you happen to be going to the Real World Linux (http://www.realworldlinux.com/jsp/ts/100454/index.jsp) show in Toronto in a few weeks you might want to check out The Linux Gaming Zone hosted by TransGaming.

Don't forget to check out this week's interview with Marcus Meissner (http://www.winehq.com/?interview=3) .

2. Updated To Do List

12 Apr 2003 (3 posts) Archive Link: "Wine 0.9 TODO v0.8"

Topics: Project Management

People: Dimitrie Paun

Dimi posted a revised version of his to do list. A lot of changes were, we now have Green (at 16) losing to a combined Red (14) and Yellow (13) total:

The next version of the 0.9 TODO is way past due (again!), and today is as good as any other day for a brand new release:

ChangeLog

Please note that this version has been in the making for almost 4 month! Lot's of stuff changed, feedback is much appreciated.

The good news is, several of the items marked as to do (Red) are just a shuffling of documentation. Right now one of the biggest blockers is creating an app to configure and manage Wine, commonly referred to as control panel applets.

3. Updated Starcraft Patch

10 Apr 2003 (1 post) Archive Link: "Starcraft Patch"

Topics: Fixes

People: John Spiegel

StarCraft (http://www.blizzard.com/starcraft/) used to be a popular game to play under Wine. Some patches to improve gameplay have been around, but they've languished over the past year or so. John Spiegel announced an update:

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout.

In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions. The changes to mouse.c enable mouse scrolling around the map.

I'm using redhat 9, so the patch also has a change to wineinstall so that the configure is set up for rh9. You'll probably need to drop that if you aren't running rh9.

Now, it would be great to get these changes merged into mainline wine. However, I imagine they break other stuff somewhere. I don't really know exactly what the changes mean, as I've mostly been converting an old patch over. I believe that the patch to input.c is simple and straightforward enough to be merged in, even if the others aren't.

Any comments as to what needs to happen to get these into wine are greatly appreciated.

The complete patch (http://www.winehq.com/hypermail/wine-devel/2003/04/0302.html) can be found in John's email.

4. Making Windres Similar to WRC

18 Mar 2003 - 15 Apr 2003 (10 posts) Archive Link: "windres: -J -I (take 4)"

Topics: Winelib, Build Process

People: Dimitrie Paun

Dimi posted a cc:ed wine-devel last month about something that went hand in hand with some changes he made to the Wine resource compiler:

For the past few month, I've been working on having better interoperability between MinGW, and Wine (http://www.winehq.org). By this I mean the ability to maintain a single build system capable of building apps for either environment. Needless to say, this is a worthy goal, as it allows Windows-only apps to seamlessly build as Linux-native apps. This is a complex problem, but for the purpose of this email I will only focus on windres.

As you probably already know, the Wine project has it's own resource compiler (wrc). For obvious reasons, it is quite desirable to have wrc and windres be command line compatible. To this end, I've modified wrc to the point where we support all but *one* of windres' options: -I.

This option is used in windres to specify the input format, while in wrc it's used to specify include directories. The wrc semantics has a lot on it's side: it is the de-facto standard in the Unix world for specifying include dirs, and it is even compatible with MS's rc. Given the overwhelming inclination to use -I as an include dir specifier, I think it would be better if we could align windres to this standard.

My proposal is simple: rename -I to something else (I suggest -J), and introduce -I as a synonym for --include-dir.

Now, I realize this is a controversial change -- what about backwards compatibility? Luckily, the situation is not as bad as it might seem. Firstly, this option does not seem to be used all that often in practice. Second, the nature of the option allows for a simple scheme. That is, with -I now used for include directories, we can try to match the 3 possible old values (res, rc, coff). If they match, we consider it a input format specifier, issue a deprecation warning, and behave in the old fashion. Otherwise, consider the input an include directory. But what if one want to specify 'res' or 'coff' as an include dir? Well, apart from the fact that this is _very_ unlikely, all they have to do is to prefix those values with '/wine/.': that is ./res or ./coff.

But I guess this is already too much talk and too little action. Here is a patch that implements the above, and updates the documentation.

This week he announced he finally received a necessary copyright assignment notification that will allow his patch to be accepted.

5. Patch Submission and Acceptance Issues

12 Apr 2003 - 14 Apr 2003 (11 posts) Archive Link: "Re: OLE storage SetFilePointer fix"

Topics: Project Management

People: Andreas MohrAlexandre JulliardMike HearnDimitrie PaunCodeWeaversFabian Cenedese

A few months ago (issue #158 (http://www.winehq.com/index.php?issue=158#Patch%20Manager) ) Fabian Cenedese asked whether it was time Wine implemented a patch management system. At the time there were only a few responses and they were mostly against such a system. Keep in mind the number of patches appearing on wine-patches has more than doubled over the past year. That doesn't even take into the account the number of patches sent directly to Alexandre or that he's pulling from CodeWeavers development. For long time Wine developers it doesn't seem like much of a problem because they understand what's likely to be accepted and what's not. Newer developers often get confused when their patches just disappear. Andi Mohr started the latest discussion when he posted a patch and made a comment:

Alexandre, I'd REALLY like you to finally put a patch status tracking system in place. The number of people submitting patches for the second, third, bazillionth time is astonishing (I speak from my very own experience, too!). I really don't know how many very valuable Wine patches got lost due to not getting applied without any status reply whatsoever... (particularly the ones from "foreigners") Someone recently said (in WWN) that patch management was perfect or something to that extent. I better don't comment on that statement, you know my hot temper ;) OK, it's definitely not awful, but I guess it could be better.

Alexandre wasn't against the idea and suggested, " You know, nobody prevents you from implementing a better patch tracking system, and if it makes my life easier I'll be more than happy to use it. Or if you don't want to write code, you could volunteer to manually keep track of all submitted patches and resubmit the lost ones. But of course that's a lot more work than simply complaining about it..."

A lot of patches get dropped with no explanation of why, and Mike Hearn thought that could be handled better:

The main problem as far as I'm concerned isn't so much the lack of a patch "tracker", I'm usually capable of keeping track of whether my patches have been applied or not by watching wine-cvs (though i've found once or twice i've missed the commit), it's more an issue of if a patch is rejected, you have to ask why.

That means I'm often left thinking, is my patch simply in the queue, or is something wrong with it? Or, like my last pkgconfig patch, is there another reason it didn't go in?

Dimi felt rejected patches were usually for obvious reasons and it wasn't much of a problem:

First off, I don't think the current system is bad. Second, I was the one this in the WWN (so sue me :P). Any system that we would put in place would have to work with email just like the current one. Other suck big time, see the SF one. Once you notice that, you realize that the problem is not the system, but rather that Alexandre needs to reply to patches he rejects, wether through email/web based form/what have you.

Don't get me wrong -- I've been multiple times at the rejecting end of this, and it's frustrating. But in retrospective, it's all for a better Wine, and I'd be hard pressed to produce a patch which got rejected by Alexandre, and which I still think should be applied.

Also, your assesment that 'very many valuable Wine patches got lost' is a gross exageration. In fact, please produce 3 such patches that got lost in the last year (heck, in the last 3 years for that matter). I think you'll have a hard time finding a single such patch in the last X years (choose X as you may) that match your description.

There is good reason for this: people put work into their patches, and if they don't get apply, they ask why. This is where I don't understand Alexandre: he will eventually have to reply to such questions, why not do it proactively, it's the same amount of work, me thinks. But I'm not the one putting in the time and effort to sort through the patches, so I may be missing many things.

Alexandre then explained the patch process he goes through and offered some insight on how to get patches in:

There are multiple factors here, I'll try to explain the process a bit more:

First, if a patch is obviously wrong, I send a reply right away; if it's obviously correct I apply it right away. But some patches are in between; they need some more thought or investigations to determine if they are OK or not. So in that case I put them aside and move on to the next patch; the idea is to provide quick turn around on the obvious patches. And hopefully it encourages people to submit easier patches, or provide better explanations...

Then when I'm through with the obvious things I come back to the pending patches; and when doing that I give a higher priority to the more recent patches. The idea is that older patches are more likely to no longer apply, or to have been superseded by a more recent one, or to have had someone else comment on them. Again the idea is to spend time first on things that are more likely to be applied. The result here is that after being pending for a week or two, a patch becomes very low in priority; this is where I expect the submitter to look into the issue, make sure that their patch is still relevant, and if it is, to resubmit to put it back at the top of the list.

Yet another factor is that I don't always bother to send an explanation if I think someone will be able to figure out for themselves why their patch was rejected. This can be because they are an experienced developer, or because they started the mail with "I know this is an ugly hack", or because of some obvious problem like not in diff -u format. In such cases, if people can't figure it out they should ask and then I will gladly provide the explanation; but if they can figure it out by themselves then I've saved the time that it would have taken to write the explanation.

And of course sometimes I hit 'd' on the wrong line and a patch disappears without a trace...

The real problem I think is that there is no external way to determine the pending/rejected/dropped status of a patch, and I understand this can be frustrating. This is where a tracking system could help; but IMO it will be quite a bit of work to implement something transparent enough that I don't have to spend more time on each patch that I do now.

In a different thread Alexandre gave some tips for resubmitting other people's patches:

If you really want to do manual patch tracking, the right way is *not* to post URLs to wine-devel. What you can do if people don't resubmit their patches in a reasonable time frame is to do it for them, regenerating the patch against latest CVS, and of course making sure to preserve all the information from the original mail.

One thing no one is complaining about is only Alexandre making CVS commits. Everyone seems to trust his judgement and the detail he puts into it. But the arguments sound similar to ones a few years ago about "Linus doesn't scale" and led the Linux kernel team to adopt BitKeeper. For details on that discussion see Kernel Traffic issues #147 (http://kt.zork.net/kernel-traffic/kt20011224_147.html#4) , #149 (http://kt.zork.net/kernel-traffic/kt20020107_149.html#2) , and #153 (http://kt.zork.net/kernel-traffic/kt20020211_153.html#9) .

6. What It Would Take To Just Link With -lwine

4 Apr 2003 - 15 Apr 2003 (44 posts) Archive Link: "Re: Support for pkgconfig"

Topics: Winelib

People: Alexandre JulliardDimitre PaunMike Hearn

We sort of covered this a few weeks ago (issue #164 (http://www.winehq.com/index.php?issue=164#How%20to%20Just%20Access%20a%20Windows%20DLL) ). This week Alexandre remarked to a patch and said, " You can't use wine by simply adding -lwine anyway" . Dimi wondered if it would ever be possible. After all the current situation is rather tough for some folks to figure out and they expect to just link against Winelib and have it work. Somehow all the features of a Windows PE-style shared library have to be made available to be linked against. Alexandre mentioned that the cleanest solution might be to do it at the linker/ld.so layer. Dimi thought another way to do it would be to just export stuff into a ELF .so library. But Alexandre pointed out some problems with that:

you'll need to redo the resource functions to deal with that. Other problems include at least ordinal exports, separate dll namespaces, and initialization order. Then of course you have all the binary compatibility problems with module handles that don't point to the right structures etc.

If you really want to provide a seamless Unix source environment, you pretty much need to give up on full binary compatibility, and do something more like what TWIN was doing. But I don't think that's where we want to go.

Dimi thought about it and wrote:

Of course, the ultimate goal would be to be able to use Wine by doing -lwine. Now, an intermediate step toward this goal would be to allow the program to remain a Unix app (rather than a Winelib app), and require a more complex linking process. Which is fairly close to what winebuild is doing currently.

So what's bothering me? I guess asking people to transform their apps to a Winelib app if they want to use Winelib.

For CUI apps, there is no difference between the current winebuild process, and what I'm proposing (a Unix app with a non-standard link). I think (please correct me if I'm wrong).

However, for GUI apps, people need to provide the WinMain entry point instead of main. Maybe we can export some sort of init function, so that they can keep their main(), and simply call a wine_init(). Doing so, we maintain the appearance of a Unix app. Of course, the limitation would be that no Wine-related funtionality can be called before the wine_init() call. So no more static C++ initializers, etc. Would this be doable?

Alexandre remarked, " The only real problem is that Winelib apps are shared libraries and not executables; but this could probably be fixed with a good amount of linker magic. The rest is just a matter of wrapping the winebuild incantations into an easier to use front end, which is basically what you started doing with winewrap."

Then he added, " I think this should wait for dll separation. It will be a lot easier to play with the linking process once all dlls get linked the same way."

Mike Hearn thought a lot of things could benefit by just exporting LoadLibrary and GetProcAddress. Codecs have few entry points and could just be quickly loaded. Alexandre didn't like that idea:

for the common case of things like codecs, you don't want to drag Wine into it. Even if the dll is calling a bunch of API functions, you want to stub these to do whatever makes sense for your app; you don't want to have to provide a config file, DOS drives, registry files, the wineserver, the X11 driver, etc. etc.

If the dll does require a lot of Windows features then yes you should use Wine, but then I think it's reasonable to build a Winelib app. Even if we somehow change the linking process so that you can simply add -lwine, you will still end up with a Winelib app, and have to deal with everything this implies. And frankly at that point the exact command line you have to use to link is a minor detail.

The problem with saying that one should be able to use Wine simply by adding -lwine is that "use Wine" means something different for each case. And what people really want is that -lwine should allow them to use the APIs their specific case needs, and not bother them with any other part of Wine; so there's simply no way to offer a general solution for that.

From there the discussion delved off into just how much integration was necessary for Wine. Dimi felt creating an entire desktop environment around Wine was not only feasible, but could end up being better than the current favorites (GNOME and KDE). Of course one advantage is how widely known the Win32 API is. In some ways its more mature than both Qt and Gtk. Dimi also felt the license lent itself well towards development. Alexandre didn't like the idea at all:

I strongly disagree. The Win32 API may not be so bad in the abstract (though I'd dispute that too), but it's a very poor choice for a Unix toolkit. It exposes way too many low-level details that don't have an equivalent on Unix. If you want a cross platform toolkit you should use a higher level one that abstracts a lot more of the platform details; and if you don't care about other platforms then you should use a Unix native toolkit. I don't think we would be doing anybody a favor by encouraging the use of Wine for new Linux developments.

and later:

Apart from the obvious technical problems with that, and the overall ugliness of the result, the major drawback is that you are essentially putting Microsoft in control of the direction of the Unix desktop.

The Windows API is not something we have freedom to change, and that is a very problematic restriction. Even if most desktop environments today are quite similar to Windows, I hope we can move beyond that someday, and leave Microsoft in the dust. This can't happen if we let them define the core APIs.

So will we see this after DLL separation? I guess that implies we'll see the end of DLL separation.. (hey, we're gettin' closer!) This is definitely more of a long term goal though.

 

 

 

 

 

 

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.