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

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

by Alexandre Julliard

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. > 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. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2011

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

by Janne Hakonen

> > If I need to make changes to, say, test cases, should I also send bug fix > > patch again even if there is no changes to that? > > Please. If it is two separate patches, be sure to make it a series > (label them 1/2, 2/2) and that the tests pass before/after each patch. > Ok, thanks for the info. :) Here's the job run by Testbot, when I posted the patches to the mailing list: http://testbot.winehq.org/JobDetails.pl?Key=8716 Looking at the logs only WNT4WSSP6 and W2KPROSP4 shows message: rtl.c:1340: Tests skipped: RtlCaptureStackBackTrace threw SEH exception, most likely running on Windows NT or 2000 Best Regards, Janne

Jan. 31, 2011

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

by Austin English

On Sun, Jan 30, 2011 at 22:15, Janne Hakonen <joyer83(a)live.fi> wrote: >>Also, it is custom to mark your resubmissions with corrections as [try x]. >> Makes it easier to determine what you are doing. > I posted my patches to patches mailing list only once so far, so there > hasn't been any retries yet. > But, I shall add that tag if/when I need to adjust those or any future > patches. > If I need to make changes to, say, test cases, should I also send bug fix > patch again even if there is no changes to that? Please. If it is two separate patches, be sure to make it a series (label them 1/2, 2/2) and that the tests pass before/after each patch. -- -Austin

Jan. 31, 2011

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

by Janne Hakonen

> Did you try this on WindowsXP or Windows7 to make sure that the win_skip did not function on those platforms? My understanding is that win_skip works on all Windows platforms not just WindowsNT or Windows2000. Well, I did test that skip doesn't happen on my home computer, which is Windows 7. I also tested that the skip do happen on Windows NT4 and 2000 on Testbot. >Also, it is custom to mark your resubmissions with corrections as [try x]. Makes it easier to determine what you are doing. I posted my patches to patches mailing list only once so far, so there hasn't been any retries yet. But, I shall add that tag if/when I need to adjust those or any future patches. If I need to make changes to, say, test cases, should I also send bug fix patch again even if there is no changes to that? Best Regards, Janne

Jan. 31, 2011

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

by Vitaliy Margolen

On 01/30/2011 12:02 PM, Peter Schlaile wrote: > Nevertheless: I hope, I explained pretty well, how and why the current code > is wrong (aquiring a bitmap-pointer using CreateDIBSection, setting this > bitmap to readonly using the fast track code path within StretchDIBits, > writing to this bitmap again.). Sounds plausible to me, but I'm not expert in that area. > probably, but you will agree, that this is a rather trivial change... (and > pretty obvious, too). No, me and everyone else here won't agree. Please send a separate patch with explanation why the change is needed. Each patch have to contain one change and one change only. No exceptions. Please see patch submission guidelines here: http://wiki.winehq.org/SubmittingPatches Vitaliy.

Jan. 31, 2011

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

by James McKenzie

On 1/28/11 11:54 AM, Janne Hakonen wrote: > > Now, when I ran these tests on Testbot using all base VMs, the tests > were run also on W2KPROSP4 and WNT4WSSP6. However, the > > function seems to buggy in those. It throws access violation > whenever it is not skipping frames. > > > Is there some way I could prevent/skip these tests to be run on > Windows NT4 and 2000? > > Ah, no matter, I think I've got it. Adding following lines to start > allows the tests to be skipped on NT and 2000: > > __TRY > { > pRtlCaptureStackBackTrace(0, 62, callers, NULL); > } > __EXCEPT_ALL > { > win_skip("RtlCaptureStackBackTrace threw SEH exception, " > "most likely running on Windows NT or 2000\n"); > return; > } > __ENDTRY > Did you try this on WindowsXP or Windows7 to make sure that the win_skip did not function on those platforms? My understanding is that win_skip works on all Windows platforms not just WindowsNT or Windows2000. Also, it is custom to mark your resubmissions with corrections as [try x]. Makes it easier to determine what you are doing. James McKenzie

Jan. 31, 2011

RFC: Final Proposed Riched20 EM_SETMARGINS Test

by James McKenzie

All: Constructive Criticism requested so that this can be made better. I've decided to use two loops in the test: One for fonts. Second for actual tests. This allows for quick and easy expansion. The check code for font changes might be removed, but does no harm by remaining. This patch is based on git as of Friday, January 28. I could find no font that changed the Margin from zero for the EC_USEFONTINFO lparam test case. If someone knows of a font that will do so, please advise as well so I can include it. Thank you. James McKenzie

Jan. 31, 2011

Re: [PATCH 2/2] mshtml: Added support for recursive script runners

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=8753 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Jan. 30, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Henri Verbeet

On 28 January 2011 17:36, Juan Lang <juan.lang(a)gmail.com> wrote: > What's the issue with building GnuTLS? Is it that GnuTLS doesn't > support the Mac Keychain? Is it that it's an external dependency? If > the latter, we already pull in quite a bit that isn't found on the > Mac, so the incremental change isn't large. > Note that I wasn't actually involved in any of this on the CodeWeavers side, but I think for CodeWeavers the consideration would be that we'd prefer to not be in the business of distributing GnuTLS, since it's extra stuff to carry around, and you'd have to keep track of security issues, etc. Although I think it's perfectly reasonable to ask Wine users, regardless of OS, to install GnuTLS if they want Schannel support, I don't think the same thing is necessarily reasonable to ask of CrossOver users. On the other hand, as a Wine (and Free Software in general) developer I'm not so convinced this would really be beneficial to Wine either. > I do see two problems with the general plan. One isn't specific to > your plan: schannel as it is is buggy. We don't know where the bugs > are, and they've languished for a long time. Your proposed plan Sadly some of that is probably my responsibility. The original plan was to implement server support after the client code went in, and then use that for writing tests. It didn't quite turn out that way, mostly due to wined3d taking priority. On 30 January 2011 20:31, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > The point is that MacOSX has built-in TLS support out of the box. Why build > GNU TLS when using MacOSX when it is not needed??? > To reduce complexity and maintenance overhead of the Wine schannel code.

Jan. 30, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by James McKenzie

On 1/28/11 9:36 AM, Juan Lang wrote: > Hi Ken, > >> I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. > What's the issue with building GnuTLS? Is it that GnuTLS doesn't > support the Mac Keychain? Is it that it's an external dependency? If > the latter, we already pull in quite a bit that isn't found on the > Mac, so the incremental change isn't large. > The point is that MacOSX has built-in TLS support out of the box. Why build GNU TLS when using MacOSX when it is not needed??? James McKenzie

Jan. 30, 2011

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

by Peter Schlaile

Hi Vitaliy, On Sun, 30 Jan 2011, Vitaliy Margolen wrote: > On 01/30/2011 04:16 AM, Peter Schlaile wrote: >> Hi, >> >> find fix for a crash in create_alpha_bitmap() attached. > > If it's easy to reproduce please create a test that demonstrates the problem. hmm, don't know, the application that triggered it, can be downloaded here: http://www.phononet.de/downloads/support/downloads/Aktueller_PNClient/PNCLI… It will fail on startup, because of that problem, showing a dialog box, that some of it's data has been damaged and offers you to close or restart. (The program installs it's own page fault exception handler, you can see the reason of the crash if you run wine with WINEDEBUG=+relay .) If you apply my patch, it will start up correctly, ask for a valid license key (which can be skipped) and show a search screen for CDs/DVDs published in Germany. Nevertheless: I hope, I explained pretty well, how and why the current code is wrong (aquiring a bitmap-pointer using CreateDIBSection, setting this bitmap to readonly using the fast track code path within StretchDIBits, writing to this bitmap again.). >> Additional minor fix: bmi_has_alpha() tests for alpha channel != 0, but >> should test for alpha channel != 255. > This should be a separate patch. probably, but you will agree, that this is a rather trivial change... (and pretty obvious, too). Hope that's ok anyways. Cheers, Peter ---- Peter Schlaile

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by GOUJON Alexandre

On 01/30/2011 07:27 PM, James McKenzie wrote: > I think Dan Kegel does not want them in the Winetest list. I'll defer > to AJ as to what HE wants. Sure ! The boss's always right. And it should be great to find a way to identify these "fake" windows. On 01/30/2011 07:29 PM, F Capela wrote: > Couple it with winetest being a fairly comprehensive test of the Windows APIs, > and I would bet such trimmed down windows to be prone to false issues. Understood. Anyway, I just submitted a patch which fix a crash occurring on this "windows" from a winetest result a user posted some days ago. He told me he used this "windows" to submit the results. Even if the errors should be ignored, the crash was real and my patch apply to all windows. Now, It's up to AJ to discard it or not.

Jan. 30, 2011

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

by Vitaliy Margolen

On 01/30/2011 04:16 AM, Peter Schlaile wrote: > Hi, > > find fix for a crash in create_alpha_bitmap() attached. If it's easy to reproduce please create a test that demonstrates the problem. > Additional minor fix: bmi_has_alpha() tests for alpha channel != 0, but > should test for alpha channel != 255. This should be a separate patch. Vitaliy.

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by F Capela

> From: GOUJON Alexandre <ale.goujon(a)gmail.com> > > On 01/30/2011 04:47 PM, James McKenzie wrote: >> On 1/27/11 7:04 PM, Dan Kegel wrote: >>> I suspect that we should discourage people from submitting >>> winetest results from 3rd party repackagings of Microsoft Windows, >>> e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience >>> >>> Agreed? >> +1. And that is a pirate version of Windows anyway. > I don't see the point ... > I mean, yeah it's not legal, it's bad and what you want but what about if they >provide results that differ from the daily bot results ? > Do you think this 'stripped' version can cause failures that would not happen >on real windows ? > Should we ignore these results ? I always customize my personal use Windows installs with nLite or something like that, and can say first hand that it can cause problems, and difficult to diagnose ones at that. And while I can often determine which component missing or misconfigured is causing the problem (since it was me in the first place that did choose to remove that specific component), I would bet the common user that downloads a stripped down version of Windows more often than not has no idea of the side effects. Couple it with winetest being a fairly comprehensive test of the Windows APIs, and I would bet such trimmed down windows to be prone to false issues.

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by James McKenzie

On 1/30/11 9:02 AM, GOUJON Alexandre wrote: > On 01/30/2011 04:47 PM, James McKenzie wrote: >> On 1/27/11 7:04 PM, Dan Kegel wrote: >>> I suspect that we should discourage people from submitting >>> winetest results from 3rd party repackagings of Microsoft Windows, >>> e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience >>> >>> Agreed? >> +1. And that is a pirate version of Windows anyway. > I don't see the point ... > I mean, yeah it's not legal, it's bad and what you want but what about > if they provide results that differ from the daily bot results ? > Do you think this 'stripped' version can cause failures that would not > happen on real windows ? > Should we ignore these results ? > I think Dan Kegel does not want them in the Winetest list. I'll defer to AJ as to what HE wants. I was just pointing out that this is legal to use in the United States and most other countries where Microsoft has enforceable copyrights. James McKenzie

Jan. 30, 2011

Re: MapleStory Wine Bug

by James McKenzie

