Wine is not guilty at all, AFAICS. It's a totally dainbread application, that's why.

It checks win.ini

[windows]
device=XXX

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 ?

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

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?

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!

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.

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

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?

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

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)

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.

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.

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?