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 #188 For 19 Sep 2003

By Brian Vincent

Table Of Contents


This is the 188th issue of the Wine Weekly News publication. Its main goal is to wander aimlessly on four wheel drive roads. 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 186 posts in 815K.

There were 55 different contributors. 27 posted more than once. 26 posted last week too.

The top posters of the week were:

1. News: TransGaming Point2Play Update

13 Sep 2003 - 19 Sep 2003 (1 post) Archive Link: "News"

Topics: News

People: TransGamingNews

TransGaming updated their Point2Play utility. Version 1.1.1 is considered " a maintenance release that provides a number of incremental refinements and fixes some reported issues"

See the release notes for more details.

2. Winecfg Status & Preferences

16 Sep 2003 - 18 Sep 2003 (11 posts) Archive Link: "Configuration parameters"

Topics: Status Updates

People: Mike HearnDimitrie PaunMax

Mike Hearn has done a lot of improvements to Winecfg lately and took a moment to write a list of things that remain to be done. Any one of these would be a great way to get involved with Wine. (ed note: This originally appeared as a patch):

TODO: (in rough order of priority)

Dimi Paun dropped an email the next day with a list of preferences in the current config file that needed to be reorganized. Some of the settings are too obscure to justify putting in a GUI config. With the improved registry editor it will be possible to just edit them there (just like those operating systems from Redmond.) Dimi's list:

Column Values
Name The name of the property/section
Needed Describes the form the parameter in needed in:
no The setting should be removed
ac Changeable at configure time only
regedt Configurable through regedit only
cfg Configurable through winecfg
Dynamic Indicates if Wine should react to changes in the value of the parameter ar runtime
PerApp Describes if the configuration parameter need to be customizable on a per-application basis
Default value The default value for the property. This should allow Wine to run winecfg without user intervention

Name Needed Dynamic PerApp Default value
[Drive X]
Path cfg yes no
Type cfg yes no
Label cfg yes no
Serial cfg yes no
Filesystem cfg yes no
Device cfg yes no
Windows cfg no no c:\\windows
System cfg no no c:\\windows\\system
Temp cfg no no
Path cfg yes no
Profile cfg yes no
GraphicsDriver regedt yes no
ShowDirSymlinks cfg no no true
ShowDotFiles cfg no no true
ShellLinker regedt no no wineshelllink
Windows cfg no yes win98
DOS cfg no yes 6.22
<dllname> cfg no yes
AllocSystemColors regedt no no
PrivateColorMap regedt no no
PerfectGraphics regedt no no
ScreenDepth cfg yes no
Display cfgt no no
Managed no no no
Desktop cfg no yes 640x480
UseDGA regedt no no
UseXVidMode regedt no no
UseTakeFocus cfg yes no yes
DXGrab cfg no no no
DesktopDoubleBuffered cfg no no no
Synchronous regedt no no no
ClientSideWithRender regedt no no yes
ClientSideWithCode regedt no no yes
ClientSideAntiAliasWithRender regedt no no yes
ClientSideAntiAliasWithCode regedt no no yes
Resolution regedt no no <auto>
Default regedt no no <auto>
DefaultFixed regedt no no <auto>
DefaultSerif regedt no no <auto>
DefaultSansSerif regedt no no <auto>
dir<no> regedt no yes <auto>
Com<no> regedt no yes /dev/ttySx
Lpt<no> regedt no yes /dev/lpx
<port> regedt no no /dev/parportX
FILE: regedt no no <auto>
LPT<no>: regedt no no <auto>
read cfg no no 0x779,0x280-0x2a0
write cfg no no 0x779,0x280-0x2a0
RelayExclude regedt no no
RelayInclude regedt no no
RelayFromExclude regedt no no
RelayFromInclude regedt no no
SnoopExclude regedt no no
SpyExclude regedt no no
GlobalRegistryDir ac no no /etc
LoadGlobalRegistryFiles regedt no no true
LoadHomeRegistryFiles regedt no no true
LoadWindowsRegistryFiles regedt no no true
WritetoHomeRegistryFiles regedt no no true
PeriodicSave regedt no no 600
SaveOnlyUpdatedKeys regedt no no true
WineLook cfg yes no Win95
ClearAllSelections regedt yes no false
PersistentSelection regedt yes no true
1 regedt no no /usr/share/ghostscript/fonts
2 regedt no no /usr/share/a2ps/afm
3 regedt no no /usr/share/enscript
4 regedt no no /usr/X11R6/lib/X11/fonts/Type1
Drivers regedt no no <auto>
WaveMapper regedt no no msacm.drv
MidiMapper regedt no no midimap.drv
UseDnsComputerName regedt no no true
HELmargin regedt no no 5
HELqueue regedt no no 5
SndQueueMax regedt no no 28
SndQueueMin regedt no no 12
HardwareAcceleration cfg no no true
DefaultPlayback cfg no no 0
DefaultCapture cfg no no 0
EmulDriver cfg no yes true

