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

Re: [3/3] comctl32/tests: Add a statusbar test for setting number of parts to zero.

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=9486 Your paranoid android. === WNT4WSSP6 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2KPROSP4 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === WXPPROSP3 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2K3R2SESP2 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === WVISTAADM (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2K8SE (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PRO (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PROX64 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PROX64 (64 bit status) === status.c:412: Test failed: Expected 1, got 0

Feb. 25, 2011

Re: kernel32/tests: remove win9x hacks (try 2)

by Saulius Krasuckas

* On Thu, 24 Feb 2011, Alexandre Julliard wrote: > Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > > > I have at least one Win16 app which behaves differently on Win16, on > > XP and on Wine [*]. > > What's the right way to get it running OK on Wine then (without > > appropriate Win16API tests) ? > > Fix the bug without a test, or work on adding a 16-bit test suite. Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests? And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK. > This has nothing whatsoever to do with running 32-bit tests on Win95. Yes, that's two separate topics in one msg. What is best in your opinion to do for those still interested in win9x's 32-bit behaviour? The only alternative coming to my mind is forking winetest. S.

Feb. 25, 2011

Dynamic OpenSSL import library

by Tim Burrell

Hi all, I'm one of TransGaming's R&D developers working on our portability products. We've recently done a cleanup and refactoring to the OpenSSL loading routines; rather than loading the libraries in a few different places we moved the code into an OpenSSL importer that consolidates the loading into a separate library. Our importer does some additional things that might not be overly useful to Wine, such as detecting and loading different versions of the OpenSSL libraries at runtime (rather that using the version detected while configuring), but the cleanup and refactoring worked out quite well, and we think the code would still be valuable to Wine. We could port this code back to the Wine tree, but it will take some effort to do so. Also, our current implementation of the dynamic OpenSSL importer isn't complete; we're only loading the specific functions we've needed up until now. Before going to the effort of completing the library, and porting it back to the Wine tree, I thought I'd reach out first to see if it's even something that's of interest? If it is, great, we can complete the library and submit some patches for review, but if the concept isn't of interest then we'll just continue using it internally. I've attached a copy of the main C file from the OpenSSL import library, so you can get an idea for what it will look like. Keeping in mind that it's not finished yet, and needs some cleaning up, does this approach look acceptable? Also attached is a patch (that won't directly apply) that should give an idea of its intended usage. Anyone have thoughts / questions? Thanks, Tim. -- Tim Burrell TransGaming <http://transgaming.com> Inc. 431 King Street West, Suite 600 Toronto, Ontario, Canada M5V 1K4

Feb. 25, 2011

Re: Is the Call for Translators forum sticky still needed?

by Michael Stefaniuc

Rosanne DiMesio wrote: > The original post asked for help leading up to the release of 1.2. That's obviously outdated, and the thread now just attracts spammers. Should it be updated, or simply removed? IMHO removing the sticky should be fine. In the midst of a development cycle there is no point to ask for translation help as Wine is a moving target (but I do *not* mean that people should stop translating Wine). bye michael

Feb. 25, 2011

Is the Call for Translators forum sticky still needed?

by Rosanne DiMesio

The original post asked for help leading up to the release of 1.2. That's obviously outdated, and the thread now just attracts spammers. Should it be updated, or simply removed? -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 25, 2011

Re: gdi32: Fix 64-bit pointer issues when copying upside-down bitmaps.

by Peter Urbanec

On 26/02/11 00:05, Marcus Meissner wrote: > diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c >> index 0619304..595eb9b 100644 >> --- a/dlls/gdi32/dib.c >> +++ b/dlls/gdi32/dib.c >> @@ -885,7 +885,7 @@ INT WINAPI GetDIBits( >> */ >> if (bmp->dib->dsBmih.biHeight< 0) >> { >> - sbits += (srcwidthb * (abs(bmp->dib->dsBmih.biHeight) - 2 * startscan - 1)); >> + sbits += (srcwidthb * (LONG)(abs(bmp->dib->dsBmih.biHeight) - 2 * startscan - 1)); > Please enlighten us to the problem you are fixing? I see no 64bit pointer relation...? When running gdi32_test bitmap on Gentoo64, I see: Unhandled exception: page fault on read access to 0x100240000 in 64-bit code (0x00007f7f8a708530). Backtrace: =>0 0x00007f7f8a708530 in libc.so.6 (+0x127530) (0x000000000022f9b0) 1 0x00007f7f88b607c4 GetDIBits+0x11f9(hdc=0x25c, hbitmap=0x750, startscan=0x1, lines=0x1, bits=0x22fa1c, info=0x22fa20, coloruse=0) [/home/eyeon/source/wine/dlls/gdi32/dib.c:914] in gdi32 (0x000000000022f9b0) 2 0x00007f7f891face5 test_GetDIBits_single_pixel_destination+0x2d2(bpp=0x10) [/home/eyeon/source/wine/dlls/gdi32/tests/bitmap.c:3026] in gdi32_test (0x000000000022f9b0) 3 0x00007f7f891fb123 func_bitmap+0xc2() [/home/eyeon/source/wine/dlls/gdi32/tests/bitmap.c:3082] in gdi32_test (0x000000000022f9b0) A little more tracing revealed that the above line without the (LONG) cast turned sbits from 0x240004 to 0x100240000, which in turn caused the page fault in memcpy(). With the (LONG) cast in place, I see sbits changing from 0x240004 to 0x240000, as expected. Using gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 with -O0 The addition of the cast fixes the issue and allows the winetest to succeed. Cheers, Peter Urbanec

Feb. 25, 2011

Re: winspool.drv: return maximum possible size of the buffer when no buffer is specified

by Vitaly Perov

В сообщении от 23 февраля 2011 21:43:49 автор Alexandre Julliard написал: > Vitaly Perov <vitperov(a)etersoft.ru> writes: > > @@ -7247,7 +7247,7 @@ static BOOL get_job_info_2(job_t *job, JOB_INFO_2W > > *ji2, LPBYTE buf, DWORD cbBuf > > > > else > > { > > > > /* align DEVMODE to a DWORD boundary */ > > > > - shift= (4 - ( (DWORD_PTR) ptr & 3)) & 3; > > + shift= ptr ? (4 - ( (DWORD_PTR) ptr & 3)) & 3 : 3; > > It should most likely align from the start of the data, not from the > pointer value. I use convert_printerinfo_W_to_A() function as an example. It aligns DEVMODE to a DWORD boundary from the pointer value. -- Best regards, Vitaly Perov

Feb. 25, 2011

Re: gdi32: Fix 64-bit pointer issues when copying upside-down bitmaps.

by Marcus Meissner

On Fri, Feb 25, 2011 at 11:41:31PM +1100, Peter Urbanec wrote: > --- > dlls/gdi32/dib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c > index 0619304..595eb9b 100644 > --- a/dlls/gdi32/dib.c > +++ b/dlls/gdi32/dib.c > @@ -885,7 +885,7 @@ INT WINAPI GetDIBits( > */ > if (bmp->dib->dsBmih.biHeight < 0) > { > - sbits += (srcwidthb * (abs(bmp->dib->dsBmih.biHeight) - 2 * startscan - 1)); > + sbits += (srcwidthb * (LONG)(abs(bmp->dib->dsBmih.biHeight) - 2 * startscan - 1)); Please enlighten us to the problem you are fixing? I see no 64bit pointer relation...? Ciao, Marcus

Feb. 25, 2011

Re: gdi32: first look for a printer driver name in the registry (try 5)

by Vitaly Perov

> > + if (!hKey) RegCloseKey(hKey); > > This one is still not fixed. Thank you very much for your patience! I am sorry for such trivial mistakes. I didn't have enough sleep last time. -- Best regards, Vitaly Perov

Feb. 25, 2011

Re: gdi32: first look for a printer driver name in the registry (try 5)

by Dmitry Timoshkov

Vitaly Perov <vitperov(a)etersoft.ru> wrote: > + if (!hKey) RegCloseKey(hKey); This one is still not fixed. -- Dmitry.

Feb. 25, 2011