August 2010 - Wine-Devel - list.winehq.org

Re: New and subtle ddraw:dsurface test failure

by wylda＠volny.cz

Hi, > Do you mean this problem? > ddraw:dsurface start ... Nope and nothing about 64bit (there was no change). I was initially talking about changed result from last Friday. To be precise this new information showed up under WinXP 32bit on nvidia 8600GT: dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned 0x00000003 dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned 0x00000003 And i had a slight feeling, that i saw you, Oldrich, doing some changes in this are. Thus decided to substitute "paranoid android" aka testbot(a)testbot.winehq.org. Last note, intel card i915gm does not fail on this "Surface_Flip" and thus i decided to pinpoint this issue for nvidia. Regards, W.

Aug. 9, 2010

winepath bug without arguments?

by Jerome Leclanche

Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: adys(a)azura:~/.wine/drive_c$ winepath -w adys(a)azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Reece Dunn

2010/8/9 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > 2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>: >> Hi W, >> >> On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: >>> Hi, >>> >>> i >> just noticed some new and subtle failure in ddraw:dsurface >>> tests. I don't >> know how closely you watch and study tests >>> results, so i thought it might >> be a good idea bring it the >>> the light. Sorry if not ;-) >>> >>> Compared >> WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last >>> Friday). >>> >>> >> Interestingly does not happen on Intel and nVidia 64bit. So >>> the only >> affected is nVidia 32bit. >> >> Do you mean this problem? >> >> ddraw:dsurface start - >> - >> dsurface.c:419: Tests skipped: Failed to create surface >> dsurface.c:801: >> Test failed: IDirectDraw7_QueryInterface returned 80004002 >> dsurface.c:808: >> this is the last test seen before the exception >> dsurface: unhandled >> exception c0000005 at 00413A29 >> ddraw:dsurface done (4294967295) >> >> I've seen >> this also during my first tests. From my understanding the problem of >> unhandled exception is caused by query interface failure. For me it looks >> like that DirectDraw7 isn't supported on the system >> (E_NOINTERFACE). >> >> Oldřich. >> > > I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came > out, DirectDraw was already deprecated and Direct3D9 was the standard. > I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it > wouldn't make sense to use it). Perhaps some IE plugins (or IE itself) > use DirectDraw and that could be why there is some support. > > More investigation is needed on what is supported in 64-bit > DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at > least 3D is not around. There is likely some limited 2D support > though. It shouldn't be that hard to fix the tests. Something like this -- I haven't tested this on affected Win64 systems. - Reece

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Roderick Colenbrander

2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > Hi W, > > On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: >> Hi, >> >> i > just noticed some new and subtle failure in ddraw:dsurface >> tests. I don't > know how closely you watch and study tests >> results, so i thought it might > be a good idea bring it the >> the light. Sorry if not ;-) >> >> Compared > WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last >> Friday). >> >> > Interestingly does not happen on Intel and nVidia 64bit. So >> the only > affected is nVidia 32bit. > > Do you mean this problem? > > ddraw:dsurface start - > - > dsurface.c:419: Tests skipped: Failed to create surface > dsurface.c:801: > Test failed: IDirectDraw7_QueryInterface returned 80004002 > dsurface.c:808: > this is the last test seen before the exception > dsurface: unhandled > exception c0000005 at 00413A29 > ddraw:dsurface done (4294967295) > > I've seen > this also during my first tests. From my understanding the problem of > unhandled exception is caused by query interface failure. For me it looks > like that DirectDraw7 isn't supported on the system > (E_NOINTERFACE). > > Oldřich. > I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came out, DirectDraw was already deprecated and Direct3D9 was the standard. I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it wouldn't make sense to use it). Perhaps some IE plugins (or IE itself) use DirectDraw and that could be why there is some support. More investigation is needed on what is supported in 64-bit DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at least 3D is not around. There is likely some limited 2D support though. It shouldn't be that hard to fix the tests. Roderick

Aug. 9, 2010

Re: New and subtle ddraw:dsurface test failure

by Oldřich Jedlička

