WWN: wn20030912_187.xml
Brian Vincent
vinn at theshell.com
Fri Sep 12 01:23:32 CDT 2003
wn20030912_187.xml
-brian
-------------- next part --------------
<?xml version="1.0" ?>
<kc>
<title>Wine Traffic</title>
<author contact="http://www.theshell.com/~vinn">Brian Vincent</author>
<issue num="187" date="09/12/2003" />
<intro> <p>This is the 187th issue of the Wine Weekly News publication.
Its main goal is to watch the snow fly. 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="375" size="1108" contrib="73" multiples="51" lastweek="26">
<person posts="59" size="156" who="Dimitrie O. Paun" />
<person posts="23" size="52" who="Alexandre Julliard" />
<person posts="22" size="78" who="Shachar Shemesh" />
<person posts="16" size="59" who="Francois Gouget" />
<person posts="15" size="43" who="Vincent Béron" />
<person posts="15" size="39" who="Mike Hearn" />
<person posts="14" size="26" who="Ivan Leo Murray-Smith" />
<person posts="12" size="33" who="Robert Shearman" />
<person posts="11" size="26" who="Tom" />
<person posts="11" size="26" who="Eric Pouech" />
<person posts="9" size="24" who="Kevin Atkinson" />
<person posts="8" size="19" who="hatky" />
<person posts="7" size="18" who="Dustin Navea" />
<person posts="7" size="18" who="Ove Kaaven" />
<person posts="6" size="24" who="Igor Grahek" />
<person posts="6" size="17" who="Fabian Cenedese" />
<person posts="6" size="16" who="Rolf Kalbermatter" />
<person posts="6" size="15" who="Sylvain Petreolle" />
<person posts="6" size="14" who="Jakob Eriksson" />
<person posts="6" size="14" who="Steven Edwards" />
<person posts="5" size="12" who="Lionel Ulmer" />
<person posts="5" size="11" who="Jeremy Newman" />
<person posts="4" size="53" who="Jonathan Wilson" />
<person posts="4" size="11" who="Ferenc Wagner" />
<person posts="4" size="10" who="Richard Cohen" />
<person posts="4" size="9" who="Jon Brandenburg" />
<person posts="4" size="9" who="David Laight" />
<person posts="4" size="9" who="eric" />
<person posts="3" size="15" who="Kevin Groeneveld" />
<person posts="3" size="9" who="Deji Akinyemi" />
<person posts="3" size="8" who="Kelly Leahy" />
<person posts="3" size="8" who="Robert Shearman" />
<person posts="3" size="8" who="eric lin" />
<person posts="3" size="8" who="Geoff Thorpe" />
<person posts="3" size="7" who="Dmitry Timoshkov" />
<person posts="3" size="6" who="Juan Lang" />
<person posts="3" size="6" who="Marcus Meissner" />
<person posts="3" size="6" who="Dan Kegel" />
<person posts="2" size="11" who="Shachar Shemesh" />
<person posts="2" size="11" who="Gregory M. Turner" />
<person posts="2" size="9" who="John Shillinglaw" />
<person posts="2" size="9" who="Rein Klazes" />
<person posts="3" size="8" who="Bill Medland" />
<person posts="2" size="5" who="Keith Matthews" />
<person posts="2" size="5" who="Sukumar .S" />
<person posts="2" size="5" who="Arjen Verweij" />
<person posts="2" size="4" who="Ian Goldby" />
<person posts="2" size="4" who="Kevin Atkinson" />
<person posts="2" size="4" who="Marcelo Duarte" />
<person posts="2" size="4" who="BiGgUn" />
<person posts="1" size="20" who="Steven Edwards" />
<person posts="1" size="5" who="Thomas J. Moore" />
<person posts="1" size="4" who="Dave Miller" />
<person posts="1" size="4" who="Arjen Verweij" />
<person posts="1" size="4" who="Robert Reif" />
<person posts="1" size="4" who="David Miller" />
<person posts="1" size="4" who="Jacobus Erasmus" />
<person posts="1" size="3" who="David Goodenough" />
<person posts="1" size="3" who="Juraj Hercek" />
<person posts="1" size="3" who="Rok Mandeljc" />
<person posts="1" size="3" who="Jeff Smith" />
<person posts="1" size="2" who="Mike McCormack" />
<person posts="1" size="2" who="Anjan Sarkar" />
<person posts="1" size="2" who="Paul McNett" />
<person posts="1" size="2" who="E Lea" />
<person posts="1" size="2" who="Huw D M Davies" />
<person posts="1" size="2" who="John Freed" />
<person posts="1" size="1" who="Jon Griffiths" />
<person posts="1" size="1" who="jeff_latimer" />
<person posts="1" size="1" who="Evalet Olivier" />
</stats>
<section
title="News: Wine-20030911, TransGaming Update"
subject="News"
archive="http://cvs.winehq.com/cvsweb/wine/ANNOUNCE?rev=1.79&content-type=text/x-cvsweb-markup"
posts="2"
startdate="09/06/2003"
enddate="09/12/2003"
>
<topic>News</topic>
<p>Barely in time for this week's news section, Alexandre released
Wine-20030911:</p>
<quote who="Alexandre Julliard"><p>
WHAT'S NEW with Wine-20030911: (see
<a href="http://cvs.winehq.com/cvsweb/wine/ChangeLog?rev=1.75&content-type=text/x-cvsweb-markup">ChangeLog</a> for details)
<ul>
<li> Many improvements to the winecfg configuration tool.</li>
<li> Massive header files cleanup for better source compatibility.</li>
<li> Some more progress on the kernel/ntdll separation.</li>
<li> Lots of bug fixes.</li>
</ul></p>
</quote>
<p>This release has more changes than usual. Alexandre has been hard
at work committing lots of changes and reorganizing stuff. As noted
above, there's been a lot of changes with the configuration tool. If
you're interested in Win32 programming and Wine you might want to check
it. There's a good opportunity to get involved with Wine development
and help build that tool. As always, you can download the
<a href="http://prdownloads.sourceforge.net/wine/">latest source
and binaries</a> from SourceForge.</p>
<p>Download. Be happy.</p>
<p>Also this week, TransGaming issued August and September's
<a href="http://www.transgaming.com/showthread.php?news=78">
development status and voting report</a>:</p>
<quote who="Transgaming"><p>
TransGaming's Toronto and Ottawa offices were both hit by the massive
power outage that affected about 50 million people in portions of the
US and Canada. As late afternoon rolled around, our computers abruptly
turned off leaving us increasingly wondering "would the bar down the
street have power"? Unfortunately cold beer was not to be found as
bars were shut, public transport was crippled, and people and cars
filled the streets. We hope that those similarly affected managed to
enjoy the forced extra long weekend and did not suffer any major disruptions.
</p><p>
Here are August's top-ranked technology poll items:
<ul>
<li>DirectX 8 Support: Direct3D </li>
<li>Improve overall sound support </li>
<li>Support new features in XFree86 4.3 </li>
<li>Support Older Games </li>
<li>Improve 3D performance </li></ul></p></quote>
<p>Check out the link above for complete details. They also announced their
<a href="http://www.transgaming.com/showthread.php?news=79">beta testing
program</a> available to subscribers.</p>
</section>
<section
title="Explorer Clone"
subject="Wine fun projects - explorer clone update"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0184.html"
posts="1"
startdate="09/06/2003"
>
<topic>Utilities</topic>
<p>Wine has never had a good replacement for Windows' Explorer. Steven
Edwards announced some work by Martin Fuchs:</p>
<quote who="Steven Edwards"><p>
I doubt this will ever make it in to WINE as Martin has been using C++ to implement our explorer
clone but you might want to have a look at it if you want a explorer clone for WINE.
<ul>
<a href="http://www.sky.franken.de/explorer/index.html">http://www.sky.franken.de/explorer/index.html</a></ul></p><p>
You will want to get the current source from ReactOS CVS. Martin has made a lot of changes to
support both WINE and ReactOS and been working on improving WINEs shell32.
</p></quote>
<p>The enhancements to shell32 are needed about as much as Explorer.
Hopefully they'll find their way into Wine. </p>
</section>
<section
title="Glibc Breakage"
subject="Wine repeated unhandled exptions"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0368.html"
posts="12"
startdate="09/10/2003"
>
<topic>Build Process</topic>
<p>Shachar Shemesh ran into a glibc problem, the type that are
really hard to diagnose:</p>
<quote who="Shachar Shemesh"><p>
I have just performed an upgrade to my Debian Sid Linux. During the
upgrade, libc was replaced. I can now not get Wine to work on the new
install.
</p><p>
Previously, I would use Wine without --with-nptl. This no longer works.
Wine sigsegv on startup (whether there are parameters or not).
</p><p>
compiling with --with-nptl gets me slightly further. Running wine
without parameters produces the help printout. However, when I try to
actually run something, this does not work. It doesn't matter what I try
to run (whether winelib or Windows). I get a series of "unhandled
expection". This happens even for the regedit that is supposed to
install my default registry via tools/wineinstall
</p><p>
Any ideas? Anyone?
</p></quote>
<p>He added,
<quote who="Shachar Shemesh">
It appears that some
black magic is destroying the content of a variable between calls.
</quote> Rein Klazes seemed to run into the same problem and
found an item in Debian's glibc-2.3.2-6 changelog that seemed to be a
smoking gun. He downgraded and everything worked again. Shachar
wanted to know how he was able to fall back on an older copy without
trashing the system. Rein sent some instructions:</p>
<quote who="Rein Klazes"><p>
If they are not still on your system ( /var/cache/apt/archives/ ) you can
download them from a local Debian mirror in pool/main/g/glibc.
</p><p>
Then I did
<ul><code>
| dpkg -i libc6-dev_2.3.2-5_i386.deb libc6_2.3.2-5_i386.deb locales_2.3.2-5_all.deb
</code></ul></p></quote>
<p>That worked for Shachar, but didn't solve the real problem. Marcus
Meissner got a little closer to the issue,
<quote who="Marcus Meissner">
The newest glibc snapshot causes problems somewhere in pthread_cond_wait or similar.
</quote></p>
<p>Ove Kåven discovered the real cause based on what Rein and Marcus
reported:</p>
<quote who="Ove Kaaven"><p>
I've just got a bug report on it (#210300) so I've taken a look. So,
this pthread_cond_timedwait.dpatch contains:
<ul><code>
--- libc/linuxthreads/sysdeps/pthread/pthread-functions.h.jj 2003-04-20 03:37:06.000000000 -0400<br />
+++ libc/linuxthreads/sysdeps/pthread/pthread-functions.h 2003-09-01 05:35:34.000000000 -0400<br />
@@ -54,6 +54,8 @@ struct pthread_functions<br />
<ul>
int (*ptr___pthread_cond_signal) (pthread_cond_t *);<br />
int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);<br />
+ int (*ptr___pthread_cond_timedwait) (pthread_cond_t *, pthread_mutex_t *,<br />
+ const struct timespec *);<br />
int (*ptr_pthread_equal) (pthread_t, pthread_t);<br />
void (*ptr___pthread_exit) (void *);<br />
int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);</ul></code></ul>
</p><p>
Compare with Wine's scheduler/pthread.c:
<ul><code>
struct pthread_functions<br />
{<br />
...<br />
<ul>
int (*ptr___pthread_cond_init) (pthread_cond_t *, const pthread_condattr_t *);<br />
int (*ptr___pthread_cond_signal) (pthread_cond_t *);<br />
int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);<br />
int (*ptr_pthread_equal) (pthread_t, pthread_t);<br />
void (*ptr___pthread_exit) (void *);<br />
int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);<br />
</ul>
...<br />
};</code></ul></p><p>
See the problem?
</p><p>
Hmm, now should I complain to Debian's glibc maintainers, or is this
Wine's problem?
</p></quote>
<p>Notice how new declarations were added right in the middle of the structure? That's not
good when you expect them to be in a defined order. Alexandre felt there wasn't much that
could be done on the Wine side,
<quote who="Alexandre Julliard">
In a sense it's a Wine problem, since this is an internal structure we
are not really supposed to be using. However, I don't think there's
any way we can fix the problem on our side, so we are going to need a
change in glibc (moving the new function to the end of the structure
should work).</quote></p>
<p>Ove put in a bug report against glibc and within hours it was fixed.
Alexandre reported,
<quote who="Alexandre Julliard">
The glibc guys have been kind enough to make the change, so this is
fixed in the current glibc CVS (and I put in the corresponding change
on the Wine side).</quote></p>
</section>
<section
title="Optimization Required"
subject="Compilation errors when compiling without optimizations"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0383.html"
posts="5"
startdate="09/10/2003"
>
<topic>Build Process</topic>
<p>Shachar Shemesh ran into a problem compiling Wine:</p>
<quote who="Shachar Shemesh"><p>
When trying to compile Wine without optimizations, the compilation
fails. I'm trying clean sources, with the "--with-nptl" flag.
</p><p>
The failure (so far, I'm still trying to figure these things out) are
when compiling ntdll and the wine executable itself. Both cases, the
problem is that same. The linker complains that
"InterlockedCompareExchange" cannot be found. Adding kernel32 to the
IMPORTS Makefile at dlls/ntdll and miscemu/wine seem to solve these
problems, but I'm somewhat worried, and would like to get a second
opinion before I submit a patch about this.
</p></quote>
<p>Alexandre jokingly pointed out the obvious solution:</p>
<quote who="Alexandre Julliard"><p>
Don't do it then <g>
</p><p>
That's a temporary problem because dll separation is not finished. It
will be fixed soon, in the meantime just make sure to compile at least
ntdll with optimization.</p></quote>
<p>Eric Pouech told Shachar his solution wasn't right and elaborated
on the DLL separation problem,
<quote who="Eric Pouech">
either ensure that the inline version of the
Interlocked* are always used, or copy the source (from kernel32) of the
non-inlined version of the Interlocked* functions in ntdll.
That'll do for the moment.</quote></p>
</section>
<section
title="Input Events and DGA Problems"
subject="DGA input events dropped"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0228.html"
posts="2"
startdate="09/07/2003"
>
<topic>Graphics</topic>
<p>There have been problems with Wine using the XFree86 DGA extension.
DGA (really DGA2), the Direct Graphics Architecture, is a 2D graphics API
that allows the CPU direct access to the framebuffer memory.
This topic came up over a year and half ago, but I didn't cover it
then. Lionel Ulmer
<a href="http://www.winehq.com/hypermail/wine-devel/2002/01/0392.html">originally</a>
diagnosed problems with DGA2 and event handling.
Thomas Moore went through a similar process and mailed in a patch:
</p><quote who="Thomas Moore"><p>
For a very long time now, enabling DGA causes mouse/keyboard events to be
ignored. There have been a few threads on this issue in the past, and it
seems nobody is willing to actually fix this problem (even though some have
submitted patches to fix it, nothing has ever made it into CVS). Why is
this? Overall, the problem seems to be related to the use of separate
per-thread X display handles, along with a global (separate) "GDI" display.
At first I tried just making the first thread's display the "global" display,
but since that didn't work, and I don't have the patience to figure out why
this dichotomy exists, here's a simple patch which at least works for a few
games I tried (but still has mouse problems with a few other games I've tried
- there was a mouse fix on an earlier thread(1) on this subject, but it
doesn't work -- perhaps it has something to do with the fact that DGA only
returns relative mouse movement, and non-DGA returns absolute movement). On
the other hand, you could just at least make your default behavior and sample
config not enable DGA.</p></quote>
<p>Ove Kåven explained why it was wrong and what the correct
solution should do (and why it's a lot harder):</p>
<quote who="Ove Kaaven"><p>
all those patches are based on having gdi_display
receive events. It should not. Consequently, DGA should be initialized
using a per-thread display so that events arrive on a per-thread
display. Originally I had thought that the DGA driver could create a
separate thread and use its thread display, but it may not be strictly
necessary, given that DirectDraw needs a cooperative window, and windows
are per-thread objects, so the thread that owns the cooperative window
could also own the DGA display. If we also assume that this thread calls
SetMode, it's probably okay to just use the current thread_display()
instead of gdi_display. But I suppose it's probably still safer to let
DGA create its own thread, though somewhat more involved (you may have
to use XSendEvent or some kind of wineserver stuff to forward keyboard
and mouse events to the thread that owns the cooperative window).
Besides, a separate thread would allow the DGA code to handle its own
events, instead of scattering DGA special cases around the rest of the
x11drv event-handling code.</p></quote>
</section>
<section
title="Locating Font Paths"
subject="Using fontconfig"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0221.html"
posts="2"
startdate="09/07/2003"
>
<topic>Configuration</topic>
<p>Mike Hearn has been putting a lot of work into Wine's
configuration lately - namely the work on winecfg. He asked
a question along those lines:</p>
<quote who="Mike Hearn"><p>
It'd be nice to use fontconfig in future to locate font installation
paths. There is a simple API:
<ul><code>
FcStrList FcConfigGetFontDirs (FcConfig *config);</code></ul></p><p>
which should let us use a small part of it, even if we don't use all of
it. It means we don't need to make the user manually configure font
paths.
</p><p>
Does anybody know how hard this would be?</p></quote>
<p>Huw Davies, Wine's font guru, has already done the work,
<quote who="Huw Davies">
I've done this for CrossOver 2.1 and hopefully we'll merge it into
winehq soon. Rather than a directory by directory approach, I'm
walking the entire font list and using any TrueType fonts that I come
across.</quote></p>
</section>
<section
title="OpenSSL Support"
subject="adding structures to headers"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0338.html"
posts="6"
startdate="09/09/2003"
enddate="09/10/2003"
>
<topic>Fixes</topic>
<p>Geoff Thorpe stubbed out some functions that let him
install and use OpenSSL:</p>
<quote who="Geoff Thorpe"><p>
I don't have or use any windows installation or compilers, but as a wine
user and openssl developer I was curious anyway about how well win32
versions of openssl programs and libraries would function under wine. It
turns out that the PRNG polling touches on some system monitoring
functions for additional sources of entropy, and these were generating
some exceptions.
</p><p>
So this just adds two stub functions that cause openssl to work (the error
values returned from these two stub functions prevent the oodles of other
functions from being used). This should help not only openssl programs
(and scripts that use them), but also any win32 programs that depend on
openssl DLLs.
</p><p>
PS: the types added with NetStatisticsGet are not used, but will be needed
if the stub is later implemented. The structure definitions in both
patches were taken from msdn's online API reference - so don't commit if
this is a violation of any legal fineprint.
</p><p>
PS2: I could have added stubs for the other Heap32<foo> functions too, but
after doing the first one (and learning a little about the ntdll/kernel
build) everything worked. Should I send stubs for the rest too?
</p></quote>
<p>Geoff had a question about adding headers that Dimi fielded. Then
he included a little more detail on exactly what his patch fixed:</p>
<quote who="Geoff Thorpe"><p>
Now, can you tell me if the code seems ok to you? :-) It's my first
submission to wine-patches and I note that it hasn't as yet elicited any
response, either as a rejection or a commit. FWIW: I was using the
prebuilt openssl installer for version 0.9.7b from:
<ul>
<a href="http://www.shininglightpro.com/search.php?searchname=Win32+OpenSSL">
http://www.shininglightpro.com/search.php?searchname=Win32+OpenSSL</a></ul>
</p><p>
This installer appears to run well under wine. My changes were sufficient
to get "<tt>wine /path/to/openssl/bin/openssl.exe -- speed rsa1024</tt>" working,
and although the timing mechanisms for benchmarking don't appear to work
properly (another problem for another time), it is nonetheless doing
crypto operations satisfactorily. As these routines include assembly
optimisations and there being a somewhat clunky win32 compilation system
behind it (long story), this was a useful test from my point of view.
</p><p>
But anyway, the point was to get the libs and crypto executing, and I
suspect those two stub functions would be enough now for any applications
using openssl libraries under wine.
</p></quote>
</section>
<section
title="Alpha/SGI Development for Wine and ReactOS"
subject="ReactOS and WINE development on AlphaAXP and others"
archive="http://www.winehq.com/hypermail/wine-devel/2003/09/0488.html"
posts="1"
startdate="09/11/2003"
>
<topic>Ports</topic>
<p>Steven Edwards extended a generous offer for developers
interested in porting Wine:</p>
<quote who="Steven Edwards"><p>
HP has recently extended the loan I requested on this alpha pws500 workstation for
another year. If anyone is interested in working on porting WINE or ReactOS to the
alpha email me privatly and I can setup a account for you on the system.
</p><p>
I have another system a friend has let me borrow for at least a few months if anyone
is interested in doing some porting work on it. Its a SGI Indigo 2 IMPACT 10000.
I still need to load linux on it and get it up on the network though it will be a few
weeks before anyone can use it if they are interested in starting a MIPS port
</p></quote>
</section></kc>
More information about the wine-patches
mailing list