wn20030912_187.xml -brian
<?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>