Hi W, On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote: > Hi, > > i just noticed some new and subtle failure in ddraw:dsurface > tests. I don't know how closely you watch and study tests > results, so i thought it might be a good idea bring it the > the light. Sorry if not ;-) > > Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last > Friday). > > Interestingly does not happen on Intel and nVidia 64bit. So > the only affected is nVidia 32bit. Do you mean this problem? ddraw:dsurface start - - dsurface.c:419: Tests skipped: Failed to create surface dsurface.c:801: Test failed: IDirectDraw7_QueryInterface returned 80004002 dsurface.c:808: this is the last test seen before the exception dsurface: unhandled exception c0000005 at 00413A29 ddraw:dsurface done (4294967295) I've seen this also during my first tests. From my understanding the problem of unhandled exception is caused by query interface failure. For me it looks like that DirectDraw7 isn't supported on the system (E_NOINTERFACE). Oldřich. > (For my education) Generally, when the test fails in Windows > world, it means that the test is wrongly written or not > supported under the tested Windows version? (not blaming > anyone, just asking how things work;) > And the last question is about MSI failures and timeouts > which some boxes suffers... In my case the "powerful" > succeeds and the "weak" timeouts here (and not just mine). > Shouldn't be the timeout prolonged? > > > Regards, > W. > > PS: I probably missed "gratulation time" for v1.2, so at > least i wish all the goodness to 1.3.xx line! And hope i > find another free time for buzilla soon.

Aug. 9, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/08/2010 06:56 AM, James McKenzie wrote: > Scott Ritchie wrote: >> I was looking through our fairly large collection of open font bugs and >> realized that things might be a lot simpler if we took some opinionated >> positions and just declared certain fonts to be dependencies and >> expected all packagers to provide them. >> >> This is similar to bundling our own Tahoma, except much less work. >> > This might work for Linux, but these fonts are not installed on any > MacOSX version that I'm aware of. This might break Wine useage for > Macs. It might also break it for Solaris as well. > > James McKenzie > It should only break in a way that makes it as bad as it currently is. Thanks, Scott Ritchie

Aug. 9, 2010

'winetricks python' and user-submitted small testcases

by Dan Kegel

Waaaay back in 2002, the wine project experimented with writing win32 conformance tests in Perl. Nobody liked it; it was dropped in favor of conformance tests in C, and there was much rejoicing. Today I noticed http://bugs.winehq.org/show_bug.cgi?id=23940 which has a simple win32 test case written in Python. Surprisingly, with 'winetricks python', the test case ran and demonstrated the problem (though since the python script expected you to start another app first, and edit the python to have the other app's window title, it wasn't an unattended test). That particular bug isn't anything special, but I was happy to see that a user who preferred Python was able to successfully send a minimal test case for a win32 problem written in his favorite language, and have someone else successfully run it.

Aug. 8, 2010

New and subtle ddraw:dsurface test failure

by wylda＠volny.cz

Hi, i just noticed some new and subtle failure in ddraw:dsurface tests. I don't know how closely you watch and study tests results, so i thought it might be a good idea bring it the the light. Sorry if not ;-) Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last Friday). Interestingly does not happen on Intel and nVidia 64bit. So the only affected is nVidia 32bit. (For my education) Generally, when the test fails in Windows world, it means that the test is wrongly written or not supported under the tested Windows version? (not blaming anyone, just asking how things work;) And the last question is about MSI failures and timeouts which some boxes suffers... In my case the "powerful" succeeds and the "weak" timeouts here (and not just mine). Shouldn't be the timeout prolonged? Regards, W. PS: I probably missed "gratulation time" for v1.2, so at least i wish all the goodness to 1.3.xx line! And hope i find another free time for buzilla soon.

Aug. 8, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4356 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1742: Test failed: Got color 000a246a, expected 00000000 visual.c:1748: Test failed: Got color 006b8bbd, expected 00ff0000 or near visual.c:1751: Test failed: Got color 00ffffff, expected 00000000 visual.c:1757: Test failed: Got color 00ffffff, expected 00800000 or near === W98SE (32 bit dsurface) === No test summary line found

Aug. 8, 2010

Re: Right-To-Left (RTL) languages and Wine

by Shachar Shemesh

