September 2004 - Wine-devel

(no subject)
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> For example, if DirectX is broken for 3 consecutive releases, I would expect > the people doing the release to label the old 'working' version and branch > from there if any bugs fixes are needed. Things in wine break all the time, users know it and are used to it, if d3d8 breaks for 3 releases, people will just use an old version until things are fixed. Many people stayed at wine-20031212 for months because of regressions that weren't fixed for a few months, but people just kept wine-20031212 and were happy. With alpha software this is quite normal. Ivan.

2 1

RE: Why is our OutputDebugString a server request?
by Raghavan Gurumurthy 13 Sep '04

13 Sep '04

I agree - I got stumped on this very issue when I got into Wine last year. I was used to relying on these trace messages and it took me a while to understand where the messages were actually being sent! //raghavan -----Original Message----- From: Shachar Shemesh [mailto:wine-devel(a)shemesh.biz] Sent: Monday, September 13, 2004 9:11 AM To: pouech-eric(a)wanadoo.fr Cc: Wine Development Subject: Re: Why is our OutputDebugString a server request? Pouech Eric DMI AEI CAEN wrote: > so that debuggers can intercept it (especially ones with GUI) and do > what they want with it. > A+ > > > > > Message du 13/09/04 17:50 > > De : "Shachar Shemesh" > > A : "Wine Development" > > Copie à : > > Objet : Why is our OutputDebugString a server request? > > > But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

A window update problem in Dutch tax program.
by Rein Klazes 13 Sep '04

13 Sep '04

Hi, I am looking in a display problem in the electronic declaration programs of the Dutch tax office. Here is a schematic of the windows involved: +--10022-------------------------------+ | | | +--100c6-------------------------+ | | | | | ..20110... | | | . . | | | . . | | | +-20114--+ | | | | | | | | | | | | | +--------+ | | | | | | | | +--------------------------------+ +--------------------------------------+ [10022] is a top level window. One of its child [20114] has itself a child window [20110] that initially lies outside the parent client area. A series of calls to ScrollWindowEx() brings it inside, simulating a drop down listbox. Now [20114] should normally not be visible because it lies behind another child of the main window: [10022] | +--[20114] | | | +--[20110] | | +-[100c6] | + ... No window styles that could affect this behavior (WS_CLIPCHILDREN, WS_CLIPSIBLINGS, WS_EX_TRANSPARENT) are used. Here the partial output of info wnd command: 00010022 WindowIB2003 14cb0000 00000000 Aangifte 2003 00020114 WindowIB2003 50000000 00000000 -- Empty -- 00020110 @LISTBOX 50800141 00000000 -- Empty -- 000100c6 WindowIB2003 50000000 00000000 TheContent The program first validates the update region of the main window with the rect of [20114]. |0009:Call user32.ValidateRect(00010022,4070f988) ret=00426f64 ... |trace:win:RedrawWindow Update region of hwnd 0x10022 is nil |0009:Ret user32.ValidateRect() retval=00000001 ret=00426f64 As the extra trace message reports, this window has a null update region at this point. Then the first scroll is requested: |0009:Call user32.ScrollWindowEx(00020114,00000000,0000000a,4070f6e4,4070f6b4,00000000,00000000,00000001) ret=00426fd1 |trace:scroll:ScrollWindowEx 0x20114, 0,10 hrgnUpdate=(nil) rcUpdate = (nil) (0,-47)-(71,0) 0001 |trace:scroll:ScrollWindowEx clipRect = (0,0)-(71,10) ... |0009:Ret user32.ScrollWindowEx() retval=00000001 ret=00426fd1 directly after this the same scroll rectangle (4070f6e4) is invalidated: |0009:Call user32.InvalidateRect(00020114,4070f6e4,00000001) ret=00426fe6 |trace:win:RedrawWindow 0x20114 (0x137e) rect 0,0-71,10 (nil) flags=0005 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE ... |0009:Ret user32.InvalidateRect() retval=00000001 ret=00426fe6 and directly UpdateWindow is called: |0009:Call user32.UpdateWindow(00020114) ret=00426fef |0009:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,4070f460,00000000,000000ff,00000000) ret=40764927 |trace:event:EVENT_ProcessEvent called. UpdateWindow calls RedrawWindows that first looks for outstanding events, that is where the trouble starts: |trace:event:EVENT_ProcessEvent Got event Expose for hwnd/window 0x20114/3a001aa, GetFocus()=0x20112 |trace:x11drv:X11DRV_Expose win 0x20114 (3a001aa) 0,0 71x47 ... |0009:Call user32.RedrawWindow(00010022,4070f010,00000000,00000085) ret=40d519a2 |trace:win:RedrawWindow 0x10022 ((nil)) rect 291,142-362,189 (nil) flags=0085 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and the main window and child [100c6] find them selves invalidated: |trace:win:RDW_Paint hwnd 0x10022 [0x1382] -> hrgn [0x139e], flags [0085] ... |trace:win:RDW_Paint hwnd 0x100c6 [0x138a] -> hrgn [0x139e], flags [0085] after the final scroll, a WM_PAINT message is dispatched to [100c6] and the scrolled window [20114] is invisible. I am not sure what the real problem is: either the expose event should not be there or the handling of the event is wrong. For the latter case: the handling in expose_window() sure does not expect to make visible a normally obscured window. Any suggestions? The program is available on-line, but I would need to give some instruction for non-Dutch users. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: Directx9
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> If we as a project are committed to doing 0.9, 1.0+ releases it means we > can't simply break code people are using to play their games for months > at a time and shrug it off After 1.0 there will be a stable and a development branch, the stable one for users, and the development one for new stuff, where it doesn't matter if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work. Ivan.

