January 2011 - Wine-Devel - list.winehq.org

Re: user32: Test for behavior of WM_SETTEXT handler regarding WM_CTLCOLOR*

by Marvin

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=8777 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

Jan. 31, 2011

Re: Wine Gecko 1.2.0 beta1

by Eric Pouech

> - dbghelp fixes > winedbg has problems with debug info from Gecko debug build, making > debugging possibilities quite limited and backtraces lacking most of > the calls. This is not related to Gecko release itself, but still it > would be great to have it fixed. what are your favorite steps to reproduce this ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Jan. 31, 2011

Re: Correction to crash inside RtlCaptureStackBackTrace() + test case

by Alexandre Julliard

Janne Hakonen <joyer83(a)live.fi> writes: > Should I still add the try-except blocks to RtlCaptureStackBackTrace() > and tests for 0xfffffffc value also? It doesn't need a try-except block, just better wrap-around handling. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: Wine Gecko 1.2.0 beta1

by Jacek Caban

On 1/31/11 6:59 PM, Jacek Caban wrote: > [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-beta1/ Sourceforge seems to have strange problems now. It closes connection just after downloading starts. Hopefully it will be fixed soon. Jacek

Jan. 31, 2011

RE: Correction to crash inside RtlCaptureStackBackTrace() + test case

by Janne Hakonen

Hi Alexandre Julliard, I see you had another idea of how to correct the RtlCaptureStackBackTrace() function. I tested your implementation with Anarchy Online's item store (ingame web browser based on Awesomium) and with AwesomiumGL (sample app from Awesomium's SDK). With AwesomiumGL I did, after a while (scrolling in an image heavy site), got it to crash: wine: Unhandled page fault on read access to 0xfffffffc at address 0x7bc7586b (thread 002e) To file dlls/ntdll/signal_i386.c, line 2438: frame = (ULONG *)*frame; (inside the skipping loop). And, so, if 'frame' is 0xfffffffc, then the added check, unfortunately, will not cut it. With Anarchy Online, I browsed quite a lot within the item store, changing pages, and finally just left the window open for ~20 minutes. No crash so far, so the correction might have worked for the game or then I just didn't wait long enough ;) Should I still add the try-except blocks to RtlCaptureStackBackTrace() and tests for 0xfffffffc value also? Please advice. Best Regards, Janne

Jan. 31, 2011

Re: msvcrt: Add type_info::name_internal_method() as alias for ::name()

