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 #201 For 19 Dec 2003

By Brian Vincent

Table Of Contents


This is the 201st issue of the Wine Weekly News publication. Its main goal is to not get the Maguai wet. 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 167 posts in 547K.

There were 49 different contributors. 35 posted more than once. 19 posted last week too.

The top posters of the week were:

1. News: Wine-20031212, WineX 3.2.1, TG Update

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

Topics: News

People: Alexandre JulliardTransgamingNewsTransGaming

Just after last week's issue came out, Alexandre tagged Wine-20031212. He noted the following changes:

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

Go download it.

TransGaming's WineX received a minor version update. WineX 3.2.1 was released on Wednesday. Additions include some game-specific fixes and web pages launched in a game should actually launch now. See their release notes for more detail.

TransGaming also came out with their December Development and Voting Report. They describe some of their work on pixel and vertex shaders. An investigation into ALSA turned up interesting results:

ALSA, of particular interest to TransGaming's Linux audience, does not provide much of an added benefit over OSS. The primary speed advantage, hardware mixing, a slower kludgy implementation use due to the fact that looping sound doesn't appear to be supported; although full duplex support should be easier to provide than with OSS. The major drawback of ALSA is that its mmap interface is not compatible with what is required for DirectSound unless undocumented interfaces are used. All in all it appears that using ALSA would provide some speed advantages for newer cards, but to be done properly would require a rewrite of the winealsa driver. Thus we would suggest that, for the time being, people continue to use the OSS emulation layer of ALSA with "MMap" = "Y" enabled in their config file to get the best performance if it's supported on their sound card.

2. Exec Shield Problems

13 Dec 2003 - 14 Dec 2003 (7 posts) Archive Link: "Allocating too much memory for prelink workaround"

Topics: Integration

People: Alexandre JulliardMarcus MeissnerVincent BeronMike HearnFabian Cenedese

Last month I covered a problem with exec shield's interactions with Wine (see issue #196 for details). I didn't cover the solution, or the ramifications of it. About a week after that issue came out Alexandre committed a patch to CVS with the following comment:

Create a huge array in bss to reserve the memory area we need for PE binaries, to prevent exec shield from mapping system libraries there.

By huge array, he meant a 256MB one. Marcus Meissner reported the first problem about 3 days after the change appeared:

On SuSE 8.2, i586 glibc, loader/wine-* crash due to the 256 MB static array in main().

The test machine has just 64MB RAM and 200MB swap.

If I start decreasing the array it works, up to 201MB.

So really wants to get 20xMB memory but fails.

Alexandre thought that the memory should just be overcommitted, and since it's not really used it wouldn't cause an issue. Apparently SuSE protects against that though. Marcus explained how to get around it:

SuSE 8.2 has a "overcommit" sysctl, which is default off. In this case at least the SuSE kernel uses a heuristic on left over memory to chek mmap()s. And it limits it at this amount of memory apparently. If I do

it works again.

A few weeks later Fabian Cenedese reported a mysterious problem where Wine just segfaulted. He tracked the problem down to the series of CVS commit on the day of the exec shield workaround. Vincent Beron wondered if there might be another way to essentially achieve the same exec shield workaround but in a little more reliable manner :

Thinking about what Fabian and Marcus hit...

Would it be possible to just have a dummy executable which allocates the 256MB chunk of memory from 11/22, linked to the same libs as the main wine-{k,p}thread, but having that executable not actually used?

That way, we still gain the prelink workaround by reserving the memory, but Wine should continue to work on computers with less memory, or those who do not overcommit memory.

Alexandre didn't think it would work, " I don't see how, if the executable isn't used it won't do any good. What we need is a way to reserve the memory but not the swap space; but I don't think we can do that simply with a bss hack, it will require a linker script which is a major pain. "

Mike Hearn thought working around it was just the wrong solution and the correct solution was elsewhere:

Well, I asked this before but didn't get an answer - why can't we work with Jakub to have some new ELF flag/section to reserve a particular area of memory for the win32 binary?

Hmm, also, what happens if the binary is >256mb? For instance, some very large installers can go beyond that size. How does that work on Windows?

Alexandre vented some frustration:

Of course we can, I was trying to find a way that would work today, without requiring upgrading to CVS binutils.