3 2

Re: Http Fixes
by Marcus Meissner 13 Sep '04

13 Sep '04

On Mon, Sep 13, 2004 at 11:38:32AM +0100, Robert Shearman wrote: > Hi, > > I have seen one server that likes to return "ICY" instead of "HTTP/1.x". > This patch allows the connection to the server continue, as native does. This would be "icecast" I suspect ;) Ciao, Marcus

1 0

Re: Wininet: InternetSetStatusCallback Fix
by Robert Shearman 13 Sep '04

13 Sep '04

Robert Shearman wrote: > Hi, > > You can call InternetSetStatusCallback on a HTTP handle, not just a > InternetOpen handle, so we should search up through the parents to > find it. Oops, I just checked on MSDN and this patch is wrong. We should copy and store the status callback in every handle, not just in the top level one. I'll submit a new patch soon. Rob

1 0

PEB documentation
by Mike Hearn 13 Sep '04

13 Sep '04

This is interesting information, but where did it come from? Is this structure described in some MS documentation? If so, does it have the full layout of the TEB as well? > Log message: > Robert Reif <reif(a)earthlink.net> > Document all the structure members up to SessionId in the PEB.

1 0

Re: winecfg (was Re: W->A calls)
by Mike Hearn 13 Sep '04

13 Sep '04

> It appears that Mike has been doing a lot of work on this. > http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html > So you probably first want to coordinate with him. Yes. I'm aware that I'm holding people up right now due to my non-connectedness. I'm actually living in a bed&breakfast with no net connection, so I only have web/email access at work. It's kind of odd - I've been doing some work on it lately, and suddenly people pop up who want to work on it after a long period of inactivity. Oh well :) > I would start by running "winecfg", and seeing what doesn't work, which > is a lot. For example, on the very first tab, you can select a "Windows > Version", but changing the setting doesn't actually change anything (it > should make/alter a registry entry). The winecfg code is in > wine/programs/winecfg. Fixed by me already. Actually, I've done quite a bit of work on it, I'd recommend waiting for 2 weeks at which point I'll have net access to my laptop again and can hopefully send off my work. At that point I'll be disappearing back into university life and doing CW work again so the coast will be clear for others to work on it. > A long discussion of things that are needed is in the thread starting: > http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I've sorted some of these already, especially in the apps tab. So ... if you guys can wait for 2 weeks I should (hopefully) have something to show soon. thanks -mike

1 0

RFC: ntdll critical section debug
by Robert Reif 13 Sep '04

13 Sep '04