Paul Vriens wrote: > Hi, > > I've been in talks with a Hebrew translator for some time now and I'd > like to have Wine being able to start doing more RTL stuff. > > I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158 > > If I run an English winmine.exe on an Arabic box (thanks to the > testbot) the main window will shows as normal LTR window layout with > the menu's left justified as well. > > So eventhough the locale is set to Arabic it doesn't turn 'everything' > into RTL. > > If we don't change the resource files for the RTL languages, that same > logic will give us LTR Wine applications or am I wrong here? > An English app running on a Hebrew Windows does not automatically get entirely reversed. There are two parts to this question, and I believe that Wine should handle those parts differently. One part are the Windows decorations - close button, minimize, maximize, etc. Under Windows, if an application is reversed, so are these. I believe Wine should not attempt to replicate this behavior for the following reasons: * It is a broken design decision. Its implications are that on the same desktop, some windows have their close button on the left, others on the right. In my experience, this does nothing to enhance the user's experience. * It is difficult to implement. The decorations on Wine windows are drawn by the X window manager. We would have to convince each window manager to reverse the window decorations on our say so. I am not aware of such an API existing, which means lots and lots and lots of bugs. * As an aggregate of the above two - the window decorations are, today, not defined by Wine to be part of the "windows experience", and as such, if the Windows behavior is broken, we need not replicate it. The other part is the actual content of the window. Here there is a need to support exactly what Windows is doing, as that is the API. As a side note, I'll add that I think that is broken too. Mirroring should not be done automatically, and reading the MSDN article that Dmitry references just shows how many ways it can, indeed, break. That said, Wine did commit to being bug-compatible with Windows, so that part should, *eventually*, be implemented. I do agree with Alexandre that there are many things more pressing on the BiDi front to handle. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Aug. 8, 2010

Re: gdi32: use usp10 to optionally generate glyphs for bidi strings

by Shachar Shemesh

Alexandre Julliard wrote: > Which of course demonstrates that gdi32 calls usp10 on native too. Maybe > it does it indirectly through lpk.dll, but the end result is the same, > you have a dependency on usp10. > > I know I'm coming a bit late into the discussion, but just for the record, this is how Windows does it (as of Windows 2000): * GDI has a soft dependency on LPK.DLL. It tries to load it using LoadLibrary. * If it succeeds, and if there are no breakout flags, each call to ExtTextOut is redirected to the LPK version of that same call * LPK links with uniscribe for the actual BiDi processing, and also with GDI for the actual rendering of the result. Yes, this means a circular dependency. * The breakout flags are ETO_IGNORELANGUAGE and ETO_GLYPH_INDEX. If these are passed, GDI handles the request itself, without forwarding it to LPK. This prevents the infinite recursion that might, otherwise, happen. I believe the reason for this twisted design is twofold. First, in Windows 2000, CTL (complex text layout) was an optional component, to be installed by a checkbox in the regional settings dialog. This meant that the entire LPK dll could just be dropped in, along with some fonts, and the system would start supporting BiDi. The second reason is because BiDi is a rather multi-layered process. With BiDi, support for multi line rendering (as done by DrawText in User32) requires some fairly complex processing before the text could be passed off to ExtTextOut for actual rendering. This way, all the BiDi code could be placed in one place. Another reason, I believe, for this separation is that pre-Windows 2000 (and more importantly, pre-uniscribe) Windows still had BiDi code, which was scattered all over the place, and which became obsolete (for one example - GetCharacterPlacement, which supposedly does BiDi, has no mechanism to choose the paragraph direction, without which no BiDi processing makes sense. The MSDN docs even explicitly state it is obsolete). I believe the best route forward is to use an LPK *like* DLL. Not LPK itself, as that would require of us to reverse engineer a whole set of APIs that no one but us even call, but another DLL, injected into the dependency order at the same location, carrying a similar functionality. I would suggest "winelpk.dll" as the name, but that is, of course, entirely open. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Aug. 8, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4352 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 8, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/03/2010 01:57 PM, Scott Ritchie wrote: > I was looking through our fairly large collection of open font bugs and > realized that things might be a lot simpler if we took some opinionated > positions and just declared certain fonts to be dependencies and > expected all packagers to provide them. > > This is similar to bundling our own Tahoma, except much less work. > > > This bug, for instance, prevents Photoshop from working unless there is > an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 > > Wine doesn't seem to respect system-level fontconfig aliases, so even > though Liberation Sans is installed on the system Photoshop won't try to > use it in place of Arial. > > But if however we assumed that Liberation Sans was installed, we could > make things much better: a link/substitution for Arial->Liberation Sans > could be provided in our own registry (and similarly for Times New Roman > and Courier). An alternative is to simply symlink to the Liberation > Fonts in /usr/share/wine/fonts as though they were our own shipped fonts > (like Tahoma). > > This would make Photoshop think Arial was present and keep it > functional. Ideally the real Arial would be displayed if it was > installed (eg through winetricks corefonts or by installing the > distro-provided corefonts package). > > > A related question is whether to show "Arial" in the list of fonts (eg > notepad) when we're actually just providing a substituted Arial. My > inclination says no, however I'm not sure how it works internally and > what an application would expect. > Assuming for a moment this is a good idea, what's the best implementation? My inclination is to say some registry font links, but I'm not completely familiar with how that works. Will font links in the registry be ignored when the real font is present? Thanks, Scott Ritchie

