Wine Traffic #102 For 15 Aug 2001

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).

There were 48 different contributors. 25 posted more than once. 21 posted last week too.

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

[windows] 

		 device=XXX

and as this entry doesn't exist (it's "HP LaserJet 5M,PCL5EMS,LPT1:" here), the app does all sorts of very strange things

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

The in_data pointer is null but the code assigns to it, thats why it crashes. I think that the result should be assigned to the output parameter.

Alexandre realized, " Yes of course, stupid typo on my part. Thanks for spotting it."

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."

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:

the wineserver is responsible for all system level synchronization of wine processes, and maintaining integrity of handles
the wineserver is the sole repository for all HANDLE data in the wine process group.
wineserver communicates with each wine process thru a socket and shared memory. There is one socket and one shared memory area per wine process.
the main task of wineserver is a loop which polls on all the wine process sockets, and handles timeouts.
the wineserver processes requests one by one (it is a single thread).
each request is triggered by the wine process writing to its socket, and ended when the wineserver writes back to the socket. During the request, the wine process is effectively stopped.
request data may be read to or written from the shared memory, but the shared memory is not used for synchronization. Synchronization is maintained solely by socket reads and writes.
the wineserver should end each request before processing the next
the wineserver must never wait for or depend upon any wine processes. All wine processes must be assumed to be unstable and unreliable. (even if they're not)
the wineserver design is reliable, but rather slow due to all the context switching required by each request. David Howells made an effort to turn it into a Linux kernel module... he hasn't finished yet.

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 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

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? :-)

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)" .

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). "

Daniel Walker was having a problem with the poll() 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. 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.

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. "

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 ~/.wine/user.reg change the [Software\Wine\WineDbg] 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 with: ./debugger/winedbg 2>&1 | tee output.log ) "

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.

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

Backtrace is:
Backtrace: =>

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\gcp9.0.0.8\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?

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.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

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

Wine Traffic #102 For 15 Aug 2001

By Brian Vincent