On 1/30/11 10:35 AM, Jack Edmonds wrote: > I recently submitted a bug > (http://bugs.winehq.org/show_bug.cgi?id=25934) I'm not sure if I did a > good job on the submission, but if I did, I was thinking it would be a > good first bug to work on so as to introduce me to the Wine source code. > I was wondering if someone could help me get started on it. > Jack: There is a whole bunch of information on how to develop for Wine on the Wine Wiki. Including Coding Standards and what NOT to do as well as what TO do. I'll defer to those pages. James McKenzie

Jan. 30, 2011

MapleStory Wine Bug

by Jack Edmonds

I recently submitted a bug (http://bugs.winehq.org/show_bug.cgi?id=25934) I'm not sure if I did a good job on the submission, but if I did, I was thinking it would be a good first bug to work on so as to introduce me to the Wine source code. I was wondering if someone could help me get started on it.

Jan. 30, 2011

Re: user32: Replicate Windows 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=8728 Your paranoid android. === WNT4WSSP6 (32 bit msg) === msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x0111 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg 0x0111 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 4: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0138 was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg sequence is not complete: expected 8000 - actual 0000 msg.c:5644: Test failed: SETTEXT on a button: 2: the msg 0x0135 was expected, but got msg 0x002b instead msg.c:5644: Test failed: SETTEXT on a button: 3: the msg 0x002b was expected, but got msg 0x8000 instead msg.c:5644: Test failed: SETTEXT on a button: 4: the msg sequence is not complete: expected 8000 - actual 0000 === W7PROX64 (64 bit msg) === Timeout

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by Juan Lang

> I mean, yeah it's not legal, it's bad and what you want but what about if > they provide results that differ from the daily bot results ? So what? You know that the Windows software may have changed, and you can't replicate the results yourself (unless you also feel like breaking the law). > Do you think this 'stripped' version can cause failures that would not > happen on real windows ? > Should we ignore these results ? Perhaps, so yes. --Juan

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by GOUJON Alexandre

On 01/30/2011 04:47 PM, James McKenzie wrote: > On 1/27/11 7:04 PM, Dan Kegel wrote: >> I suspect that we should discourage people from submitting >> winetest results from 3rd party repackagings of Microsoft Windows, >> e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience >> >> Agreed? > +1. And that is a pirate version of Windows anyway. I don't see the point ... I mean, yeah it's not legal, it's bad and what you want but what about if they provide results that differ from the daily bot results ? Do you think this 'stripped' version can cause failures that would not happen on real windows ? Should we ignore these results ?

Jan. 30, 2011

Re: Policy regarding 3rd party "windows" distributions and winetest

by James McKenzie

On 1/27/11 7:04 PM, Dan Kegel wrote: > I suspect that we should discourage people from submitting > winetest results from 3rd party repackagings of Microsoft Windows, > e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience > > Agreed? +1. And that is a pirate version of Windows anyway. James McKenzie

Jan. 30, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by James McKenzie

On 1/29/11 6:53 AM, Qian Hong wrote: > Dear all, > While test another online bank with wine ActiveX, > I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, > I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, > so I can't understand this log: > wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called > at address 0x7b839552 (thread 0022), starting debugger... > Grateful for any explain! > Qian: I would like to echo Nikolay's comment and add one more: Please search through the Bug Reports before submitting a new one. You might receive more assistance on the Wine User list as well. Most of the developers lurk there. Thank you. James McKenzie

Jan. 30, 2011

Re: [PATCH 1/2] winecoreaudio: Don't use Component Manager on Mac OS 10.6.

by Charles Davis

On 1/29/11 6:40 PM, James McKenzie wrote: > Chip: > > I'm assuming that this has been checked on Tiger/Leopard and it works. I checked that it would work if the AudioComponent header weren't present (which it isn't pre-SL). > > I don't have a Leopard system here and I'm reluctant to try it on one of > the systems I have Tiger installed on (it is a PowerPC Mac.) I can't imagine why... :) Chip

Jan. 30, 2011

Re: Wine FAQ edits

by Vitaliy

On 01/29/2011 12:21 PM, Dan Kegel wrote: > Hi Albert, > http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks > like it was a pretty big edit. > > Try smaller ones, and try to do just one kind of change per edit. That, and the fact that some changes where questionable, and broken: > -cd ~/.wine/drive_c/Program\ Files > +cd .wine/drive_c/Program\ Files This will break if current directory is not $HOME. > - You can also use double quotes, but you need two backslashes instead of one: > - > -{{{ > -wine start "C:\\Games\\Tron\\tron.exe" > -}}} Backslashes still have special meaning inside double quotes. So they should be escaped. > -/bin/sh -c glxgears > +/usr/bin/env glxgears What advantage does "env" has over full featured shell? This is unnecessary. > -@="/bin/sh run_linx_program acroread \"%1\"" > +@="/bin/sh -c \"acroread `wine winepath -u '%1'`\"" Have you actually tested this? This won't work for paths with spaces. If it will work at all. Vitaliy

Jan. 29, 2011

re: Wine FAQ edits

by Dan Kegel

Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit. Try smaller ones, and try to do just one kind of change per edit.

Jan. 29, 2011

Wine FAQ edits

by Albert Lee

Hi Vitaliy, I notice you have reverted my edits to the FAQ on the wiki ( http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify the shell metacharacter information and operating system/platform support, and add new file association instructions, I would like to know why this happened and what changes should be done. -Albert

Jan. 29, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Nikolay Sivov

On 1/29/2011 16:53, Qian Hong wrote: > Dear all, > While test another online bank with wine ActiveX, > I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, > I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, > so I can't understand this log: > wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called > at address 0x7b839552 (thread 0022), starting debugger... > Grateful for any explain Please open bugs for such issues. wine-devel is for development process related discussions, not for user support.

Jan. 29, 2011

Re: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Erich Hoover

On Sat, Jan 29, 2011 at 4:18 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > Jackpot. This version ran 10,000 times without a glitch on the dual-core machine. Great! Thank you so much for helping me to track this down. Erich Hoover ehoover(a)mines.edu

Jan. 29, 2011

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Qian Hong

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Jan. 29, 2011

RE: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Greg Geldorp

From: Erich Hoover > Hmm, interesting - thanks for taking a look into this, I really appreciate > it. I ran a test on a different XP SP3 machine here (this time a dual-core) > and it worked just fine. So, at first I thought this must be an issue to > the combination of multi-core and Windows 7. > However, if the location of the exception has anything to say about it > (crashing after test_Navigate2:test_LocationURL), then my guess would be that > it's because of the "wb" global. I didn't notice this before (or if I did, I > forgot) but test_Navigate2:test_ready_state uses the IWebBrowser2 "wb" global, > which I did not initialize until after test_Navigate2. > If you wouldn't mind giving it a try on your system where the error is > reproducible, I've attached a revised patch where this variable is initialized > properly. Jackpot. This version ran 10,000 times without a glitch on the dual-core machine. Greg.

Jan. 29, 2011

Re: winex11.drv: When copying window bits exclude an update region only if the parent doesn't clip its children.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > - ExcludeUpdateRgn( hdc_dst, data->hwnd ); > > + if (!parent || !(GetWindowLongW( parent, GWL_STYLE ) & WS_CLIPCHILDREN)) > > + ExcludeUpdateRgn( hdc_dst, data->hwnd ); > > I don't see what the parent clipping has to do with this. Could you > please explain? Additional testing shows that this change is not correct, I'll try to figure out a better one. -- Dmitry.

Jan. 29, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Scott Ritchie

On 01/27/2011 11:24 PM, Reece Dunn wrote: > On 28 January 2011 01:44, Scott Ritchie <scott(a)open-vote.org> wrote: >> On 01/27/2011 02:20 PM, Reece Dunn wrote: >>> === Steps to Reproduce === >>> >>> Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. >>> >>> 1/ Build the latest version of wine with no special options -- >>> `./configure && make` >>> 2/ Remove any previously run test result -- `find . -type f | grep >>> .ok | xargs rm` >>> 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` >>> 4/ Run the tests -- `make test` >>> >>> This will download the gecko package and then fail in the dsound:ds3d >>> tests with: >>> >>> ds3d.c:467: Test failed: buffer size changed after SetFormat() >>> - previous size was 88200, current size is 22052 >>> >>> This error seems to be specific to 64-bit versions of the Ubuntu >>> family, looking at the http://test.winehq.org/data/ results. >>> >> >> Is this with the ia32-libs from the Wine PPA? > > $ dpkg -s ia32-libs > Package: ia32-libs > Status: install ok installed > Priority: extra > Section: libs > Installed-Size: 143224 > Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> > Architecture: amd64 > Version: 20090808ubuntu9 > > I am not using wine from the PPA, I am building it from git myself. > > - Reece You don't need the wine package from the PPA You do need the ia32-libs package from the Wine PPA in order to get gettext support. I recommend you do this when you're developing. -Scott

Jan. 28, 2011

Re: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Erich Hoover

On Fri, Jan 28, 2011 at 6:45 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > ... > I started by running your test binary 10,000 times on W7PROX64. Not a single > crash, so that looked kind of promising. Just to be sure, I then ran the > binary on a dual-core Win7 x64 machine (the W7PROX64 VM has only one core > assigned to it). This resulted in an immediate crash. Tried a few more times, > it crashed 9 out of 10 times. > > To make sure that these crashes are related to your patch, I ran the test > without your patch on the same dual-core machine. First few tries didn't > produce crashes, I then ran it in a loop 10,000 times. Not a single crash. > > So, it looks like your patch introduces some multi-threading issue. I haven't > investigated further, perhaps I'll have some time over the weekend to dig a > bit deeper. Hmm, interesting - thanks for taking a look into this, I really appreciate it. I ran a test on a different XP SP3 machine here (this time a dual-core) and it worked just fine. So, at first I thought this must be an issue to the combination of multi-core and Windows 7. However, if the location of the exception has anything to say about it (crashing after test_Navigate2:test_LocationURL), then my guess would be that it's because of the "wb" global. I didn't notice this before (or if I did, I forgot) but test_Navigate2:test_ready_state uses the IWebBrowser2 "wb" global, which I did not initialize until after test_Navigate2. If you wouldn't mind giving it a try on your system where the error is reproducible, I've attached a revised patch where this variable is initialized properly. Erich Hoover ehoover(a)mines.edu

Jan. 28, 2011

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

by Janne Hakonen

> Now, when I ran these tests on Testbot using all base VMs, the tests were run also on W2KPROSP4 and WNT4WSSP6. However, the > function seems to buggy in those. It throws access violation whenever it is not skipping frames. > Is there some way I could prevent/skip these tests to be run on Windows NT4 and 2000? Ah, no matter, I think I've got it. Adding following lines to start allows the tests to be skipped on NT and 2000: __TRY { pRtlCaptureStackBackTrace(0, 62, callers, NULL); } __EXCEPT_ALL { win_skip("RtlCaptureStackBackTrace threw SEH exception, " "most likely running on Windows NT or 2000\n"); return; } __ENDTRY Thanks, Janne

Jan. 28, 2011

Re: Alexander Scott-Johns : ole32: Add support for rendering METAFILEPICT clipboard objects.

by Nikolay Sivov

On 1/28/2011 21:30, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 0f4fbd30f6bf3d2ef471d3d75307c7fa8a7df137 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=0f4fbd30f6bf3d2ef471d3d75… > > Author: Alexander Scott-Johns<alexander.scott.johns(a)googlemail.com> > Date: Tue Jan 25 15:09:21 2011 +0000 > > ole32: Add support for rendering METAFILEPICT clipboard objects. > > --- > dlls/ole32/clipboard.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 96 insertions(+), 1 deletions(-) > > +/*************************************************************************** > + * get_data_from_metafilepict > + */ > +static HRESULT get_data_from_metafilepict(IDataObject *data, FORMATETC *fmt, HGLOBAL *mem) > +{ > + HGLOBAL copy; > + HRESULT hr; > + FORMATETC mem_fmt; > + STGMEDIUM med; > + > + *mem = NULL; > + > + mem_fmt = *fmt; > + mem_fmt.tymed = TYMED_MFPICT; > + > + hr = IDataObject_GetData(data,&mem_fmt,&med); > + if(FAILED(hr)) return hr; > + > + hr = dup_metafilepict(med.u.hMetaFilePict,&copy); > + if(FAILED(hr)) return hr; 'med' should be released here on failure. > + > + *mem = copy; > + > + ReleaseStgMedium(&med); > + > + return hr; > +} > + > /***********************************************************************

Jan. 28, 2011

Re: [PATCH 4/4] [Kernel32]: add ability to load additional terminfo data from Wine registry

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > as I said, terminfo is not fully populated > it misses lots of ctrl-<key> (left arrow, right arrow...) and has not > been updated lately > most of the common text editors come with their own config files > for example, /etc/inputrc has the missing bindings for libreadline > (and of course it depends on $TERM) > so, updating terminfo isn't the solution > > would you consider inclusion in hklm (instead of hkcu) ? If it's user-editable, it has to be in HKCU, with proper defaults in the code because we don't want to create user keys from wine.inf. Plus of course the format has to be something that users can understand, it can't be a binary array. Basically you'd have to replicate inputrc inside the registry, I'm not sure it's worth the trouble. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2011

Re: [PATCH 2/2] msvcrt: Use the _set_error_mode value to switch between a dialogbox and stderr for C runtime messages

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -134,8 +135,9 @@ static void DoMessageBox(LPCSTR lead, LPCSTR message) > void CDECL _amsg_exit(int errnum) > { > TRACE("(%d)\n", errnum); > - /* FIXME: text for the error number. */ > - if (MSVCRT_app_type == 2) > + > + if ((MSVCRT_error_mode == MSVCRT__OUT_TO_MSGBOX) || > + ((MSVCRT_error_mode == MSVCRT__OUT_TO_DEFAULT) && (MSVCRT_app_type != 1))) If you want to change the app type check that should be a separate patch, with its own justification. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Juan Lang

Hi Ken, > I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency? If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large. > I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. One minor nit: s/adaptor/adapter/ > I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. > > I'd appreciate a review of this general plan. I do see two problems with the general plan. One isn't specific to your plan: schannel as it is is buggy. We don't know where the bugs are, and they've languished for a long time. Your proposed plan doesn't help. The second is the additional bug triaging complexity. I'd much prefer to see a decent set of test cases for schannel. I suppose one could argue that that's orthogonal to this plan, but see my second complaint: without test cases, an additional implementation just makes debugging schannel bugs harder. Thanks, --Juan

Jan. 28, 2011

Re: PATCH: User32: Replicate Windows behavior of WM_SETTEXT handler regarding WM_CTLCOLOR*

by Vitaliy Margolen

On 01/27/2011 11:51 PM, Alexander LAW wrote: > > > + if (style & WS_VISIBLE) { > + HDC hdc = GetDC(hWnd); > + HBRUSH hbrush; > + RECT client, rc; > + HWND parent = GetParent(hWnd); Please follow the style of the file - curly brace goes on a separate line. Please if you can't set your editor to have tab character equal 8 spaces - don't use tabs! Use space characters only. > + if (!parent) parent = hWnd; > + UINT ctlMessage=((btn_type==BS_PUSHBUTTON || > btn_type==BS_DEFPUSHBUTTON || btn_type==BS_PUSHLIKE)?WM_CTLCOLORBTN: > WM_CTLCOLORSTATIC); This is not c++ inline declarations are not allowed. Please cut this line down it's too long. Also please add corresponding test to msg.c tests to validate the change. Vitaliy.

Jan. 28, 2011

Re: winex11.drv: Implement synthesizing the CF_ENHMETAFILE clipboard format from CF_METAFILEPICT.

by Vitaliy Margolen

On 01/27/2011 07:42 PM, Alexander Scott-Johns wrote: > > > > > + FIXME("Called to synthesize unknown format 0x%08x\n", wFormatID); Formats defined as decimal, so you should print it as decimal. > + if ((lpSource = X11DRV_CLIPBOARD_LookupData(CF_ENHMETAFILE)) && lpSource->hData) > + { > + bret = TRUE; > + } Just do "return TRUE". It will remove one level of indentation. > + void *mf_bits = HeapAlloc(GetProcessHeap(), 0, size_mf_bits); > + GetMetaFileBitsEx(pmfp->hMF, size_mf_bits, mf_bits); Please check if allocation succeeded. Vitaliy.

Jan. 28, 2011

Re: [PATCH 1/2] msvcrt: Add private define and header tests for _set_error_mode options

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=8692 Your paranoid android. === WNT4WSSP6 (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W2KPROSP4 (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === WXPPROSP3 (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W2K3R2SESP2 (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === WVISTAADM (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W2K8SE (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W7PRO (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W7PROX64 (32 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2 === W7PROX64 (64 bit headers) === headers.c:343: Test failed: Defines (MSVCRT_)_OUT_TO_MSGBOX are different: 2 vs. 1 headers.c:344: Test failed: Defines (MSVCRT_)_OUT_TO_STDERR are different: 1 vs. 2

Jan. 28, 2011

RE: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Greg Geldorp

From: Greg Geldorp <ggeldorp(a)vmware.com> > From: Erich Hoover > > On Thu, Jan 27, 2011 at 3:53 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > > > ... > > > Looking at http://test.winehq.org/data/tests/shdocvw:webbrowser.html, > > > the shdocvw:webbrowser test doesn't have a history of occasional > > > crashes. There are a few failures, but none of them are due to access > > > violations. Which kind of indicates that the crash is because of the > > > changes you made. > > > I know it sucks to investigate failures that don't repro consistently, > > > but I do think some more testing would be good here. Of course, if > > > there's any info you need about the VM just let me know. > > > > Well, I commandeered a XP SP3 box this morning and ran that exact same > > set of tests successfully 10,000 times. I don't have access to a Win7 > > box or I would have run the tests on that. Thoughts? > > I'll do a similar test on Win7 tomorrow and let you know the results. I started by running your test binary 10,000 times on W7PROX64. Not a single crash, so that looked kind of promising. Just to be sure, I then ran the binary on a dual-core Win7 x64 machine (the W7PROX64 VM has only one core assigned to it). This resulted in an immediate crash. Tried a few more times, it crashed 9 out of 10 times. To make sure that these crashes are related to your patch, I ran the test without your patch on the same dual-core machine. First few tries didn't produce crashes, I then ran it in a loop 10,000 times. Not a single crash. So, it looks like your patch introduces some multi-threading issue. I haven't investigated further, perhaps I'll have some time over the weekend to dig a bit deeper. Greg.

Jan. 28, 2011

Re: [1/2] shell32: Implement IShellDispatch::NameSpace

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=8684 Your paranoid android. === WVISTAADM (32 bit shelldispatch) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Jan. 28, 2011

Re: winex11.drv: When copying window bits exclude an update region only if the parent doesn't clip its children.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1624,7 +1624,8 @@ static void move_window_bits( struct x11drv_win_data *data, const RECT *old_rect > hdc_src = hdc_dst = GetDCEx( data->hwnd, 0, DCX_CACHE ); > } > > - ExcludeUpdateRgn( hdc_dst, data->hwnd ); > + if (!parent || !(GetWindowLongW( parent, GWL_STYLE ) & WS_CLIPCHILDREN)) > + ExcludeUpdateRgn( hdc_dst, data->hwnd ); I don't see what the parent clipping has to do with this. Could you please explain? -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2011

Re: [PATCH] winecoreaudio: Fix deprecation warnings.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > @@ -198,10 +222,19 @@ int AudioUnit_CreateInputUnit(void* wwi, AudioUnit* out_au, > UInt32* outFrameCount) > { > OSStatus err = noErr; > +#ifdef HAVE_AUDIOUNIT_AUDIOCOMPONENT_H > + /* Apple has threatened to rip out the Component Manager. > + * Protect ourselves from that. > + */ > + AudioComponentDescription description; > + AudioComponent component; > +#else > ComponentDescription description; > Component component; > +#endif It would be better to have a set of compatibility defines at the top instead of spreading #ifdefs all through the code. And please split independent changes into separate patches. -- Alexandre Julliard julliard(a)winehq.org

Jan. 28, 2011

Re: FYI: OpenCL/opencl.h from NVIDIA...

by Peter Urbanec

On 21/01/11 13:21, James McKenzie wrote: > As far as I knew from information I gathered here, the only OS that > supports OpenCL was MacOSX. Sorry for the misleading information. I developed wine OpenCL support under Gentoo, using the Gentoo provided NVidia drivers and NVidia CUDA packages. I'm not sure if anyone got it working on OSX. You should be able to: 1. Install the NVidia drivers 2. Install NVidia CUDA/OpenCL SDK 3. Make a link /usr/include/CL -> /opt/cuda/include/CL (or wherever you installed the SDK) After that, configure should find OpenCL and use it. If you want RPMs or other distro specific packages, hassle your distribution maintainers. (Or switch to Gentoo ;-) Both AMD and Intel also have OpenCL implementations/SDKs available. Their distro support varies. Best regards, Peter Urbanec

Jan. 28, 2011

Wine Source Study

by Pankaj Swami

Please help me..... I am last year Computer Engineering student & I want to study wine source code but I'm unable to decide from where to start studying wine source code.........? I have wine source code.

Jan. 28, 2011

Re: Another milestone

by Saulius Krasuckas

* On Thu, 27 Jan 2011, Greg Geldorp wrote: > > Today we had a clean winetest.exe run on all 31 TestBot VMs for the > first time. Although there are still failures on other test machines and > some tests fail occasionally on TestBot, I still think this is a > significant milestone. Congrats to all! And thanks :) > Hopefully the "Wine" column on http://test.winehq.org/data/ will soon > start to show some yellow spots too! I'm waiting years for this (since probably 2004:) My thanks go to all the developers and testers. S.

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Reece Dunn

On 28 January 2011 01:44, Scott Ritchie <scott(a)open-vote.org> wrote: > On 01/27/2011 02:20 PM, Reece Dunn wrote: >> === Steps to Reproduce === >> >> Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. >> >> 1/ Build the latest version of wine with no special options -- >> `./configure && make` >> 2/ Remove any previously run test result -- `find . -type f | grep >> .ok | xargs rm` >> 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` >> 4/ Run the tests -- `make test` >> >> This will download the gecko package and then fail in the dsound:ds3d >> tests with: >> >> ds3d.c:467: Test failed: buffer size changed after SetFormat() >> - previous size was 88200, current size is 22052 >> >> This error seems to be specific to 64-bit versions of the Ubuntu >> family, looking at the http://test.winehq.org/data/ results. >> > > Is this with the ia32-libs from the Wine PPA? $ dpkg -s ia32-libs Package: ia32-libs Status: install ok installed Priority: extra Section: libs Installed-Size: 143224 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Architecture: amd64 Version: 20090808ubuntu9 I am not using wine from the PPA, I am building it from git myself. - Reece

Jan. 28, 2011

Policy regarding 3rd party "windows" distributions and winetest

by Dan Kegel

I suspect that we should discourage people from submitting winetest results from 3rd party repackagings of Microsoft Windows, e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience Agreed?

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Austin English

On Thu, Jan 27, 2011 at 17:44, Scott Ritchie <scott(a)open-vote.org> wrote: > On 01/27/2011 02:20 PM, Reece Dunn wrote: >> === Steps to Reproduce === >> >> Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. >> >> 1/ Build the latest version of wine with no special options -- >> `./configure && make` >> 2/ Remove any previously run test result -- `find . -type f | grep >> .ok | xargs rm` >> 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` >> 4/ Run the tests -- `make test` >> >> This will download the gecko package and then fail in the dsound:ds3d >> tests with: >> >> ds3d.c:467: Test failed: buffer size changed after SetFormat() >> - previous size was 88200, current size is 22052 >> >> This error seems to be specific to 64-bit versions of the Ubuntu >> family, looking at the http://test.winehq.org/data/ results. >> > > Is this with the ia32-libs from the Wine PPA? > > Is 10.10 unaffected? 10.04 and 10.04 are both affected, the dsound tests fail with pulseaudio installed, see http://bugs.winehq.org/show_bug.cgi?id=20604 -- -Austin

Jan. 28, 2011

Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Scott Ritchie

On 01/27/2011 02:20 PM, Reece Dunn wrote: > === Steps to Reproduce === > > Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. > > 1/ Build the latest version of wine with no special options -- > `./configure && make` > 2/ Remove any previously run test result -- `find . -type f | grep > .ok | xargs rm` > 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` > 4/ Run the tests -- `make test` > > This will download the gecko package and then fail in the dsound:ds3d > tests with: > > ds3d.c:467: Test failed: buffer size changed after SetFormat() > - previous size was 88200, current size is 22052 > > This error seems to be specific to 64-bit versions of the Ubuntu > family, looking at the http://test.winehq.org/data/ results. > Is this with the ia32-libs from the Wine PPA? Is 10.10 unaffected? Thanks, Scott Ritchie

Jan. 28, 2011

RFC: Adding Mac support to secur32/schannel.c

by Ken Thomases

Hi, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. I'd appreciate a review of this general plan. Thanks, Ken

Jan. 28, 2011

Re: msvcrt: Forward _realloc_crt to realloc

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=8669 Your paranoid android. === WVISTAADM (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77497580 === W2K8SE (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 778A814C === W7PRO (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 772D2B79 === W7PROX64 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77E03100 === W7PROX64 (64 bit msvcr90) === No test summary line found

Jan. 27, 2011

Re: [4/4] gdi32: Move common code into helper function.

by Nikolay Sivov

On 1/27/2011 12:23, Kusanagi Kouichi wrote: > On 2011-01-26 19:28:29 +0300, Nikolay Sivov wrote: >> On 1/26/2011 19:09, Kusanagi Kouichi wrote: >>> -static LPSTR FONT_GetCharsByRangeA(HDC hdc, UINT firstChar, UINT lastChar, PINT pByteLen) >>> +static LPWSTR FONT_GetCharsByRangeA(HDC hdc, UINT firstChar, UINT lastChar, PINT pLen) >>> { >> It's better to change naming too, since it's won't return char >> string anymore. > What name do you think is better? > Is FONT_GetCharsByRange or FONT_GetCharsByRangeAToW OK? I think FONT_GetCharsByRangeW would be fine. Note that I don't know this code, and probably it should be done another way to avoid conversion in a first place (if possible at all).

Jan. 27, 2011

RE: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Greg Geldorp

From: Erich Hoover > On Thu, Jan 27, 2011 at 3:53 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > > ... > > Looking at http://test.winehq.org/data/tests/shdocvw:webbrowser.html, the > > shdocvw:webbrowser test doesn't have a history of occasional crashes. > > There are a few failures, but none of them are due to access violations. > > Which kind of indicates that the crash is because of the changes you > > made. > > I know it sucks to investigate failures that don't repro consistently, > > but I do think some more testing would be good here. Of course, if there's > > any info you need about the VM just let me know. > > Well, I commandeered a XP SP3 box this morning and ran that exact same > set of tests successfully 10,000 times. I don't have access to a Win7 > box or I would have run the tests on that. Thoughts? I'll do a similar test on Win7 tomorrow and let you know the results. Greg.

Jan. 27, 2011

Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi

by Reece Dunn

=== Observations === 1/ The dsound:ds3d tests fail when using the ALSA audio driver on 64-bit (K)Ubuntu, but succeed with the OSS audio driver. 2/ The mmdevapi tests fail with a "Device not found"/"No driver" error (hr = 0x88780078) when running with the OSS driver. For the mmdevapi failures, the tests should skip when intercepting a "Device not found" error. === Steps to Reproduce === Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. 1/ Build the latest version of wine with no special options -- `./configure && make` 2/ Remove any previously run test result -- `find . -type f | grep .ok | xargs rm` 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` 4/ Run the tests -- `make test` This will download the gecko package and then fail in the dsound:ds3d tests with: ds3d.c:467: Test failed: buffer size changed after SetFormat() - previous size was 88200, current size is 22052 This error seems to be specific to 64-bit versions of the Ubuntu family, looking at the http://test.winehq.org/data/ results. 5/ Open winecfg -- `./wine winecfg` 6/ Select the Audio tab This should being up a message to recommend a driver (as no driver is set in the registry) and then select the ALSA driver. 7/ Switch the audio driver from ALSA to OSS and press OK. 8/ Re-run the tests -- `make test` This passes the ds3d tests, but fails with: ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so dependency.c && touch dependency.ok err:quartz:DSoundRender_create Cannot create Direct Sound object (88780078) fixme:ole:CoCreateInstance no instance created for interface {56a86895-0ad4-11ce-b03a-0020af0ba770} of class {79376820-07d0-11cf-a24d-0020afd79767}, hres is 0x88780078 dependency.c:85: Test failed: Activating bf failed: 0x88780078 9/ Open winecfg -- `./wine winecfg` 10/ Switch the audio driver from OSS back to ALSA and press OK. 11/ Re-run the tests -- `make test` The mmdevapi tests now pass. - Reece

Jan. 27, 2011

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

by Janne Hakonen

Hi again, I've been working to implement the tests for RtlCaptureStackBackTrace(), but I have encountered a problem. The function, according to MSDN should be available only in Windows XP and newer OSes. Now, when I ran these tests on Testbot using all base VMs, the tests were run also on W2KPROSP4 and WNT4WSSP6. However, the function seems to buggy in those. It throws access violation whenever it is not skipping frames. Here's the test patch I used: http://testbot.winehq.org/GetFile.pl?JobKey=8606&StepKey=1 In both cases, test on patch's line 83 failed and call on line 92 crashed the test. In other VMs the tests succeeded and none crashed. Is there some way I could prevent/skip these tests to be run on Windows NT4 and 2000? Best Regards, Janne Hakonen

Jan. 27, 2011

Another milestone

by Greg Geldorp

Today we had a clean winetest.exe run on all 31 TestBot VMs for the first time. Although there are still failures on other test machines and some tests fail occasionally on TestBot, I still think this is a significant milestone. Hopefully the "Wine" column on http://test.winehq.org/data/ will soon start to show some yellow spots too! Greg.

Jan. 27, 2011

Re: [PATCH 4/4] [Kernel32]: add ability to load additional terminfo data from Wine registry

by Eric Pouech

Le 19/01/2011 13:07, Alexandre Julliard a écrit : > Eric Pouech<eric.pouech(a)orange.fr> writes: > >> you mean hardwiring the missing keys (potentially different according to >> terminal type) in the code? > If they depend on terminal type they belong in terminfo, not in the > registry. > as I said, terminfo is not fully populated it misses lots of ctrl-<key> (left arrow, right arrow...) and has not been updated lately most of the common text editors come with their own config files for example, /etc/inputrc has the missing bindings for libreadline (and of course it depends on $TERM) so, updating terminfo isn't the solution would you consider inclusion in hklm (instead of hkcu) ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Jan. 27, 2011

Re: [ActiveX] Wine builtin IE crash while login to https://www.alipay.com/

by Jacek Caban

Hi Qian, On 1/26/11 9:06 AM, Qian Hong wrote: > However, sence Wine buitin IE began to support ActiveX, I have also > tested alipay.com with wine buitin IE, just for reporting. Support for ActiveX in Wine IE is a fairly new feature and it still quite limited. Honestly I've tested it mostly with Flash ActiveX version (which was my main interest in implementing it). I don't expect much more to work, but I'd be interested in results of real-world tests with other controls/requirements. Please file a bug about it (in mshtml component) and CC me. Jacek

Jan. 27, 2011

Re: [ActiveX]crash while open https://mybank.icbc.com.cn/icbc/perbank/index.jsp use wine buitin IE

by Jacek Caban

On 1/27/11 8:19 PM, Qian Hong wrote: > On Fri, Jan 28, 2011 at 2:51 AM, Saulius Krasuckas<saulius2(a)ar.fi.lt> wrote: >> ABBYY FormFiller software (used to fill data for electronic tax >> declaration system at the state level in our country) also requires >> vbscript.dll to parse data validation rules. There is workaround, though. >> You just run "winetricks wsh56vb". > Dear Saulius, thanks for the tips! > However, I wonder whether this workaround will work for wine builtin > IE, it seems that wine builtin IE doesn't handle for vbscript yet? Yes, it should, but it's not well tested. I've only tested it while implementing the very first Active Script support with a hello world script. Jacek

Jan. 27, 2011

Re: [ActiveX]crash while open https://mybank.icbc.com.cn/icbc/perbank/index.jsp use wine buitin IE

by Qian Hong

On Fri, Jan 28, 2011 at 2:51 AM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > ABBYY FormFiller software (used to fill data for electronic tax > declaration system at the state level in our country) also requires > vbscript.dll to parse data validation rules. There is workaround, though. > You just run "winetricks wsh56vb". Dear Saulius, thanks for the tips! However, I wonder whether this workaround will work for wine builtin IE, it seems that wine builtin IE doesn't handle for vbscript yet? Best wishes ! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Jan. 27, 2011

Re: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.

by Erich Hoover

On Thu, Jan 27, 2011 at 3:53 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote: > ... > Looking at http://test.winehq.org/data/tests/shdocvw:webbrowser.html, the > shdocvw:webbrowser test doesn't have a history of occasional crashes. > There are a few failures, but none of them are due to access violations. > Which kind of indicates that the crash is because of the changes you > made. > I know it sucks to investigate failures that don't repro consistently, > but I do think some more testing would be good here. Of course, if there's > any info you need about the VM just let me know. Well, I commandeered a XP SP3 box this morning and ran that exact same set of tests successfully 10,000 times. I don't have access to a Win7 box or I would have run the tests on that. Thoughts? Erich Hoover ehoover(a)mines.edu

Jan. 27, 2011

Re: [ActiveX]crash while open https://mybank.icbc.com.cn/icbc/perbank/index.jsp use wine buitin IE

by Saulius Krasuckas

* On Thu, 27 Jan 2011, Juan Lang wrote: > > > By the way, will wine builtin IE support vbscript in the future? ICBC > > online bank required vbscript. > > That's a pretty open-ended question. I haven't seen anyone volunteer > to work on this in some time, so I'd say the odds are not so good. ABBYY FormFiller software (used to fill data for electronic tax declaration system at the state level in our country) also requires vbscript.dll to parse data validation rules. There is workaround, though. You just run "winetricks wsh56vb". S.

Jan. 27, 2011

Re: shell32/tests: Remove shlwapi dependency

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=8618 Your paranoid android. === WVISTAADM (32 bit shelldispatch) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Jan. 26, 2011

Re: winex11.drv: initialize drawable (clang)

by denis bonnenfant

Le mardi 25 janvier 2011 à 19:10 +0100, Henri Verbeet a écrit : > 2011/1/25 André Hentschel <nerv(a)dawncrow.de>: > > http://austinenglish.com/logs/clang_analyzer/report-dRpLpZ.html#EndPath > > then the if condition is reliable > I don't think that can happen unless hwnd is NULL and top is non-NULL, > which looks like invalid input to me. > > Maybe http://bugs.winehq.org/show_bug.cgi?id=24621 ? Is it worth to investigate in this direction ? Denis.

Jan. 25, 2011

Re: kernel32: Removing - key from keybindings.

by Trygve Vea

On Tue, Jan 25, 2011 at 8:35 PM, Trygve Vea <trygve.vea(a)gmail.com> wrote: > Fixes bug 25856, introduced in 2a219b948c451213fb4554352b86f3784a8f7e32. > It seems that Eric Pouech already posted an identical patch, which has been applied. This is then unnecessary. I apologize for the noise. -- Trygve Vea

Jan. 25, 2011

Re: wine-patches

by Juan Lang

Hi Vincent, > I sent this email on wine-patch but... nothing. > > Am I doing something wrong ? Sorry, I should have replied earlier. The patch doesn't appear to fix anything, so it's unclear where you're going with it. It'd be better to send a more complete patch series. For example, +static BOOL PCSCLite_loadfunctions(void) +{ + FIXME("%s\n", SONAME_LIBPCSCLITE); + return TRUE; +} this just adds spam to the console. Also, why do you return BOOL, when the return value is never checked? More nitpicking: +static void *g_pcscliteHandle = NULL; The initialization is unnecessary, statics are implicitly initialized to 0. + if (g_pcscliteHandle) + { + wine_dlclose(g_pcscliteHandle, NULL, 0); + g_pcscliteHandle = NULL; The assignment of NULL is unneeded, the process is being unloaded. + if (g_pcscliteHandle) + return TRUE; /* already loaded */ + else This check is unneeded, the function is only called at process load, i.e. only once. --Juan

Jan. 25, 2011

Re: winex11.drv: initialize drawable (clang)

by Henri Verbeet

2011/1/25 André Hentschel <nerv(a)dawncrow.de>: > http://austinenglish.com/logs/clang_analyzer/report-dRpLpZ.html#EndPath > then the if condition is reliable I don't think that can happen unless hwnd is NULL and top is non-NULL, which looks like invalid input to me.

Jan. 25, 2011

Re: po: Update the Dutch translation

by Alexandre Julliard

Sven Baars <sven.wine(a)gmail.com> writes: > Hey, > > All those po editors piss me off. First, the changes I make don't get > saved, then they do get saved but magically disappear when I try to > send them. Now I used poedit, which is apparently the only one that > works, and this one makes whole bunch of changes by itself. > > If this unacceptable, could someone please tell me how to work with > this stuff? Or would it be better to just use a normal editor? Maybe > emacs? And how could I recover the actual changes I made (and not the > ones poedit made) if this patch is not acceptable? You should run it through msgmerge before sending. Something like msgmerge nl.po wine.pot > nl.po.new -- Alexandre Julliard julliard(a)winehq.org

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Loïc Maury

On Tue, Jan 25, 2011 at 12:29 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > Loïc, > > Your mailer seems to have mangled your patch with line wrapping. There are > some suggestions on Wine's SubmittingPatches wiki page for avoiding this. > Primarily, you should attach the patch to your email. If you already did > that, then you may need to use a different mailer. For example, Mail.app > used to mess up even attached patches, although it doesn't for me anymore. > (I don't know if that's because Mail.app changed or if git-format-patch > changes.) When it used to be a problem, I had to use Thunderbird to send my > Wine patches. Thank you for advices, I will use Thunderbird. Loïc

Jan. 25, 2011

ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 4)

by Loïc Maury

--- dlls/ntdll/cdrom.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)

Jan. 25, 2011

Re: [Bug 25402] Woody Two Legs crashes with unimplemented function msvcr90.dll._wcslwr_s

by Eric Pouech

the spec should read wstr instead of ptr A+ 2011/1/25 <wine-bugs(a)winehq.org> > http://bugs.winehq.org/show_bug.cgi?id=25402 > > Andrew Millington <andrew.millington(a)gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Keywords| |patch > > --- Comment #5 from Andrew Millington <andrew.millington(a)gmail.com> > 2011-01-25 01:23:06 CST --- > After applying http://source.winehq.org/patches/data/70240 it complains > about > unimplemented function d3dx9_36.dll.D3DXFloat32To16Array and that is bug > #25769. > > -- > 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. > > > -- -- Eric Pouech

Jan. 25, 2011

Re: [PATCH 2/4] wined3d: Add support for the NULL format.

by Henri Verbeet

On 25 January 2011 11:17, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am 24.01.2011 um 18:41 schrieb Henri Verbeet: > >> - if (surface) >> + if (surface && surface->resource.format->id != WINED3DFMT_NULL) > Doesn't this cause GL errors? In my testing I had to set the draw buffer to GL_NONE to be able to draw without a color attachment. > You're probably right, although it worked fine when I tested it, probably by chance. Please ignore this patch for now.

Jan. 25, 2011

Re: [PATCH 2/4] wined3d: Add support for the NULL format.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.01.2011 um 18:41 schrieb Henri Verbeet: > - if (surface) > + if (surface && surface->resource.format->id != WINED3DFMT_NULL) Doesn't this cause GL errors? In my testing I had to set the draw buffer to GL_NONE to be able to draw without a color attachment. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNPqNaAAoJEN0/YqbEcdMwWFwP/0KW7THyiplBKi6csC7b6qWi i7Bi3VG5UMRomIDUyWMTlH+mwLqP7+AchzVYEHAM/blhe5yqemDc2YAN2f2/aNtV cbWoaIilTNF3PKH11wVvtUowidrwHmr9eV+SmHplvhdpJCTGKqU0ZxmNgl2DDiSD iPVfCmL6RE1e5n9i11AH7aQIcZjwPTEQBQlLR5IB1zpcnXab0r7vyTU44f0HkcJ0 785ast6QuG7lawibe7PmRz41VcFCtSMZF3QGgEujAn+frtYhqjVLdP8LITWZ+1mL jPfCWEQX1vlgbdMogykfnKSfm5oxaDMsrU3vMskwUGWFZCX+M7ffHIfy7cpy8HUt YVz4kqeaLr1xeZEsEaAQqjNal1PXoJCJSVA6ckV7VhB0+OkXpcH4i8ifdCtRv1PJ 0V/vryBBQgM9AczBQI8lb1c7w7lQL9EzttpNwbbC3mBTsT3/7EHJRuxR8EStIgzC 8gyTXveyBGuJel8Bwx6M+tBSskCNKFzPN7MKkvIE2+X5NSYj5eI05GSQRMl/eush jZWe+ls9GYgl76bL8+By1RRTsXGizPdW8UnX6HhzMfBErU1Z7IZbbqEiTMgXFOJL 0v0UXfLecE/mHlgrauk7b0C51JMtTXq5uuSOQ8uxFz/t2KcElja6pY4/nkN3DoLe I/cZaSyeQ3B5lTVTeZt/ =UA0G -----END PGP SIGNATURE-----

Jan. 25, 2011

wine-patches

by Vincent Hardy

Hi, I sent this email on wine-patch but... nothing. Am I doing something wrong ? Am I blacklisted ? Vincent

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Henri Verbeet

On 25 January 2011 01:06, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Uh, you mean git send-email, right? Right.

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Charles Davis

On 1/24/11 4:51 PM, Henri Verbeet wrote: > On 25 January 2011 00:29, Ken Thomases <ken(a)codeweavers.com> wrote: >> Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. >> > Just use git format-patch for sending patches, if possible. Uh, you mean git send-email, right? All git format-patch does is, well, format patches so they can be sent by a mail client. Chip

Jan. 25, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Henri Verbeet

On 25 January 2011 00:29, Ken Thomases <ken(a)codeweavers.com> wrote: > Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. > Just use git format-patch for sending patches, if possible. Mail clients are just terrible, and using git format-patch avoids a lot of the common issues. If you send more than one or two patches it's usually faster too.

Jan. 24, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Ken Thomases

Loïc, Your mailer seems to have mangled your patch with line wrapping. There are some suggestions on Wine's SubmittingPatches wiki page for avoiding this. Primarily, you should attach the patch to your email. If you already did that, then you may need to use a different mailer. For example, Mail.app used to mess up even attached patches, although it doesn't for me anymore. (I don't know if that's because Mail.app changed or if git-format-patch changes.) When it used to be a problem, I had to use Thunderbird to send my Wine patches. Cheers, Ken On Jan 23, 2011, at 3:47 AM, Loïc Maury wrote: > --- > dlls/ntdll/cdrom.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c > index 59f85a0..6a6d8e0 100644 > --- a/dlls/ntdll/cdrom.c > +++ b/dlls/ntdll/cdrom.c > @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) > return STATUS_SUCCESS; > else > return STATUS_NO_MEDIA_IN_DEVICE; > +#elif defined(__APPLE__) > + /* At this point, we know that we have media, because in Mac OS X, the > + * device file is only created when media is present. */ > + return STATUS_SUCCESS; > #else > FIXME("not supported on this O/S\n"); > return STATUS_NOT_SUPPORTED; > -- > 1.7.3.2 >

Jan. 24, 2011

Re: Static analysis scan

by Juan Lang

Hi Amine, > I've set up a static analysis scan using clang static analyzer. The results > are available at http://austinenglish.com/logs/clang_analyzer/index.html > thanks to Austin for the web space. > > Please feel free to fix the defects. I'll run future scans when the defects > get fixed progressively. That's nice, but there's no way to remove false positives, and not every "bug" listed is in fact a bug. This makes the results a bit unwieldy, IMO. --Juan

Jan. 24, 2011

Static analysis scan

by Amine Khaldi

Hello folks, I've set up a static analysis scan using clang static analyzer. The results are available at http://austinenglish.com/logs/clang_analyzer/index.html thanks to Austin for the web space. Please feel free to fix the defects. I'll run future scans when the defects get fixed progressively. Have fun ;) With best regards, Amine.

Jan. 24, 2011

Re: oleaut32/typelib2: Use implementation pointer to trace ICreateTypeInfo2

by Nikolay Sivov

On 1/24/2011 12:38, Michael Stefaniuc wrote: > Hello Nikolay, > > On 01/24/2011 01:01 AM, Nikolay Sivov wrote: >> Use implementation pointer to trace ICreateTypeInfo2 > >> diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c >> index 8260ef2..5c843a1 100644 >> --- a/dlls/oleaut32/typelib2.c >> +++ b/dlls/oleaut32/typelib2.c > >> @@ -2322,6 +2321,7 @@ static HRESULT WINAPI >> ICreateTypeInfo2_fnAddVarDesc( >> >> /* increment the number of variable elements */ >> This->typeinfo->cElement += 0x10000; >> +ERR("count=%d\n", This->typeinfo->cElement); > this looks like some leftover debug line. Right, thanks.

Jan. 24, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Erich Hoover

On Sun, Jan 23, 2011 at 11:32 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 1/20/11 6:40 PM, Erich Hoover wrote: >> On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >>> + ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status); >>> You could test the exact value here: ok(status == ...) >> >> I was trying to avoid adding some conditional todo_wine calls > > Hiding differences between Wine and Windows in tests is the worst thing you can do. When one is trying to find a bug, tested parts of implementation are much less suspicious than not or poorly tested. If you know about more such things in the patch, please fix them. You don't write the test to pass on your implementation. You write it to know the right implementation. I would say that testing the mask is not about hiding differences, it makes it clear that this particular test is meant to demonstrate whether a specific feature is available. At some point you have to make a trade-off between making a particular test completely comprehensive or having it be clear exactly what is being tested. In this particular component there are a lot of things that are not yet implemented, so it's a little difficult to add a self-contained test for a feature without it ballooning into a bunch of unrelated issues. There are two other such "issues" I have become aware of with the current implementation that could be added as tests, but I would say that they both belong in separate patches (if you want them at all): 1) The IOleCommandTarget is cached when the WebBrowser is initialized (rather than being requested each time it is used) 2) The document is initialized much earlier on native than it is in Wine My goal here is to implement (as well as I can) a single feature that I've had sitting in my stack of unsubmitted patches, I'm not trying to implement everything in this component in one fell swoop. If that's really what it's going to take to get this feature implemented then I can take the time to implement more, but it'll take me a while and I'd really like to move this item off of my plate so I can clean up some of my other unsubmitted patches before they become too far out of sync. >> (for some reason native does not respond with "supported", even though it >> does in the mshtml tests), please see if you like the attached better. > Or it proves that it's not a simple forward to mshtml? It's possible that they masked the supported flag out, especially since all of the examples I've seen on MSDN check for the enabled flag rather than the supported flag. However, I doubt that they copy-pasted the mshtml code and then made changes to it. I'd say that even if they did it'd be better to forward to mshtml and discover if there are any differences (and where they are) as people test applications that use this functionality. > We still have them in separated functions you've called test_QueryStatusWB and test_ExecWB. We most likely will want more tests on WebBrowser instance without container's IOleCommandTarget, and it would be nice if we could reuse test_CommandTargetPassthru for that (well, the name would be better more generic as well). Sorry, for some reason I was a bit dense and didn't catch exactly what you were planning here. Please see if the attached is more to your liking, the test bot results are available here: https://testbot.winehq.org/JobDetails.pl?Key=8575 Erich Hoover ehoover(a)mines.edu

Jan. 24, 2011

Re: gdi32: Prevent character code from wrapping around.

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > If lastChar is 0xffffffff, FONT_GetCharsByRangeA falls into > infinite loop and crash. You probably want more sanity checks (with tests), characters above 0xffff wouldn't make sense anyway. -- Alexandre Julliard julliard(a)winehq.org

Jan. 24, 2011

Re: [PATCH] To: wine-patches@winehq.org

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > [Kernel32]: in bare console with curses, ensure control stream is sent to tty (even when some fd:s are redirected) There doesn't seem to be much point in initializing input if we can't see the output. On the contrary, I think we should err on the side of not initializing anything unless really necessary. -- Alexandre Julliard julliard(a)winehq.org

Jan. 24, 2011

Re: Questioning the depth_clamp_test in d3d8:visual

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.01.2011 um 13:02 schrieb <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com>: > - Wylda's Intel-based machine #2 passes the tests. Hurray! > - One unknown win7 machine with Intel gfx also passes them. > - Aurimas' machine produces one different error (also Intel gfx). Afaik the test passes on Windows everything but Nvidia(well, it passes on Intel according to your observations, and I know it passes on my ATI box). I tried to understand the Nvidia failure, as far as I know the depth clamp state just doesn't do anything on this card. A game that depends on the behavior tested by the test is Prince of Persia 3D, a ddraw/d3d7 game. I could not test this game on my Windows 7 machine(s), it failed to install. Any decent explanation why the test fails on Nvidia on Windows, or clear proof that the driver is broken(e.g. POP3D doesn't render properly) would be very welcome. > Looking at Wine test data (from 1.3.12), it appears that Wine > implements exactly the opposite behaviour: the NVidia (+ 1 ATI) machines > pass the tests, e.g. behave like Intel on native, while the Intel gfx one > (eeepc) produces the 3 errors known from native NVidia! We don't have card-specific behavior in wined3d. wined3d implements the behavior according to what the test says is correct. I suspect the Intel driver used to run the failing Linux test does not implement GL_NV_depth_clamp or GL_ARB_depth_clamp, or implements it incorrectly. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNPW01AAoJEN0/YqbEcdMw7+0QAIASHnfadfVtST4r5ZKUR54p 2eZjo6zwkF6v/uY0V6PTpiIKFmnXwLus37de7/A0r8x7f/C9cjpo0YpcGKBX5pAo Qht6AtNuQup6U9EAZ+cVksqyRwfYLL4GC43v18nf1wugdxnGeg7tMM6Btz0wE3id WmVL82k2Y0unqPttFIGrE5MVK6vjmm/Xy5W00U1jP7rbSaKn6maycAIeAl3nh6oa sBQD6qoU6wy63vQImhy37mc4LNETmxMOYDMabfgcypZXiPx7V9/xst8NyJU9cmJg 03+K5/PkyxknM7wZWHiJe0cmEOf1iNlk7qrDDMUGukvsQKwqEr1AeaMQnqALMnuV b+aK7k13dMI+aJ3EDWlyQq7DGaASSHVW6N7A8ZaApaX/ldBvBBRzg/3Ueb0tWv/j /Iik1CIVQ2YbDw6Zx9YxxBYVr7kTNS6CDvQ96+o448QPekdFVNZpFHuly7R1inZF anOw7zQJuzCuOyo5dksmyq3oe4raFL3hkrR0APHh33eFaGIKeoaxIBmhPsYHF7da LzlChwGAJpbwNm1A7zebGd33lmc5ll6ewYB3rT4XElb4Gsxs3yAcaWklSN85NidK ngLx7x448u1HsH+3ueqz4gDvjMv+J+IE067bS/K7UsZGqz9OM8OPlQQ9/S3TnAcO 95agLGJfYmme9XO3jFNN =7yAs -----END PGP SIGNATURE-----

Jan. 24, 2011

Re: Questioning the depth_clamp_test in d3d8:visual

by Henri Verbeet

On 24 January 2011 13:02, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > My conclusion: the tests only prove that Wine wants to mimic Intel graphics, > but they do not account for the variety of observed test results. The issue is more subtle than that.

Jan. 24, 2011

Questioning the depth_clamp_test in d3d8:visual

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Trying to understand bugs #10636 and #19773 , I glanced at the d3d8 visual.ok directx test results. It appears that the green colour on test.winehq does not mean much. - All (any exception?) WTB machines skip the tests because d3d8 is not installed. - Same for Francois Gouget's virtual machines. That alone explains green colour. - Wylda's *real* machine #1 (NVidia gfx) produces 5 errors: visual.c:1411: Test failed: color 0x00ffffff. visual.c:1413: Test failed: color 0x00ffffff. visual.c:1415: Test failed: color 0x00ffffff. - "geniuh"'s (NVidia) machine as well. - Saulius' (NVidia) XP and w7 machines shows only these 3 errors. - Wylda's Intel-based machine #2 passes the tests. Hurray! - One unknown win7 machine with Intel gfx also passes them. - Aurimas' machine produces one different error (also Intel gfx). BTW, Wylda recently mentioned that the d3d tests produce vastly different graphics on his 2 machines. My conclusion: the tests only prove that Wine wants to mimic Intel graphics, but they do not account for the variety of observed test results. Danger: one may draw false conclusions from the ok() and wrongly generalize supposed behaviour of the tested functions. Looking at Wine test data (from 1.3.12), it appears that Wine implements exactly the opposite behaviour: the NVidia (+ 1 ATI) machines pass the tests, e.g. behave like Intel on native, while the Intel gfx one (eeepc) produces the 3 errors known from native NVidia! This smells wrong... Regards, Jörg Höhle

Jan. 24, 2011

Re: oleaut32/typelib2: Use implementation pointer to trace ICreateTypeInfo2

by Michael Stefaniuc

Hello Nikolay, On 01/24/2011 01:01 AM, Nikolay Sivov wrote: > Use implementation pointer to trace ICreateTypeInfo2 > diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c > index 8260ef2..5c843a1 100644 > --- a/dlls/oleaut32/typelib2.c > +++ b/dlls/oleaut32/typelib2.c > @@ -2322,6 +2321,7 @@ static HRESULT WINAPI ICreateTypeInfo2_fnAddVarDesc( > > /* increment the number of variable elements */ > This->typeinfo->cElement += 0x10000; > +ERR("count=%d\n", This->typeinfo->cElement); this looks like some leftover debug line. > > return status; > } bye michael

Jan. 24, 2011

Re: server: fix connect failures on newer kernels

by Dmitry Timoshkov

Marcus Meissner <marcus(a)jet.franken.de> wrote: > > diff --git a/server/sock.c b/server/sock.c > > index d37a316..134efb0 100644 > > --- a/server/sock.c > > +++ b/server/sock.c > > @@ -388,6 +388,9 @@ static void sock_poll_event( struct fd *fd, int event ) > > > > if (sock->state & FD_CONNECT) > > { > > + if (event & POLLOUT && event & (POLLERR|POLLHUP)) > > + event &= ~POLLOUT; > > Add more braces to make the operator precedence a bit more clear... > (just a style issue though) Or probably more simple if (event & (POLLERR|POLLHUP)) event &= ~POLLOUT; -- Dmitry.

Jan. 24, 2011

Re: server: fix connect failures on newer kernels

by Marcus Meissner

On Mon, Jan 24, 2011 at 12:21:15AM -0500, Mike Kaplinskiy wrote: > For some reason the newer kernels report POLLOUT|POLLERR|POLLHUP when > connect() fails. Strip the POLLOUT in this case. This (hopefully) > fixes bug 25456. > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 1b81544..3c6425e 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -3965,7 +3965,7 @@ static void test_ConnectEx(void) > closesocket(listener); > listener = INVALID_SOCKET; > > - address.sin_port = 1; > + address.sin_port = htons(1); > > bret = pConnectEx(connector, (struct sockaddr*)&address, addrlen, NULL, 0, &bytesReturned, &overlapped); > ok(bret == FALSE && GetLastError(), "ConnectEx to bad destination failed: " > diff --git a/server/sock.c b/server/sock.c > index d37a316..134efb0 100644 > --- a/server/sock.c > +++ b/server/sock.c > @@ -388,6 +388,9 @@ static void sock_poll_event( struct fd *fd, int event ) > > if (sock->state & FD_CONNECT) > { > + if (event & POLLOUT && event & (POLLERR|POLLHUP)) > + event &= ~POLLOUT; Add more braces to make the operator precedence a bit more clear... (just a style issue though) Ciao, Marcus

Jan. 24, 2011

new winetricks 20110123: work around bug in wine-1.3.12. new winetricks-alpha 20110123: ditto, plus new verbs cnc3_demo, guildwars, hphbp_demo, nfsshift_demo, sims3, spotify, vc2005trial

by Dan Kegel

Another week, another winetricks. This release is mainly to add a workaround for http://bugs.winehq.org/show_bug.cgi?id=25838 in wine-1.3.12, which broke winetricks. winetricks-alpha version 20110123 adds the following new verbs: cnc3_demo: Command and Conquer 3 demo guildwars: Guild Wars hphbp_demo: Harry Potter Half Blood Prince demo nfsshift_demo: Need For Speed: Shift demo sims3: The Sims 3 spotify: the popular music service vc2005trial: Visual C++ 2005 Trial winetricks version 20110123 adds no new verbs. Both scripts can be downloaded from winetricks.org at the obvious urls: http://winetricks.org/winetricks http://winetricks.org/winetricks-alpha (The old download url at kegel.com/wine/winetricks still works, too.) Bug tracker and svn repository are at http://winetricks.googlecode.com ----------------------------------- Changelog for winetricks-alpha: Dan Kegel: Work around wine bug 25838 :-( Ported verbs hphbp_demo, sims3 from wisotool Fix mingw PATH (again) Add example to help for 'list' command w_download{,_manual}: get rid of need to specify package name. w_download_manual: open destination folder in desktop for user python26_comtypes: metadata should be "year", not "date". Shortened title for psdkwin7 to fit window. Shannon Vanwagner: New verb spotify Phil Blankenship: Ported verbs cnc3_demo, guildwars, nfsshift_demo, vc2005trial from wisotool. ----------------------------------- Changelog for winetricks: Dan Kegel: Work around wine bug 25838 :-( Austin English: update opensymbol url/sha1sum ----------------------------------- Enjoy!

Jan. 24, 2011

wine-1.3.12 broke winetricks :-(

by Dan Kegel

Looks like wine-1.3.12 went out without the fix for http://bugs.winehq.org/show_bug.cgi?id=25838 I've checked a workaround into winetricks, and will do a release, but I bet a few users will be confused...

Jan. 24, 2011

Re: 3Dmark2001se & heap corruption

by Jeff Zaroyko

On Mon, Jan 24, 2011 at 6:42 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 23 January 2011 09:03, <wylda(a)volny.cz> wrote: >> >> Is there any way to verify such heap corruption on real windows? >> > Not easily, I think. There are certainly tools like Valgrind for > Windows, but I'm not sure if there are any free ones. If there's no > Wine code being executed between the allocation and the free it seems > unlikely to me that it's a problem in Wine though. > This one is free (LGPL) http://dynamorio.org/drmemory.html IBM has evaluation versions of Rational Purify too. Jeff

Jan. 23, 2011

Re: 3Dmark2001se & heap corruption

by Vitaliy Margolen

On 01/23/2011 01:03 AM, wylda(a)volny.cz wrote: >>> Is that somehow useful? >>> >> Are there any calls in between? It may just be an >> application bug. > > No, it's complete and taken with WINEDEBUG=+all. Wine by default hides internal calls to many system dlls. See RelayFromExclude key. Vitaliy.

Jan. 23, 2011

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

by Janne Hakonen

Thanks for quick response! > First i see is that your mail application wrapped the patch ( that is when > long likes brake down into the next line ). > Then you have a whitespace issue in the makefile i think... Looks like my mailer (Windows Live Mail) thinks that if attachment has .txt extension it is ok to do line wrapping and changing EOLs to CR LF. I couldn't find an option to turn this feature off, but sending patches with .patch extensions seems to prevent this formatting. > > I created a new signal.c file for the test case under ntdll/tests since > > I couldn’t find more fitting place. > Not a good idea. Please put the test into rtl.c Ok, I will do that. > Please put ok() check inside get_back_trace_with_invalid_frame_pointer(). Hmm, good point, I wonder why I didn't check the result -variable instead... I will change it as you proposed. > Please use HeapAlloc/HeapFree. Don't cast void pointers. Here you don't > need > to allocate anything, just use a stack variable. True, using stack is easier, I don't know why I tried to do it the hard way. > Also you not checking the return value from RtlCaptureStackBackTrace(). > Please do. The function returns number of frames it could get. I don't know what kind of value should be checked here since RtlCaptureStackBackTrace() is implemented only on i386 architecture. The test would fail on other architectures like arm, powerpc, x86_64 and sparc. > Also, please send the test patch by itself through winebot before posting > and verify that it passes on all flavors of windows. Ok, I will try it out when I have fixed the test case. Thanks, Janne Hakonen

Jan. 23, 2011

Re: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

by Vitaliy Margolen

On 01/21/2011 08:43 AM, Greg Geldorp wrote: > From: Vitaliy Margolen [mailto:wine-patches(a)kievinfo.com] >> Shame on me, I've totally forgot that the latest DX version for NT was DX3 >> that came with service pack. Don't recall thou if it was a separate install >> or not. > > Wikipedia says (http://en.wikipedia.org/wiki/DirectX#Releases) that DirectX 3.0a > was the last supported version of DX for NT4 and it was included in SP3. It's been a while since I last touched NT 4.0. It was my O/S of choice for many years... Forgot lots of details about it by now. I've modified the test to skip on NT 4.0 same as the current version skips. Vitaliy.

Jan. 23, 2011

Re: Winetricks game verbs - good or bad? (was: Re: New winetricks 20110117-alpha: new verbs dxdiag, firefox4, ut3, hegemonygold_demo, ...)

by Vitaliy Margolen

To pick up where we left of. On 01/17/2011 02:23 PM, Dan Kegel wrote: > On Mon, Jan 17, 2011 at 8:31 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >> On 01/17/2011 01:15 PM, Dan Kegel wrote: >>> What concrete problems do you see with winetricks having >>> verbs for popular games? >> >> Does it cover Steam'ed versions? >> Different languages? > > I'm curious why you ask - would covering (or not covering) Steam or > different languages lead to poor quality bug reports? > I guess you're afraid of people complaining about the tool and not about Wine? I'm talking about system being in a different locale. And you trying to install an English program. Some installers don't like that. Also number of system directory paths would be different. Alternatively what if user wants to install not English version of say FireFox? As far as games go, most steamed versions don't really require an installation, steam downloads them and runs re-distributable installers that game requires. I guess where I'm going with it, is how much will winetricks install to satisfy each program? And how well this list will correspond to environment? >> How about conflicts between setups for different games under one wineprefix? >> Or conflicts with existing installed software under the same wineprefix? >> >> The only scenario that would be fine with me, if winetricks will allow new >> prefix only for complete software installs. And refuse to install into >> existing one. > > The author of PlayOnLinux agrees with you; that's how that tool works. > > I do have code for that, but I haven't turned it on yet, since it > raises some UI issues. > I could make it the default for app installs once I iron those out. This will be highly beneficial for everyone. User will be able to easily remove programs, and you won't need to deal with conflicting requirements. Also this will guarantee that default prefix is left untouched. Vitaliy.

Jan. 23, 2011

Re: 3Dmark2001se & heap corruption

by Henri Verbeet

On 23 January 2011 09:03, <wylda(a)volny.cz> wrote: >> > Is that somehow useful? >> > >> Are there any calls in between? It may just be an >> application bug. > > No, it's complete and taken with WINEDEBUG=+all. > > Is there any way to verify such heap corruption on real windows? > Not easily, I think. There are certainly tools like Valgrind for Windows, but I'm not sure if there are any free ones. If there's no Wine code being executed between the allocation and the free it seems unlikely to me that it's a problem in Wine though.

Jan. 23, 2011

Re: FYI: GCC-4.6 rebuild tests

by Marcus Meissner

On Wed, Jan 19, 2011 at 12:18:42PM -0500, Susan Cragin wrote: > GCC-4.6 has more build failures than mine. Here's the info. > They don't test wine, apparently. It's not on the list. Maybe I can add it, or get it added. I am actually building my 32bit tree with gcc 4.6. Also our openSUSE gcc developer is building openSUSE with 4.6 too I think. I also think Gerald does. So we have good coverage. :) Ciao, Marcus

Jan. 23, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Jacek Caban

On 1/20/11 6:40 PM, Erich Hoover wrote: > On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >> ... >> + ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status); >> You could test the exact value here: ok(status == ...) > I was trying to avoid adding some conditional todo_wine calls Hiding differences between Wine and Windows in tests is the worst thing you can do. When one is trying to find a bug, tested parts of implementation are much less suspicious than not or poorly tested. If you know about more such things in the patch, please fix them. You don't write the test to pass on your implementation. You write it to know the right implementation. > (for some reason native does not respond with "supported", even though it > does in the mshtml tests), please see if you like the attached better. Or it proves that it's not a simple forward to mshtml? >> test_CommandTargetPassthru(TRUE) could go to existing test_WebBrowser. > Would it not be better to just keep these all in one place, since for > the tests without the custom target it's necessary to create and > initialize a web-browser? We still have them in separated functions you've called test_QueryStatusWB and test_ExecWB. We most likely will want more tests on WebBrowser instance without container's IOleCommandTarget, and it would be nice if we could reuse test_CommandTargetPassthru for that (well, the name would be better more generic as well). >> + if (!target) >> + return E_FAIL; >> A test for this case would be nice. Also with this patch, testing ExecEB shouldn't be too hard, let's test it as well. > Ugg, apparently MSDN lies horribly - it's actually E_UNEXPECTED. That's why we need tests :) Jacek

Jan. 23, 2011

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

by Vitaliy Margolen

On 01/23/2011 10:54 AM, André Hentschel wrote: > further you should consider using IsBadReadPtr instead of try...except, but i'm not sure if that would work. No, one should never ever use those functions. Even MS says they ave evil. Try .. except is the right thing to use here. On 01/23/2011 10:20 AM, Janne Hakonen wrote: > I created a new signal.c file for the test case under ntdll/tests since I couldn’t find more fitting place. Not a good idea. Please put the test into rtl.c > +static void test_pRtlCaptureStackBackTrace(void) > +{ > + ok(TRUE == get_back_trace_with_invalid_frame_pointer(),"get_back_trace_with_invalid_frame_pointer() failed\n" ); > +} Please put ok() check inside get_back_trace_with_invalid_frame_pointer(). > +static void capture_stack_back_trace(void) > +{ > + void** callers = (void**) calloc(maxCallers, sizeof(void*)); > + free(callers); > +} Please use HeapAlloc/HeapFree. Don't cast void pointers. Here you don't need to allocate anything, just use a stack variable. Also you not checking the return value from RtlCaptureStackBackTrace(). Please do. Vitaliy.

Jan. 23, 2011

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

by Dan Kegel

Hi Janne, I haven't reviewed your code, but I can suggest sending each patch as a separate message to wine-patches, and using titles more like ntdll: test corrupt stack frame in RtlCaptureStackBackTrace() ntdll: handle corrupt stack frame in RtlCaptureStackBackTrace() and mention clearly that this fixes the online store in Anarchy Online (if it does). Also, please send the test patch by itself through winebot before posting and verify that it passes on all flavors of windows. See http://wiki.winehq.org/SubmittingPatches Thanks!

Jan. 23, 2011

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

by André Hentschel

Am 23.01.2011 18:20, schrieb Janne Hakonen: > Hi, > > This is my first attempt to post patches to Wine and it would be great if you could review these. > > First patch (0001-2-2-ntdll-Added-try-except-blocks-to-RtlCaptureStackBa.txt) is a correction to a crash situation where application crashes if RtlCaptureStackBackTrace() is called and one of the frame pointers of call stack is invalid, pointing usually to 0xffffffff, sometimes to other invalid locations. > The correction wraps the offending code inside __try â�� __except blocks so that a resulting access violation is caught before it can crash the calling application. > > Second patch (0002-1-2-ntdll-tests-Added-a-test-for-RtlCaptureStackBackTr.txt) is a test case for the correction. > It changes one of the frame pointers to invalid value and then calls RtlCaptureStackBackTrace(). The test fails on Wineâ��s HEAD (without the first patch), but passes successfully on Windows 7. Havenâ��t tested this on other OSes. I created a new signal.c file for the test case under ntdll/tests since I couldnâ��t find more fitting place. > > This crash can be reproduced with Anarchy Online game when trying to open an in-game browser. Also reproducible with AwesomiumGL sample application from Awesomiumâ��s SDK. The crash (among other problems) is reported to bugzilla at: http://bugs.winehq.org/show_bug.cgi?id=25206. > > Best Regards, > Janne Hakonen Hi and welcome to wine development! First i see is that your mail application wrapped the patch ( that is when long likes brake down into the next line ). Then you have a whitespace issue in the makefile i think... further you should consider using IsBadReadPtr instead of try...except, but i'm not sure if that would work. If you solved the issues, you can send the patch to wine-patches(a)winehq.org and can track the status at source.winehq.org/patches -- Best Regards, André Hentschel

Jan. 23, 2011

Correction to crash inside RtlCaptureStackBackTrace() + test case

by Janne Hakonen

Hi, This is my first attempt to post patches to Wine and it would be great if you could review these. First patch (0001-2-2-ntdll-Added-try-except-blocks-to-RtlCaptureStackBa.txt) is a correction to a crash situation where application crashes if RtlCaptureStackBackTrace() is called and one of the frame pointers of call stack is invalid, pointing usually to 0xffffffff, sometimes to other invalid locations. The correction wraps the offending code inside __try – __except blocks so that a resulting access violation is caught before it can crash the calling application. Second patch (0002-1-2-ntdll-tests-Added-a-test-for-RtlCaptureStackBackTr.txt) is a test case for the correction. It changes one of the frame pointers to invalid value and then calls RtlCaptureStackBackTrace(). The test fails on Wine’s HEAD (without the first patch), but passes successfully on Windows 7. Haven’t tested this on other OSes. I created a new signal.c file for the test case under ntdll/tests since I couldn’t find more fitting place. This crash can be reproduced with Anarchy Online game when trying to open an in-game browser. Also reproducible with AwesomiumGL sample application from Awesomium’s SDK. The crash (among other problems) is reported to bugzilla at: http://bugs.winehq.org/show_bug.cgi?id=25206. Best Regards, Janne Hakonen

Jan. 23, 2011

RE: gdi32/tests: Skip font metrics test on non-English systems

by Greg Geldorp

From: Dmitry Timoshkov [mailto:dmitry(a)codeweavers.com] > Greg Geldorp <ggeldorp(a)vmware.com> wrote: > > > I can easily imagine fonts for non-Western scripts not adhering to the > > hard-coded metrics in the test, which is why I thought skipping them on > > non-English systems might be ok. Of course, if you have an idea how to > > improve the test I'm all ears, after all the goal is to run as many tests > > as possible, not skip them. > > Probably adding a separate set of data with FS_ARABIC for Small Fonts could > help (similar to FS_JISJAPAN ones). Turns out it isn't quite as easy as adding a separate set of test data, adding test data doesn't influence whether existing tests are run or what their expected values are. In other words, after adding FS_ARBIC test data the tests for FS_LATIN1 still fail. I've added a skip_lang_id member to the test data to skip some of the tests on Arabic machines. Not ideal (blacklisting instead of whitelisting), but I guess it will have to do for now. Greg.

Jan. 23, 2011

Re: Wine: Downgrade lack of libxslt from configure warning to notice.

by Marcus Meissner

On Wed, Jan 19, 2011 at 11:37:17PM +0100, Gerald Pfeifer wrote: > On Sat, 28 Jun 2008, Gerald Pfeifer wrote: > > [ Still running into this, and compared to the others where we only > > use WINE_NOTICE_WITH, like CUPS or HAL this really seems very low > > importance. ] > > > > On a test system of mine which does not feature too many packages I am > > getting the following: > > > > configure: libsane development files not found, scanners won't be supported. > > configure: libgphoto2 development files not found, digital cameras won't be supported. > > configure: libldap (OpenLDAP) development files not found, LDAP won't be supported. > > configure: libcapi20 development files not found, ISDN won't be supported. > > configure: WARNING: libxslt development files not found, xslt won't be supported. > > > > Looking that libxslt only seems to be used by msxml3, I am wondering > > whether this really is worth a warning? > > > > How about the patch below? > > So I found this older patch of mine in a TODO folder and am wondering > whether it can be considered. It not, that's fine too and I'll remove > it over here; an explicit NACK would be nice in that case. As libxslt missing reduces the msxml3 functionality it is definitely worth a warning. Ciao, Marcus

Jan. 23, 2011

ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 3)

by Loïc Maury

--- dlls/ntdll/cdrom.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c index 59f85a0..6a6d8e0 100644 --- a/dlls/ntdll/cdrom.c +++ b/dlls/ntdll/cdrom.c @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) return STATUS_SUCCESS; else return STATUS_NO_MEDIA_IN_DEVICE; +#elif defined(__APPLE__) + /* At this point, we know that we have media, because in Mac OS X, the + * device file is only created when media is present. */ + return STATUS_SUCCESS; #else FIXME("not supported on this O/S\n"); return STATUS_NOT_SUPPORTED; -- 1.7.3.2

Jan. 23, 2011

USB architecture: driver loading question

by Damjan Jovanovic

Hi There's essentially 2 ways USB could work in Wine[1]: 1. Process per driver, but special-case loading and initializing USBD.SYS Like my previous patchset: http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html 2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises. What's the right way? Which approach is going to get my patches accepted? Thank you Damjan [1] Because the steps are as follows: 1. USB device is plugged in 2. USB hub driver looks up the driver based on the device class/vendor/product IDs 3. The device driver gets loaded and DriverEntry() gets called on it 4. AddDevice() gets called on the driver, specifying the device 5. Only then, the driver calls things lower in the stack, to do USB I/O The driver needn't load any other driver in its DLL import table, and even if it did, drivers loaded through the import table don't have their DriverEntry() called, so they cannot do anything on load. Even if we rely on most USB drivers loading USBD.SYS, USBD.SYS needs to do steps 1-4 first, but it wouldn't have control passed to it until step 5, hence it can't ever do anything. The only way out is one of the following: 1. Process-per-driver, but when a driver loads USBD.SYS, USBD.SYS is special-cased by winedevice, ie. it has a special export called on it at load which specifies the other driver and gives it a chance to create a separate thread for steps 1-4. 2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises.

Jan. 23, 2011

3Dmark2001se & heap corruption

by wylda＠volny.cz

> > Is that somehow useful? > > > Are there any calls in between? It may just be an > application bug. No, it's complete and taken with WINEDEBUG=+all. Is there any way to verify such heap corruption on real windows? W.

Jan. 23, 2011

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 2)

by Ken Thomases

On Jan 22, 2011, at 8:35 AM, Loïc Maury wrote: > I have add comment in the code for the patch. > @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) > return STATUS_SUCCESS; > else > return STATUS_NO_MEDIA_IN_DEVICE; > +/* At this point, we know that we have media, because in Mac OS X, the > + * device file is only created when media is present. */ > +#elif defined(__APPLE__) > + return STATUS_SUCCESS; > #else > FIXME("not supported on this O/S\n"); > return STATUS_NOT_SUPPORTED; The comment should be inside the __APPLE__ block, and indented to match the return statement. Regards, Ken

Jan. 23, 2011

Re: 3Dmark2001se & heap corruption

by Henri Verbeet

On 23 January 2011 00:11, <wylda(a)volny.cz> wrote: > Is that somehow useful? > Are there any calls in between? It may just be an application bug.

Jan. 23, 2011

3Dmark2001se & heap corruption

by wylda＠volny.cz

Hi, i was able to narrow the problem: 0009:CALL MFC42.823() ret=00ae484e 0009:Call msvcrt.malloc(00000031) ret=5f40384f 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,00000031) ret=7ea60413 0009:trace:heap:RtlAllocateHeap (0x110000,70000062,00000031): returning 0xc11c70 0009:Ret ntdll.RtlAllocateHeap() retval=00c11c70 ret=7ea60413 0009:Ret msvcrt.malloc() retval=00c11c70 ret=5f40384f 0009:RET MFC42.823() retval=00c11c70 ret=00ae484e 0009:CALL MFC42.825() ret=003b16b5 0009:Call msvcrt.free(00c11c50) ret=5f40388b 0009:Call ntdll.RtlFreeHeap(00110000,00000000,00c11c50) ret=7ea603d4 0009:err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0xc11c70 tail overwritten at 0xc11ca1 (byte 0/15 == 0x00) Is that somehow useful? W.

Jan. 22, 2011

ntdll/cdrom : implement CDROM_Verify to work on Mac OS X, with comment (try 2)

by Loïc Maury

Hello, I have add comment in the code for the patch. Thank you Loïc --- dlls/ntdll/cdrom.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c index 59f85a0..d65850d 100644 --- a/dlls/ntdll/cdrom.c +++ b/dlls/ntdll/cdrom.c @@ -1121,6 +1121,10 @@ static NTSTATUS CDROM_Verify(int dev, int fd) return STATUS_SUCCESS; else return STATUS_NO_MEDIA_IN_DEVICE; +/* At this point, we know that we have media, because in Mac OS X, the + * device file is only created when media is present. */ +#elif defined(__APPLE__) + return STATUS_SUCCESS; #else FIXME("not supported on this O/S\n"); return STATUS_NOT_SUPPORTED; -- 1.7.3.2

Jan. 22, 2011

Re: winscard

by André Hentschel

Am 21.01.2011 09:53, schrieb vince: > Hi all, > > I'm back with a smaller and reworked winscard patch. > > In respond to Vitaly Margolen (http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html) > 1. I used configure to get the so name of the library. > 2. I removed trailing spaces. > 3. When this patch is approved, I will make a new patch for SCardListReadersA. > > Is this patch ready for wine-patch ? > > Thanks for your help. > > Vincent. > > > > Doesn't look bad, but have a look at whitespace adding. -- Best Regards, André Hentschel

Jan. 22, 2011

Re: [PATCH 5/5] d3dx9_36/tests: Added tests for ID3DXConstantTable_Set* functions

by Travis Athougies

Regardless, I've modified the tests a so that they should pass on windows. Can you verify that they do? Travis. On Fri, Jan 21, 2011 at 9:22 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 22 January 2011 06:11, Travis Athougies <iammisc(a)gmail.com> wrote: >> The failed tests worry me since it passes on linux with a native >> d3dx9_36 dll. Have you tried a native d3dx9_36 with wine? Do the tests >> still fail? >> > That's not a valid way to verify tests. > -- Travis Athougies

Jan. 22, 2011

Re: [PATCH 5/5] d3dx9_36/tests: Added tests for ID3DXConstantTable_Set* functions

by Henri Verbeet

On 22 January 2011 06:11, Travis Athougies <iammisc(a)gmail.com> wrote: > The failed tests worry me since it passes on linux with a native > d3dx9_36 dll. Have you tried a native d3dx9_36 with wine? Do the tests > still fail? > That's not a valid way to verify tests.

Jan. 22, 2011

Re: [PATCH 5/5] d3dx9_36/tests: Added tests for ID3DXConstantTable_Set* functions

by Travis Athougies

The failed tests worry me since it passes on linux with a native d3dx9_36 dll. Have you tried a native d3dx9_36 with wine? Do the tests still fail? Travis. On Thu, Jan 20, 2011 at 8:48 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/1/20 Travis Athougies <iammisc(a)gmail.com>: >> +static void test_setting_basic_table(IDirect3DDevice9 *device) >> +{ >> + static const D3DXMATRIX mvp = { >> + 0.514f, 0.626f, 0.804f, 0.786f, >> + 0.238f, 0.956f, 0.374f, 0.483f, >> + 0.109f, 0.586f, 0.900f, 0.255f, >> + 0.898f, 0.411f, 0.932f, 0.275f}; > > This throws some warnings here. Apparently you have to put some > additional braces around that initializer. > > + ok(out[0] == (float)iarray[0] && out[4] == (float)iarray[1] && > out[8] == (float)iarray[2] && > + out[12] == (float)iarray[3], "SetIntArray did not > properly set a float array: out={%f, %f, %f, %f}, should" > + " be {%d, %d, %d, %d}\n", out[0], out[4], out[8], > out[12], iarray[0], iarray[1], iarray[2], iarray[3]); > > The float casts are unneeded. > > The tests look generally OK to me otherwise, albeit they are somewhat > wordy. Oh, please notice that some tests fail on Windows. The testbot > can't create a d3d device so it skips these tests, but on my Win7 box > I get this: > > shader.c:462: Test failed: The first row of mvp was not set correctly, got {0.51 > 4000, 0.238000, 0.109000, 0.898000}, should be {0.514000, 0.626000, 0.804000, 0. > 786000} > shader.c:465: Test failed: The second row of mvp was not set correctly, got {0.6 > 26000, 0.956000, 0.586000, 0.411000}, should be {0.238000, 0.956000, 0.374000, 0 > .483000} > shader.c:468: Test failed: The third row of mvp was not set correctly, got {0.80 > 4000, 0.374000, 0.900000, 0.932000}, should be {0.109000, 0.586000, 0.900000, 0. > 255000} > shader.c:471: Test failed: The fourth row of mvp was not set correctly, got {0.7 > 86000, 0.483000, 0.255000, 0.275000}, should be {0.898000, 0.411000, 0.932000, 0 > .275000} > shader.c:530: Test failed: The excess elements of the array were not set correct > ly, out={0.000000, 0.000000, 0.000000, 0.000000}, should be {0.010000, 0.020000, > 0.030000, 0.040000} > shader: 248 tests executed (0 marked as todo, 5 failures), 0 skipped. > > The matrix seems to have its rows and columns switched (probably this > has to do with row-major vs column-major matrix storage - > http://msdn.microsoft.com/en-us/library/bb509706%28v=VS.85%29.aspx) > So you have to fix your SetMatrixArray implementation to account for > that (and update the tests accordingly). The other failing test shows > that actually the excess elements are not set, apparently. > > A last thing. I noticed that you never set the vertex shader in the > d3d9 device. I'd say: don't change that. This shows that > ID3DXConstantTable doesn't pay attention to the vertex shader > currently set and it is responsibility of the application programmer > to call these functions with the correct shader program. > -- Travis Athougies

Jan. 22, 2011

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.

by Ken Thomases

On Jan 21, 2011, at 2:36 AM, Damjan Jovanovic wrote: > Should we reconsider libicns? Apple's APIs obviously can't be relied upon. On Jan 21, 2011, at 5:04 AM, Alexandre Julliard wrote: > Several other things are already broken on Mac OS X 10.4. Basic > functionality is there, but it's not worth investing a lot of efforts > into supporting every last bit of functionality on 10.4. In addition to what Alexandre said, if we did want to put in the effort to maintain Tiger support, we'd still use the native API. Tiger does have support for ICNS and the IconFamily API; that API goes back to classic Mac OS. It's just that Leopard introduced some conveniences to that API -- in particular, treating sizes smaller than 256 as ARGB instead of separate image and mask -- that I took advantage of in my code. So, supporting Tiger would entail more cumbersome code, but not a reversion to libicns. Regards, Ken

Jan. 22, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Michael Stefaniuc

On 01/22/2011 12:22 AM, Travis Athougies wrote: > matrix + i will advance by the size of 1 D3DXMATRIX, since matrix is a > pointer to a D3DXMATRIX. Michael is right, I thought the code was > clearer with the pointer arithmetic, but I now see more people are > familiar with the array indexing style. Actually the pointer cast draw my attention. Pointer casts are bad. Bad and evil. They serve to make the compiler stfu and for the code reader they are a big WARNING comment "There might be dragons!". And there was a dragon: the cast of a struct pointer to a pointer to its first field. The pointer arithmetic to array conversion I have seen only after you explained it that way to Matteo. bye michael > On Fri, Jan 21, 2011 at 8:47 AM, Matteo Bruni<matteo.mystral(a)gmail.com> wrote: >> 2011/1/21 Michael Stefaniuc<mstefani(a)redhat.com>: >>> On 01/21/2011 06:56 AM, Travis Athougies wrote: >>>> On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni<matteo.mystral(a)gmail.com> >>>> wrote: >>>>> >>>>> 2011/1/20 Travis Athougies<iammisc(a)gmail.com>: >>>>>> >>>>>> + /* D3DXMATRIX is a union, one of whose elements is an >>>>>> array, so it can be cast to a float pointer */ >>>>>> + if (is_vertex_shader(This->desc.Version)) >>>>>> + IDirect3DDevice9_SetVertexShaderConstantF(device, >>>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>>> + desc.RegisterCount); >>>>>> + else >>>>>> + IDirect3DDevice9_SetPixelShaderConstantF(device, >>>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>>> + desc.RegisterCount); >>>>> >>>>> Can't you just pass matrix->m[i] as parameter, instead of that cast? >>>>> >>>> >>>> Uh no. If I were to do that, matrix->m[1] would be the second row, not >>>> the second matrix. I'm trying to get at the second matrix. To >>>> illustrate this, suppose the matrix were at 0x8000 (not going to >>>> happen, but just pretend). matrix->m[1] would be at 0x8010, since >>>> floats are 4 bytes. However, the next matrix is actually at 0x8040 >>>> (since sizeof(float) * 16 [the number of elements in the matrix] = >>>> 64). >>> >>> So you want a pointer to the first element of the "i"th matrix, right? >>> &matrix[i]._11 >>> No cast, no explicit pointer arithmetic. >>> >> >> Oh, right, I misread that (and Michael's suggestion is good). But then >> I would expect the register index to be incremented by >> desc.RegisterCount at each iteration. RegisterCount is supposedly 4, >> but what if it is not? This calls for some SetMatrixArray tests.

Jan. 21, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Travis Athougies

Oh I'm sorry. I now see what you mean, you were talking about the register index parameter to Set*ShaderConstantF? Yes, that should be changed. I will submit updated patches shortly. Travis. On Fri, Jan 21, 2011 at 3:22 PM, Travis Athougies <iammisc(a)gmail.com> wrote: > matrix + i will advance by the size of 1 D3DXMATRIX, since matrix is a > pointer to a D3DXMATRIX. Michael is right, I thought the code was > clearer with the pointer arithmetic, but I now see more people are > familiar with the array indexing style. > > Travis. > > On Fri, Jan 21, 2011 at 8:47 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2011/1/21 Michael Stefaniuc <mstefani(a)redhat.com>: >>> On 01/21/2011 06:56 AM, Travis Athougies wrote: >>>> On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni<matteo.mystral(a)gmail.com> >>>> wrote: >>>>> >>>>> 2011/1/20 Travis Athougies<iammisc(a)gmail.com>: >>>>>> >>>>>> + /* D3DXMATRIX is a union, one of whose elements is an >>>>>> array, so it can be cast to a float pointer */ >>>>>> + if (is_vertex_shader(This->desc.Version)) >>>>>> + IDirect3DDevice9_SetVertexShaderConstantF(device, >>>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>>> + desc.RegisterCount); >>>>>> + else >>>>>> + IDirect3DDevice9_SetPixelShaderConstantF(device, >>>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>>> + desc.RegisterCount); >>>>> >>>>> Can't you just pass matrix->m[i] as parameter, instead of that cast? >>>>> >>>> >>>> Uh no. If I were to do that, matrix->m[1] would be the second row, not >>>> the second matrix. I'm trying to get at the second matrix. To >>>> illustrate this, suppose the matrix were at 0x8000 (not going to >>>> happen, but just pretend). matrix->m[1] would be at 0x8010, since >>>> floats are 4 bytes. However, the next matrix is actually at 0x8040 >>>> (since sizeof(float) * 16 [the number of elements in the matrix] = >>>> 64). >>> >>> So you want a pointer to the first element of the "i"th matrix, right? >>> &matrix[i]._11 >>> No cast, no explicit pointer arithmetic. >>> >> >> Oh, right, I misread that (and Michael's suggestion is good). But then >> I would expect the register index to be incremented by >> desc.RegisterCount at each iteration. RegisterCount is supposedly 4, >> but what if it is not? This calls for some SetMatrixArray tests. >> > > > > -- > Travis Athougies > -- Travis Athougies

Jan. 21, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Travis Athougies

matrix + i will advance by the size of 1 D3DXMATRIX, since matrix is a pointer to a D3DXMATRIX. Michael is right, I thought the code was clearer with the pointer arithmetic, but I now see more people are familiar with the array indexing style. Travis. On Fri, Jan 21, 2011 at 8:47 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/1/21 Michael Stefaniuc <mstefani(a)redhat.com>: >> On 01/21/2011 06:56 AM, Travis Athougies wrote: >>> On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni<matteo.mystral(a)gmail.com> >>> wrote: >>>> >>>> 2011/1/20 Travis Athougies<iammisc(a)gmail.com>: >>>>> >>>>> + /* D3DXMATRIX is a union, one of whose elements is an >>>>> array, so it can be cast to a float pointer */ >>>>> + if (is_vertex_shader(This->desc.Version)) >>>>> + IDirect3DDevice9_SetVertexShaderConstantF(device, >>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>> + desc.RegisterCount); >>>>> + else >>>>> + IDirect3DDevice9_SetPixelShaderConstantF(device, >>>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>>> + desc.RegisterCount); >>>> >>>> Can't you just pass matrix->m[i] as parameter, instead of that cast? >>>> >>> >>> Uh no. If I were to do that, matrix->m[1] would be the second row, not >>> the second matrix. I'm trying to get at the second matrix. To >>> illustrate this, suppose the matrix were at 0x8000 (not going to >>> happen, but just pretend). matrix->m[1] would be at 0x8010, since >>> floats are 4 bytes. However, the next matrix is actually at 0x8040 >>> (since sizeof(float) * 16 [the number of elements in the matrix] = >>> 64). >> >> So you want a pointer to the first element of the "i"th matrix, right? >> &matrix[i]._11 >> No cast, no explicit pointer arithmetic. >> > > Oh, right, I misread that (and Michael's suggestion is good). But then > I would expect the register index to be incremented by > desc.RegisterCount at each iteration. RegisterCount is supposedly 4, > but what if it is not? This calls for some SetMatrixArray tests. > -- Travis Athougies

Jan. 21, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Matteo Bruni

2011/1/21 Michael Stefaniuc <mstefani(a)redhat.com>: > On 01/21/2011 06:56 AM, Travis Athougies wrote: >> On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni<matteo.mystral(a)gmail.com> >> wrote: >>> >>> 2011/1/20 Travis Athougies<iammisc(a)gmail.com>: >>>> >>>> + /* D3DXMATRIX is a union, one of whose elements is an >>>> array, so it can be cast to a float pointer */ >>>> + if (is_vertex_shader(This->desc.Version)) >>>> + IDirect3DDevice9_SetVertexShaderConstantF(device, >>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>> + desc.RegisterCount); >>>> + else >>>> + IDirect3DDevice9_SetPixelShaderConstantF(device, >>>> desc.RegisterIndex + i, (float *)(matrix + i), >>>> + desc.RegisterCount); >>> >>> Can't you just pass matrix->m[i] as parameter, instead of that cast? >>> >> >> Uh no. If I were to do that, matrix->m[1] would be the second row, not >> the second matrix. I'm trying to get at the second matrix. To >> illustrate this, suppose the matrix were at 0x8000 (not going to >> happen, but just pretend). matrix->m[1] would be at 0x8010, since >> floats are 4 bytes. However, the next matrix is actually at 0x8040 >> (since sizeof(float) * 16 [the number of elements in the matrix] = >> 64). > > So you want a pointer to the first element of the "i"th matrix, right? > &matrix[i]._11 > No cast, no explicit pointer arithmetic. > Oh, right, I misread that (and Michael's suggestion is good). But then I would expect the register index to be incremented by desc.RegisterCount at each iteration. RegisterCount is supposedly 4, but what if it is not? This calls for some SetMatrixArray tests.

Jan. 21, 2011

RE: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

by Greg Geldorp

From: Vitaliy Margolen [mailto:wine-patches(a)kievinfo.com] > Shame on me, I've totally forgot that the latest DX version for NT was DX3 > that came with service pack. Don't recall thou if it was a separate install > or not. Wikipedia says (http://en.wikipedia.org/wiki/DirectX#Releases) that DirectX 3.0a was the last supported version of DX for NT4 and it was included in SP3. The VM runs SP6, I've checked the version info of dinput.dll, it says "4.04" without further qualifications. winetest.exe dumps the version number 4.4.1381.4 (http://test.winehq.org/data/55f6f9ada43acef87b4ee10096997ac73e4e8e23/nt4_wt…) Greg.

Jan. 21, 2011

Re: Translating a same message used in different contexts

by Akihiro Sagawa

On Thu, 20 Jan 2011, Alexandre Julliard wrote: > > So otherwise for context issues I believe the outcome of the WineConf > > discussion was that we'd insert a prefix in the two strings to > > translate, e.g. 'CTX-IDS_DESKTOP:Desktop' and > > 'CTX-IDS_DESKTOPDIRECTORY:Desktop', and have wrc remove it when > > producing the localized resource files (i.e. detect that the string to > > translate starts with 'CTX-' and remove everything until the colon). > > That means the English resource must be 'translated' too. > > The prefix is actually #msgctxt#, but yes that's how it works, it's > already used in a couple of places. Thank you for your advice. This is what I want to know. I'll update the PO files with #msgctxt# to distinguish a desktop directory name from a displyed one. And continue tranlating ja.po file. Akihiro Sagawa

Jan. 21, 2011

Re: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

by Vitaliy Margolen

On 01/21/2011 01:43 AM, Greg Geldorp wrote: > I've tried to install the June 2010 DirectX redistributable on it Shame on me, I've totally forgot that the latest DX version for NT was DX3 that came with service pack. Don't recall thou if it was a separate install or not. The patch still should go in as-is. Will send a fix for NT later. Vitaliy.

Jan. 21, 2011

RE: shell32/tests: Add tests for IShellDispatch::NameSpace.

by Greg Geldorp

> === W7PROX64 (32 bit shelldispatch) === > shelldispatch.c:80: Test failed: bad title I suppose the title here was "Program Files (x86)", it would be good to print the title that you got (using wine_dbgstr_w()). This test will probably fail when running as 32-bit executable on any Windows 64-bit version. I also expect it to fail on some non-English Windows versions (e.g. I think German uses "Programme" instead of "Program Files"). Greg.

Jan. 21, 2011

Re: shell32/tests: Add tests for IShellDispatch::NameSpace.

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=8506 Your paranoid android. === W7PROX64 (32 bit shelldispatch) === shelldispatch.c:80: Test failed: bad title

Jan. 21, 2011

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > If distribution of Wine users among Linux and MacOS is roughly equal, then > even if we disable icons on only Intel MacOS X 10.4, it will break for > almost as many users as are using Ubuntu 10.04 and 10.10 put together. Several other things are already broken on Mac OS X 10.4. Basic functionality is there, but it's not worth investing a lot of efforts into supporting every last bit of functionality on 10.4. If you want the latest and greatest Wine I don't think it's unreasonable to ask that you upgrade the rest of the OS too. -- Alexandre Julliard julliard(a)winehq.org

Jan. 21, 2011

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.

by Damjan Jovanovic

On Fri, Jan 21, 2011 at 10:52 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > On 21 January 2011 08:36, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Should we reconsider libicns? Apple's APIs obviously can't be relied > upon. > > You could always: > > 1. check for native support (including presence of > kIconServices16PixelDataARGB) and use if present; > 2. check for libicns and use it if present; > 3. disable ICNS support. > > using autoconf checks. That way, support is enabled where available > (instead of relying on OS version detection logic). > > NOTE: the libicns check is optional as it would require maintaining > both native OSX and libicns versions. > > - Reece > About option 3: December 2010 desktop OS market share, Wikimedia stats: Intel MacOS X 10.4 0.49% Ubuntu 10.10 0.25% Ubuntu 10.04 0.34%. If distribution of Wine users among Linux and MacOS is roughly equal, then even if we disable icons on only Intel MacOS X 10.4, it will break for almost as many users as are using Ubuntu 10.04 and 10.10 put together. Damjan

Jan. 21, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Michael Stefaniuc

On 01/21/2011 06:56 AM, Travis Athougies wrote: > Uh no. If I were to do that, matrix->m[1] would be the second row, not > the second matrix. I'm trying to get at the second matrix. To > illustrate this, suppose the matrix were at 0x8000 (not going to > happen, but just pretend). matrix->m[1] would be at 0x8010, since > floats are 4 bytes. However, the next matrix is actually at 0x8040 > (since sizeof(float) * 16 [the number of elements in the matrix] = > 64). So you want a pointer to the first element of the "i"th matrix, right? &matrix[i]._11 No cast, no explicit pointer arithmetic. > On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni<matteo.mystral(a)gmail.com> wrote: >> 2011/1/20 Travis Athougies<iammisc(a)gmail.com>: >>> + /* D3DXMATRIX is a union, one of whose elements is an array, so it can be cast to a float pointer */ >>> + if (is_vertex_shader(This->desc.Version)) >>> + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), >>> + desc.RegisterCount); >>> + else >>> + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), >>> + desc.RegisterCount); >> >> Can't you just pass matrix->m[i] as parameter, instead of that cast? >> bye michael

Jan. 21, 2011

winscard

by vince

Hi all, I'm back with a smaller and reworked winscard patch. In respond to Vitaly Margolen (http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html) 1. I used configure to get the so name of the library. 2. I removed trailing spaces. 3. When this patch is approved, I will make a new patch for SCardListReadersA. Is this patch ready for wine-patch ? Thanks for your help. Vincent.

Jan. 21, 2011

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.

by Reece Dunn

On 21 January 2011 08:36, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Should we reconsider libicns? Apple's APIs obviously can't be relied upon. You could always: 1. check for native support (including presence of kIconServices16PixelDataARGB) and use if present; 2. check for libicns and use it if present; 3. disable ICNS support. using autoconf checks. That way, support is enabled where available (instead of relying on OS version detection logic). NOTE: the libicns check is optional as it would require maintaining both native OSX and libicns versions. - Reece

Jan. 21, 2011

RE: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

by Greg Geldorp

From: Vitaliy Margolen > On 01/20/2011 07:52 PM, Marvin wrote: > > === WNT4WSSP6 (32 bit device) === > > device.c:168: Test failed: DirectInputCreate() failed: 80040154 > > Does this box has any newer version of DX installed at all? If it doesn't > know about DX2 interfaces I'm guessing not. I've tried to install the June 2010 DirectX redistributable on it, but it won't even start the setup program. Says the setup program is not a valid Windows NT application, which happens if the Major/MinorOperatingSystemVersion in the PE header is set to 5.0. So in short, no, there's no recent DX version installed. Greg

Jan. 21, 2011

Re: windowscodecs: Disable ICNS support when building for Mac OS X 10.4 Tiger.

by Damjan Jovanovic

Should we reconsider libicns? Apple's APIs obviously can't be relied upon. On Fri, Jan 21, 2011 at 2:58 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > > For http://bugs.winehq.org/show_bug.cgi?id=25778 > --- > dlls/windowscodecs/icnsformat.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > > > >

Jan. 21, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Travis Athougies

Uh no. If I were to do that, matrix->m[1] would be the second row, not the second matrix. I'm trying to get at the second matrix. To illustrate this, suppose the matrix were at 0x8000 (not going to happen, but just pretend). matrix->m[1] would be at 0x8010, since floats are 4 bytes. However, the next matrix is actually at 0x8040 (since sizeof(float) * 16 [the number of elements in the matrix] = 64). Travis. On Thu, Jan 20, 2011 at 7:27 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/1/20 Travis Athougies <iammisc(a)gmail.com>: >> + /* D3DXMATRIX is a union, one of whose elements is an array, so it can be cast to a float pointer */ >> + if (is_vertex_shader(This->desc.Version)) >> + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), >> + desc.RegisterCount); >> + else >> + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), >> + desc.RegisterCount); > > Can't you just pass matrix->m[i] as parameter, instead of that cast? > -- Travis Athougies

Jan. 21, 2011

Re: Where can I get OpenCL for Fedora 14.

by Nicholas van Oudtshoorn

On 01/21/2011 09:48 AM, Nicholas van Oudtshoorn wrote: > The latest closed source nvidia drivers from the rpmfusion repository > include openCL support. You'll also have to have the -devel I have > found, though, that I have to explicitly tell the wine build system > where it is. A simple > > export LDFLAGS="-L /usr/lib/nvidia -L /usr/lib64/nvidia/" > > seems to do the trick for me. (Of course, being i686, you'll want just > "-L /usr/lib/nvidia" ). Not sure why this is the case, ld seems to be > set up with all the information... > > But wait, there's more! > > For some obscure reason known only to themselves, there is no cl.h > included in the rpmfusion -devel package. To get that, you have to > manually install CUDA support from nvidia. From > http://developer.nvidia.com/object/cuda_3_2_downloads.html#Linux > what you want to download is the "CUDA Toolkit for Fedora 13[1]" (don't > worry, it works fine!) > > Run this as root from a console: > sudo sh cudatoolkit_3.2.16_linux_32_fedora13.run > And follow the prompts. (Just accept all the defaults). > > Finally, for completeness, create a file in /etc/ld.so.conf.d/ called > cuda.conf with the contents > For i686: > /usr/local/cuda/lib > For x86_64: > /usr/local/cuda/lib64 > /usr/local/cuda/lib > > And there you go! OpenCL support in Wine. Hopefully, it'll get easier. > > Nick Just noticed that the nvidia cuda libraries are being worked on over at rpmfusion [1], so maybe this process will get easier sometime soon... Nick [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=459

Jan. 21, 2011

Re: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

by Vitaliy Margolen

On 01/20/2011 07:52 PM, Marvin wrote: > === WNT4WSSP6 (32 bit device) === > device.c:168: Test failed: DirectInputCreate() failed: 80040154 > > Does this box has any newer version of DX installed at all? If it doesn't know about DX2 interfaces I'm guessing not. Vitaliy

Jan. 21, 2011

Re: dinput: Combine ASCII and Unicode device create callbacks. Add tests. (try 2)

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=8488 Your paranoid android. === WNT4WSSP6 (32 bit device) === device.c:168: Test failed: DirectInputCreate() failed: 80040154

Jan. 21, 2011

Re: FYI: OpenCL/opencl.h from NVIDIA...

by James McKenzie

On 1/20/11 5:20 PM, Max TenEyck Woodbury wrote: > But it is not an RPM or tarball. It's in their 'cudatoolkit'. > > Umm, guys, the pointer to the fedora list isn't helpful. Someone here > is going to know much more about where to get that package than J. > Random Joe over on the Fedora lists since someone here obviously coded > the requirement for it into 'configure'. Max: As far as I knew from information I gathered here, the only OS that supports OpenCL was MacOSX. Sorry for the misleading information. James McKenzie

Jan. 21, 2011

Re: Where can I get OpenCL for Fedora 14.

by Nicholas van Oudtshoorn

The latest closed source nvidia drivers from the rpmfusion repository include openCL support. You'll also have to have the -devel I have found, though, that I have to explicitly tell the wine build system where it is. A simple export LDFLAGS="-L /usr/lib/nvidia -L /usr/lib64/nvidia/" seems to do the trick for me. (Of course, being i686, you'll want just "-L /usr/lib/nvidia" ). Not sure why this is the case, ld seems to be set up with all the information... But wait, there's more! For some obscure reason known only to themselves, there is no cl.h included in the rpmfusion -devel package. To get that, you have to manually install CUDA support from nvidia. From http://developer.nvidia.com/object/cuda_3_2_downloads.html#Linux what you want to download is the "CUDA Toolkit for Fedora 13[1]" (don't worry, it works fine!) Run this as root from a console: sudo sh cudatoolkit_3.2.16_linux_32_fedora13.run And follow the prompts. (Just accept all the defaults). Finally, for completeness, create a file in /etc/ld.so.conf.d/ called cuda.conf with the contents For i686: /usr/local/cuda/lib For x86_64: /usr/local/cuda/lib64 /usr/local/cuda/lib And there you go! OpenCL support in Wine. Hopefully, it'll get easier. Nick [1] http://www.nvidia.com/object/thankyou.html?url=/compute/cuda/3_2_prod/toolk… On 01/20/2011 11:28 PM, Max TenEyck Woodbury wrote: > For the first time in several years, I did a fresh install on this > machine and I am in the process of getting all the tweaks back in place. > > Part of that process is assuring that wine's configure script has all > the pieces it can use. I have found almost everything. What I am missing > is OpenCL (that is C as in Charles). I see stuff for Apple, but not for > Fedora.i386 (cpu is intel.core2 and an Nvidia card). > > Search results are inconclusive - I checked the first five pages and > found nothing specifically about .rpm files. > > Where can I get an .rpm or tarball that contains a usable OpenCL > implementation for Fedora 14? > > Max > > >

Jan. 21, 2011

FYI: OpenCL/opencl.h from NVIDIA...

by Max TenEyck Woodbury

But it is not an RPM or tarball. It's in their 'cudatoolkit'. Umm, guys, the pointer to the fedora list isn't helpful. Someone here is going to know much more about where to get that package than J. Random Joe over on the Fedora lists since someone here obviously coded the requirement for it into 'configure'. Max

Jan. 21, 2011

winepath breakage?

by Dan Kegel

Hi Eric, thanks again for your tireless efforts in debugging and console stuff! Stefan alerted me to the following winetricks breakage: http://bugs.winehq.org/show_bug.cgi?id=25838 Could you have a look and decide who needs to give here - winepath, kernel32, or the poor user scripts? Hopefully not the latter. Thanks, Dan

Jan. 20, 2011

Re: Where can I get OpenCL for Fedora 14.

by Seth Shelnutt

I've never used fedora but my playing around with opencl in gentoo the libonpencl.so only can come from two sources, the nvidia driver or the ati stream sdk. So you might want to look at the binary driver for nvidia. That's my only guess. -Seth On Jan 20, 2011 10:34 AM, "Max TenEyck Woodbury" <max(a)mtew.isa-geek.net> wrote: > For the first time in several years, I did a fresh install on this > machine and I am in the process of getting all the tweaks back in place. > > Part of that process is assuring that wine's configure script has all > the pieces it can use. I have found almost everything. What I am missing > is OpenCL (that is C as in Charles). I see stuff for Apple, but not for > Fedora.i386 (cpu is intel.core2 and an Nvidia card). > > Search results are inconclusive - I checked the first five pages and > found nothing specifically about .rpm files. > > Where can I get an .rpm or tarball that contains a usable OpenCL > implementation for Fedora 14? > > Max > >

Jan. 20, 2011

Re: Translating a same message used in different contexts

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Ah, sorry. I don't know about Vista and greater. So why does Wine do it > the Vista way? > > This has changed so much that it seems like we should be able to pick > the scheme we prefer without breaking applications (or they would be > broken on Windows already). Given that I'd personnaly pick the XP way > (case 2). Using non-localized names for directories is probably better, in case the underlying filesystem doesn't support all character sets properly. > So otherwise for context issues I believe the outcome of the WineConf > discussion was that we'd insert a prefix in the two strings to > translate, e.g. 'CTX-IDS_DESKTOP:Desktop' and > 'CTX-IDS_DESKTOPDIRECTORY:Desktop', and have wrc remove it when > producing the localized resource files (i.e. detect that the string to > translate starts with 'CTX-' and remove everything until the colon). > That means the English resource must be 'translated' too. The prefix is actually #msgctxt#, but yes that's how it works, it's already used in a couple of places. Of course, if the directory is really supposed to be named Desktop in all languages then we might as well remove it from the .rc file. -- Alexandre Julliard julliard(a)winehq.org

Jan. 20, 2011

Re: Translating a same message used in different contexts

by Francois Gouget

On Fri, 21 Jan 2011, Akihiro Sagawa wrote: [...] > In Japanese Windows, desktop directory name has following > characteristics. > 1.In Windows NT 4, localized with half-width katakana. > 2.In Windows 2000, localized with full-width katakana. > 3.In Windows Vista, no localization about directory name. > > Japanese version of Windows XP is the second one. The desktop folder > path is C:\Documents and Settings\<user>\XXXXXX (where X is a Katakana > characer). In this case, desktop directory name and its display name are > same. > > But Wine uses the third style (Vista style) as of the commit 853d9938 > against shellpath.c. Ah, sorry. I don't know about Vista and greater. So why does Wine do it the Vista way? This has changed so much that it seems like we should be able to pick the scheme we prefer without breaking applications (or they would be broken on Windows already). Given that I'd personnaly pick the XP way (case 2). So otherwise for context issues I believe the outcome of the WineConf discussion was that we'd insert a prefix in the two strings to translate, e.g. 'CTX-IDS_DESKTOP:Desktop' and 'CTX-IDS_DESKTOPDIRECTORY:Desktop', and have wrc remove it when producing the localized resource files (i.e. detect that the string to translate starts with 'CTX-' and remove everything until the colon). That means the English resource must be 'translated' too. That's unless we figure out a more sophisticated mechanism but the problem was that the translation happens on the compiled resource so there's not much data to work with (i.e. special comments are out). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Jan. 20, 2011

Re: Where can I get OpenCL for Fedora 14.

by James McKenzie

On 1/20/11 8:28 AM, Max TenEyck Woodbury wrote: > For the first time in several years, I did a fresh install on this > machine and I am in the process of getting all the tweaks back in place. > The question is "Is there OpenCL" for Fedora? The only people who can answer this question are the Fedora Developers and Users. There is a wonderful Fedora Users Mailing list where this question would be more appropriate. Ask there (and I lurk there as well.) James McKenzie

Jan. 20, 2011

Re: Where can I get OpenCL for Fedora 14.

by Charles Davis

On 1/20/11 8:28 AM, Max TenEyck Woodbury wrote: > Where can I get an .rpm or tarball that contains a usable OpenCL > implementation for Fedora 14? What are you asking us for? We don't know! :) Seriously, this is a question for the Fedora folks. They're the ones you should be asking, not us. (Over on wine-users, people ask "where can I find package X?" all the time, and the answer is inevitably "ask your distro.") Chip

Jan. 20, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Erich Hoover

On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > ... > + ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status); > You could test the exact value here: ok(status == ...) I was trying to avoid adding some conditional todo_wine calls (for some reason native does not respond with "supported", even though it does in the mshtml tests), please see if you like the attached better. > test_CommandTargetPassthru(TRUE) could go to existing test_WebBrowser. Would it not be better to just keep these all in one place, since for the tests without the custom target it's necessary to create and initialize a web-browser? > + if (!target) > + return E_FAIL; > A test for this case would be nice. Also with this patch, testing ExecEB shouldn't be too hard, let's test it as well. Ugg, apparently MSDN lies horribly - it's actually E_UNEXPECTED. Please check the attached for both. Corresponding test results: https://testbot.winehq.org/JobDetails.pl?Key=8482 Thanks for all your feedback! Erich Hoover ehoover(a)mines.edu

Jan. 20, 2011

Implementing basic_string::substr in msvcp90

by Daniel Mierswa

Hey list, I was wondering how to implement substr in msvcp90/string.c. I followed the already existing code when implementing some operators and other things my application needed but I'm not sure how to construct a new string (rather allocate) and return it as it's the case with substr. Any ideas on this? Thanks in advance. -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22

Jan. 20, 2011

Re: [PATCH 5/5] d3dx9_36/tests: Added tests for ID3DXConstantTable_Set* functions

by Matteo Bruni

2011/1/20 Travis Athougies <iammisc(a)gmail.com>: > +static void test_setting_basic_table(IDirect3DDevice9 *device) > +{ > + static const D3DXMATRIX mvp = { > + 0.514f, 0.626f, 0.804f, 0.786f, > + 0.238f, 0.956f, 0.374f, 0.483f, > + 0.109f, 0.586f, 0.900f, 0.255f, > + 0.898f, 0.411f, 0.932f, 0.275f}; This throws some warnings here. Apparently you have to put some additional braces around that initializer. + ok(out[0] == (float)iarray[0] && out[4] == (float)iarray[1] && out[8] == (float)iarray[2] && + out[12] == (float)iarray[3], "SetIntArray did not properly set a float array: out={%f, %f, %f, %f}, should" + " be {%d, %d, %d, %d}\n", out[0], out[4], out[8], out[12], iarray[0], iarray[1], iarray[2], iarray[3]); The float casts are unneeded. The tests look generally OK to me otherwise, albeit they are somewhat wordy. Oh, please notice that some tests fail on Windows. The testbot can't create a d3d device so it skips these tests, but on my Win7 box I get this: shader.c:462: Test failed: The first row of mvp was not set correctly, got {0.51 4000, 0.238000, 0.109000, 0.898000}, should be {0.514000, 0.626000, 0.804000, 0. 786000} shader.c:465: Test failed: The second row of mvp was not set correctly, got {0.6 26000, 0.956000, 0.586000, 0.411000}, should be {0.238000, 0.956000, 0.374000, 0 .483000} shader.c:468: Test failed: The third row of mvp was not set correctly, got {0.80 4000, 0.374000, 0.900000, 0.932000}, should be {0.109000, 0.586000, 0.900000, 0. 255000} shader.c:471: Test failed: The fourth row of mvp was not set correctly, got {0.7 86000, 0.483000, 0.255000, 0.275000}, should be {0.898000, 0.411000, 0.932000, 0 .275000} shader.c:530: Test failed: The excess elements of the array were not set correct ly, out={0.000000, 0.000000, 0.000000, 0.000000}, should be {0.010000, 0.020000, 0.030000, 0.040000} shader: 248 tests executed (0 marked as todo, 5 failures), 0 skipped. The matrix seems to have its rows and columns switched (probably this has to do with row-major vs column-major matrix storage - http://msdn.microsoft.com/en-us/library/bb509706%28v=VS.85%29.aspx) So you have to fix your SetMatrixArray implementation to account for that (and update the tests accordingly). The other failing test shows that actually the excess elements are not set, apparently. A last thing. I noticed that you never set the vertex shader in the d3d9 device. I'd say: don't change that. This shows that ID3DXConstantTable doesn't pay attention to the vertex shader currently set and it is responsibility of the application programmer to call these functions with the correct shader program.

Jan. 20, 2011

Re: Translating a same message used in different contexts

by Akihiro Sagawa

On Thu, 20 Jan 2011, Francois Gouget wrote: (snipped) > I believe that in French the IDS_DESKTOPDIRECTORY is supposed to > get translated. I'm not 100% this happens in Wine but on Windows I > do get a path of the form 'c:\Documents and Settings\foo\Bureau' so in > Wine I'd expect something like 'c:\users\foo\Bureau' too. > > Does Windows do it differently for Japanese? > Or is the problem that the translation differs because of the context? Unfortunately, the answer is yes. There are three styles in user profile directory name. 1.Windows NT 4 style, e.g. C:\Windows\Profile\<name>. 2.Windows 2000 style, e.g. C:\Documents and Settings\<name>. 3.Windows Vista style, e.g. C:\Users\<name>. In Japanese Windows, desktop directory name has following characteristics. 1.In Windows NT 4, localized with half-width katakana. 2.In Windows 2000, localized with full-width katakana. 3.In Windows Vista, no localization about directory name. Japanese version of Windows XP is the second one. The desktop folder path is C:\Documents and Settings\<user>\XXXXXX (where X is a Katakana characer). In this case, desktop directory name and its display name are same. But Wine uses the third style (Vista style) as of the commit 853d9938 against shellpath.c. Hence I'd like to adapt a desktop directory name to user profile directory style, I kept IDS_DESKTOPDIRECTORY untranslated though I translated IDS_DESKTOP message. So in French (or any other language), are there no differences between directory name and display name, especially in Vista? Akihiro Sagawa

Jan. 20, 2011

Where can I get OpenCL for Fedora 14.

by Max TenEyck Woodbury

For the first time in several years, I did a fresh install on this machine and I am in the process of getting all the tweaks back in place. Part of that process is assuring that wine's configure script has all the pieces it can use. I have found almost everything. What I am missing is OpenCL (that is C as in Charles). I see stuff for Apple, but not for Fedora.i386 (cpu is intel.core2 and an Nvidia card). Search results are inconclusive - I checked the first five pages and found nothing specifically about .rpm files. Where can I get an .rpm or tarball that contains a usable OpenCL implementation for Fedora 14? Max

Jan. 20, 2011

Re: [PATCH 4/5] d3dx9_36: Implemented ID3DXConstantTable_SetMatrix and ID3DXConstantTable_SetMatrixArray

by Matteo Bruni

2011/1/20 Travis Athougies <iammisc(a)gmail.com>: > + /* D3DXMATRIX is a union, one of whose elements is an array, so it can be cast to a float pointer */ > + if (is_vertex_shader(This->desc.Version)) > + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), > + desc.RegisterCount); > + else > + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, (float *)(matrix + i), > + desc.RegisterCount); Can't you just pass matrix->m[i] as parameter, instead of that cast?

Jan. 20, 2011

Hebrew PO and some issues

by Yaron Shahrabani

I copied all the strings that shouldn't be translated, if anyone has a better suggestion be my guest. I don't want all the apps that shouldn't be translated listed in the PO. Also I need seperate translations for the same term, Ready should be translated differently among files. There are also strings that are similar between apps I should translate and apps I should so I'm a little confused about it, can I create seperate entries manually? The problem is that if I edit manually these entries will be deleted in the next update... Translating the apps in the old style was way better for me, how can I get back to that? Kind regards, Yaron Shahrabani <Hebrew translator>

Jan. 20, 2011

RE: gdi32/tests: Skip font metrics test on non-English systems

by Greg Geldorp

From: Dmitry Timoshkov [mailto:dmitry(a)codeweavers.com] > Probably adding a separate set of data with FS_ARABIC for Small Fonts could > help (similar to FS_JISJAPAN ones). Excellent. I'll look into it. Greg.

Jan. 20, 2011

Re: comctl32/tests: Fix failures for 120DPI display

by Nikolay Sivov

On 1/20/2011 13:40, Greg Geldorp wrote: > --- > dlls/comctl32/tests/listview.c | 5 +++-- > dlls/comctl32/tests/rebar.c | 2 +- > dlls/comctl32/tests/treeview.c | 4 ++++ > 3 files changed, 8 insertions(+), 3 deletions(-) > @@ -4163,7 +4163,8 @@ static void test_getcolumnwidth(void) > SendMessage(hwnd, LVM_INSERTITEMA, 0, (LPARAM)&itema); > ret = SendMessage(hwnd, LVM_GETCOLUMNWIDTH, 0, 0); > hdc = GetDC(hwnd); > - todo_wine expect(GetDeviceCaps(hdc, LOGPIXELSX), ret); > +trace("ggeldorp %d %d\n", GetDeviceCaps(hdc, LOGPIXELSX), ret); > + todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret); > ReleaseDC(hwnd, hdc); > DestroyWindow(hwnd); > } Minor thing, you forgot to remove a trace.

Jan. 20, 2011

Re: gdi32/tests: Skip font metrics test on non-English systems

by Dmitry Timoshkov

Greg Geldorp <ggeldorp(a)vmware.com> wrote: > I can easily imagine fonts for non-Western scripts not adhering to the > hard-coded metrics in the test, which is why I thought skipping them on > non-English systems might be ok. Of course, if you have an idea how to > improve the test I'm all ears, after all the goal is to run as many tests > as possible, not skip them. Probably adding a separate set of data with FS_ARABIC for Small Fonts could help (similar to FS_JISJAPAN ones). -- Dmitry.

Jan. 20, 2011

RE: gdi32/tests: Skip font metrics test on non-English systems

by Greg Geldorp

From: Dmitry Timoshkov > That test is supposed to pass at least on russian locale. On which locale > does the test fail for you? Arabic (http://test.winehq.org/data/98834637eb25caf986c9feae3eaa0b855cc19a26/xp_wtb -wxpproarsp3/gdi32:font.html). I can easily imagine fonts for non-Western scripts not adhering to the hard-coded metrics in the test, which is why I thought skipping them on non-English systems might be ok. Of course, if you have an idea how to improve the test I'm all ears, after all the goal is to run as many tests as possible, not skip them. Greg.

Jan. 20, 2011

Re: gdi32/tests: Skip font metrics test on non-English systems

by Dmitry Timoshkov

"Greg Geldorp" <ggeldorp(a)vmware.com> wrote: > --- > dlls/gdi32/tests/font.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) That test is supposed to pass at least on russian locale. On which locale does the test fail for you? -- Dmitry.

Jan. 20, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Jacek Caban

On 1/19/11 9:31 PM, Erich Hoover wrote: > On Wed, Jan 19, 2011 at 1:05 PM, Jacek Caban<jacek(a)codeweavers.com> wrote: >> On 1/18/11 7:31 PM, Erich Hoover wrote: >>> I've attached a test where I disabled the client/container, and you >>> can see that it then gets passed through (QueryStatusWB will return >> success instead of passing through the client target and returning >> failure): >>> https://testbot.winehq.org/JobDetails.pl?Key=8408 >> Hmm, it means that another run of tests (at least required subset of >> existing test_WebBrowser) with client's IOleCommandTarget disabled would >> be interesting. Do you feel like writing it? Otherwise we'd need at least >> a FIXME in this case. > I've been working on putting such a test together, I actually just > finished it up when I got your message. It's attached to this email, > and I would appreciate it if you would take a look - it ends up being > rather non-trivial since native caches the IOleCommandTarget on > creation of the container. > > Corresponding test results: > https://testbot.winehq.org/JobDetails.pl?Key=8449 Thanks. I have a few comments: +static int OleContainer_use_custom_target = TRUE; Please name it without mixing naming convention, something like use_container_olecmd would do. + case IDM_STOP: + prgCmds[0].cmdf = 0; + return S_OK; CHECK_EXPECT(QueryStatus_STOP) would be nice here. + ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status); You could test the exact value here: ok(status == ...) + ok(!(status& success_flag), "IDM_STOP enabled/supported: %08x\n", status); And here. + +static void test_CommandTargetPassthru(int use_custom_target) +{ test_CommandTargetPassthru(TRUE) could go to existing test_WebBrowser. + + if (!target) + return E_FAIL; A test for this case would be nice. Also with this patch, testing ExecEB shouldn't be too hard, let's test it as well. Jacek

Jan. 20, 2011

Re: Translating a same message used in different contexts

by Francois Gouget

On Thu, 20 Jan 2011, Akihiro Sagawa wrote: [...] > One of its contexts is a real path name of a desktop (IDS_DESKTOPDIRECTORY). > That is "C:\Users\foo\Desktop"'s Desktop. In other contexts, it makes a > localized name (IDS_DESKTOP). That is shown in a common dialog box. In > the previous Japanese resource, the former was "Desktop" and the latter > was localized. However, in the po file, they merged into one! Context is going to be a problem one day but I'm not sure it is one in this case (hopefully it isn't). I believe that in French the IDS_DESKTOPDIRECTORY is supposed to get translated. I'm not 100% this happens in Wine but on Windows I do get a path of the form 'c:\Documents and Settings\foo\Bureau' so in Wine I'd expect something like 'c:\users\foo\Bureau' too. Does Windows do it differently for Japanese? Or is the problem that the translation differs because of the context? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Jan. 20, 2011

Re: Improve handling of invalid input in dlls/comctl32/datetime.c

by Gerald Pfeifer

For the record, this is how this has been addressed a few months after this discussion. That's another way of doing it. :-) Gerald commit 1af17844301c4924dd8324cbf2f9c3c1ef0394b2 Author: Huw Davies <huw(a)codeweavers.com> Date: Tue May 4 14:05:13 2010 +0100 comctl32: Silence a few compiler warnings. diff --git a/dlls/comctl32/datetime.c b/dlls/comctl32/datetime.c index dc2dd12..2418950 100644 --- a/dlls/comctl32/datetime.c +++ b/dlls/comctl32/datetime.c @@ -614,7 +614,7 @@ DATETIME_ReturnFieldWidth (const DATETIME_INFO *infoPtr, HDC hdc, int count, SHO lctype = LOCALE_SABBREVMONTHNAME1; max_count = 12; break; - case FULLMONTH: + default: /* FULLMONTH */ fall = fld_mon; lctype = LOCALE_SMONTHNAME1; max_count = 12; On Fri, 25 Dec 2009, James McKenzie wrote: > Nikolay Sivov wrote: >> On 12/26/2009 00:04, James McKenzie wrote: >>> Nikolay Sivov wrote: >>> >>>> On 12/25/2009 14:18, Gerald Pfeifer wrote: >>>> >>>>> Otherwise max_count will be undefined in the following loop may do >>>>> interesting things it seems. (Does Coverity diagnose similar items?) >>>>> >>>>> Gerald >>>>> >>>>> ChangeLog: >>>>> Improve handling of invalid input in DATETIME_ReturnFieldWidth. >>>>> >>>>> diff --git a/dlls/comctl32/datetime.c b/dlls/comctl32/datetime.c >>>>> index c240d4f..08c7082 100644 >>>>> --- a/dlls/comctl32/datetime.c >>>>> +++ b/dlls/comctl32/datetime.c >>>>> @@ -38,6 +38,7 @@ >>>>> * -- FORMATCALLBACK >>>>> */ >>>>> >>>>> +#include<assert.h> >>>>> #include<math.h> >>>>> #include<string.h> >>>>> #include<stdarg.h> >>>>> @@ -619,6 +620,9 @@ DATETIME_ReturnFieldWidth (const DATETIME_INFO >>>>> *infoPtr, HDC hdc, int count, SHO >>>>> lctype = LOCALE_SMONTHNAME1; >>>>> max_count = 12; >>>>> break; >>>>> + default: >>>>> + assert(0); >>>>> + max_count=0; >>>>> } >>>>> >>>>> cx = 0; >>>>> >>>>> >>>> Hi, Gerald. >>>> >>>> This can't even happen. spec if filtered later with: >>>> --- >>>> case THREECHARMONTH: >>>> case FULLMONTH: >>>> case THREECHARDAY: >>>> case FULLDAY: >>>> --- >>>> So no default case here. >>>> >>>> >>> Even if the default case cannot be reached, it is not a 'bad thing' to >>> have one, even if it is an error message stating "Something went wrong, >>> we should not get here" with an exit code... >>> >> Why? There's no default case, treat is as 'if () {} else if () {} etc.'. >> It's the same thing to have explicit initializers for all local >> variables even if I don't use it before >> set some value. It's a pollution, especially if used to silence >> analyzer warnings. > Nikolay: > > Things can and do go 'wrong'. For instance, you build on Linux, I build > on a Mac. Sometimes the ported programs from UNIX can and will do > 'strange' things. If you don't have a method to know that there is an > error, then you go about blaming Wine when it is a poor program port. > Also, it is good programming practice to account for the situations you > don't expect to encounter and to initialize variables that you will be > using. This is not a 'just in case' thing, it can help when program > errors occur to see where in the code an expected value did or did not > happen. > > I know, it looks like pollution, but when code goes wrong, and it will, > this makes troubleshooting much easier. I know this from running > Quality Assurance testing for many years and coding myself. My > programming instructor deducted grade points for failing to handle error > and other unexpected conditions. > > James McKenzie

Jan. 19, 2011

Re: today's git does not compile

by Dan Kegel

Nicely done! Thanks for taking the time to do the full-on gcc bug report with .i file. If at some point in the future you want to ascend to the next level of gcc bug reporting awesomeness, read up on delta debugging, an easy technique for automatically reducing the .i file to (nearly) the smallest possible input file that causes the crash. http://en.wikipedia.org/wiki/Delta_Debugging Or don't; it's an easy next step for the gcc professionals, given what you gave them. - Dan

Jan. 19, 2011

Re: setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)

by Austin English

On Wed, Jan 19, 2011 at 1:00 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > On 1/19/11 12:52 PM, Qian Hong wrote: >> >> On Thu, Jan 20, 2011 at 3:15 AM, Ricardo Filipe >> <ricardojdfilipe(a)gmail.com> wrote: >>> >>> That should only need a stub to go forward (setupapi is already full of >>> them). >>> If you are not able to patch wine with a stub of that function then yeah, >>> open a bug report. >> >> Thanks for reply :) >> Reported here : http://goo.gl/FHely >> >> > Two things: > > ONE; CEASE TOP POSTING IMMEDIATELY. You have been told time and time again > not to do this. Please read RFC 1855 if you need to know why. A quick search in my email doesn't show anyone telling Qian not to top post. Of course it is discouraged, but no need to yell about it. > TWO: CEASE USING GOO.GL FOR SHORT URL POSTING. We expect a full URL to the > Wine Bugzilla to be posted here and it is preferred. Again, no reason to yell. That said, Qian, please do post the full url, bugzilla urls are not that long :-). -- -Austin

Jan. 19, 2011

Re: setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)

by James McKenzie

On 1/19/11 12:52 PM, Qian Hong wrote: > On Thu, Jan 20, 2011 at 3:15 AM, Ricardo Filipe > <ricardojdfilipe(a)gmail.com> wrote: >> That should only need a stub to go forward (setupapi is already full of >> them). >> If you are not able to patch wine with a stub of that function then yeah, >> open a bug report. > Thanks for reply :) > Reported here : http://goo.gl/FHely > > Two things: ONE; CEASE TOP POSTING IMMEDIATELY. You have been told time and time again not to do this. Please read RFC 1855 if you need to know why. TWO: CEASE USING GOO.GL FOR SHORT URL POSTING. We expect a full URL to the Wine Bugzilla to be posted here and it is preferred. James McKenzie >

Jan. 19, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Erich Hoover

On Wed, Jan 19, 2011 at 1:05 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 1/18/11 7:31 PM, Erich Hoover wrote: > > I've attached a test where I disabled the client/container, and you > > can see that it then gets passed through (QueryStatusWB will return > success instead of passing through the client target and returning > failure): > > https://testbot.winehq.org/JobDetails.pl?Key=8408 > > Hmm, it means that another run of tests (at least required subset of > existing test_WebBrowser) with client's IOleCommandTarget disabled would > be interesting. Do you feel like writing it? Otherwise we'd need at least > a FIXME in this case. I've been working on putting such a test together, I actually just finished it up when I got your message. It's attached to this email, and I would appreciate it if you would take a look - it ends up being rather non-trivial since native caches the IOleCommandTarget on creation of the container. Corresponding test results: https://testbot.winehq.org/JobDetails.pl?Key=8449 Erich Hoover ehoover(a)mines.edu

Jan. 19, 2011

Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

by Jacek Caban

On 1/18/11 7:31 PM, Erich Hoover wrote: > On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)codeweavers.com>> wrote: > ... > I'm not sure what you mean by "hijack the IOleCommandTarget". All we do is implementing client's IOleCommandTarget. It's something different from document's one. > I understand that, but apparently the native implementation (testing on the test bot WXPPROSP3) sends the command to the client > IOleCommandTarget instead of the document IOleCommandTarget (at least under the conditions of the webbrowser tests). That is what I mean by hijacking, the command is going to the "wrong" target. My guess would be that there is some sort of priority mechanism, though I have no idea how it would work (except maybe "if there's a client/container then send to that target, else send to the document target). That sounds reasonable. > I've attached a test where I disabled the client/container, and you > can see that it then gets passed through (QueryStatusWB will return success instead of passing through the client target and returning failure): > https://testbot.winehq.org/JobDetails.pl?Key=8408 Hmm, it means that another run of tests (at least required subset of existing test_WebBrowser) with client's IOleCommandTarget disabled would be interesting. Do you feel like writing it? Otherwise we'd need at least a FIXME in this case. Jacek

Jan. 19, 2011

Re: setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)

by Qian Hong

Thanks for reply :) Reported here : http://goo.gl/FHely On Thu, Jan 20, 2011 at 3:15 AM, Ricardo Filipe <ricardojdfilipe(a)gmail.com> wrote: > > That should only need a stub to go forward (setupapi is already full of > them). > If you are not able to patch wine with a stub of that function then yeah, > open a bug report. -- Regards, Qian Hong - Send from Ubuntu http://www.ubuntu.com/

Jan. 19, 2011

re: today's git does not compile

by Susan Cragin

https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/704633 Bug successfully updated and confirmed by a member of Ubuntu's testing team, so we're off to the races.

Jan. 19, 2011

Re: setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)

by Ricardo Filipe

2011/1/19 Qian Hong <fracting(a)gmail.com> > Dear All, while testing a USB production tool with unofficial USB > patches + native oleaut32.dll, > I got a crashing and such logs: > > wine: Call from 0x7b839292 to unimplemented function > setupapi.dll.CM_Get_DevNode_Status, aborting > wine: Unimplemented function setupapi.dll.CM_Get_DevNode_Status called > at address 0x7b839292 (thread 002f), starting debugger... > Unhandled exception: unimplemented function > setupapi.dll.CM_Get_DevNode_Status called in 32-bit code (0x7b839292). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:7b839292 ESP:003158b8 EBP:0031591c EFLAGS:00000246( - -- I Z- -P- > ) > EAX:7b82540d EBX:7b887ff4 ECX:00000000 EDX:80000100 > ESI:80000100 EDI:00000001 > Stack dump: > 0x003158b8: 0031593c 00000008 00020108 80000100 > 0x003158c8: 00000001 00000000 7b839292 00000002 > 0x003158d8: 7ebc3d60 7ebc42a9 00003218 00003218 > 0x003158e8: 00000001 00000000 989c7900 00000000 > 0x003158f8: 00000004 7eba6cfb 7ebd2ff4 00000000 > 0x00315908: 00000000 0031595c 7b83924a 00000111 > Backtrace: > =>0 0x7b839292 RaiseException+0x52(code=0x80000100, flags=0x1, > nbargs=0x2, args=0x31593c) > [/home/fracting/wine-git/dlls/kernel32/except.c:84] in kernel32 > (0x0031594c) > > ... > > > Should I post a new bug? > > Best wishes! > > -- > Regards, > Qian Hong > - > Send from Ubuntu > http://www.ubuntu.com/ > > > That should only need a stub to go forward (setupapi is already full of them). If you are not able to patch wine with a stub of that function then yeah, open a bug report.

Jan. 19, 2011

setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)

by Qian Hong

Dear All, while testing a USB production tool with unofficial USB patches + native oleaut32.dll, I got a crashing and such logs: wine: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status, aborting wine: Unimplemented function setupapi.dll.CM_Get_DevNode_Status called at address 0x7b839292 (thread 002f), starting debugger... Unhandled exception: unimplemented function setupapi.dll.CM_Get_DevNode_Status called in 32-bit code (0x7b839292). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b839292 ESP:003158b8 EBP:0031591c EFLAGS:00000246( - -- I Z- -P- ) EAX:7b82540d EBX:7b887ff4 ECX:00000000 EDX:80000100 ESI:80000100 EDI:00000001 Stack dump: 0x003158b8: 0031593c 00000008 00020108 80000100 0x003158c8: 00000001 00000000 7b839292 00000002 0x003158d8: 7ebc3d60 7ebc42a9 00003218 00003218 0x003158e8: 00000001 00000000 989c7900 00000000 0x003158f8: 00000004 7eba6cfb 7ebd2ff4 00000000 0x00315908: 00000000 0031595c 7b83924a 00000111 Backtrace: =>0 0x7b839292 RaiseException+0x52(code=0x80000100, flags=0x1, nbargs=0x2, args=0x31593c) [/home/fracting/wine-git/dlls/kernel32/except.c:84] in kernel32 (0x0031594c) ... Should I post a new bug? Best wishes! -- Regards, Qian Hong - Send from Ubuntu http://www.ubuntu.com/

Jan. 19, 2011

kernel32: Correctly parse the input strings for advanced keys.

by James Eder

On systems without the appropriate curses development files, compilation is broken here: gcc -m32 -c -I/home/james/build/wine/wine-git/dlls/kernel32 -I. -I/home/james/build/wine/wine-git/include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_NORMALIZE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o term.o /home/james/build/wine/wine-git/dlls/kernel32/term.c /home/james/build/wine/wine-git/dlls/kernel32/term.c:368:10: error: conflicting types for ‘TERM_FillInputRecord’ /home/james/build/wine/wine-git/dlls/kernel32/console_private.h:40:17: note: previous declaration of ‘TERM_FillInputRecord’ was here make[1]: *** [term.o] Error 1 make[1]: Leaving directory `/home/james/build/wine/wine-32/dlls/kernel32' make: *** [dlls/kernel32] Error 2 Jim

Jan. 19, 2011