Aug. 8, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 4)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4348 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091 === W98SE (32 bit dsurface) === No test summary line found

Aug. 7, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 4)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4345 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091

Aug. 7, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 4)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4344 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 07.08.2010 14:06, schrieb Nikolay Sivov: > On 8/7/2010 15:54, André Hentschel wrote: >> Am 06.08.2010 20:44, schrieb Nikolay Sivov: >>> On 8/6/2010 22:22, André Hentschel wrote: >>>> got that case with an MFC application which had a 3state radiobutton >>>> with buttonstyle 15(decimal) >>>> with this fix everything is fine as the painting of the button is >>>> handled elsewhere, without that fix it crashes as it reads bad data >>>> behind the array. >>>> >>>> --- >>>> dlls/user32/button.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >>>> index 54d54dc..4f629f0 100644 >>>> --- a/dlls/user32/button.c >>>> +++ b/dlls/user32/button.c >>>> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >>>> window_style ) >>>> /* paint a button of any type */ >>>> static inline void paint_button( HWND hwnd, LONG style, UINT >>>> action ) >>>> { >>>> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >>>> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >>>> IsWindowVisible(hwnd)) >>>> { >>>> HDC hdc = GetDC( hwnd ); >>>> btnPaintFunc[style]( hwnd, hdc, action ); >>> This needs a test to see what happens visually for style 0xf, maybe we >>> need just to duplicate an entry in paint function table; also while >>> you're at it: >>> >>> static inline UINT get_button_type( LONG window_style ) >>> { >>> return (window_style& 0x0f); >>> } >>> >>> here BS_TYPEMASK should be used instead of 0xf. >>> >> Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i >> made a typo in my oneline patch :) >> But i am still not sure if we really should paint in that case >> (unless some peoble come up with "invisible checkboxes"), >> because in my case the dialog style was that "ms office 2007 style", >> so mfc or the app handled the paint. if we would have drawn something >> it would have make it worse. > All I mean is that you need a small test app that creates button > directly without any mfc wrappers or anything. > Probably such style is even not accepted by control, or replaced with > some other style. > > If style is not accepted or replaced this should go directly to button > tests, if it's accepted we need visually guess how it works and add a > handler. i tested it on win7_x64 and it gets invisible after some dialog interaction, style gets accepted and is not replaced. So my initial patch was mostly correct. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: Configuring with -Werror

by André Hentschel

> Configuring with -Werror used to work a while back for me; now that > -Wno-unused-result has been fixed I gave it another try and got this: > > configure: libxrandr 32-bit development files not found, XRandr won't > be supported. > configure: WARNING: Old Mesa headers detected. Consider upgrading your > Mesa libraries. > OpenGL and Direct3D won't be supported. > configure: WARNING: No sound system was found. Windows applications > will be silent. > > After a quick investigation, turns out many configure checks produce > warnings; patch below hacks around it, but I've never dealt with > configure before and apparently fixes need to go in configure.ac -- > anyone wants to give it a proper shot? Sorry for the noise on wine-patches, this should have been gone here... Patch looks ok, but that should only be changed in configure.ac... And the chance to get that in is not very high because AJ not always suppports different compilerflags. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 07.08.2010 14:06, schrieb Nikolay Sivov: > On 8/7/2010 15:54, André Hentschel wrote: >> Am 06.08.2010 20:44, schrieb Nikolay Sivov: >>> On 8/6/2010 22:22, André Hentschel wrote: >>>> got that case with an MFC application which had a 3state radiobutton >>>> with buttonstyle 15(decimal) >>>> with this fix everything is fine as the painting of the button is >>>> handled elsewhere, without that fix it crashes as it reads bad data >>>> behind the array. >>> This needs a test to see what happens visually for style 0xf, maybe we >>> need just to duplicate an entry in paint function table; also while >>> you're at it: >>> >>> static inline UINT get_button_type( LONG window_style ) >>> { >>> return (window_style& 0x0f); >>> } >>> >>> here BS_TYPEMASK should be used instead of 0xf. >>> >> Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i >> made a typo in my oneline patch :) >> But i am still not sure if we really should paint in that case >> (unless some peoble come up with "invisible checkboxes"), >> because in my case the dialog style was that "ms office 2007 style", >> so mfc or the app handled the paint. if we would have drawn something >> it would have make it worse. > All I mean is that you need a small test app that creates button > directly without any mfc wrappers or anything. > Probably such style is even not accepted by control, or replaced with > some other style. > > If style is not accepted or replaced this should go directly to button > tests, if it's accepted we need visually guess how it works and add a > handler. Ok i see. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by Nikolay Sivov

