Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #192 For 17 Oct 2003

By Brian Vincent

Table Of Contents


This is the 192nd issue of the Wine Weekly News publication. Its main goal is to hover gracefully in midair. 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

Mailing List Stats For This Week

We looked at 237 posts in 1233K.

There were 94 different contributors. 34 posted more than once. 34 posted last week too.

The top posters of the week were:

1. News: Wine-20031016, TransGaming Updates

11 Oct 2003 - 17 Oct 2003 (2 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardNewsTransGaming

Alexandre tagged a new version of Wine in CVS this week:

WHAT'S NEW with Wine-20031016: (see ChangeLog for details)

I almost mentioned the Kerne32/NtDLL separation last week but I was hoping someone would start a thread on it. If you've followed WWN issues you'll recognize that as an often mentioned topic. By the time you read this you should be able to download binaries and source from SourceForge.

In other news, TransGaming provided some updates to what they're up to. Next week they'll be discounting items in their store to celebrate their 2nd anniversary. They also detailed plans to set up as a community site for WineX. WineX's CVS repository will move to this new site. Apparently their beta testing program is attracting lots of interest and they announced the first round of applicants has been selected. You may be interested in an update for The Sims or an update for Kohan. Finally, check out October's development update for details of what they're working on.

2. Support For XRandR

15 Oct 2003 - 16 Oct 2003 (12 posts) Archive Link: "configure check for Xrandr extension"

Topics: Graphics, Integration

People: Alex PasadynAlexandre JulliardDimitrie PaunLionel Ulmer

Alex Pasadyn added support for XFree86's Xrandr (Resize and Rotate) extension this week. However, part of his patch added a configure check for Xrender that didn't get committed by Alexandre: " the version that made it into CVS did not include the -lXrender. At least on my system, the check fails without that because the Xrandr library itself calls functions in Xrender. Is there a better way to specify that dependency or was this unintentional? "

Alexandre hadn't realized it was actually needed:

My version of Xrandr doesn't need Xrender so I hoped it wouldn't be needed, guess I was wrong.... what does it need Xrender for?

The problem with the dependency is that currently we deliberately don't link to libXrender but load it dynamically so that it works on all platforms; so I guess we'll need to load libXrandr dynamically too.

Alexandre realized his version of X was older than Alex's and didn't work the same. He added the configure check back in, but told Alex that libXrandr needed to be set up to load dynamically.

Dimi thought using Xrandr could be made more transparent to the user, " once we have the dynamic check, we should drop the UseXRandR config option, and just use it unconditionally. Let's be lazy, and wait until someone comes with a good enough reason to disable it. BTW, any conceivable reasons for someone to disable it? If there is, it should be system wide, not Wine specific I'd think, no? "

Lionel Ulmer wasn't sold on the idea:

Dimi, when you are debugging a game and have your desktop change resolution all the time, trust me, you NEED a way to easily disable it.

So, well, if you do not like the config file option, please AT LEAST put it as a registry key (I would hate to always have to change my Wine tree to disable it in the code itself).

Everyone agreed that a registry key was the way to go. The next day Alex added:

One more thing I noticed about resolution changing:

Sometimes a program running with Wine terminates without cleaning everything up. When XVidMode is used to switch resolutions, the user can use ctrl-alt-plus/minus to restore the resolution.

Those don't work when the resolution was changed with RandR. A user would need to run

to restore it. Since that may be hard for some to remember, is it worth including a trivial Winelib program that does the same thing? ChangeDisplaySettings(NULL, 0); is all it needs to do to restore the default mode.

I have been testing using a simple program that puts up a dialog box listing all the modes and lets you choose them. Is that worth including somewhere/merging with winecfg?

3. Integrating Start Menu Shortcuts

13 Oct 2003 - 16 Oct 2003 (10 posts) Archive Link: "Wine Start menu"

Topics: Integration

People: Robert van HerkGreg TurnerMike McCormackReactOSCodeweavers

We discussed a Wine "Start" menu a bit last week. Robert van Herk followed up this week with some questions:

As some of you might know I am working on a Wine Start menu, for Linux.

I have heard different things on this list about the way Windows treats the start menu.

Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory.

From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory.

So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu?

Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here?

Greg Turner gave his thoughts on it:

my guess is that, eventually, some fancy feature will be lacking unless wine/winelib is brought into the picture, for example, control-panel, "My Computer" or context-sensitive right-click menu-actions, the fancy docking capability of Windows Media Player 9, etc. One thing I do know for sure -- those don't /have/ to be .lnk files in there... they could be .exe's or .mp3's or whatever, and in Windows, "the right thing" would happen....

That is not to say that a rational cost/bene analysis will not ultimately favor a pure-linux implementation, depending on where your code is going.... but my bias would be towards a wine/winelib implementation. Do you forsee this code going into wine or into kde/gnome, or remaining as a separate thing? What relationship would you like between your code and wine's "explorer.exe," once it has one?

Codeweavers has done a lot of work with shortcuts & menuitems, to make them work with different distros... so they might know what some of the nitty-gritty details are (Unfortunately, I do not). You may also want to look at LiteStep, ReactOS's explorer, and other windows shell-replacement software for clues.

Robert wrote back with how he envisioned it working:

Since I want the menu to really integrate into your Linux environment, this would be a Linux executable. I guess than that if I'd want to query Wine for the needed links, that would have to be in a Wine executable. The problem is that this seems a bit of an overkill:

Therefore, I would prefer to write just a number of Linux apps, one for each desktop environment. Maybe some could be merged together.

In the current setup, an abstract menu is kept as a datastructure in which the menu items are stored. So, for the different Linux desktop environments, only the very frontend of the application would have to be rewritten.

After some discussion it seemed Robert didn't require a Winelib app and everything could be self-contained as a regular KDE or GNOME app. Mike McCormack mentioned some things worth looking into:

It's probably easier to just go with the link file reader first, but it will have some limitations:

  1. you won't be able to get stuff in the shell namespace (eg. desktop icons, Control panel stuff)
  2. you'll have to hardcode the location of the start menu (you can change the location of the start menu by playing with registry keys... see SHGetSpecialFolderLocation).
  3. you'll have to duplicate the code to read .lnk files (see dlls/shell32/shelllink.c), and the code to read the icons from .exe files
  4. if you want to support adding other stuff (eg. a .txt file) to the menus, you'll have to read the registry to get the right association, to pull the right icon from an exe.

I guess that's not too much of a problem, and it's probably not worth the effort to make it perfect.

The code that wine Crossover uses to generate KDE/Gnome menus is already merged into Wine. We just have a more extensive wineshelllink script that deals with more corner cases.

4. Privileged Instructions Removed, Apps Broken

11 Oct 2003 - 12 Oct 2003 (6 posts) Archive Link: "Breakage in 'priviledged instructions' handling."

Topics: Fixes

People: Lionel UlmerAlexandre JulliardMike Hearn

Lionel Ulmer found some recent CVS commits broke some programs:

Some games that worked pretty well in Wine (like, for example, Tomb Raider 3) are now failing with latest CVS due to :

So I was wondering what changed in the Wine code that suppressed the emulation of these instructions.

Alexandre recognized the problem:

What changed is that emulation of these instructions was deliberately removed ;-)

