WWN: wn20031017_192.xml

Brian Vincent vinn at theshell.com
Fri Oct 17 10:01:26 CDT 2003



-------------- next part --------------
<?xml version="1.0" ?>

<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&#233;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&#252;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" />

	title="News: Wine-20031016, TransGaming Updates" 
<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&amp;content-type=text/x-cvsweb-markup">ChangeLog</a>
 for details)
       <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>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>

	title="Support For XRandR" 
	subject="configure check for Xrandr extension"
<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?

<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?
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

<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>Dimi thought using Xrandr could be made more transparent to the
<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?

<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.
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>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:
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
     <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.
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?

	title="Integrating Start Menu Shortcuts" 
	subject="Wine Start menu"
<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.
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?

<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 
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 &amp; 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>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.
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 

<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:
<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.
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.

	title="Privileged Instructions Removed, Apps Broken" 
	subject="Breakage in 'priviledged instructions' handling."
<p>Lionel Ulmer found some recent CVS commits broke some programs:</p>
<quote who="Lionel Ulmer">
Some games that worked pretty well in Wine (like, for example, Tomb Raider
3) are now failing with latest CVS due to :
Unhandled exception: privileged instruction in 32-bit code (0x0048e2e1).
So I was wondering what changed in the Wine code that suppressed the
emulation of these instructions.

<p>Alexandre recognized the problem:</p>
<quote who="Alexandre Julliard"><p>
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?

<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>

	title="Detecting NPTL At Runtime" 
	subject="Run-time NPTL detection"
<p>Vincent Beron did some work to support NPTL-enabled kernels at
<quote who="Vincent Beron"><p>
This is a first patch to let Wine run on either an NPTL enabled or not
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.

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

	title="Setting Up A Backtrace" 
<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
<quote who="Alexandre Julliard">
 Once it is deadlocked, you should attach to the various threads with
 gdb or winedbg and do a backtrace.

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

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

	title="Better OpenSSL Support" 
	subject="openssl-based win32 programs"
<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);
<a href="http://marc.theaimsgroup.com/?l=openssl-users&amp;m=106626702426381&amp;w=2">


More information about the wine-patches mailing list