by Marvin

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=8775 Your paranoid android. === WXPPROSP3 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 00543C08 === W2K3R2SESP2 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 00533C78 === WVISTAADM (32 bit msvcr90) === msvcr90: unhandled exception c000001d at 00D5129D === W2K8SE (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 01961298 === W7PRO (32 bit msvcr90) === msvcr90: unhandled exception c000001d at 009212A5 === W7PROX64 (32 bit msvcr90) === msvcr90: unhandled exception c000001d at 005212A4

Jan. 31, 2011

Re: [PATCH 2/4] d3d9/tests: Check ColorFill() return codes in color_fill_test() (LLVM/Clang).

by Marvin

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=8768 Your paranoid android. === WXPPROSP3 (32 bit visual) === No test summary line found

Jan. 31, 2011

Re: [PATCH] Clarify 'fixme'...

by Charles Davis

On 1/31/11 12:01 PM, max(a)mtew.isa-geek.net wrote: > @@ -2519,7 +2519,7 @@ static BOOL CommitUrlCacheEntryInternal( > > if (URLCache_FindHash(pHeader, lpszUrlNameA, &pHashEntry)) > { > - FIXME("entry already in cache - don't know what to do!\n"); > + FIXME("hash matces - collision check needed.\n"); Typo "matces" -> "matches". Chip

Jan. 31, 2011

Wine Gecko 1.2.0 beta1

by Jacek Caban

Hi all, We're nearing the time for the next Gecko update. Beta builds are done and available on Sourceforge [1]. To use them, you need to download the .cab file, put it as you usually do into the right directory (most likely wine_gecko-1.2.0-beta1-x86.cab, see [2] for details) and apply the attached patch to recent Wine git version. The plan for release is other than we usually did and we have still some work to do. I hope to do the release short after Firefox 4 release, which is scheduled for the end of February. Firefox is nearing final beta and we will branch together with RC branch for Firefox 4. This should give us more stability in the code base than we usually had. We've never succeeded in avoiding regressions with the new Gecko releases and I hope to improve this situation. This early beta build is one part of the plan. It would be great if you could use it for some time or try some apps with it. I'm most interested in reports about regression, but also general stability and improvements. * Changes - We use Firefox 4 beta11pre codebase - Some regression caused by integration with new parser are fixed (affected among others CS4 installer, STO, EQ2) - IO fixes for custom protocol handlers, mostly affecting .chm files and Outlook If you hit a blank-page bug, some page elements don't work or just a crash, there is a big chance that this build will fix it. Of course it's always nice to test everything regardless if it's currently working or not. * TODO - win64 fix It currently crashes, that's a regression. I've decided to do the beta release anyways, but it's an obvious blocker for further releases. I've put win64 builds on Sourceforge in case anyone is interested in looking at them, but the problem seems to be in the build, not in Wine. - MSI packages This beta still uses .cab files done on Windows. We're planning to do some work on it with Hans and Alexandre so that the final release will use MSI files. - dbghelp fixes winedbg has problems with debug info from Gecko debug build, making debugging possibilities quite limited and backtraces lacking most of the calls. This is not related to Gecko release itself, but still it would be great to have it fixed. - Getting rid of ugly hacks that Firefox uses Esp. API hooks. I don't think it's acceptable for us. - Tests and fixes The more tests, the better. I really hope to get community help here. * For packagers If you're considering building the next Gecko release yourself, it's probably a good idea to try the compilation now. It requires very recent mingw-w64, so a package update (or creating a new package if it's not yet available for the distro) will most likely be needed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-beta1/ [2] http://wiki.winehq.org/Gecko

Jan. 31, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 17:08 schrieb Matteo Bruni: > The attached patch should follow your idea, does it look right? FWIW, > I can't see any 1-pixel offset in The Sims 3 with this patch. Yes, I > know that's not how it should be tested... Looks OK on first sight. Does it work as well? I can't think of any game where you could see a half pixel issue wrt clipplanes. Maybe the d3d7 clipping example can shows something, but I think to be sure you'd have to write a test. The half pixel offset is mostly visible when games draw text by drawing textured quads, e.g. the menu and console in the source engine. Another odd occurrence is in Spore, where the game draws some heightmaps and reads them back. With incorrect half pixel offsets the in-game world is suddenly full of high walls. Then there's Warhammer Online which draws floor tiles in offscreen textures, leading to odd lines in the floor when they are not drawn properly. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRub1AAoJEN0/YqbEcdMwAA4P/AoF12KxCyW/L7K1FV4EOKoz HDKpNZ4D1dOPf35JJuZaVOuEqh7AJrmp9QSorgF0kFkdEAr7bHaBnGuSny+STEMi zDfW1VdeKAwVbfuQCjVP3FwKMkw/K5Olg5U9D+CBIIAaPG2A2PSoV3FPjtQ2RJ8s K8so7GqlgqcSEPc6TXD0ngS1jTmRVpTqCzX3wDbGTM6jO7lqoajngdYoXGcVVR+j vYiWVXHXOhnmqTD48xw7uqKTEwd9+zseAXZVWSVL3Rk+l0pdvT8pfPNUguKrqipx MizDRGT6iw2f3/7lrePacbLzGnxhH4DACIgJnoBjvZdfrtXFezuJFz7kIHy/XqyE EXUCF/2SDqFYCTnFtBgSL6u/4xGhoIw1tj7pnzrLN+wzqx+VWfndquj5+rTEoNFK FxY0X/6bLPSaUDs6J9GjzwFQ1j5XTr6ebFcwtGvCsADx4IHiUO0/d1WdafNoMpH5 /YWC2Spa+OXe9dWwNR/4XqQny+KAFEIfnqZJGTp/8Ak7rGIhIVgmUqxcklp2p0hb qwgtD79uaW4tOQnLQcOV2F4JxW0HdOb4yKtoinPskIcw234TegfHFr6MKgEjl9Mi kFmYS3CHfd9ABC+YSB17KYu93S3t3KI4YuYcftuf06czFAXue9c6P8VwzjAfmM5l KoFYrEBo518k3bgtMpPr =4Ham -----END PGP SIGNATURE-----

Jan. 31, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Matteo Bruni

2011/1/31 Stefan Dösinger <stefandoesinger(a)gmx.at>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Am 31.01.2011 um 15:57 schrieb Henri Verbeet: > >> On 31 January 2011 15:45, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >>> >>> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. >> >> Wouldn't it still have to be after the half-pixel offset is applied though? > That's what I am not sure about, but my gut feeling says no. In the ffp pipeline clipping wrt user clip planes is done in eye coordinates, so the half pixel offset should have no effect on it. I see no reason why it shouldn't work with shaders in the same way. > The attached patch should follow your idea, does it look right? FWIW, I can't see any 1-pixel offset in The Sims 3 with this patch. Yes, I know that's not how it should be tested... > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > iQIcBAEBAgAGBQJNRtD8AAoJEN0/YqbEcdMwVOUP/1x8ZB6vutkspZU2fhspi1tE > s+b1drKBfHMu3LxswKwo/tA+xB/3h+qyKLuo6GT0kqQ+kF4IbFE3No1oX//baRDn > 9eWYke1dz/Q0Jh6K1dA72moptYvbpplgvjr4/8bnBCFGChkbQsaK2O0o6zxFtIXc > yeTxB+oymu0tNxLXzJn+nrOT3qMp1yN9c/MX7crK7O0B56RAUTTg8P4i2Zz4r9L8 > WBHQ8sGGBtpeN9lf65MZeJNZvchLrWsJjq5iDvGxl1vRVuEsMzMEM7xqosOeQgul > dFlYQFRTNxQk0XCdprq2jIdc/HiZANjvXO7U0eBiV6Orjo91Rbjtg2UCr43Q3hQH > wdtoXYyPRbCuvttEpnQBg6vg/UegTGIqKNl2QynN/wFocoJ/2FX+aNC49KGnrhEj > RzUCPuLuQ4y2DqX5zqggnbmrFPHke2Gbz4RJZy085X+FbKGpWen3o+iZCK2rX294 > 8nrlfO1JEGu2Gay+gqUJUQFUhdI1DRr0i5c+Lw7sLztqTZDeGt4/Al+wEDmkS1XA > lRJVdOtib+BtBzXB2k9H5vawJt2xmqxSmMfjBu7tvkdoINISmDRNHZoow/Io2sid > P2ZYNXt1AFnRFrvtC5CMLkTYEqMhh5/mcAzrmsVVD8WR4mwAR8dGUMCH17R3+C3L > P9sP1J5E/M1B9Yx5YV8M > =gL/E > -----END PGP SIGNATURE----- > > >

Jan. 31, 2011

Re: winex11.drv: Make sure that default clipping region exists before calling ExcludeUpdateRgn().

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > I looks like the default clip region created by ExtSelectClipRgn() uses >> > the dimensions of the selected bitmap, and it's not large enough. >> >> That's a window DC, it doesn't have a selected bitmap. > > You are right. The app creates very large child window to fit the whole map > inside it (it's at least two times larger than the screen), and moves the child > window inside the parent window once one presses mouse button and drags the map > (when I drag the map into the left top corner the coordinates of the child window > are about -970,-860 while the screen resolution is 1680x1050 in my case). So, > using the screen size for a default clipping is not enough. OK, that makes sense. It sounds like a test case for ExtSelectClipRgn is in order, before we work around it. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: winex11.drv: Make sure that default clipping region exists before calling ExcludeUpdateRgn().

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > I looks like the default clip region created by ExtSelectClipRgn() uses > > the dimensions of the selected bitmap, and it's not large enough. > > That's a window DC, it doesn't have a selected bitmap. You are right. The app creates very large child window to fit the whole map inside it (it's at least two times larger than the screen), and moves the child window inside the parent window once one presses mouse button and drags the map (when I drag the map into the left top corner the coordinates of the child window are about -970,-860 while the screen resolution is 1680x1050 in my case). So, using the screen size for a default clipping is not enough. -- Dmitry.

