Table Of Contents
|1.||23�Nov�2002�-�29�Nov�2002||(2 posts)||News: Wine-20021125|
|2.||26�Nov�2002||(1 post)||WineX on FreeBSD|
|3.||25�Nov�2002�-�27�Nov�2002||(16 posts)||Porting Apps With Winelib|
|4.||25�Nov�2002||(4 posts)||Porting to a Standalone App|
|5.||24�Nov�2002||(2 posts)||Submitting Multiple Patches|
|6.||28�Nov�2002||(3 posts)||Debugging wineserver|
|7.||26�Nov�2002||(7 posts)||Shortening Debug Logs|
|8.||24�Nov�2002�-�25�Nov�2002||(6 posts)||OpenGL & Double Buffering|
|9.||28�Nov�2002||(4 posts)||Wine Under Cygwin|
|10.||26�Nov�2002�-�27�Nov�2002||(12 posts)||Quick Response to SwitchToThread() Problem|
This is the 146th 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).
Mailing List Stats For This Week
We looked at 323 posts in 1018K.
There were 79 different contributors. 49 posted more than once. 46 posted last week too.
The top posters of the week were:
1. News: Wine-20021125
23�Nov�2002�-�29�Nov�2002 (2 posts) Archive Link: "News"
People: Alexandre Julliard,�FranksCorner,�,�News
Alexandre released Wine-20021125 on Tuesday with this note:
WHAT'S NEW with Wine-20021125: (see ChangeLog (http://cvs.winehq.com/cvsweb/wine/ChangeLog?rev=1.65&content-type=text/x-cvsweb-markup) for details)
This link was shamelessly copied from Frank's Corner (http://www.frankscorner.org) , " On www.desktop-linux.net you can find a howto (http://www.desktop-linux.net/cxwine-mime.htm) for setting up mimetypes and symlinks, so you can launch windows executables by clicking on them in the Konqueror file manager. "
2. WineX on FreeBSD
26�Nov�2002 (1 post) Archive Link: "Warcraft3 on FreeBSD"
Slashdot announced Kenneth Culver had hacked some syscalls into FreeBSD that allows Warcraft 3 using the Linux WineX package:
Just in case anyone here cares, I have implemented the linux ftruncate64, truncate64, and mmap2 syscalls in the linuxulator on my computer, (mostly cut 'n pasted the mmap2 from regular mmap with a couple of changes) and with these changes it is possible to run the linux version of winex (the one you have to pay for) to run warcraft 3. IT works in both direct3d mode and in opengl mode using the following commandline:
winex --dll dsound=n --dll quartz=n --dll d3d8=b War3.exe -- War3.exe
Anyway, just thought someone might want to know. If anyone wants step-by-step instructions to getting this working I'll have those worked up in the next few days and posted somewhere along with the patches to the linux kernel module.
3. Porting Apps With Winelib
25�Nov�2002�-�27�Nov�2002 (16 posts) Archive Link: "Winelib Apps v0.1"
People: Dimitrie Paun,�Martin Wilck,�
Last week I covered a thread where Dimi Paun worked on porting a Windows program using Winelib Issue�#145, Section�#2� (21�Nov�2002:�Porting PuTTY With Winelib) . He announced a web page based on that experience:
Version 0.1 of the Winelib Applications page is available here:
The current version is always available at this address
Your comments, and suggestions are highly appreciated.
In the past people have debated exactly how practical Winelib is. It doesn't really give a speedup by compiling it as a native app. Nor does it (yet) allow you do use that app without Wine (see the next thread). But Dimi makes some excellent points on that page why it's important. First, for Wine development it provides an excellent testing tool. As he puts it, " There are many such apps around, and a lot of them are hosted at SourceForge. There are over 10,000 apps listed as running under Windows OS, and over 7,000 of them are listed as running under the Win32 environment. "
Martin Wilck likes Winelib for another reason:
Winelib can be a solution for porting such software to Linux by only rewriting those parts that need to be rewritten, replacing NT with Unix functionality. This is much easier than doing a native port; most of the application's code can be left untouched.
IMO this is the "real world" reason for doing Winelib development - you can *combine* Windows and Unix code. OTOH Putty and Mozilla are apps that I'd expect to be able to run natively.
Also, once an app gets ported using Winelib it's more platform independent and could conceivably someday run on Linux/PPC or Solaris. It can also begin taking advantage of features native to those platforms. Winelib is still rough around edges - the build tools used by a lot of Windows programs require a little massaging to compile with Wine. If you like to fiddle with compiling programs check out Dimi's guide above. And if you're successful with something I'm sure everyone on wine-devel would love to hear about it.
4. Porting to a Standalone App
25�Nov�2002 (4 posts) Archive Link: "Fwd: Re: [putty]Winelib support + patch"
People: Dimitrie Paun,�Simon Tatham,�Alexandre Julliard,�
A little background on this thread might be necessary. Dimi explained a little bit about Wine to the folks who wrote PuTTY (a telnet/ssh client for Windows):
FYI: the way it works is that instead of compiling the app as an executable, we generate a .so that's loaded by wine. Now, wine is simply a one page program that loads the libraries that the program expects (like kernel, gdi, user), and then loads the program itself. This is required by some apps which have C++ static initializers, which expect to be able to call Win32 functions, and they do so before we get a chance to initialize them, if we were to have the app load the libs.
Simon Tatham from that project wasn't really sure why was needed for normal old apps written in C, " OK, I've now read the docs and I understand this a bit better now. My next awkward question is: I can see that this is necessary for some apps which have C++ static initialisers, or which load libraries that have C++ static initialisers, but why does that mean it's necessary for PuTTY? PuTTY contains no C++, and as far as I know it uses no libraries _except_ standard Win32 API ones. Surely it should be possible _for these particular applications_ to compile them as standalone binaries? Or does Winelib currently only support doing things the inconvenient way? "
Which led Dimi to ask, " Alexandre, do we support generating regular executables for the apps we don't necessarily need the wrapper stuff for initialization purposes?"
Alexandre explained, " No, that's not supported at this point. It may be possible to support it again with some linker magic, now that apps no longer link to dlls directly. That's definitely something we should try to do as part of the "making winelib more user-friendly" task. "
5. Submitting Multiple Patches
24�Nov�2002 (2 posts) Archive Link: "Re: Some additions to D3D"
People: Lionel Ulmer,�Alexandre Julliard,�
Lionel Ulmer submitted a Direct3D patch and in the process asked, " how would you prefer for us to track dependencies between patches ? Submit each time a patch agains fresh CVS with all previous patches sent (with an ever growing changelog) or do you prefer (like here) a lot of patches dependant one on the others ? If it's the latter, do we need to do 'letter tracking' as Dimi did ? "
In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix.
And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order.
6. Debugging wineserver
28�Nov�2002 (3 posts) Archive Link: "How to debug wineserver"
People: Rajesh Akkineni,�Tony Lambregts,�Martin Wilck,�
Rajesh Akkineni wanted to know, " is there any way we can debug the wineserver? "
Tony Lambregts mentioned, " when you start wineserver you can start it with debug levels i.e., "wineserver -d1". Setting d0 turns winserver debugging off. "
Martin Wilck had some suggestions too, " Starting wine with "-debugmsg trace+server" works quite well. Furthermore, wineserver is a true Unix program. You can run in through gdb. I often run wine normally, then start gdb and simply attach to the running wineserver process. "
7. Shortening Debug Logs
26�Nov�2002 (7 posts) Archive Link: "Re: Some fixes in capabilities"
People: Lionel Ulmer,�Alexandre Julliard,�
Lionel Ulmer ran into a situation where he wanted to begin debugging a program long after it started. He described his problem:
I do not want to turn on relaying for only one DLL (as I have no clue at all where the problem is)... What I want is to turn on relaying for all DLLs *after* the program has started (and *from* one of Wine's DLL and not from the loader or any other 'special' code).
Ie, the program starts, loads the level / stuff for 10 minutes (and whould have produced a 2.5 GB log unreadable without big file support) and then only the last 10 seconds are important. So I would like to only relay these.
Alexandre suggested two possibilities:
The easy way would be to print some magic string at that point, and pipe the output into a sed that deletes everything before that string. It will still be a bit slow though.
The harder way is to call wine_dbg_parse_options("+relay"). This would work for a normal debugging option, but for relay there is some work that needs to be done at startup so you need to handle that too. A way would be to start with +relay, turn it off with wine_dbg_parse_options, and then turn it on again when needed.
8. OpenGL & Double Buffering
24�Nov�2002�-�25�Nov�2002 (6 posts) Archive Link: "And opengl regression"
People: Duane Clark,�Lionel Ulmer,�Alexandre Julliard,�
Duane Clark spotted a regression due to the new dynamic loading of OpenGL:
The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html (http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html)
has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/ (http://www.navagent.com/products/earthquake/)
That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.
After looking into it, he found the new code that caused the problem. It appeared the new code checks to see if double buffering was selected:
/* If OpenGL is available, change the default visual, etc as necessary */
if (desktop_dbl_buf && (desktop_vi = X11DRV_setup_opengl_visual( display )))
Lionel asked if the "DesktopDoubleBuffered" option was set in Duane's config file. Duane replied that he did, and if he changed it then the problem went away. He asked why that was default behavior and Lionel described the process:
Well, before my patch, in one of the X11DRV rewrite, the option got somehow lost and was enabled by default whatever the value of the entry in the config file. So that it was working before was a 'feature' :-)
Now let's try to explain the reason of this option : in Windows, you first create the Window and then only tell it that one wants to do OpenGL drawing in it (single or double buffered). Now, in X11, if you plan to use a window to do OpenGL drawings, you first need to be sure that the visual you choose for it is compatible with OpenGL (ie does it support double buffering ? has it a stencil buffer ? ...). The problem is that when Wine detects that the application wants to do double buffered OpenGL drawings in that window, it's too late as the window was already created with the default visual => hence the option to have the default visual used by all windows be double buffered.
I do not think putting it as default is such a good idea as it may lead to performance problems to all the people not using OpenGL... And the gamerz just have to read the config file (if they know how to read, sometimes we wonder when doing 'support' on #WineHQ 8-) ).
As to why it's called 'DesktopDoubleBuffered' and not something else, it's also historic : at the beginnings, OpenGL only worked properly in Desktop mode :-)
Finally, Alexandre (if you read this :-) ), now that you rewrote most of the internal Windows handling code (ie with the Wine window == X11 window stuff), would it be possible to somehow recreate the X11 window when we detect OpenGL attaching to it and replace the old window in Wine's window hierarchy ?
To which Alexandre replied, " Possible, yes. Easy, definitely not ;-)"
9. Wine Under Cygwin
28�Nov�2002 (4 posts) Archive Link: "compiling wine under cygwin - status"
Topics: Status Updates
People: David Fraser,�Dimitrie Paun,�
David Fraser has been working on compiling Wine under Cygwin. For more details, see issue #144 about "Fun Projects" Issue�#144, Section�#4� (14�Nov�2002:�Fun Projects) He wrote in with a status update:
This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully.
The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list.
My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-)
For a complete list of what's working and what's not, check out David's original post (http://www.winehq.com/hypermail/wine-devel/2002/11/1522.html)
In response to David's question about ptrace.c functionality, Dimi Paun wrote, " So actually a first approximation for [sg]et_thread_context for Cygwin would be one that does nothing. Then we can try submitting patches to Cygwin (Approach 2), so that other apps can make use of ptrace, if necessary. "
David did that and announced more progress, " OK, done that. So now wineserver.exe actually links :-) And it runs too! However can't yet see whether its going to do anything as in order to actually run programs it looks like we need tolink miscemu/main.c Problem here being that it wants to link with ntdll, which doesn't build yet. That still needs a lot more work... In the mean time a very simple patch that does nothing for context_i386.c is below in case anyone else wants to try..."
10. Quick Response to SwitchToThread() Problem
26�Nov�2002�-�27�Nov�2002 (12 posts) Archive Link: "Whither SwitchToThread()?"
People: Sean Mitchell,�Martin Wilck,�,�Francois Gouget
Sean Mitchell wrote to wine-devel with a problem:
I'm doing a proof-of-concept for my boss to demonstrate that we can port a large-ish application developed on Windows (using mostly crossplatform libraries like wxWindows, STLport, Xerces) to Linux using winelib to cover a few WIN32 API calls we've made.
I've just started into it, and have compiled a dozen files so far, but ran into trouble with the thread code. I cannot find SwitchToThread anywhere, not even in the winbase.h header file I expected it in. There are some changelogs to indicate that it exists, and the symbol does live in libntdll.dll.so, but I cannot find a header file that defines it.
An hour and half later Andrew Hughes dropped a note saying the MSDN docs listed the prototype in winbase.h. Francois Gouget sent a one line patch updating winbase.h a few minutes later. Sean wrote back the next morning, " I told my boss that I posted the query last night and had a response with a fix waiting for me this morning. He is lukewarm about Open Source, but when I told him about this he was very, very impressed. He's never seen that sort of response from a commercial vendor except in a few emergency situations. "
Several others were also pleased with the quick response. Martine Wilck added, " even if Sean is happy now, and his boss too, let's keep realistic - we were able to give quick feedback here because the solution was simple."
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.