Also, frankly, I've spent the last year chasing glibc breakages, and I don't particularly feel like spending the next year chasing kernel breakages. I was kind of hoping someone else would pick that fight, so I could go back to writing some real Wine code for a change...

Any kernel/distro people listening?

3. Delayed Debug Tracing

13 Dec 2003 (9 posts) Archive Link: "Delayed debug tracing"

Topics: Debugging

People: Mike HearnRein KlazesAlexandre JulliardGerard PatelRein Klaze

I think someone asked this last year, but there was no good answer at the time. Mike Hearn inquired about adding a feature to Wine's debugging mechanisms:

I'd like to implement delayed debug tracing, by which I mean you can do a +relay,+seh,+tid,+win,+otherstuff and yet not create a log file so huge it's impossible to work with. I seem to recall seeing this feature in WineX, where you can press Alt-F12 to switch it on.

Does anybody who knows the debugging/keyboard code have any particular preferences as to how this should be implemented?

Rein Klazes replied with a really neat solution:

Gerard Patel (if I remember his name correctly) sent in such a patch years ago, which was not committed for obvious reasons.

My way to create a small log goes like this. Start wine like this:

filling the log will only begin after pressing the enter key. Add a while(true), to make it behave as a toggle.

Mike thought building this into Wine might be better, " Certainly using mini shell scripts like that seems to be more of a hack than special casing some Wine code. " Besides being inefficient, Rein then pointed out another problem, " it suffers from certain side effects like having to change focus as well."

Alexandre argued the opposite - that scripting provided more functionality, " a wrapper script is much cleaner than adding some special handling deep in the Wine core. That way you can define the policy you want (switching on a key press, after a delay, after a certain function is called, etc.) instead of having the Wine core impose its own. "

Mike went ahead and submitted a patch to delay debug tracing that was faster than sending it through a script, " The tradeoff that my patch makes is flexibility for performance - if you are redirecting wines output through wrapper programs and scripts then you have the overhead at least of the IPC, and maybe also text parsing. Simply enabling relay gives a huge speed hit even when not logging things, the last thing wanted is even more overhead. "

4. Printing With No Printer

14 Dec 2003 (2 posts) Archive Link: "Printing with no printer"

Topics: Configuration

People: Mike HearnMarcus Meissner

Mike Hearn is working on an app that requires a printer set up in Windows. Not having a printer is causing a bit of a problem, so he asked:

It seems from reading the documentation that it's possible to print to a .ps file in Wine, even if you don't actually have a printer. However, I'm not sure how to do that - I've got far enough to get the "Couldn't find PPD file '/unix/path/to/PPD/file/index.html', expect a crash now!" message, but am not sure where to go from here. I don't have any PPD files, as I have no printer.

Has anybody done this before?

Marcus Meissner provided the recipe:

You copy the generic.ppd file from documentation/samples, and add to .wine/config:

5. Alexandre on Vacation

15 Dec 2003 (2 posts) Archive Link: "Vacation"

Topics: Project Management

People: Alexandre Julliard

Just a heads up - news will probably slow to a trickle. Alexandre is going on vacation:

There won't be any commits for a while, since I'm leaving now for a vacation in Switzerland, where I won't have net access. Assuming I survive the deprivation, I'll be back in two weeks.

I hope you all have nice holidays, and I look forward to finding a few hundred patches in my mailbox when I get back...

6. Status Update Preview

16 Dec 2003 - 17 Dec 2003 (2 posts) Archive Link: "Wine Status Page Pre-1"

Topics: Status Updates

People: Tom Wickline

Tom Wickline finished a draft version of updated Wine DLL status page. He asked everyone to please review it and proofread it:

Here is the current DLL's Status Page. Ive made a number of changes since I last sent these partial pages to the dev-list. Here is a list of things I still need todo for completeness.

  1. Proof Read! (against all my notes)
  2. Doc links, (Thursday night Friday AM)
  3. Send to Brian V for WWN coverage :) (Brian if you want you can get a early start)
  4. Add/Remove todo's
  5. changelog update
  6. Give everyone a chance to respond.. Friday? ;)
  7. diff -u & send
  8. :)

Tom's email contains the complete status update.







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.