Jan. 31, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 15:57 schrieb Henri Verbeet: > On 31 January 2011 15:45, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> >> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. > > Wouldn't it still have to be after the half-pixel offset is applied though? That's what I am not sure about, but my gut feeling says no. In the ffp pipeline clipping wrt user clip planes is done in eye coordinates, so the half pixel offset should have no effect on it. I see no reason why it shouldn't work with shaders in the same way. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRtD8AAoJEN0/YqbEcdMwVOUP/1x8ZB6vutkspZU2fhspi1tE s+b1drKBfHMu3LxswKwo/tA+xB/3h+qyKLuo6GT0kqQ+kF4IbFE3No1oX//baRDn 9eWYke1dz/Q0Jh6K1dA72moptYvbpplgvjr4/8bnBCFGChkbQsaK2O0o6zxFtIXc yeTxB+oymu0tNxLXzJn+nrOT3qMp1yN9c/MX7crK7O0B56RAUTTg8P4i2Zz4r9L8 WBHQ8sGGBtpeN9lf65MZeJNZvchLrWsJjq5iDvGxl1vRVuEsMzMEM7xqosOeQgul dFlYQFRTNxQk0XCdprq2jIdc/HiZANjvXO7U0eBiV6Orjo91Rbjtg2UCr43Q3hQH wdtoXYyPRbCuvttEpnQBg6vg/UegTGIqKNl2QynN/wFocoJ/2FX+aNC49KGnrhEj RzUCPuLuQ4y2DqX5zqggnbmrFPHke2Gbz4RJZy085X+FbKGpWen3o+iZCK2rX294 8nrlfO1JEGu2Gay+gqUJUQFUhdI1DRr0i5c+Lw7sLztqTZDeGt4/Al+wEDmkS1XA lRJVdOtib+BtBzXB2k9H5vawJt2xmqxSmMfjBu7tvkdoINISmDRNHZoow/Io2sid P2ZYNXt1AFnRFrvtC5CMLkTYEqMhh5/mcAzrmsVVD8WR4mwAR8dGUMCH17R3+C3L P9sP1J5E/M1B9Yx5YV8M =gL/E -----END PGP SIGNATURE-----

