July 2008 - Wine-Bugs - list.winehq.org

[Bug 14019] systray icon not displayed in dual screen

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14019 --- Comment #8 from Jonathan Isom <jeisom(a)gmail.com> 2008-07-22 20:02:03 --- Looks Good Thanks -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 23, 2008

[Bug 7711] tomtom home does not find the device go 901

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=7711 --- Comment #49 from Lennart Hansen <lahansen(a)gmail.com> 2008-07-22 19:53:16 --- Is anyone looking into this issue? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 23, 2008

[Bug 10342] Implement ClearType also known as SubPixel Rendering

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10342 --- Comment #14 from Erik Johnson <junk1112(a)new.rr.com> 2008-07-22 18:41:29 --- > The bug seems perfectly valid to me. There's no reason that Wine shouldn't be > able to take advantage of subpixel rendering where it's supported. > Absolutely. Java, Openoffice.org 3, Firefox, Opera, KOffice, and every other GUI application I run on my system take advantage of subpixel rendering when available. Wine is the only one that doesn't; it's the odd one out. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 13057] BYOND.exe: crashes upon attempting to log in.

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13057 Stephen Badger <sb1105(a)ecs.soton.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #8 from Stephen Badger <sb1105(a)ecs.soton.ac.uk> 2008-07-22 18:39:53 --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 13057] BYOND.exe: crashes upon attempting to log in.

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13057 --- Comment #7 from Stephen Badger <sb1105(a)ecs.soton.ac.uk> 2008-07-22 18:38:41 --- Created an attachment (id=14994) --> (http://bugs.winehq.org/attachment.cgi?id=14994) Console output from running BYOND with the built-in ole32.dll, attempting login. Attached a console output run from a Gentoo AMD64 machine, WINE Version 1.1.0. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 18:19:46 --- Created an attachment (id=14993) --> (http://bugs.winehq.org/attachment.cgi?id=14993) +tid,+seh,+msg,+win,+relay showing endless paint loop problem Hello, attached is full relay (cut to ~24000 lines) showing the problem. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #6 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 17:51:56 --- Created an attachment (id=14992) --> (http://bugs.winehq.org/attachment.cgi?id=14992) Recorded call sequences from window proc (wine, endless paint looping) Hello again, attached is the call sequence in Wine for comparison. Note: I didn't use WINEDEBUG but my debugger+scratchpad to keep same style for better comparison (diffing) with previously posted attachment. In short: Wine: (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCACTIVATE (active = FALSE) (#4) WM_NCPAINT (Region = 00000001) .. <repeats forever (same as #4)> .. This is different from previously posted behaviour of app in Windows: (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCPAINT (Region = 0004083B, valid region) (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT (Region = BB040864, valid region) <refresh finished, ends here> Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 14592] Soldat Performance Spikes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14592 --- Comment #3 from Brian <tehstealth(a)yahoo.com> 2008-07-22 16:59:44 --- Using the latest drivers Ubuntu has (169.something I think) with an Nvidia 8800GTS. Yes, I noticed that when you die, the respawn countdown timer flashes for every millisecond it counts. This lags a little bit too, but nothing compared to the crawling speeds of when the menu comes up. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 10620] PAF 5 help viewer hits unhandled page fault while closing

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10620 ben <beckyben2000junk(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #4 from ben <beckyben2000junk(a)yahoo.com> 2008-07-22 16:59:13 --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008

[Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #5 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 16:55:29 --- Created an attachment (id=14991) --> (http://bugs.winehq.org/attachment.cgi?id=14991) Recorded call sequences from window proc (expected behaviour) Hello, there seem to be at least two issues involved here. It's a pain to debug this large app with all its unmanaged and managed code so I sticked with investigating windbg behaviour in hope that's the same issue as VS.NET 2005 Basically the message sequence for the affected window goes like this (5 calls of that winproc): (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (#3) WM_NCPAINT (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT After that sequence, the window refresh is finished. The info for the affected window (opened via toolbar): --- snip --- Title="Scratch Pad - WinDbg:6.9.0003.113 X86" Parent=00030460 Style=96CD0000 WS_POPUP|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION ExtStyle=00000100 WS_EX_WINDOWEDGE Class=WinBaseClass --- snip --- Parent (top level): --- snip --- Title="WinDbg:6.9.0003.113 X86" Parent=Topmost Style=16CF0000 WS_OVERLAPPED|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION ExtStyle=00000110 WS_EX_ACCEPTFILES|WS_EX_WINDOWEDGE Class=WinDbgFrameClass --- snip --- I made note of each user32 call within the app window proc to keep things simple. After comparing both sequences, I noticed the following problem: hRegionClip = NULL; Flags = DCX_WINDOW | DCX_INTERSECTRGN; The call to user32.GetDCEx( hWndScratchWindow, hRegionClip, Flags) returned NULL on Windows XP while Wine returned a valid DC. After further investigation with google it seems this is some sort of undocumented behaviour, see: http://www.virtualdub.org/blog/pivot/entry.php?id=37 --- quote --- As a side note, a poster on the forum recently helped me track down an irritating bug in VirtualDub's draggable video frames that was causing some instability on Win9x platforms. It happened because of a code fragment that I adapted from the MSDN Library documentation for WM_NCPAINT that supposedly helps you draw custom window frames. Well, the code fragment as given doesn't work, because it lacks an essential flag. GetDCEx() simply returns NULL and leaves the error code as NO_ERROR. You need to add 0x10000, called "an undocumented flag which can magically make GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the function to actually return a usable DC. It turns out that there is an even worse problem with the code as given because it causes window regions to be doubly freed! On Win9x, this results in an occasional crash in 16-bit GDI. (This particular problem with the WM_NCPAINT example is also colorfully documented in comments in the WINE source code.) After I fixed this issue, the poster's problem went away. So if you are using a Win9x platform, expect some stability improvements in edit mode in 1.6.4. --- quote --- I patched dlls/user32/painting.c:GetDCEx for testing purposes but it didn't solve the endless looping problem. The call sequences within that app window proc where GetDCEx was involved were more matching, showing slight improvement over previous situation. It seems the app directly checked for GetDCEx() returning NULL and took that into account (expecting such result). It remains mysterious why a Micro$oft app actually made this call with hard coded flags when it's expected to return NULL? Maybe the people there don't talk to each other/suffer from their own MSDN hell ;-) Maybe some Windows versions show different behaviour? This has to be added to conformance test ... Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 22, 2008