On 8/7/2010 15:54, André Hentschel wrote: > Am 06.08.2010 20:44, schrieb Nikolay Sivov: >> On 8/6/2010 22:22, André Hentschel wrote: >>> got that case with an MFC application which had a 3state radiobutton >>> with buttonstyle 15(decimal) >>> with this fix everything is fine as the painting of the button is >>> handled elsewhere, without that fix it crashes as it reads bad data >>> behind the array. >>> >>> --- >>> dlls/user32/button.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >>> index 54d54dc..4f629f0 100644 >>> --- a/dlls/user32/button.c >>> +++ b/dlls/user32/button.c >>> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >>> window_style ) >>> /* paint a button of any type */ >>> static inline void paint_button( HWND hwnd, LONG style, UINT action ) >>> { >>> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >>> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >>> IsWindowVisible(hwnd)) >>> { >>> HDC hdc = GetDC( hwnd ); >>> btnPaintFunc[style]( hwnd, hdc, action ); >> This needs a test to see what happens visually for style 0xf, maybe we >> need just to duplicate an entry in paint function table; also while >> you're at it: >> >> static inline UINT get_button_type( LONG window_style ) >> { >> return (window_style& 0x0f); >> } >> >> here BS_TYPEMASK should be used instead of 0xf. >> > Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i > made a typo in my oneline patch :) > But i am still not sure if we really should paint in that case > (unless some peoble come up with "invisible checkboxes"), > because in my case the dialog style was that "ms office 2007 style", > so mfc or the app handled the paint. if we would have drawn something > it would have make it worse. All I mean is that you need a small test app that creates button directly without any mfc wrappers or anything. Probably such style is even not accepted by control, or replaced with some other style. If style is not accepted or replaced this should go directly to button tests, if it's accepted we need visually guess how it works and add a handler.

Aug. 7, 2010

Re: user32: Don't crash for unknown button styles

by André Hentschel

Am 06.08.2010 20:44, schrieb Nikolay Sivov: > On 8/6/2010 22:22, André Hentschel wrote: >> got that case with an MFC application which had a 3state radiobutton >> with buttonstyle 15(decimal) >> with this fix everything is fine as the painting of the button is >> handled elsewhere, without that fix it crashes as it reads bad data >> behind the array. >> >> --- >> dlls/user32/button.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/dlls/user32/button.c b/dlls/user32/button.c >> index 54d54dc..4f629f0 100644 >> --- a/dlls/user32/button.c >> +++ b/dlls/user32/button.c >> @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG >> window_style ) >> /* paint a button of any type */ >> static inline void paint_button( HWND hwnd, LONG style, UINT action ) >> { >> - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) >> + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& >> IsWindowVisible(hwnd)) >> { >> HDC hdc = GetDC( hwnd ); >> btnPaintFunc[style]( hwnd, hdc, action ); > This needs a test to see what happens visually for style 0xf, maybe we > need just to duplicate an entry in paint function table; also while > you're at it: > > static inline UINT get_button_type( LONG window_style ) > { > return (window_style & 0x0f); > } > > here BS_TYPEMASK should be used instead of 0xf. > Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i made a typo in my oneline patch :) But i am still not sure if we really should paint in that case (unless some peoble come up with "invisible checkboxes"), because in my case the dialog style was that "ms office 2007 style", so mfc or the app handled the paint. if we would have drawn something it would have make it worse. -- Best Regards, André Hentschel

Aug. 7, 2010

Re: [PATCH] quartz: implement AsyncReader_FindPin

by David Adam

Hi, what about if ppPin is NULL? I think that this patch needs test cases to prove that it is correct? David 2010/8/6 Anton Khirnov <wyskas(a)gmail.com> > --- > dlls/quartz/filesource.c | 32 ++++++++++++++++++++++++++++++-- > 1 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index 110415d..00a91c8 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -548,9 +548,37 @@ static HRESULT WINAPI AsyncReader_EnumPins(IBaseFilter > * iface, IEnumPins **ppEn > > static HRESULT WINAPI AsyncReader_FindPin(IBaseFilter * iface, LPCWSTR Id, > IPin **ppPin) > { > - FIXME("(%s, %p)\n", debugstr_w(Id), ppPin); > + IEnumPins *enumpins; > + HRESULT hr; > > - return E_NOTIMPL; > + hr = AsyncReader_EnumPins(iface, &enumpins); > + if (FAILED(hr)) > + return S_FALSE; > + > + while (hr == S_OK) { > + IPin *pin; > + LPWSTR pinname; > + > + hr = IEnumPins_Next(enumpins, 1, &pin, NULL); > + if (FAILED(hr)) > + break; > + > + hr = IPin_QueryId(pin, &pinname); > + if (SUCCEEDED(hr)) { > + if (!strcmpW(pinname, Id)) { > + *ppPin = pin; > + IPin_AddRef(*ppPin); > + CoTaskMemFree(pinname); > + break; > + } > + CoTaskMemFree(pinname); > + } > + } > + > + IEnumPins_Release(enumpins); > + if (SUCCEEDED(hr)) > + return S_OK; > + return S_FALSE; > } > > static HRESULT WINAPI AsyncReader_QueryFilterInfo(IBaseFilter * iface, > FILTER_INFO *pInfo) > -- > 1.7.1 > > > >

Aug. 7, 2010

Wine 1.3 packaged for Ubuntu, must be installed explicitly

by Scott Ritchie

I have added a new series of Wine 1.3 packages to the Wine PPA: https://launchpad.net/~ubuntu-wine/+archive/ppa These are for 10.04 (Lucid) only and must be explicitly installed: sudo apt-get install wine1.3 Users who simply install the wine or wine1.2 packages (as in, all existing users) will instead get the stable Wine 1.2 release, which is still packaged there. Thanks, Scott Ritchie

Aug. 7, 2010

Configuring with -Werror

by Jerome Leclanche

Configuring with -Werror used to work a while back for me; now that -Wno-unused-result has been fixed I gave it another try and got this: configure: libxrandr 32-bit development files not found, XRandr won't be supported. configure: WARNING: Old Mesa headers detected. Consider upgrading your Mesa libraries. OpenGL and Direct3D won't be supported. configure: WARNING: No sound system was found. Windows applications will be silent. After a quick investigation, turns out many configure checks produce warnings; patch below hacks around it, but I've never dealt with configure before and apparently fixes need to go in configure.ac -- anyone wants to give it a proper shot? Jerome L. diff --git a/configure b/configure index 05a9317..ae29fe4 100755 --- a/configure ++ J. Leclanche / Adys+ b/configure @@ -8430,7 +8430,7 @@ int main () { static typeof(XRRSetScreenConfigAndRate) * func; - ; + if(func); return 0; } _ACEOF @@ -8685,7 +8685,7 @@ int main () { GLenum test = GL_UNSIGNED_SHORT_5_6_5; - ; + if(test); return 0; } _ACEOF @@ -10517,8 +10517,8 @@ if test "x$ac_cv_lib_asound_snd_pcm_hw_params_get_access" = x""yes; then : int main () { -int ret = snd_pcm_hw_params_get_access(NULL, NULL) - ; +int ret = snd_pcm_hw_params_get_access(NULL, NULL); + if(ret); return 0; } _ACEOF

Aug. 7, 2010

Re: Wine users with a CD-ROM drive, please test

by Erik Inge Bolsø

On Fri, 6 Aug 2010, Erik Inge Bolsø wrote: > No failures on my winxp laptop. No mixed cd handy, so only audio cd > tested. Though on the win7-64 desktop, I get the same failures as everyone else. mcicda.c:270: CD length 73:35:54 mcicda.c:325: track #1 length 35694ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:25s:41frames mcicda.c:418: last track position: 69m:12s:13frames mcicda.c:425: Test failed: SEEK to 00362549 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. Same cd. -- -erik http://useofwords.blogspot.com/

Aug. 6, 2010