Jan. 31, 2011

Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()

by Alexandre Julliard

Peter Schlaile <peter(a)schlaile.de> writes: > And: do you want to say, that there is a page fault handler within > wine, that can handle *that* case above? Yes, that's how DIBs work in Wine. > In either way, I hope we can agree on the following: > > a) the app is *not* broken (at least not regarding it's usage of > CreateIconFromResourceEx() ) > b) wine code *is* broken here > c) we can work around the problem within create_alpha_bitmap() or > d) make StretchDIBits() a function a lot less surprising to call... There's nothing surprising here. The page protection is transparent to the app, and exceptions are handled by Wine. It's only because the app breaks exception handling that you get problems. > At least, they seem to install the handler in such a clever way, that > no problems seem to occur within Windows (several different versions). > That said: I'd have prefered, if they didn't do that, since it made my > debugging session a lot longer... They don't install it in a clever way, that's the whole problem. They simply blindly override any other installed handler. The only way to fix it apart from writing a DIB engine would be to add a special hack to make the DIB exception handler take priority over the app broken handler. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Henri Verbeet

On 31 January 2011 15:45, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Am 31.01.2011 um 15:13 schrieb Matteo Bruni: > >> It should fix http://bugs.winehq.org/show_bug.cgi?id=25877 >> <0001-wined3d-Update-clip-planes-when-switching-to-from-offs.txt> > If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. Wouldn't it still have to be after the half-pixel offset is applied though?

