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

Re: Wine bot results

by Saulius Krasuckas

* On Tue, 28 Aug 2012, Saulius Krasuckas wrote: > * On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > > > Target: i686-w64-mingw32 > ... > > Target: i586-mingw32msvc > > There was the same topic brought up two years ago: > http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html > > IIRC, MSVC and i586-mingw32msvc compilers initialize every declared > variable while *-mingw32* one does not. I mean *-mingw32-gcc (the one not using MSVCRT.DLL) with the latter;) S.

Aug. 28, 2012

Re: Wine bot results

by Saulius Krasuckas

* On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: > > > Target: i686-w64-mingw32 ... > Target: i586-mingw32msvc There was the same topic brought up two years ago: http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html IIRC, MSVC and i586-mingw32msvc compilers initialize every declared variable while *-mingw32* one does not. S.

Aug. 28, 2012

Re: About WineHQ Wiki

by Kyle Auble

Tues, Aug 28, 2012 4:47 AM, Oleg Yarigin wrote: > Now I wait an answer from Dimi Paun. > > > Well, in addition, how do you think, is any necessarity there to move > wine site and wiki from Apache to Cherokee? While I think it's good to keep alternatives in mind as new technology comes out, I wouldn't want to switch the actual http server out until it starts having noticeable problems, or in the distant future once higher priorities have been taken care of. For me, WineHQ itself seems to be really fast, and as we were discussing earlier in the thread, the wiki is hosted at Lattica, which may not have the same hardware resources or bandwidth of WineHQ. If you're mainly noticing problems with the wiki, that may also be that we're using an outdated version of moinmoin. Cheer Xiao was saying that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend upgrading Moinmoin, then converting the pages to Mediawiki syntax. I've never run a real Apache server myself (just played with it on my computer), but while it can be a pain to set up, it is battle-tested. Since the site admins would have to do all the dirty work, I feel like this should be their call in the end. However, I believe all the content on WineHQ & the wiki are under the LGPL so if you really wanted to, I'd think you could try testing a mirror of the site as a proof of concept, running Cherokee on your own computer. If you can show the advantages outweigh the trouble of switching over, the site admins would probably be more willing to consider it. Rather than switching out the http server, I think there is some interest in moving WineHQ over to a web-framework/CMS. I wanted to handle the wiki first, but afterwards if there's still demand for it, I'd like to try helping make the jump to a CMS. -Kyle

Aug. 28, 2012

Re: Wine bot results

by Jacek Caban

On 08/28/12 12:04, Alistair Leslie-Hughes wrote: > Hi, > > I have a patch that when run on on the testbot, it fails on all but > two machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? + VariantClear(&d); + V_VT(&v) = VT_BSTR; + V_BSTR(&v) = SysAllocStringLen(NULL, 0); This VariantClear call attempts to free uninitialized VARIANT instance. You probably meant VariantInit(). Jacek

Aug. 28, 2012

Re: About WineHQ Wiki

by Jeremy Newman

On 08/28/2012 04:47 AM, Oleg Yarigin wrote: > Well, in addition, how do you think, is any necessarity there to move > wine site and wiki from Apache to Cherokee? Not going to happen anytime in the near future. I won't say never however. -N

Aug. 28, 2012

Re: [PATCH 1/5] d3dx9: Add some traces to D3DXLoadSurfaceFromMemory().

by Henri Verbeet

2012/8/28 Rico Schüller <kgbricola(a)web.de>: > + FIXME("Format conversation missing %#x -> %#x\n", src_format, surfdesc.Format); I don't think that's really what we want it to say.

Aug. 28, 2012

Re: shell32: Make ShellExecute use native file association databases as fallback path (resend)

by Alexandre Julliard