I have been running into deadlock problems in the direct sound dll and have been playing with the debug part of critical sections. I added a lock name to Spare[1] to give the critical sections names that will show up in the error messages just like wine's ntdll does. After looking at the ntdll code, it looks like this causes a leak because ntdll statically initializes it's locks and doesn't delete the debug part when it finds Spare[1] used. I also tried adding a linked list of critical section debug structs just like real windows does. Because ntdll statically initializes it's locks, they don't get added to the list. I manually stuff the critical section list lock into the list so it shows up and user locks show up but not the other internal ntdll locks. Is there a good reason to statically initialize ntdll locks or can they be initialized like normal locks? Here is a patch that adds the linked list of debug info: Index: dlls/ntdll/critsection.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v retrieving revision 1.27 diff -u -r1.27 critsection.c --- dlls/ntdll/critsection.c 6 Sep 2004 20:26:23 -0000 1.27 +++ dlls/ntdll/critsection.c 10 Sep 2004 16:29:14 -0000 @@ -36,6 +36,51 @@ WINE_DEFAULT_DEBUG_CHANNEL(ntdll); WINE_DECLARE_DEBUG_CHANNEL(relay); +static LIST_ENTRY RtlCriticalSectionList; +static CRITICAL_SECTION RtlCriticalSectionLock; +static CRITICAL_SECTION_DEBUG RtlCriticalSectionDebug = +{ + 0, 0, &RtlCriticalSectionLock, + { &RtlCriticalSectionDebug.ProcessLocksList, + &RtlCriticalSectionDebug.ProcessLocksList }, + 0, 0, { 0, (DWORD)(__FILE__ ": RtlCriticalSectionLock") } +}; +static CRITICAL_SECTION RtlCriticalSectionLock = { &RtlCriticalSectionDebug, -1, 0, 0, 0, 0 }; + +void critsection_init() +{ + InitializeListHead( &RtlCriticalSectionList ); + InsertHeadList( &RtlCriticalSectionList, &RtlCriticalSectionDebug.ProcessLocksList ); +} + +static void CRIT_Dump() +{ + int i = 0; + PLIST_ENTRY mark, entry; + PCRITICAL_SECTION_DEBUG debug; + + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + + mark = &RtlCriticalSectionList; + for (entry = mark->Flink; entry != mark; entry = entry->Flink) + { + debug = CONTAINING_RECORD(entry, CRITICAL_SECTION_DEBUG, ProcessLocksList); + + TRACE("RtlCriticalSectionDebug[%d]:\n", i++); + TRACE(" Type = %04x\n", debug->Type); + TRACE(" CreatorBackTraceIndex = %04x\n", debug->CreatorBackTraceIndex); + TRACE(" CriticalSection = %p\n", debug->CriticalSection); + TRACE(" ProcessLocksList.Flink = %p\n", debug->ProcessLocksList.Flink); + TRACE(" ProcessLocksList.Blink = %p\n", debug->ProcessLocksList.Blink); + TRACE(" EntryCount = %ld\n", debug->EntryCount); + TRACE(" ContentionCount = %ld\n", debug->ContentionCount); + TRACE(" Spare[0] = %08lx\n", debug->Spare[0]); + TRACE(" Spare[1] = %08lx (%s)\n", debug->Spare[1], debugstr_a((char *)debug->Spare[1])); + } + + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); +} + inline static LONG interlocked_inc( PLONG dest ) { return interlocked_xchg_add( dest, 1 ) + 1; @@ -126,12 +171,16 @@ crit->DebugInfo->Type = 0; crit->DebugInfo->CreatorBackTraceIndex = 0; crit->DebugInfo->CriticalSection = crit; - crit->DebugInfo->ProcessLocksList.Blink = &(crit->DebugInfo->ProcessLocksList); - crit->DebugInfo->ProcessLocksList.Flink = &(crit->DebugInfo->ProcessLocksList); crit->DebugInfo->EntryCount = 0; crit->DebugInfo->ContentionCount = 0; crit->DebugInfo->Spare[0] = 0; crit->DebugInfo->Spare[1] = 0; + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + InsertTailList( &RtlCriticalSectionList, &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } } crit->LockCount = -1; @@ -195,12 +244,19 @@ crit->LockSemaphore = 0; if (crit->DebugInfo) { + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + RemoveEntryList( &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + /* only free the ones we made in here */ if (!crit->DebugInfo->Spare[1]) { RtlFreeHeap( GetProcessHeap(), 0, crit->DebugInfo ); crit->DebugInfo = NULL; } + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } return STATUS_SUCCESS; } Index: dlls/ntdll/ntdll_misc.h =================================================================== RCS file: /home/wine/wine/dlls/ntdll/ntdll_misc.h,v retrieving revision 1.48 diff -u -r1.48 ntdll_misc.h --- dlls/ntdll/ntdll_misc.h 15 Jul 2004 22:07:21 -0000 1.48 +++ dlls/ntdll/ntdll_misc.h 10 Sep 2004 16:29:14 -0000 @@ -50,6 +50,7 @@ extern void debug_init(void); extern void thread_init(void); extern void virtual_init(void); +extern void critsection_init(void); /* server support */ extern void server_init_process(void); Index: dlls/ntdll/thread.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/thread.c,v retrieving revision 1.21 diff -u -r1.21 thread.c --- dlls/ntdll/thread.c 23 Aug 2004 18:52:54 -0000 1.21 +++ dlls/ntdll/thread.c 10 Sep 2004 16:29:14 -0000 @@ -134,6 +134,7 @@ debug_info.str_pos = debug_info.strings; debug_info.out_pos = debug_info.output; + critsection_init(); debug_init(); virtual_init();

3 2

spying COM
by Saulius Krasuckas 13 Sep '04

13 Sep '04

Am not sure would it be of any use for list members, but just some minutes ago I've discovered "The COM spy". Quite old stuff, but whatever: http://staff.develop.com/jasonw/comspy/default.htm

2 1