Jan. 31, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 15:13 schrieb Matteo Bruni: > It should fix http://bugs.winehq.org/show_bug.cgi?id=25877 > <0001-wined3d-Update-clip-planes-when-switching-to-from-offs.txt> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRssNAAoJEN0/YqbEcdMwZv8P+wbbhcamRsg42fMzJ02jKLcT s4p19OqKPZEdVvzsfQCe4e7KGgGdZUefMWsY2ib9AK21cQXB3R9fnyl5TMDcuxuh EojJvAQCVd/hgnz7tserUJT6rS/W08BPsdHM4dgxdnhRTzi2FAc7l3NgFOONJXpG i8HfcmD2AgaGOam6Wriv3SD8fM0zrfmpZdJDH1moCefqptEEWD9adwWRSMhaMvTl rlj1gDR9cRC9fsxur2U1f5NuXN0AY+a+5VPQHElZV2bP9ulheoa9nYuXU+8F7OhK RyIJ2DO4vpaLpEbXW/amtUWnlBSk0n7k3F9w/fcthOmUvlPHOBY7i2Ukf4j84vQD AhpN7Yf4cFZaSV8q/gww+U9H1udelidiTEL05OKQJUohnM1F9/cRnXbXmmA5Nuia rQlcCnm12cw1ClykdrY7B/hDCqGOPnnmPp580kW1LlEtidYyGbG35seyHxNqcNcQ RWlvVsGwvlzgex7qWf9hT34KOcUzMKZdlehfvtQn0Fjrcf+/3s5EvrtG4Mw6qHNh aBFNaeB8LkV36hu71r/1yxsqHO+taYt1/Ho8poANYbOplV9FCpd0nXeK8n7rqCPx L5TVgSJVd4n354FlguuIUAiFlXxcxFN2CJlN2Hd4dwhZZhGBh+4LH+XhjUtzX4ge 15usBq4VUhhssvv6dVys =urcm -----END PGP SIGNATURE-----

Jan. 31, 2011

Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()

by Peter Schlaile

Hi Alexandre, On Mon, 31 Jan 2011, Alexandre Julliard wrote: >> And: from a design perspective it sounds very strange that a fast >> track optimisation *silently* changes protection bits! > > There's nothing silent about it, the protection bits have to match the > DIB state. Hmm. In which way changes StretchDIBits() the DIB state? Or: why should be a DIB, that is created using CreateDIBSection() as READWRITE, silently change it's state into READONLY? (At least, msdn-docs don't tell me anything about that... Can you provide me with a link? ) But, let's say for a moment, that this is true and the right(tm) behaviour: Then create_alpha_bitmap() (within user32/cursoricon.c) seems to be broken. It does the following: * create a DIBSection alpha = CreateDIBSection( hdc, info, DIB_RGB_COLORS, &bits, NULL, 0) * here we can savely expect bits to be writable (at least the msdn-documentation says so) * in certain cases (if we are provided with a src_info-pointer), we do now: StretchDIBits( hdc, 0, 0, bm.bmWidth, bm.bmHeight, 0, 0, src_info->bmiHeader.biWidth, src_info->bmiHeader.biHeight, color_bits, src_info, DIB_RGB_COLORS, SRCCOPY ); * after that, bits is *probably* non-writable (depending on fast path or not) (I still find that *really* strange. Again: it depends on certain parameters of this function, specifically: if in and out parameters do match at enough places, the DIB bitmap *changes* it's state to READONLY, in other cases it doesn't. If that isn't a big surprise, what is? :) ). * and here... /* pre-multiply by alpha */ for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) { unsigned int alpha = ptr[3]; ptr[0] = ptr[0] * alpha / 255; ptr[1] = ptr[1] * alpha / 255; ptr[2] = ptr[2] * alpha / 255; } * ... we write to the now readonly bits-array, which leads to a page fault. This is everything within wine code, the application only called CreateIconFromResourceEx(), which then called create_alpha_bitmap() (so: no, I don't think, the app is broken :) It only triggered a seldomly used code path within wine. ). Where is the page fault handler within wine and what should the page fault handler actually do in that situation? If we can't expect the "bits"-pointer to be writable after a call to StretchDIBs(), create_alpha_bitmap() should be rewritten. >> That wouldn't be a problem, if windows behaved exactly the same way. >> (which it most likely does not, otherwise PNClient wouldn't crash, >> right?). > > I wouldn't be surprised if there was a way to crash it on Windows too, > that app is broken, it never gives the code a chance to handle the > exception. This is not how exception handlers are supposed to work. Well, it doesn't crash on Windows and is actually rock solid there. And: do you want to say, that there is a page fault handler within wine, that can handle *that* case above? We either have to rewrite create_alpha_bitmap() in a way, that doesn't call StretchDIBits() in the fast path case and solves problems differently or: we should fix it at the source (which I still think my patch does, since it follows the rules of least surprise...). In either way, I hope we can agree on the following: a) the app is *not* broken (at least not regarding it's usage of CreateIconFromResourceEx() ) b) wine code *is* broken here c) we can work around the problem within create_alpha_bitmap() or d) make StretchDIBits() a function a lot less surprising to call... > Of course this specific issue would be fixed by a DIB engine, but there are > other places where exceptions can happen internally, even on Windows. At least, they seem to install the handler in such a clever way, that no problems seem to occur within Windows (several different versions). That said: I'd have prefered, if they didn't do that, since it made my debugging session a lot longer... >> Are you sure? 0 means: everything is transparent, and that sounds >> like: we need an alpha channel, right? > > 0 means there's no alpha channel, which is what we are checking here. Ouch! If that is really Windows behaviour, then it is really broken but bug-to-bug compatible :) Cheers, Peter ---- Peter Schlaile