There was a bit of discussion on the details of some of those options. Everyone seemed to agree on most of them.

3. System Tray Support

15 Sep 2003 - 16 Sep 2003 (11 posts) Archive Link: "Re: resend - system tray support"

Topics: Integration

People: Mike HearnAlexandre JulliardDmitry TimoshkovSylvain PetreolleMicrosoftRolf Kalbermatter

Mike Hearn reposted a patch to add XEmbed system tray support, " I'm going to keep sending this flipping patch until it gets in, or I find out what the next problem is you know. There's no escape! :)"

Alexandre duly replied with things he didn't like, " Well, at least the critical section handling is broken, but the real problem is that all this stuff doesn't belong in shell32. We should really redesign it to get rid of the internal WS_EX_TRAYWINDOW flag and have a separate process to manage the tray window (plus other background tasks like the progman DDE interface, and maybe the desktop window too)."

There was then some debate over those details. Rolf Kalbermatter felt a bunch of it did belong in shell32 because Microsoft seemed to have some interfaces there, including DDE. Dmitry Timoshkov looked into and reported, " After looking again at the shell32 from win2k SP4 I've found that it really has the strings used by the progman DDE interface. The reason why I didn't find the first time is that strings are spread over the code section. So, yes, it seems that at least the progman DDE interface handler is residing in shell32. Now the question is: how we should implement it? Just add a necessary atom "progman" and create a hidden window on dll load event, or wait for some apparently undocumented API call and initialize only then? "

Dmitry's questions went unanswered. Before the thread ended Sylvain Petreolle mentioned he had applied the patch and reported success with Yahoo Messenger.

4. Blank Screen of Death

18 Sep 2003 (6 posts) Archive Link: "Starting wine turns off my screen"

Topics: Fixes

People: Philipp WollermannRoderick ColenbranderSylvain Petreolle

Philipp Wollermann ran into a problem with the following symptoms:

