Wine Traffic #166 For 18 Apr 2003

• Point2Play graphical frontend is now available to help TransGamers manage multiple WineX versions, store configuration options and stop using arcane command line options and syntax.
• Hardware accelerated Vertex Shaders have been implemented. These are only supported on OpenGL drivers which implement the NV_vertex_program extension. The ARB extension will be supported in future releases.
• Copy protection support for newer, and several older, SafeDisc® versions. Additionally SecuRom copy protection speed has been enhanced for some hardware configurations.
• Many installer-related issues have been resolved; starting installs with autorun.exe should now work in many cases, multi-disc installs should now have fewer issues with disc changing, and large installers are now supported. Additionally, significant effort has gone into making InstallShield 6 graphics update correctly and InstallShield 7 work.
• Render to Texture and Cube Mapping support implemented for cool texturing effects.
• The core threading model has moved to pthreads to decouple WineX from the continuing changes to certain core system libraries.
• Better handling of X11 Window Manager idiosyncrasies - WineX 3.0 does a much better job of going into 'full-screen' mode.
• Many texturing robustness fixes.
• A combination of optimizations should provide faster game play for some games.
• A new ALSA sound driver backend has been provided although it is untested at this point.
• Force feedback joysticks are now supported, but untested, on newer versions of the Linux kernel (2.5 series at this time or get the patch yourself at http://user.it.uu.se/~johannd/projects/ff/). Thanks to David Engle who kindly contributed this functionality. Unfortunately, TransGaming has not had enough time to do extensive testing on this new feature.

The detailed notes for the WineX 3.0 release are available here.

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:

http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html

ChangeLog

• Jer finished the WineHQ redesign (A1)
• Brian completed the screenshot galery (A4)
• Adam is our new Slackware maintainer (A6)
• Andreas updated the User & Development Guide (B1,B3)
• I took on the Packaging Guide and Winelib docu (B2,B4,B8)
• New task: more modular doc building (B12)
• I've updated and integrated Jaco's winecfg into the tree (C2)
• John did more work on the DLL registration (C5)
• Shachar got a working version of wineboot into the tree (C7)
• I finished messing with wrc (D5)
• I got winegcc to a working state (D6)
• Marcus made the printing system detection dynamic (E3)
• Eric improved WinHelp some more (E6)

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.

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.

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.

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.

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?

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.

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.

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.

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.

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?

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.

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.

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.