Jan. 31, 2011

Re: [3/3] d3d9: account for another different behavior in the viewport test

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just noticed that I sent the other two mails with my gmail account, so they got stuck in moderation. This patch should apply on its own, but depending on what Alexandre commits today I'll resend the patches after today's commit wave. Am 31.01.2011 um 11:21 schrieb Stefan Dösinger: > The alternative to this patch is to remove the test entirely, as it now accepts all possible outcomes on windows. I prefer to keep it because the behavior it accepts as non-broken(invalid viewport = "default" viewport) is required by some ddraw apps. We also have a test in ddraw, but it isn't quite as straightforward. > > <0011-d3d9-account-for-another-different-behavior-in-the-v.patch> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRsifAAoJEN0/YqbEcdMwUSAP/2HphIB7RzKXuS/q52t5mCvt b9yFQ/9ci11GWlzWG7okm72Z+hUdC4bIMPxIalWM7/VKPzsSB7Qg2EvwpMTGq0r5 lAX3WFFqWqCNoAZd7JnQO6LqX0TR4wJOCxIjAYSw+WlZW7tYNVFEsw3mPTUxqggR 88wVQ8C5oBAW3Rns6QGYmxyw+R6Xryh3pdukxBP2DS6jQDkqodq9L6JU24YHHy0z OFEZCIAl8VqhTfgTeO5pqJ7e4ujGyT0U25h8rmIuhMt8DFRdxTSE4agib4haFrLb jLEUAVqjSrV4EX1A+iisryBYCCOGpGT9vYKB5Xw169fzkjd2XMQ9C3udE/VznGWo grcWX9CJxm1XzR/AYuNh+pNSq+wZPxwrlJrOmcW4EC1o1X/OdXr+KtZFX2ldkGwF v6LCel4WPN5G4+mKryNnPMRDPo69ccZr2iKTdMQFs7nm0NZGxPNnj3o7eGDP92pq DNUboQ3EoZ3ow9c8vpfeGgxk647jgJwpeOzUKj7ON3l5XyFvoEAAv2pFwRp/lpn8 3ioLYDePd7VBcf6cT9ckI0Qptx2hM8yRyd1r+qC4jGv8ydQnHmAu+w61cmSrpl3X EYpvHmFYEdkJjDKcn2Z1gYekg4RisXcd/CVBWfZHLudpibEab+3NQp7wb+HwNscu 2P/hz0RIdqEC7BBQf6bJ =Vxnq -----END PGP SIGNATURE-----

Jan. 31, 2011