Erik van Pienbroek <erik(a)vanpienbroek.nl> writes: > +#if defined(HAVE_FORK) && defined(HAVE_WAITPID) > +static UINT_PTR SHELL_try_native_execute ( const char *openCmd, const char *unixName ) > +{ > + UINT_PTR retval = SE_ERR_NOASSOC; > + pid_t cpid; > + struct stat st; > + > + if (stat(openCmd, &st) == -1) > + { > + TRACE("stat() %s failed: %s\n", openCmd, strerror(errno)); > + return retval; > + } > + > + cpid = fork(); > + if (!cpid) > + { > + /* Prevent the situation where the native file association database > + * tries to run wine to execute a program and we trigger this fallback > + * path again and end up in a recursive loop */ > + if (getenv("WINE_INSIDE_SHELLEXECUTE")) > + { > + TRACE("recursive loop detected, not continuing with ShellExecute call\n"); > + exit(EXIT_SUCCESS); > + } > + setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0); > + > + TRACE("running %s %s\n", openCmd, unixName); > + execlp(openCmd, openCmd, unixName, (char*) NULL); > + /* execlp replaces the current process image with a new process image, > + * so no code below here should get executed by the forked child */ > + } else { > + int status; > + waitpid(cpid, &status, 0); > + TRACE("status %x\n", status); > + if(!WEXITSTATUS(status)) > + retval = 33; > + } > + > + return retval; > +} You want spawnvp(), but that sort of thing should probably go in winebrowser or something like that, and be configurable. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: kernel32: Try to get the drive type from the mountmgr first [resend]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Should fix bug #17037 > Now that my patch disappeared from source.winehq.org/patches, I'm resending it. > Before commenting, please read the e-mail I sent in July (winehq.org/pipermail/wine-devel/2012-July/096587.html) The goal here is to avoid a mountmgr round-trip for the common case, calling mountmgr first defeats this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 28.08.2012 10:50, Henri Verbeet wrote: > On 28 August 2012 09:12, Rico Schüller <kgbricola(a)web.de> wrote: >> 3. The wine_todo should be fixed in the test. Is there a way to disable them >> to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit >> annoying when you search for your own failing tests. Well I could comment >> out the tests, but that's also not a very fine solution. >> > You can set WINETEST_PLATFORM=wine, but the easiest is probably to > just do "make shader.ok" instead of trying to run the test manually. > Thanks, that's exactly what I need. Cheers Rico

Aug. 28, 2012

Re: Wine bot results

by Alistair Leslie-Hughes

Hi Qian, > > $ i686-w64-mingw32-gcc -v > Using built-in specs. > COLLECT_GCC=i686-w64-mingw32-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper > Target: i686-w64-mingw32 > Configured with: ../../src/configure --build=i686-linux-gnu > --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' > --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var > --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode > --disable-dependency-tracking --prefix=/usr --disable-shared > --disable-multilib --enable-linker-build-id --with-system-zlib > --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib > --enable-libstdcxx-time=yes --with-tune=generic > --enable-version-specific-runtime-libs > --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld > --enable-fully-dynamic-string --target=i686-w64-mingw32 > --with-gxx-include-dir=/usr/include/c++/4.6 > --with-as=/usr/bin/i686-w64-mingw32-as > --with-ld=/usr/bin/i686-w64-mingw32-ld > Thread model: win32 > gcc version 4.6.1 (GCC) > $ i586-mingw32msvc-gcc -v Using built-in specs. Target: i586-mingw32msvc Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs Thread model: win32 gcc version 4.2.1-sjlj (mingw32-2) Here is what install on my system, Ill try to update it to a later version. Best Regards Alistair Leslie-Hughes

Aug. 28, 2012

Re: Wine bot results

by Qian Hong

Hello Alistair, On Tue, Aug 28, 2012 at 6:04 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 I downloaded your patch from http://testbot.winehq.org/GetFile.pl?JobKey=21257&StepKey=1 , compiled with i686-w64-mingw32-gcc on Ubuntu 10.10, then resubmit it to wine testbot, my result is the same as the one built by testbot: https://testbot.winehq.org/JobDetails.pl?Key=21288 Maybe it is interesting to know what compiler you use and which one is used by testbot. Though we should make sure we are always test on the same patch first =) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --disable-shared --disable-multilib --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld --enable-fully-dynamic-string --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.6 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.6.1 (GCC) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

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=21287 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === 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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Re: Wine bot results

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > I have a patch that when run on on the testbot, it fails on all but two > machines. > However when I build the exe myself and run it, it pass on all but two > machines. > > http://testbot.winehq.org/JobDetails.pl?Key=21257 > http://testbot.winehq.org/JobDetails.pl?Key=21256 > > Ubuntu 12.04. > > Any Ideas on the different results? This probably means that behaviour is undefined and depends on memory contents. -- Dmitry.

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

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=21286 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === 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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Re: [PATCH 6/6] Always define WIDL_C_INLINE_WRAPPERS

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=21285 Your paranoid android. === 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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Aug. 28, 2012

