Table Of Contents
|1.||13�Sep�2003�-�19�Sep�2003||(1 post)||News: TransGaming Point2Play Update|
|2.||16�Sep�2003�-�18�Sep�2003||(11 posts)||Winecfg Status & Preferences|
|3.||15�Sep�2003�-�16�Sep�2003||(11 posts)||System Tray Support|
|4.||18�Sep�2003||(6 posts)||Blank Screen of Death|
|5.||17�Sep�2003�-�18�Sep�2003||(4 posts)||Finding Memory Management Problems|
|6.||12�Sep�2003�-�14�Sep�2003||(8 posts)||Library Loading Problem|
This is the 188th issue of the Wine Weekly News publication. Its main goal is to wander aimlessly on four wheel drive roads. 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 www.winehq.com (http://www.winehq.com)
Mailing List Stats For This Week
We looked at 186 posts in 815K.
There were 55 different contributors. 27 posted more than once. 26 posted last week too.
The top posters of the week were:
1. News: TransGaming Point2Play Update
13�Sep�2003�-�19�Sep�2003 (1 post) Archive Link: "News"
TransGaming updated their Point2Play utility. Version 1.1.1 is considered " a maintenance release that provides a number of incremental refinements and fixes some reported issues"
See the release notes (http://downloads.transgaming.com/files/point2play-1.1.1_releasenotes.txt) for more details.
2. Winecfg Status & Preferences
16�Sep�2003�-�18�Sep�2003 (11 posts) Archive Link: "Configuration parameters"
Topics: Status Updates
People: Mike Hearn,�Dimitrie Paun,�Max,�
Mike Hearn has done a lot of improvements to Winecfg lately and took a moment to write a list of things that remain to be done. Any one of these would be a great way to get involved with Wine. (ed note: This originally appeared as a patch):
TODO: (in rough order of priority)
Dimi Paun dropped an email the next day with a list of preferences in the current config file that needed to be reorganized. Some of the settings are too obscure to justify putting in a GUI config. With the improved registry editor it will be possible to just edit them there (just like those operating systems from Redmond.) Dimi's list:
|Name||The name of the property/section|
|Needed||Describes the form the parameter in needed in:
|Dynamic||Indicates if Wine should react to changes in the value of the parameter ar runtime|
|PerApp||Describes if the configuration parameter need to be customizable on a per-application basis|
|Default value||The default value for the property. This should allow Wine to run winecfg without user intervention|
There was a bit of discussion on the details of some of those options. Everyone seemed to agree on most of them.
3. System Tray Support
15�Sep�2003�-�16�Sep�2003 (11 posts) Archive Link: "Re: resend - system tray support"
People: Mike Hearn,�Alexandre Julliard,�Dmitry Timoshkov,�,�Sylvain Petreolle,�Microsoft,�Rolf Kalbermatter
Mike Hearn reposted a patch to add XEmbed (http://www.freedesktop.org/standards/xembed-spec/0.5-html/) system tray support, " I'm going to keep sending this flipping patch until it gets in, or I find out what the next problem is you know. There's no escape! :)"
Alexandre duly replied with things he didn't like, " Well, at least the critical section handling is broken, but the real problem is that all this stuff doesn't belong in shell32. We should really redesign it to get rid of the internal WS_EX_TRAYWINDOW flag and have a separate process to manage the tray window (plus other background tasks like the progman DDE interface, and maybe the desktop window too)."
There was then some debate over those details. Rolf Kalbermatter felt a bunch of it did belong in shell32 because Microsoft seemed to have some interfaces there, including DDE. Dmitry Timoshkov looked into and reported, " After looking again at the shell32 from win2k SP4 I've found that it really has the strings used by the progman DDE interface. The reason why I didn't find the first time is that strings are spread over the code section. So, yes, it seems that at least the progman DDE interface handler is residing in shell32. Now the question is: how we should implement it? Just add a necessary atom "progman" and create a hidden window on dll load event, or wait for some apparently undocumented API call and initialize only then? "
Dmitry's questions went unanswered. Before the thread ended Sylvain Petreolle mentioned he had applied the patch and reported success with Yahoo Messenger.
4. Blank Screen of Death
18�Sep�2003 (6 posts) Archive Link: "Starting wine turns off my screen"
People: Philipp Wollermann,�Roderick Colenbrander,�,�Sylvain Petreolle
Philipp Wollermann ran into a problem with the following symptoms:
I recently installed Mandrake 9.1 and updated it to the newest packages .. I'm using the ATI fglrx 3.2.5 driver for XFree 4.3.0 (I have a Hercules Radeon 9700) and playing 3D games like tuxracer works great. However, when I try to start any program with wine my screen gets dark and goes into standby. This happens even with Notepad or the programs included with Wine! This problem didn't happen on my earlier installations of Linux, but I can't say if it's the driver of my graphics card (maybe I should try an older version? mmh.), my Mandrake 9.1 or wine itself (I'm using the current version from CVS, just updated). Maybe somebody had this problem too and knows how to get wine running again?
The funny thing is: My PC keeps running, I can connect to it using SSH and kill wine, but this doesn't do anything about my screen. I can even start wine again (wine notepad.exe) and it gives me the usual output, no Errors or Warnings.
Sylvain Petreolle asked what version of Wine he was running. Philipp reported it was the latest CVS. Roderick Colenbrander jumped in an diagnosed the problem, " The problem you have is a bug in the dga code of the ati drivers. To workaround the problem set the option UseDGA to N in your config file. The strange part is that dga only works for root users and that this problem also appears for non-root users. "
Phillip changed the option and reported success.
5. Finding Memory Management Problems
17�Sep�2003�-�18�Sep�2003 (4 posts) Archive Link: "Bug in the heap management code?"
Topics: Memory Management
People: Michael Gunnewig,�Mike Hearn,�Shachar Shemesh,�Eric Pouech,�
Michael G�nnewig needed help figuring out what a game was trying to do and why it broke Wine:
When I try to play "The Elder Scroll III: Tribunal" version 1.4.1313 german under wine I get a page fault after some time. The time span differs and so the calling point of the heap management but it always occurs in HEAP_CreateFreeBlock in line 415.
Generating of a full "-debugmsg +heap" log is nearly impossible because it takes too long to start the game and start playing (after > 200 min. it still wasn't finished with initializing).
Mike Hearn offered his condolences, " This is very much like a problem I am having with InstallShield. Something, somewhere, is trashing the heap data structures, which causes a crash some time later, often yards away from the original bug. As far as I know, there is no good way to spot this problem, it's just C/C++ sucking.... maybe valgrind might help? "
Shachar Shemesh had an idea how memory use could be tracked but it involved Changing the way Wine allocates memory :
Something else that might help is an algorithm I suggested a long time ago, and which was not thought as worth the effort. Since I have not tried to run Wine with valgrind yet, I don't know whether it is or isn't.
The gist of it is that you pad each and every alloc with more memory, and you fill it in with signatures. When you release the memory, you check that the signatures are ok. Tweaking the amount of extra memory can cause you to not corrupt the heap structure at some point, which will allow you reliable pin-pointing the buffer in which the overflow occures.
I have never worked with valgrind (though I love the principle behind it), so I can't say whether it is more effective at this sort of problems. My method, in any case, is not very difficult to implement, so if valgrind does not provide what you need, I may invest the time in it.
Eric Pouech didn't think it would work in a lot of cases and also suggested Valgrind:
The issue with this approach is that you only trigger the check when releasing the block. It might well happen that the crash takes place before you free the memory. IMO, this is well suited to situations where either you have, from time to time, synchronisation points (you check the heap situation) or you check a memory block before using it (think of overloading operator-> in C++).
In this case it would help if:
IMO, running valgrind will allow you actually stop on the faulty write operation. valgrind is worth a try.
6. Library Loading Problem
12�Sep�2003�-�14�Sep�2003 (8 posts) Archive Link: "load library problem"
People: Dimitrie Paun,�Eric Pouech,�Alexandre Julliard,�Vincent Beron,�
Dimi had a problem loading a library:
I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples):
trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'
warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'; status=c000000f
Error: Could not load the application's module calendar-wrap.dll (126)
The piece of code that fails is from the automatically generated wrapper. Here is the part that fails:
I have the WINEDLLPATH set, what gives? Alexandre, I can't really track this easily back, but I have a gut feeling it got triggered by one of the reorganizations that you did around the loader...
Vincent Beron suggested changing WINEDLLPATH to include the current working directory. It didn't help. Eric Pouech then posted a small patch to winewrapper, but Dimi reported he wasn't using it. Then Eric suggested, " Another issue could be the (.so) dependencies on wine-calendar.dll.so which cannot be resolved."
Dimi posted how it was linked:
Hmm, that would be very odd. Do you see any problem with these:
[dimi_at_dimi calendar]$ ldd calendar.exe.so
����libwine.so =>usr/local/lib/libwine.so (0x40029000)
����libdl.so.2 =>lib/libdl.so.2 (0x40040000)
����libstdc++.so.5 =>usr/lib/libstdc++.so.5 (0x40044000)
����libm.so.6 =>lib/tls/libm.so.6 (0x400f8000)
����libgcc_s.so.1 =>lib/libgcc_s.so.1 (0x4011a000)
����libc.so.6 =>lib/tls/libc.so.6 (0x42000000)
����/lib/ld-linux.so.2 =>lib/ld-linux.so.2 (0x80000000)
[dimi_at_dimi calendar]$ ldd calendar-wrap.dll.so
����libwine.so =>usr/local/lib/libwine.so (0x402f5000)
����libstdc++.so.5 =>usr/lib/libstdc++.so.5 (0x4030c000)
����libm.so.6 =>lib/tls/libm.so.6 (0x403bf000)
����libgcc_s.so.1 =>lib/libgcc_s.so.1 (0x403e2000)
����libc.so.6 =>lib/tls/libc.so.6 (0x42000000)
����libdl.so.2 =>lib/libdl.so.2 (0x403ea000)
����/lib/ld-linux.so.2 =>lib/ld-linux.so.2 (0x80000000)
It seems to me calendar-wrap.dll.so has the same dependencies as calendar.exe.so (in a bit different order, does it matter?)
It appeared some private exchange took place off list, then Eric wrote the list with the solution, " after some more exchanges with Dimi, it turned out that this was caused by a too short buffer in relay32/builtin32.c_at_BUILTIN32_LoadLibraryExA (dllname was way to short). Alexandre, any reason for keeping this at 20 chars ? "
Alexandre committed a change and explained, " No, there's no reason, that's a leftover from the Win16 version. It should probably be MAX_PATH or something like that. "
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.