Re: winex11.drv: Make sure that default clipping region exists before calling ExcludeUpdateRgn().

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > I looks like the default clip region created by ExtSelectClipRgn() uses > the dimensions of the selected bitmap, and it's not large enough. That's a window DC, it doesn't have a selected bitmap. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: winex11.drv: Make sure that default clipping region exists before calling ExcludeUpdateRgn().

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > If there is no current clipping region ExtSelectClipRgn(hdc, hrgn, RGN_DIFF) > > creates its own default clipping region which in most cases doesn't match > > neither a visible region nor the window extents attached to the DC. > > It will get intersected with the visible region anyway, so it shouldn't > matter as long as it's large enough. Why does it make a difference? I looks like the default clip region created by ExtSelectClipRgn() uses the dimensions of the selected bitmap, and it's not large enough. -- Dmitry.

Jan. 31, 2011

Re: winex11.drv: Make sure that default clipping region exists before calling ExcludeUpdateRgn().

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > If there is no current clipping region ExtSelectClipRgn(hdc, hrgn, RGN_DIFF) > creates its own default clipping region which in most cases doesn't match > neither a visible region nor the window extents attached to the DC. It will get intersected with the visible region anyway, so it shouldn't matter as long as it's large enough. Why does it make a difference? -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: [PATCH] [patch] Already in cache means nothing more to do...

by Alexandre Julliard

max(a)mtew.isa-geek.net writes: > @@ -2519,11 +2519,7 @@ static BOOL CommitUrlCacheEntryInternal( > > if (URLCache_FindHash(pHeader, lpszUrlNameA, &pHashEntry)) > { > - FIXME("entry already in cache - don't know what to do!\n"); > -/* > - * SetLastError(ERROR_FILE_NOT_FOUND); > - * return FALSE; > - */ > + error = ERROR_SUCCESS; The entry is not necessarily the same even if the hash matches. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()

by Alexandre Julliard

Peter Schlaile <peter(a)schlaile.de> writes: > At least, wine reacts very differently than windows here :) > Read: it crashes the application I mentioned in my previous mail: > http://www.phononet.de/downloads/support/downloads/Aktueller_PNClient/PNCLI… > > And: from a design perspective it sounds very strange that a fast > track optimisation *silently* changes protection bits! There's nothing silent about it, the protection bits have to match the DIB state. > That wouldn't be a problem, if windows behaved exactly the same way. > (which it most likely does not, otherwise PNClient wouldn't crash, > right?). I wouldn't be surprised if there was a way to crash it on Windows too, that app is broken, it never gives the code a chance to handle the exception. This is not how exception handlers are supposed to work. Of course this specific issue would be fixed by a DIB engine, but there are other places where exceptions can happen internally, even on Windows. > Are you sure? 0 means: everything is transparent, and that sounds > like: we need an alpha channel, right? 0 means there's no alpha channel, which is what we are checking here. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()

by Peter Schlaile

Hi Alexandre, On Mon, 31 Jan 2011, Alexandre Julliard wrote: > Peter Schlaile <peter(a)schlaile.de> writes: > >> Fix: X11DRV_SetDIBits() shouldn't silently change Bitmap protection, so >> we now restore the protection bits, that were present before instead of >> always changing to READONLY. > > No, it needs to be read-only so that we can detect further changes. so: what is your proposal to fix the problem? At least, wine reacts very differently than windows here :) Read: it crashes the application I mentioned in my previous mail: http://www.phononet.de/downloads/support/downloads/Aktueller_PNClient/PNCLI… And: from a design perspective it sounds very strange that a fast track optimisation *silently* changes protection bits! That wouldn't be a problem, if windows behaved exactly the same way. (which it most likely does not, otherwise PNClient wouldn't crash, right?). And: my problem is, that I already spent three days in tracking this bug down, so, I'm not sure, if I find the time to write test code, that will demonstrate the difference between windows and wine. Should we move to bug tracker then? >> Additional minor fix: bmi_has_alpha() tests for alpha channel != 0, but >> should test for alpha channel != 255. > > No it shouldn't, 0 is correct. Are you sure? 0 means: everything is transparent, and that sounds like: we need an alpha channel, right? Don't get me wrong, if windows behaves like that, it's ok for me, too, but that really sounds strange. Cheers, Peter ---- Peter Schlaile

Jan. 31, 2011