I recently installed Mandrake 9.1 and updated it to the newest packages .. I'm using the ATI fglrx 3.2.5 driver for XFree 4.3.0 (I have a Hercules Radeon 9700) and playing 3D games like tuxracer works great. However, when I try to start any program with wine my screen gets dark and goes into standby. This happens even with Notepad or the programs included with Wine! This problem didn't happen on my earlier installations of Linux, but I can't say if it's the driver of my graphics card (maybe I should try an older version? mmh.), my Mandrake 9.1 or wine itself (I'm using the current version from CVS, just updated). Maybe somebody had this problem too and knows how to get wine running again?

The funny thing is: My PC keeps running, I can connect to it using SSH and kill wine, but this doesn't do anything about my screen. I can even start wine again (wine notepad.exe) and it gives me the usual output, no Errors or Warnings.

Sylvain Petreolle asked what version of Wine he was running. Philipp reported it was the latest CVS. Roderick Colenbrander jumped in an diagnosed the problem, " The problem you have is a bug in the dga code of the ati drivers. To workaround the problem set the option UseDGA to N in your config file. The strange part is that dga only works for root users and that this problem also appears for non-root users. "

Phillip changed the option and reported success.

5. Finding Memory Management Problems

17 Sep 2003 - 18 Sep 2003 (4 posts) Archive Link: "Bug in the heap management code?"

Topics: Memory Management

People: Michael GunnewigMike HearnShachar ShemeshEric Pouech

Michael Günnewig needed help figuring out what a game was trying to do and why it broke Wine:

When I try to play "The Elder Scroll III: Tribunal" version 1.4.1313 german under wine I get a page fault after some time. The time span differs and so the calling point of the heap management but it always occurs in HEAP_CreateFreeBlock in line 415.

Generating of a full "-debugmsg +heap" log is nearly impossible because it takes too long to start the game and start playing (after > 200 min. it still wasn't finished with initializing).

Mike Hearn offered his condolences, " This is very much like a problem I am having with InstallShield. Something, somewhere, is trashing the heap data structures, which causes a crash some time later, often yards away from the original bug. As far as I know, there is no good way to spot this problem, it's just C/C++ sucking.... maybe valgrind might help? "

Shachar Shemesh had an idea how memory use could be tracked but it involved Changing the way Wine allocates memory :

Something else that might help is an algorithm I suggested a long time ago, and which was not thought as worth the effort. Since I have not tried to run Wine with valgrind yet, I don't know whether it is or isn't.

The gist of it is that you pad each and every alloc with more memory, and you fill it in with signatures. When you release the memory, you check that the signatures are ok. Tweaking the amount of extra memory can cause you to not corrupt the heap structure at some point, which will allow you reliable pin-pointing the buffer in which the overflow occures.

I have never worked with valgrind (though I love the principle behind it), so I can't say whether it is more effective at this sort of problems. My method, in any case, is not very difficult to implement, so if valgrind does not provide what you need, I may invest the time in it.

Eric Pouech didn't think it would work in a lot of cases and also suggested Valgrind:

The issue with this approach is that you only trigger the check when releasing the block. It might well happen that the crash takes place before you free the memory. IMO, this is well suited to situations where either you have, from time to time, synchronisation points (you check the heap situation) or you check a memory block before using it (think of overloading operator-> in C++).

In this case it would help if:

tricky but doable.

IMO, running valgrind will allow you actually stop on the faulty write operation. valgrind is worth a try.

6. Library Loading Problem

12 Sep 2003 - 14 Sep 2003 (8 posts) Archive Link: "load library problem"

Topics: Winelib

People: Dimitrie PaunEric PouechAlexandre JulliardVincent Beron

Dimi had a problem loading a library:

I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples):

The piece of code that fails is from the automatically generated wrapper[1]. Here is the part that fails:

I have the WINEDLLPATH set, what gives? Alexandre, I can't really track this easily back, but I have a gut feeling it got triggered by one of the reorganizations that you did around the loader...

Vincent Beron suggested changing WINEDLLPATH to include the current working directory. It didn't help. Eric Pouech then posted a small patch to winewrapper, but Dimi reported he wasn't using it. Then Eric suggested, " Another issue could be the (.so) dependencies on which cannot be resolved."

Dimi posted how it was linked:

Hmm, that would be very odd. Do you see any problem with these:

It seems to me has the same dependencies as (in a bit different order, does it matter?)

It appeared some private exchange took place off list, then Eric wrote the list with the solution, " after some more exchanges with Dimi, it turned out that this was caused by a too short buffer in relay32/builtin32.c_at_BUILTIN32_LoadLibraryExA (dllname was way to short). Alexandre, any reason for keeping this at 20 chars ? "

Alexandre committed a change and explained, " No, there's no reason, that's a leftover from the Win16 version. It should probably be MAX_PATH or something like that. "







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.