This was done for dll separation reasons, and because they are not emulated under NT either (which also means better performance for the exception handling). What happens if you run with Windows version set to NT?

Mike Hearn also reported a broken program. Alexandre decided that eventually the functionality would be added back in, " Sure, we'll need to put it back somehow, there are too many broken 32-bit apps out there. Part of the reason I disabled it was to find out whether we really needed it or not, but I think the answer is clear. But there are still a number of things that need to be changed in the signal handling first, so it will bit some time before we can make it work properly again."

5. Detecting NPTL At Runtime

16 Oct 2003 (2 posts) Archive Link: "Run-time NPTL detection"

Topics: Integration

People: Vincent BeronAlexandre Julliard

Vincent Beron did some work to support NPTL-enabled kernels at runtime:

This is a first patch to let Wine run on either an NPTL enabled or not system.

The remaining issues deal with linking ntdll to libpthread, and autodetection in configure.

It's not production-ready yet, I'm aware that there are a couple rough edges (ie, nptl_check passing from libwine to ntdll, wine_pthread_init_(process,thread)_no_nptl, what really happens if run on a system without NPTL).

It's been tested on RH9 with NPTL.

Alexandre replied, " It won't work on non-NPTL I'm afraid, you need the pthread wrappers right from the start, you can't load them dynamically; this requires using a different wine binary. I'm working on it, but there are still a couple of architectural issues to solve first. "

6. Setting Up A Backtrace

14 Oct 2003 - 16 Oct 2003 (7 posts) Archive Link: "Deadlock?"

Topics: Debugging

People: Alexandre JulliardMike Hearn

Michael Sauer couldn't get Panzer General 3 to run and tracked it down to a Wine bug. He asked for help debugging it and Alexandre suggested, " Once it is deadlocked, you should attach to the various threads with gdb or winedbg and do a backtrace. "

Mike Hearn the detailed what that process would consist of:

I might as well point out (as I didn't find this intuitive when I was learning) that you do that like this:

  1. Open up a new terminal window
  2. Run winedbg
  3. "walk process"
  4. Locate the win32 process id of the program that has deadlocked
  5. "attach X" where X is the pid
  6. "bt 0x9" gives you a backtrace of thread 9
  7. "bt 0x15" gives you a backtrace of thread 15 etc....

Then you can see what path the code took before it hit the locks.

7. Better OpenSSL Support

15 Oct 2003 (1 post) Archive Link: "openssl-based win32 programs"

Topics: Integration

People: Geoff ThorpeEric Pouech

A few weeks ago I reported that OpenSSL was beginnig to be supported. This week Geoff Thorpe provided an update:

I have just sent a post to the openssl list trying to solicit any developers of openssl-based win32 programs to try their programs under Wine. Eric Pouech helped me recently by fixing the one or two glitches in Wine that the openssl libs and utilities were stumbling on, and so openssl seems now to pose no problems for Wine. Anyhow, I just thought I'd post a link to this 'openssl-users' thread in case there's anyone else interested in this (in particular, if you think I've misrepresented anything about Wine or the process of testing win32 applications under it, feedback would be welcome);







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.