Wine Traffic #95 For 13 May 2001 By Brian Vincent Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Mailing List Stats For This Week * Threads Covered 1. 10 May 2001 (1 post) Headlines 2. 8 May 2001 - 9 May 2001 (3 posts) doors IPC 3. 9 May 2001 (2 posts) Helping with Wine 4. 9 May 2001 (4 posts) GDB Remote Debugging Introduction This is the 95th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator). Next week's issue will likely arrive on Tuesday, or possibly later depending on how many threads there are. I'll be on vacation next week. On a related note, does anyone have any suggestions as to what to see or do at Lake Powell, UT? Mailing List Stats For This Week We looked at 2 posts in 182K. There were 2 different contributors. 13 posted more than once. 0 posted last week too. The top posters of the week were: * 9 posts in 32K by Francois Gouget * 8 posts in 35K by Marcus Meissner * 6 posts in 18K by Ian Pilcher * 3 posts in 8K by Andreas Mohr * 3 posts in 7K by Alexandre Julliard * Full Stats 1. Headlines 10 May 2001 (1 post) Archive Link: "A new vintage and some interesting press" People: Gavriel State, eetimes, CodeWeavers, , Transgaming, TransGaming Alexandre has unleashed a new snapshot unto the world. On Thursday Wine-20010510 was cut and made available. The source is available via http at http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010510.tar.gz ( http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010510.tar.gz) or through ftp at ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/ development/Wine-20010510.tar.gz (ftp://ftp.infomagic.com/pub/mirrors/linux/ sunsite/ALPHA/wine/development/Wine-20010510.tar.gz) . The main changes include: * a ton of printing enhancements (check out last weeks issue about the addition of CUPS support) * graphics driver restructurations * changes to facilitate a port to NetBSD * and lots of other fixes for bugs Also out this week were a pair of interesting stories in the press. The first one, from GameSpy.Com (http://www.gamespy.com) , is titled Ports vs. Wine (http://www.gamespy.com/articles/may01/wine/) . As Linux Today (http:// www.linuxtoday.com) describes it, "GameSpy takes on the question of whether Linux gamers are better off waiting for Linux ports (which aren't as plentiful as many would like) or getting behind Wine. Includes commentary from Gavriel State of Transgaming, which is working on bringing DirectX to Wine; and an assortment of pro-ports people including Scott Draeker of Loki, who maintain that compatibility layers are bad news". This is what Gavriel had to say in the article: TransGaming doesn't see WineX as competition for source level porting efforts from companies such as TribSoft and Loki. Rather the opposite: WineX compliments the existing Linux games market by keeping Linux users in Linux to play their games, even when the developer or publisher has decided against a direct Linux port. TransGaming is certainly not going to be spending any effort on games that have already been ported by Loki or TribSoft. Keep in mind also that WineX can be used for source level compatibility (aka Winelib) to speed up the process of recompiling games using Linux-based compilers and development tools, and thus taking advantage of Linux-specific features where they make sense. In fact, internally we use the Winelib approach for regression testing with the various Microsoft Direct3D samples. It's not an either/or situation. We'll see some games being played under the Wine binary loader, some ported"natively" to Linux using Winelib and some direct access to Linux APIs, and others rewritten from the ground up using APIs like SDL. The true strength of Linux and Open Source lies in diversity and choice, and having multiple approaches to game portability is just one more aspect of that strength. Also included in the article is a nice screenshot (http://www.gamespy.com/asp/ image.asp?/articles/may01/wine/1.jpg) of Shiny's Sacrifice running with WineX. The second article out this week is "Plug-ins to enhance browsers of Linux-based appliances" (http://www.eet.com/story/OEG20010508S0061) from EETimes (http://www.eet.com) . It starts off: Looking to narrow the gap in features between Windows- and Linux-based platforms, CodeWeavers Inc. has developed a series of browser plug-ins such as Shockwave and QuickTime for Linux-based Internet appliances. CodeWeavers' Crossover plug-in software, scheduled for a May 15 launch, will be offered to Internet appliance manufacturers building platforms that run Linux or any Unix-like operating system. And then further down: "In addition to the Crossover plug-ins, CodeWeavers plans this fall to launch Crossover display, which will let an Internet appliance start up a Windows application installed on a nearby PC with a click of a button, but without a Windows OS. And Crossover server, scheduled for release in mid-2002, is a complete Windows-compatible Linux-based server. " 2. doors IPC 8 May 2001 - 9 May 2001 (3 posts) Archive Link: "doors IPC" People: Damjan Lango, Marcus Meissner, Damjan Lango posted note about speeding up the wineserver: Some time ago here was a discussion about speeding up the communication between the wineserver and the application with various kernel patches. I was reading "Unix Network Programming, volume 2 - IPC" and ran over a "doors" IPC api that is implemented on Solaris and has the lowest latency. According to the book it is ~3 times faster than pipe. Actual values for Solaris 2.6 in the book are: (in miliseconds) doors: 121 sysv msgq: 260 pipe: 324 unix dom. socket: 465 posix msgq: 584 ... There is also a link to a Linux implementation of doors on: http:// www.rampant.org/doors/ On this link you will find also more info on doors. But according to the performance tests that the author made, the linux pipe is somewhat the same speed as doors so maybe it could be optimized more or maybe is Linux's pipe already so optimized that doors are unnecesary. So what do you think, would this be useful for speeding up wine? I apologoize if you already know about this... Marcus Meissner replied with: What a coincidence ;) I just did a patch changing the critical section handling to become more of a spinlock. I have attached it. This should reduce the critical section based reschedules between: wine <-> wineserver <-> wine to: wine <-> wine Since critical sections are thought to be 'fast' and 'short time' locking primitives, and Win32 threads should not sleep in a critical section, we can just give up our timeslice and wait for the other thread that has the lock to continue. This is a preliminary version, but it works. It uses 'LockSemaphore' as differentation between process-local and global critical sections. It uses 'sched_yield', which is a POSIX feature, to give up the timeslice. How does one force a reschedule on another UNIX? Is select(0,NULL,NULL,NULL,shorttimeout); reliable? This patch can give spinning processes on SMP systems, but I do not consider this a real problem at this time. I would like to know if there is something wrong with the concept ;) At least winword feels a bit snappier now. 3. Helping with Wine 9 May 2001 (2 posts) Archive Link: "Re: where do I go to find out who needs help" People: Francois Gouget, , codeweavers Sean Callahan sent a message that asked what could be done to help out with Wine. Francois Gouget sent a lengthy reply that listed a lot of items: Hmmm, I think I can also find a list of bugs in bugzilla that could easily be fixed by someone new to Wine: Easy: * Builtin msvcrt mishandles the cmdline to argv conversion #234: http:// wine.codeweavers.com/bugzilla/show_bug.cgi?id=234 This prevents 'wine /mnt/ win/Program\ Files\whatever\foo.exe' from working if you're using the builtin msvcrt! * I'm almost 100% certain that there's another bug in the same function in its handling of the environment variable. * PrgWin95/98: System metrics differ from the Win9x values #48: http:// wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, ... * The doc about the command line arguments and the config file is out of date. I'm sure there are plenty of other things that are out of date. * Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion. * PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (http:// wine.codeweavers.com/bugzilla/show_bug.cgi?id=56) (I can provide you with the sample application) * I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming. * There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code. Medium (I expect these would take longer or be a bit harder) * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/ show_bug.cgi?id=91 (http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 ) I know there's sample code that does that already floating around so it should be relatively simple. * wrc fails on preprocessed files #115: http://wine.codeweavers.com/bugzilla/ show_bug.cgi?id=115 (http://wine.codeweavers.com/bugzilla/show_bug.cgi?id= 115) I believe it's just a grammar problem. You'll need to know (or to get cozy with) lex/yacc... * CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/ bugzilla/show_bug.cgi?id=175 (http://wine.codeweavers.com/bugzilla/ show_bug.cgi?id=175) I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction. * winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227 (http:// wine.codeweavers.com/bugzilla/show_bug.cgi?id=227) * winemaker: Ignores the '--with-{mfc,wine}' options once they are cached # 225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 (http:// wine.codeweavers.com/bugzilla/show_bug.cgi?id=225) If you're familiar with autoconf and know how configure scripts should behave... * StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/ show_bug.cgi?id=11 (http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 ) This should not be too difficult to fix but it would certainly help if you are familiar with GDI. * Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences. * Enhancing the above perl script. But let us know also what kind of work you would like to do and what kind of things you're best at: - C programming - Debugging - Windows programming - tweaking shell scripts - writing/fixing documentation - doing web stuff It also depends on what motivates you: getting an application to work, implementing some new functionality, getting applications to compile, fixing scripts, fixing documentation or writing new documentation... And the last parameter is how much time you have for Wine work. In any case it's probably better to start with something simple to see if you like it. And in a completely different thread it was asked how to submit code once something has been fixed. Francois also replied to that with: > Have a look at http://www.winehq.com More precisely: * CVS http://www.winehq.com/dev.shtml#CVS The best way to stay up to date. * wine-patches http://www.winehq.com/mailman/listinfo/wine-patches (http:// www.winehq.com/mailman/listinfo/wine-patches) It's best if you subscribe to wine-patches (otherwise each of your emails will go through the moderator) * Wine Developer's Guide: Chapter 4. Submitting Patches http://www.winehq.com /Docs/wine-devel/patches.shtml (http://www.winehq.com/Docs/wine-devel/ patches.shtml) All you need to know about submitting patches (I hope) Should you run out of FIXMEs (!), don't hesitate to ask for ideas of things to hack on this list. 4. GDB Remote Debugging 9 May 2001 (4 posts) Archive Link: "GDB remote debugging" People: Ove Kaaven, Alexandre Julliard, , Ove K?ven, Eric Pouech Ove K?ven posted a patch on the wine-patches list with updates on some code he wrote for using gdb to debug Wine apps: For any sufficiently disillusioned Wine hackers, here's my current experimental code for letting GDB attach to a Wine process. It's reasonably featured (exceptions are caught, changing threads work, single-stepping works, software breakpoints work, you can do backtraces, change registers and variables, etc). You can also do "info shared" to get a list of loaded .sos, and use the "sharedlibrary" command to load their symbols, but I strongly recommend against loading symbols for libpthread.so, or you'll destroy the neat "info thread" display. This code has helped me quite a bit in my debugging, actually, when winedbg couldn't be used... Apply autoconf after patching. Engage with ./configure --enable-remote-gdb I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it... He was right, Alexandre responded with: How did you guess I wouldn't like it? ;-) Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there. Ove responded to this and said that he could attach and detach gdb to a running process whereas the winedebugger can't do that. Eric Pouech cleared this up with some instructions: > winedbg can't, at least nobody knows > how to attach winedbg to a running process. well, winedbg can... and now everybody *SHOULD* know start winedbg without any argument on commande line then, use command walk process you'll get a list of running processes using the command attach really attaches to the running process the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger) Sharon And Joy Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.