WWN Issue 201

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 www.winehq.org

This week, 167 posts consumed 547 K. There were 49 different contributors. 35 (71%) posted more than once. 19 (38%) posted last week too.

The top 5 posters of the week were:

19 posts in 46K by Alexandre Julliard
16 posts in 37K by Mike Hearn
10 posts in 32K by Fabian Cenedese
7 posts in 16K by Ivan Leo Murray-Smith
7 posts in 17K by Dimitrie O. Paun

News: Wine-20031212, WineX 3.2.1, TG Update	12/13/2003	Archive
News 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) Initial implementation of XDND drag&drop support. Improved startup performance on remote displays. Major improvements in the oleaut32 dll. Some support for Netbios functions. Work around for Exec Shield and prelinking troubles. Many code cleanups. Lots of bug fixes. 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.

News: Wine-20031212, WineX 3.2.1, TG Update

12/13/2003

Archive

News

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)

Initial implementation of XDND drag&drop support.
Improved startup performance on remote displays.
Major improvements in the oleaut32 dll.
Some support for Netbios functions.
Work around for Exec Shield and prelinking troubles.
Many code cleanups.
Lots of bug fixes.

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.

Exec Shield Problems 12/13/2003 Archive

Exec Shield Problems	12/13/2003	Archive
Integration 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. $ /lib/ld-linux.so.2 ./wine-kthread ./wine-kthread: error while loading shared libraries: ./wine-kthread: cannot map zero-fill pages: Cannot allocate memory $ So ld.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 `echo -n 1 >/proc/sys/vm/overcommit_memory` 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?

Integration

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.

$ /lib/ld-linux.so.2 ./wine-kthread ./wine-kthread: error while loading shared libraries: ./wine-kthread: cannot map zero-fill pages: Cannot allocate memory $

So ld.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

echo -n 1 >/proc/sys/vm/overcommit_memory

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?

Delayed Debug Tracing 12/13/2003 Archive

Delayed Debug Tracing	12/13/2003	Archive
Debugging 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: `(wine <arguments> & read ans; echo '===') 2>&1 \| awk '{if( $1 == "===") flag=1-flag; if(flag) print}' >wine.log` 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 wine's 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.

Debugging

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:


(wine <arguments> & read ans; echo '===') 2>&1 |
awk '{if( $1 == "===") flag=1-flag; if(flag) print}' >wine.log

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 wine's 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.

Printing With No Printer 12/14/2003 Archive

Printing With No Printer	12/14/2003	Archive
Configuration 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', 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: `[ppd] "generic" = "/usr/lib/wine/ppd/generic.ppd"`

Configuration

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', 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:


[ppd]

"generic" = "/usr/lib/wine/ppd/generic.ppd"

Alexandre on Vacation	12/15/2003	Archive
Project Management 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...

Status Update Preview	12/16/2003	Archive
Status Updates 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 DLLs Status Page. I've 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 to do for completeness. Proof Read! (against all my notes) Doc links, (Thursday night Friday AM) Send to Brian V for WWN coverage :) (Brian if you want you can get an early start) Add/Remove todo's changelog update Give everyone a chance to respond.. Friday? ;) diff -u & send :) Tom's email contains the complete status update.

Status Update Preview

12/16/2003

World Wine News