Table Of Contents
|1.||1 Aug 2001 - 7 Aug 2001||(9 posts)||16-bit Printer Drivers|
|2.||8 Aug 2001 - 13 Aug 2001||(9 posts)||Unable to use RegisterClass(&WndClass);|
|3.||14 Aug 2001 - 15 Aug 2001||(7 posts)||Navigating Through Wine|
|4.||8 Aug 2001||(2 posts)||Winelib Application Debugging|
|5.||15 Aug 2001 - 16 Aug 2001||(4 posts)||Using WinHelp|
|6.||15 Aug 2001 - 16 Aug 2001||(9 posts)||Ignored Sockets|
|7.||15 Aug 2001||(2 posts)||Adding FIXME's|
|8.||15 Aug 2001||(3 posts)||Using the Debugger|
|9.||15 Aug 2001||(3 posts)||Finding Locking Bugs|
|10.||15 Aug 2001||(3 posts)||DC lock in CreateDIBitmap|
This is the 102nd 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 157 posts in 473K.
There were 48 different contributors. 25 posted more than once. 21 posted last week too.
The top posters of the week were:
1. 16-bit Printer Drivers
1 Aug 2001 - 7 Aug 2001 (9 posts) Archive Link: "Re: CS_PARENTDC with WS_CLIPSIBLINGS"
People: Ladislav Sladecek, Andreas Mohr, Alexandre Julliard,
Ladislav Sladecek had a problem getting a program working and traced the problem to the handling of some flags in GetDCEx. Alexandre Julliard replied that he thought all of those should be fixed in the latest version of CVS. Ladislav thought the fix was fine, but was still unable to get the app, prowin.exe from Progress RDBMS, to run. It's a 16-bit app and according to Ladislav, " After the menu is drawn, the application stops responding and complains about some illegal string operations and then about unknown driver ,, in GetDCA."
He attached a trace with all of the debugging information in it. From that Andreas Mohr concluded the program was dainbread:
Wine is not guilty at all, AFAICS. It's a totally dainbread application, that's why.
It checks win.ini
My guess is that this application exhibits so braindead, non-checking behaviour since this win.ini entry is absolutely expected to exist.
Unfortunately I can't see from this short log why it checks the printer at all. We might want to make sure that in case we get asked for a printer, we also have a device= line in place, and if this isn't the case, then issue a fat warning to the end user. So OTOH Wine is probably guilty by not making sure that there is a device= line in case of psdrv or something.
What happens if you run this program on a windoze box without any printer installed ? (and thus the device= line should not exist, there, too...) Does it fail the same way or does it seem to recognize somehow that there is no printer installed ?
Ladislav said Windows had no problems if a printer wasn't installed. However, he found a patch from 7/26/2001 that indicated 16-bit printer driver support does not ever get initialized, regardless if a printer is installed. Alexandre replied, "actually the 16-bit driver support is temporarily broken (not that it really worked well before anyway). It shouldn't be too hard to fix, but I haven't had time yet. Volunteers are welcome..." .
Ladislav dug a little deeper and discovered that the unknown driver error has actually always been occuring, but the message only recently appeared because Alexandre had it printed out. However, he found, " The real reason for the crash is that the application calls Escape16 with hdc equal to 0 and function equal to GETPRINTINGOFFSET. I do not understand why, they did not even start to print. Maybe, this is an undocumented windows function? After I temporarily disabled Escape16, the application began to work. " . To reenable Escape16 he would require working 16-bit printer drivers. What Alexandre wondered though was, " It's not supposed to crash even if the hdc is invalid. Do you have a backtrace of the crash?" .
I ovelooked that the EscapeXXXX functions changed too.
The function is called like this:
0806c1c8:Call GDI.38: ESCAPE(0x0000,0x000d,0x0000,0x00000000,0657:e8f4) ret=0ff7:4428 ds=1207
Alexandre realized, " Yes of course, stupid typo on my part. Thanks for spotting it."
2. Unable to use RegisterClass(&WndClass);
8 Aug 2001 - 13 Aug 2001 (9 posts) Archive Link: "Unable to use RegisterClass(&WndClass);"
People: Craig Chandler, Dmitry Timshkov, , Dmitry Timoshkov
Craig Chandler's question:
when i use the RegisterClass(&WndClass); under wine the call fails. I'm using it to sub class the button class. Does wine not support this?
Dmitry Timoshkov asked to see the offending code which Craig provided. Craig has had the program working under all versions of Windows for years. Dmitry suggested, " As a temporary workaround you could use unique class names for local classes. " . In addition he provided some patches to try out.
Craig tried this and replied, " ok, played around with both patches, both refuse to start the application with errors in invalid class names. Changed my own source to rename the "button" class to my own custom name ("ifbutton") and it starts fine. (so the original class.c works). Had a whole lot of other errors but i'll get to them later. I'm reading up on how to debug wine at the moment (i'm a new user) so hopefully i'll get some more usefull info to you later."
3. Navigating Through Wine
14 Aug 2001 - 15 Aug 2001 (7 posts) Archive Link: "Wine call graph; wineserver; the big picture"
People: Phillip Schmitz, Mike McCormack, Dan Kegel, , David Howells, Gavriel State
Phillip Schmitz wanted to start working on implementing COM/DCOM functionality. What he was having a hard time understanding was the relationship of the various parts of Wine and the interdependencies of the code. He wrote:
I've read most of the developer docs and some relevant source but I'm still having problems grokking the interrelationships between different parts of wine and the role(s) of wineserver. I have a general understanding of Win32 from a programatic point of view rather than wine's implementation details. While I'm quite willing to "read the source" there's rather a lot of it :) and rather deep dependencies (even with tags one jumps around for a while trying to understand what does what).
Does anyone have a call graph for wine or a (decent, open-source) program for making one. I've considered Source-Navigator but it seems like the required database would be twice the size of the wine source!
Gavriel State and a few others wrote back about the work going on right now to support out of process COM. They pointed out some work that could be done in that area. Mike McCormack wrote a description about the features of the wineserver:
The wineserver does the job of the Windows NT kernel in wine. Here's a summary of what i've worked out about the wineserver:
Phillip also wanted to know what people use in term of test suites. He would really like to be able to use many small test apps. Dan Kegel replied:
There *is* a COM conformance test suite; see http://www.microsoft.com/msj/1298/ntUnix/ntUnixtop.htm (http://www.microsoft.com/msj/1298/ntUnix/ntUnixtop.htm) I doubt that Microsoft would let Wine developers use it, though.
On the other hand, the Open Group sells COM/DCOM implementations packaged with the interoperability test suite at a "nominal fee"; see http://www.opengroup.org/comsource/datasheet.htm (http://www.opengroup.org/comsource/datasheet.htm)
They have released things like Motif as open source in the past... I wonder if they'd be willing to contribute their DCOM or the test suite? That would rock.
Anyone know anyone who works at the Open Group? :-)
4. Winelib Application Debugging
8 Aug 2001 (2 posts) Archive Link: "winelib application debugging"
People: Vitaly Kuznetsov, Eric Pouech,
This was just a question and answer. Vitaly Kuznetsov wondered, " Is there currently any way to debug winelib application? I read winedbg doc, but there are only samples for windows executables. " .
Eric Pouech replied, " you can also debug winelib applications with winedbg and you should get access to both the executable information and the different loaded DLL (counting the Wine builtin ones)" .
5. Using WinHelp
15 Aug 2001 - 16 Aug 2001 (4 posts) Archive Link: "Does Wine's winhlp work?"
People: David Hagood, Bobby Bingham,
David Hagood was wondering about the status of using Wine's WinHelp program to open up help files:
Is Wine's WinHelp program supposed to work? By that I mean, if I invoke that program with a Windows help file, is it supposed to be able to display the contents of the help file as Window's winhelp.exe would?
I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses WinHelp format documents for some of its normal operation, and 2) I have a WinHelp format file I'd dearly like to be able to access directly from Wine.
When I try to launch Wine's Winhelp, it brings up a window, but the window is empty. If I go to File->Open and try to open a WinHelp file, I get the same result. Is there some setup I'm missing?
Several other people were experiencing the same thing. Bobby Bingham suggested using winhlp32.exe from Windows, " I get the same thing. I think Wine's winhelp isn't supposed to work yet. If you have access to the windows winhlp32.exe, it runs perfectly under wine (afaict better than in windows. I have a help file that creating a search index always crashes it under windows. Under wine it doesn't work, but it recovers without crashing). "
6. Ignored Sockets
15 Aug 2001 - 16 Aug 2001 (9 posts) Archive Link: "not-yet-connected sockets?"
People: Daniel Walker, , Ove Kåven
Daniel Walker was having a problem with the
implementation in the 2.4 kernel:
The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications?
a socket is created using socket() then, say, ioctl() is run on it. ioctl() then ,through the wineserver, runs sock_reselect() then poll() returns POLLHUP in revents and the wineserver stop watching the socket .. Since most non-blocking applications run socket() then ioctl() I would think that several applications would be effected..
Ove Kåven didn't understand what the problem was since a patch had been submitted a year and half ago fixing the problem. He gave a link to it at: http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12 (http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12) . Daniel's problem seemed to be with running Bearshare and he submitted a one-liner commenting out the sock_reselect() so that the poll() doesn't happen.
7. Adding FIXME's
15 Aug 2001 (2 posts) Archive Link: "Protocol for adding FIXMEs"
People: Bill Medland, Alexandre Julliard,
Bill Medland was wondering what the procedure was for adding FIXME's to the code:
I seem to have a knack for finding things that are probably going to need fixing at some point but for which I do not have time or knowledge currently. My first temptation is to add a FIXME macro in the code directly.
However I am occasionally frustrated by the number of times I see the same FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also recognise from posts that these disconcert newbies whereas after a couple of weeks one gets used to them.
So maybe it is better to use FIXME comments where one knows that something is wrong but it doesn't seem to matter.
I know that the manual (wine-devel 8.0) says to add FIXMEs I am concerned that this could lead to ridiculously large traces that hide the important stuff (to say nothing of upsetting timing)
Alexandre explained, " FIXME macros should be used in cases where we know something is wrong but we don't expect this part of the code to ever get used. This way if some app triggers the wrong code we can hear about it. It doesn't make sense to add FIXME output to parts of the code we know are going to be called, it just generates noise; a comment is much better in this case. "
8. Using the Debugger
15 Aug 2001 (3 posts) Archive Link: "Stupid Winedbg question"
People: Bobby Bingham, James Hatheway,
Bobby Bingham wondered:
Ok, I feel like an idiot for having to ask this, but it's my first time realing using the debugger. When wine starts the debugger on an exception, it opens it up in another xterm. Is there an easy way to copy it's output? The usual select and middle-click isn't working because it doesn't let me select the text to begin with.
James Hatheway suggested,
Hold the Shift key while selecting the text. Or, in your
UseXTerm key from 01 to 00.
I find that is more useful so that all the output can be put
into a file for later perusal. (ie. I usually run the debugger
./debugger/winedbg 2>&1 | tee output.log )
9. Finding Locking Bugs
15 Aug 2001 (3 posts) Archive Link: "patch.py?id=997918367324549717828631"
People: Lawson Whitney, Alexandre Julliard,
This thread will dovetail into the next one. Lawson Whitney posted a report:
I guess native riched32.dll does something nasty to provoke the new DbgBreakPoint in _CheckNotSysLevel. Builtin riched32 doesn't, of course, but then the app won't start.
I can't remember that I've ever seen the fixme that was here before, but I'll check again when I send this.
I've attached a backtrace. I'd appreciate some guidance on what else might be useful, or maybe a pointer to some doco on critical sections in Wine, even it is in .sgml, .c or .h in case I have to debug it myself.
Alexandre replied with a patch and a note that said, " No, the CheckNotSysLevel calls were not done before. I added a few of them in GDI to find potential locking bugs; seems pretty successful so far ;-) " Lawson tested the patch and found it worked.
10. DC lock in CreateDIBitmap
15 Aug 2001 (3 posts) Archive Link: "DC lock in CreateDIBitmap"
People: Uwe Bonnes, Alexandre Julliard,
I almost never include parts of posts that include traces. Many times they're quite long and are often easier explained in English. However, I realize a lot of people reading this may never have looked at them and might find it interesting. Here's a short one that came up this week and it's relatively straight forward. Uwe Bonnes wrote:
with the new
GDI_CheckNotLock() stuff, some application (gcprevue 9) fails with
> err:win32:_CheckNotSysLevel Holding lock 0x4079b9e8 level 3
0 0x400e21d1 (_CheckNotSysLevel+0x51(lock=0x4079b9e8) [syslevel.c:152] in libntdll.so) (ebp=405c6090)
1 0x4078261c (GDI_CheckNotLock+0x1c [gdiobj.c:510] in libgdi32.so) (ebp=405c60a0)
2 0x4077823d (CreateDCA+0x1d(driver=0x407909d3, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x407909d3) [dc.c:558] in libgdi32.so) (ebp=405c61e8)
3 0x4077bbc6 (CreateDIBitmap+0x166(hdc=0xdec, header=0x41eadb50, init=0x0, bits=0x0, data=0x41eadb50, coloruse=0x0) [dib.c:881] in libgdi32.so) (ebp=405c6218)
4 0x409f9479 (X11DRV_DIB_CreateDIBSection+0x359(dc=0x404225f4, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:3914] in libx11drv.so) (ebp=405c62a0)
5 0x4077bd75 (DIB_CreateDIBSection+0x65(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:944] in libgdi32.so) (ebp=405c62d4)
6 0x4077bdd1 (CreateDIBSection+0x31(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0) [dib.c:961] in libgdi32.so) (ebp=405c6304)
7 0x00401fba (gcprevue.exe..text+0xfba in D:\cae\gcp22.214.171.124\gcprevue.exe) (ebp=ffffffff)
CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause is true,
CreateDCA() checks that the lock is not hold. A laymans approach to release hdc before
CreateDCA() and reopen it afterwards resulted in this report asr startup, with no visual output:
fixme:win32:PE_CreateModule Security directory ignored
err:win32:_LeaveSysLevel (0x4079ba08, level 3): Invalid state: count 0 mutex (nil).
err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=030f
err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=031f
err:ntdll:RtlpWaitForCriticalSection section 0x4079ba08 "gdiobj.c: GDI_level" wait timed out, retrying (60 sec) fs=008f
How to cure this problem?
Alexandre replied with a small patch and explained,
I don't think we should be using CreateDC at all in CreateDIBitmap. Could you try this?
diff -u -r1.59 dib.c
--- objects/dib.c 2001/08/15 23:33:20 1.59
+++ objects/dib.c 2001/08/16 21:08:12
@@ -875,12 +875,7 @@
/* Now create the bitmap */
- if (fColor)
- HDC tmpdc = CreateDCA( "DISPLAY", NULL, NULL, NULL );
- handle = CreateCompatibleBitmap( tmpdc, width, height );
- DeleteDC( tmpdc );
+ if (fColor) handle = CreateCompatibleBitmap( hdc, width, height );
else handle = CreateBitmap( width, height, 1, 1, NULL );
if (!handle) return 0;
Uwe reported success. And as a side note, that entire exchange of email from bug report to patch occured over the span of about 1.5 hours on Thursday.
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.