wn20031017_192.xml -brian
<?xml version="1.0" ?> <kc> <title>Wine Traffic</title> <author contact="http://www.theshell.com/~vinn";>Brian Vincent</author> <issue num="192" date="10/17/2003" /> <intro> <p>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 <a href="http://www.winehq.com";>www.winehq.com</a></p> </intro> <stats posts="237" size="1233" contrib="94" multiples="34" lastweek="34"> <person posts="23" size="58" who="Alexandre Julliard" /> <person posts="26" size="116" who="Dimitrie O. Paun" /> <person posts="17" size="98" who="Steven Edwards" /> <person posts="13" size="44" who="Ivan Leo Murray-Smith" /> <person posts="9" size="25" who="Alex Pasadyn" /> <person posts="8" size="106" who="Vincent Béron" /> <person posts="7" size="17" who="Mike Hearn" /> <person posts="6" size="13" who="Lionel Ulmer" /> <person posts="5" size="13" who="Jerry Jenkins" /> <person posts="5" size="12" who="Dmitry Timoshkov" /> <person posts="4" size="20" who="Geoff Thorpe" /> <person posts="4" size="16" who="Sylvain Petreolle" /> <person posts="3" size="16" who="Mike McCormack" /> <person posts="3" size="15" who="Michael Sauer" /> <person posts="3" size="10" who="Gregory M. Turner" /> <person posts="3" size="8" who="Vizzini" /> <person posts="3" size="8" who="Jason Filby" /> <person posts="3" size="7" who="Maxime Bellenge" /> <person posts="3" size="7" who="Gerald Pfeifer" /> <person posts="3" size="5" who="BiGgUn" /> <person posts="2" size="156" who="Irvin Rodrigues" /> <person posts="2" size="146" who="Keri Corley" /> <person posts="2" size="15" who="Martin Fuchs" /> <person posts="2" size="8" who="Rein Klazes" /> <person posts="2" size="7" who="Wilfred Mikang" /> <person posts="2" size="6" who="Robert van Herk" /> <person posts="2" size="5" who="Jukka Heinonen" /> <person posts="2" size="5" who="Patrik Stridvall" /> <person posts="2" size="5" who="Troy Rollo" /> <person posts="2" size="4" who="Jeremy White" /> <person posts="2" size="4" who="Daniel Marmier" /> <person posts="2" size="4" who="Gerhard W. Gruber" /> <person posts="2" size="3" who="Jon Griffiths" /> <person posts="1" size="13" who="Subhobroto Sinha" /> <person posts="1" size="9" who="Ediciones" /> <person posts="1" size="7" who="Vera Cole" /> <person posts="1" size="5" who="Ines Villarreal" /> <person posts="1" size="4" who="Michael Günnewig" /> <person posts="1" size="4" who="Teddy E. Livingston" /> <person posts="1" size="4" who="Robert Reif" /> <person posts="1" size="4" who="Pat Wiseman" /> <person posts="1" size="4" who="Vilma Putnam" /> <person posts="1" size="4" who="(Dave_Belanger)" /> <person posts="1" size="4" who="Steve" /> <person posts="1" size="4" who="Business Office Online" /> <person posts="1" size="4" who="Maia" /> <person posts="1" size="3" who="Quinn Odonnell" /> <person posts="1" size="3" who="Pete Douglas" /> <person posts="1" size="3" who="Rolf Kalbermatter" /> <person posts="1" size="3" who="Ruth Maddox" /> <person posts="1" size="3" who="Marcus Meissner" /> <person posts="1" size="3" who="Jeremy Newman" /> <person posts="1" size="3" who="Gerald Pfeifer" /> <person posts="1" size="3" who="Cary Ibarra" /> <person posts="1" size="3" who="Dawn Bouchard" /> <person posts="1" size="2" who="Dave Wickham" /> <person posts="1" size="2" who="Jerry Jenkins" /> <person posts="1" size="2" who="Fredrick Townsend" /> <person posts="1" size="2" who="Uwe Bonnes" /> <person posts="1" size="2" who="Tom" /> <person posts="1" size="2" who="Chris Hansen" /> <person posts="1" size="2" who="Cory" /> <person posts="1" size="2" who="Kevin Koltzau" /> <person posts="1" size="2" who="Tamera Rodriquez" /> <person posts="1" size="2" who="Francois Gouget" /> <person posts="1" size="2" who="Jakob Eriksson" /> <person posts="1" size="2" who="Jonathan Wilson" /> <person posts="1" size="2" who="Cole Harding" /> <person posts="1" size="2" who="Connie Conway" /> <person posts="1" size="2" who="Warren Baird" /> <person posts="1" size="1" who="Wolfgang Draxinger" /> <person posts="1" size="1" who="Eric Kohl" /> <person posts="1" size="1" who="Fabian Cenedese" /> <person posts="1" size="1" who="Dan Kegel" /> <person posts="1" size="1" who="Omar Meadows" /> <person posts="1" size="1" who="Paul Rupe" /> <person posts="1" size="1" who="Kevin DeKorte" /> <person posts="1" size="1" who="Johnie Sheehan" /> <person posts="1" size="1" who="Shawn Holman" /> <person posts="1" size="1" who="Jordan Robinson" /> <person posts="1" size="1" who="Martin Troester" /> <person posts="1" size="1" who="Duane Clark" /> </stats> <section title="News: Wine-20031016, TransGaming Updates" subject="News" archive="http://sourceforge.net/project/showfiles.php?group_id=6241"; posts="2" startdate="10/11/2003" enddate="10/17/2003" > <topic>News</topic> <p>Alexandre tagged a new version of Wine in CVS this week:</p> <quote who="Alexandre Julliard"><p> WHAT'S NEW with Wine-20031016: (see <a href="http://cvs.winehq.com/cvsweb/wine/ChangeLog?rev=1.76&content-type=text/x-cvsweb-markup";>ChangeLog</a> for details) <ul> <li> Support for the Xrandr extension.</li> <li> Dll separation of kernel and ntdll is finished.</li> <li> Many enhanced metafile improvements.</li> <li> Lots of bug fixes.</li></ul> </p></quote> <p>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 <a href="http://sourceforge.net/project/showfiles.php?group_id=6241";>to download</a> binaries and source from SourceForge.</p> <p>In other news, TransGaming provided some updates to what they're up to. Next week they'll be <a href="http://www.transgaming.com/showthread.php?news=86";>discounting items</a> in their store to celebrate their 2nd anniversary. They also detailed plans to <a href="http://www.transgaming.com/showthread.php?news=85";>set up TransGaming.org</a> 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 <a href="http://www.transgaming.com/showthread.php?news=81";>the first round</a> of applicants has been selected. You may be interested in <a href="http://www.transgaming.com/showthread.php?news=82";>an update for The Sims</a> or <a href="http://www.transgaming.com/showthread.php?news=83";>an update for Kohan</a>. Finally, check out <a href="http://www.transgaming.com/showthread.php?news=84";>October's development update</a> for details of what they're working on.</p> </section><section title="Support For XRandR" subject="configure check for Xrandr extension" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0491.html"; posts="12" startdate="10/15/2003" enddate="10/16/2003" > <topic>Graphics</topic> <topic>Integration</topic> <p>Alex Pasadyn added support for XFree86's <a href="http://www.xfree86.org/current/Xrandr.3.html";>Xrandr</a> (Resize and Rotate) extension this week. However, part of his patch added a configure check for Xrender that didn't get committed by Alexandre: <quote who="Alex Pasadyn"> 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? </quote></p> <p>Alexandre hadn't realized it was actually needed:</p> <quote who="Alexandre Julliard"><p> 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? </p><p> 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. </p></quote> <p>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. </p> <p>Dimi thought using Xrandr could be made more transparent to the user, <quote who="Dimitrie Paun"> 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? </quote></p> <p>Lionel Ulmer wasn't sold on the idea:</p> <quote who="Lionel Ulmer"><p> 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. </p><p> 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). </p></quote> <p>Everyone agreed that a registry key was the way to go. The next day Alex added:</p> <quote who="Alex Pasadyn"><p> One more thing I noticed about resolution changing: </p><p> 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. </p><p> Those don't work when the resolution was changed with RandR. A user would need to run <ul> <tt>xrandr -s 0</tt></ul></p><p> 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. </p><p> 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? </p></quote> </section><section title="Integrating Start Menu Shortcuts" subject="Wine Start menu" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0431.html"; posts="10" startdate="10/13/2003" enddate="10/16/2003" > <topic>Integration</topic> <p>We discussed a Wine "Start" menu a bit last week. Robert van Herk followed up this week with some questions:</p> <quote who="Robert van Herk"><p> As some of you might know I am working on a Wine Start menu, for Linux. </p><p> I have heard different things on this list about the way Windows treats the start menu. </p><p> 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. </p><p> From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory. </p><p> 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? </p><p> 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? </p></quote> <p>Greg Turner gave his thoughts on it:</p> <quote who="Greg Turner"><p> 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.... </p><p> 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? </p><p> 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. </p></quote> <p>Robert wrote back with how he envisioned it working:</p> <quote who="Robert van Herk"><p> 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: <ul><li>I'd have to write a communcation protocoll between the Wine app and Linux app</li> <li> A wine process would always be running, just for serving the menu. Killing your wineserver (what I personally like to do often :-)) would kill the start menu server too... It would take some fancy programming to get it back up again without the user noticing it (i.e. without some horrible crashing of the Linux client ;-))</li></ul></p><p> Therefore, I would prefer to write just a number of Linux apps, one for each desktop environment. Maybe some could be merged together. </p><p> 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. </p></quote> <p>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:</p> <quote who="Mike McCormack"><p> It's probably easier to just go with the link file reader first, but it will have some limitations: <ol> <li> you won't be able to get stuff in the shell namespace (eg. desktop icons, Control panel stuff)</li> <li> 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).</li> <li> 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</li> <li> 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.</li></ol></p><p> I guess that's not too much of a problem, and it's probably not worth the effort to make it perfect. </p><p> 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. </p></quote> </section><section title="Privileged Instructions Removed, Apps Broken" subject="Breakage in 'priviledged instructions' handling." archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0372.html"; posts="6" startdate="10/11/2003" enddate="10/12/2003" > <topic>Fixes</topic> <p>Lionel Ulmer found some recent CVS commits broke some programs:</p> <quote who="Lionel Ulmer"> <p> Some games that worked pretty well in Wine (like, for example, Tomb Raider 3) are now failing with latest CVS due to : <ul><tt> Unhandled exception: privileged instruction in 32-bit code (0x0048e2e1). </tt></ul></p><p> So I was wondering what changed in the Wine code that suppressed the emulation of these instructions. </p></quote> <p>Alexandre recognized the problem:</p> <quote who="Alexandre Julliard"><p> What changed is that emulation of these instructions was deliberately removed ;-) </p><p> 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? </p></quote> <p>Mike Hearn also reported a broken program. Alexandre decided that eventually the functionality would be added back in, <quote who="Alexandre Julliard"> 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.</quote></p> </section><section title="Detecting NPTL At Runtime" subject="Run-time NPTL detection" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0514.html"; posts="2" startdate="10/16/2003" > <topic>Integration</topic> <p>Vincent Beron did some work to support NPTL-enabled kernels at runtime:</p> <quote who="Vincent Beron"><p> This is a first patch to let Wine run on either an NPTL enabled or not system. </p><p> The remaining issues deal with linking ntdll to libpthread, and autodetection in configure. </p><p> 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). </p><p> It's been tested on RH9 with NPTL. </p></quote> <p>Alexandre replied, <quote who="Alexandre Julliard"> 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. </quote></p> </section><section title="Setting Up A Backtrace" subject="Deadlock?" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0461.html"; posts="7" startdate="10/14/2003" enddate="10/16/2003" > <topic>Debugging</topic> <p>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, <quote who="Alexandre Julliard"> Once it is deadlocked, you should attach to the various threads with gdb or winedbg and do a backtrace. </quote></p> <p>Mike Hearn the detailed what that process would consist of:</p> <quote who="Mike Hearn"><p> I might as well point out (as I didn't find this intuitive when I was learning) that you do that like this: <ol> <li> Open up a new terminal window</li> <li> Run winedbg</li> <li> "walk process"</li> <li> Locate the win32 process id of the program that has deadlocked</li> <li> "<tt>attach X</tt>" where X is the pid</li> <li> "<tt>bt 0x9</tt>" gives you a backtrace of thread 9</li> <li> "<tt>bt 0x15</tt>" gives you a backtrace of thread 15 etc....</li> </ol></p><p> Then you can see what path the code took before it hit the locks. </p></quote> </section><section title="Better OpenSSL Support" subject="openssl-based win32 programs" archive="http://www.winehq.com/hypermail/wine-devel/2003/10/0492.html"; posts="1" startdate="10/15/2003" > <topic>Integration</topic> <p>A few weeks ago I reported that OpenSSL was beginnig to be supported. This week Geoff Thorpe provided an update:</p> <quote who="Geoff Thorpe"><p> 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); </p><p> <a href="http://marc.theaimsgroup.com/?l=openssl-users&m=106626702426381&w=2";> http://marc.theaimsgroup.com/?l=openssl-users&m=106626702426381&w=2</a> </p></quote> </section></kc>