Wine bot results

by Alistair Leslie-Hughes

Hi, I have a patch that when run on on the testbot, it fails on all but two machines. However when I build the exe myself and run it, it pass on all but two machines. http://testbot.winehq.org/JobDetails.pl?Key=21257 http://testbot.winehq.org/JobDetails.pl?Key=21256 Ubuntu 12.04. Any Ideas on the different results? Best Regards Alistair Leslie-Hughes

Aug. 28, 2012

Re: About WineHQ Wiki

by Oleg Yarigin

Finally I got an answer from Jeremy White, wine site admin: >Hi Oleg, > >On 08/26/2012 08:21 AM, Oleg Yarigin wrote: >> Good time of a day, Jeremy. >> >> I write to you as to a WEB-administrator of WineHQ server about some >> ideas of site functionality improvement: >> >> 1. How is about moving WineHQ Wiki onto Wikimedia engine and break >> it into multiple language trurd-level domains (like interwiki in >> Wikipedia)? I am ready to move the Wiki`s material from old one >> (wiki.winehq.org) to new one. A discussion of this idea is in August >> wine-devel pipemail, "About WineHQ Wiki" thread. > >I'm afraid that this is something best discussed on the wine-devel list. > And the person you really need to persuade is Dimi Paun - he runs the >Wiki. > >> 2. How is about moving a whole site from Apache web server to >> Cherokee web server? I heared, it is much faster. > >Are we having a problem with Apache being too slow? I think you'll find >us very reluctant to make change for no driving reason. Again, if you >are finding a problem with the current web site, please share that on >the wine-devel mailing list. > >Cheers, > >Jeremy Now I wait an answer from Dimi Paun. Well, in addition, how do you think, is any necessarity there to move wine site and wiki from Apache to Cherokee? --- Oleg

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> I just did, and the behavior, though it looks wrong, is the same > >> between builtin and native - the image is shifted by 1/2 pixel so that > >> it's cut off at the upper-left and we have extra transparent space at > >> the lower-right. > > > > With native gdiplus scenario described earlier works just fine for me, > > while with built-in there are black borders on bottom/right. > > You should be getting transparent borders on the bottom/right. > > This probably means you're using a surface that's not capable of alpha > blending, and in that situation gdi_alpha_blend currently draws fully > transparent pixels as black when it shouldn't. I'm pretty sure I > mentioned that as a problem earlier, around the time you introduced > gdi_alpha_blend. The problem is not related to a device not supporting alpha blending, I even replaced a TRACE there by ERR just in case, but it never triggers. > If you compare the size of the image drawn between native/builtin (not > counting the border, which native draws as transparent, as does > builtin under normal circumstances), I think you'll find that it > currently matches and your patch changes it. If you didn't notice, > you're probably not enlarging the image enough. I don't see a difference in the image size regardless how much I enlarge the image. > Since GdipDrawImage doesn't accept a source rectangle, and those extra > pixels are supposed to be transparent, you could probably have > GdipDrawImage subtract 0.5 from your image width and height. That > should solve your problem in this limited case without fixing > gdi_alpha_blend or introducing a bug. Subtracting 0.5 from width and height hides the problem, but that's just a compensation to rounding up that my patch is removing. -- Dmitry.

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Henri Verbeet

On 28 August 2012 09:12, Rico Schüller <kgbricola(a)web.de> wrote: > 3. The wine_todo should be fixed in the test. Is there a way to disable them > to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit > annoying when you search for your own failing tests. Well I could comment > out the tests, but that's also not a very fine solution. > You can set WINETEST_PLATFORM=wine, but the easiest is probably to just do "make shader.ok" instead of trying to run the test manually.

Aug. 28, 2012

Re: xmllite: Store DTD processing mode in reader

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Alexandre Julliard wrote: >> Explicit ok() calls are better than hiding them inside a macro. > > Uh-oh. Want me to get rid of this macro > > +#define CHECK_RET_ERRNO(ret, ex) \ > + do { \ > + ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \ > + ok(errno == ex, "errno is %d, expected %d\n", errno, ex); \ > + } while (0) > > in http://source.winehq.org/patches/data/89349 ? Obviously, yes. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 23.08.2012 22:58, Rico Schüller wrote: > On 23.08.2012 15:43, Józef Kucia wrote: >> I would prefer you to clean it up submit it. I hope it gets committed >> this time. > > Ok, I'll try to clean them and send them. I will do it the safe way and > compare each handle with all handles we have. If it is slow, we could > easily move by using the highest bit for comparison against the > D3DXHANDLE. We just have to take care that an easy switch is possible. > > Thanks for the input. > Rico > Patches are in git now. The normal way should work fine. The following things should be considered (but I have no patches for these): 1. The cross calling (table1, variable_from_table2). 2. We may avoid the desc copy, because the variables may be set often and so the copy time will make some speed difference in set_*_array and GetSamplerIndex. Example for GetSamplerIndex: res = ID3DXConstantTable_GetConstantDesc(iface,constant,&desc,&count); if (FAILED(res)) return (UINT)-1; if (desc.RegisterSet != D3DXRS_SAMPLER) to something like: struct ctab_constant *c = get_valid_constant(This, constant); if (c->desc.RegisterSet != D3DXRS_SAMPLER) 3. The wine_todo should be fixed in the test. Is there a way to disable them to show up, when running e.g. "wine d3dx9_36_test.exe.so shader"? It's a bit annoying when you search for your own failing tests. Well I could comment out the tests, but that's also not a very fine solution. Cheers Rico

Aug. 28, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > If there are only cosmetic objections, I'd like to see this patch accepted, > > and work of further improvements after that. > > I asked Alexandre to wait until I had more time to understand/test this patch. > > It seems you've introduced a problem with scaling (see attached test > program and screenshot). I think that MeasureString is working > correctly in this case, and DrawString/MeasureCharacterRanges are > wrong. Thanks for the test program, it's pretty illustrative. I sent another version of the patch that should take scaling and world transform into account. > This sort of problem would be less likely if the logic were in > gdip_format_string. I still think that it's more important to make these APIs behave correctly first, and only then try to optimize/merge/redesign the logic behind them. -- Dmitry.

Aug. 28, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

>> I just did, and the behavior, though it looks wrong, is the same >> between builtin and native - the image is shifted by 1/2 pixel so that >> it's cut off at the upper-left and we have extra transparent space at >> the lower-right. > > With native gdiplus scenario described earlier works just fine for me, > while with built-in there are black borders on bottom/right. You should be getting transparent borders on the bottom/right. This probably means you're using a surface that's not capable of alpha blending, and in that situation gdi_alpha_blend currently draws fully transparent pixels as black when it shouldn't. I'm pretty sure I mentioned that as a problem earlier, around the time you introduced gdi_alpha_blend. If you compare the size of the image drawn between native/builtin (not counting the border, which native draws as transparent, as does builtin under normal circumstances), I think you'll find that it currently matches and your patch changes it. If you didn't notice, you're probably not enlarging the image enough. Since GdipDrawImage doesn't accept a source rectangle, and those extra pixels are supposed to be transparent, you could probably have GdipDrawImage subtract 0.5 from your image width and height. That should solve your problem in this limited case without fixing gdi_alpha_blend or introducing a bug.

Aug. 27, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Just write a test with GdipDrawImageI and scenario described above and > > you will see the problem. In my case it's even more visible because of > > indirect magnifaction: image with resolution 100 dpi is being copied to > > device with 300 dpi. > > I just did, and the behavior, though it looks wrong, is the same > between builtin and native - the image is shifted by 1/2 pixel so that > it's cut off at the upper-left and we have extra transparent space at > the lower-right. With native gdiplus scenario described earlier works just fine for me, while with built-in there are black borders on bottom/right. -- Dmitry.

Aug. 27, 2012

Re: gdiplus: When copying an image do not round pixel positions up.

by Vincent Povirk

> Just write a test with GdipDrawImageI and scenario described above and > you will see the problem. In my case it's even more visible because of > indirect magnifaction: image with resolution 100 dpi is being copied to > device with 300 dpi. I just did, and the behavior, though it looks wrong, is the same between builtin and native - the image is shifted by 1/2 pixel so that it's cut off at the upper-left and we have extra transparent space at the lower-right.

Aug. 27, 2012