December 2015 - Wine-devel - list.winehq.org

build Wine using Intel compiler (win32)
by Paul Gofman 22 Dec '15

22 Dec '15

Dear all, I compiled Wine with icc and found 2 issues, which I managed to fix in the code. The issues are: 1. Crash in Wine loader (at least with using Intel compiler) Checking return values from all the calls to wld_mprotect in loader/preloader.c solved the issue (apparently syscall was optimized out when return value was not used, which is likely a compiler problem) 2. msvcrt/math.c has a number of trigonometrical functions implementations named __libm_sse2_... (e. g., __libm_sse2_cos). icc substitutes these names for some of trigonometrical functions (e. g., tan is replaced internally by __libm_sse2_tan). This results in endless recursion and stack overflow both in __lib_sse2_tan and the ordinary tan function in msvcrt (which is get aliased to __libm_sse2_tan). I solved this by renaming these functions in the code but keeping the original export name through spec files. Is there any chance for such changes to find the way upstream? If yes, could you please advice how is it best to proceed: create a bug first, or just send a patch (probably 2 separate patches) to wine-patches for review? Thanks, Paul.

2 1

Re: [PATCH 1/2] oledb32: Convert to a BSTR to work out it size
by Huw Davies 22 Dec '15

22 Dec '15

On Tue, Dec 22, 2015 at 06:32:03PM +1100, Alistair Leslie-Hughes wrote: > This makes code for handling variants with DBTYPE_STR and DBTYPE_WSTR > types consistent. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 72714d3..a87cf18 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -1372,10 +1372,22 @@ static HRESULT WINAPI convert_GetConversionSize(IDataConvert* iface, > switch (src_type) > { > case DBTYPE_VARIANT: > - if(V_VT((VARIANT*)src) == VT_BSTR) > - *dst_len = (SysStringLen(V_BSTR((VARIANT*)src))+1) * sizeof(WCHAR); > + { > + VARIANT v; > + > + VariantInit(&v); > + if ((hr = VariantChangeType(&v, (VARIANT*)src, 0, VT_BSTR)) == S_OK) > + { > + *dst_len = (SysStringLen(V_BSTR(&v))+1) * sizeof(WCHAR); > + VariantClear(&v); > + } > else > + { > WARN("DBTYPE_VARIANT(%d)->DBTYPE_WSTR unimplemented\n", V_VT((VARIANT*)src)); This WARN should go away, then it will actually be consistent with the DBTYPE_STR case. Huw.

1 0

EnableShell registry key
by Ruslan Kabatsayev 22 Dec '15

22 Dec '15

Hello, Wine 1.8 announcement mentions EnableShell key: > There is an optional Start Menu in desktop mode, that can be enabled > on a per-desktop basis by setting "EnableShell" to "Y" under > HKCU\Software\Wine\Explorer\Desktops\<name>. But when I tried to use it, I failed with "Y" string key (i.e. only desktop with special name "shell" got the start button). After reading the sources that key appears to be a DWORD, so it has to be created as a DWORD with value of "1". Also, the key isn't listed @ http://wiki.winehq.org/UsefulRegistryKeys . What's it supposed to be — a string or a dword? Is it a bug in implementation, or is it a misdocumentation? And should it also be listed @ UsefulRegistryKeys? Regards, Ruslan

2 1

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 20.12.2015 19:42, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > > The code in SetCaretPos doesn't change the caret state if it's position is unchanged. > Reflect this at the server side to avoid caret corruption. > > try2: > - fixed incorrect if statement in the server > --- > dlls/user32/caret.c | 2 +- > server/protocol.def | 3 ++- > server/queue.c | 5 +++++ > 3 files changed, 8 insertions(+), 2 deletions(-) After playing around a bit more I can confirm that this is the right way to fix it. I was already about to send my sign-off, but then I noticed that it breaks ./tools/make_requests, which doesn't seem to like multiline comments in protocol.def. $ ./tools/make_requests Unrecognized syntax * -2=on if the position differs, unchanged otherwise) */ at ./tools/make_requests line 257, <PROTOCOL> line 2981. Please resend after fixing this issue (probably just make the comment a bit smaller), then I'll add my signoff. ;) Best regards, Sebastian

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 3).
by Stefan Dösinger 21 Dec '15

21 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-12-18 um 14:43 schrieb Aaryaman Vasishta: > +static char *create_bitmap(const char *filename, const int w, const int h, const int type) Just fyi: The const on parameters that are passed by value (non-pointers) doesn't really do much, so we usually leave it out. Feel free to keep it though. > + /* Type 1 bitmaps are 8 bpp whereas type 2 bitmaps are 24bpp. */ > + const int bpp = type == 1 ? 8 : 24; Urk. Why not just pass the bpp? Or a "BOOL palettized"? > + unsigned char *buffer = NULL; > + DWORD written, size; > + int i, j; > + > + /* Calculate size of the BITMAPINFO header */ > + /* Space for 256 color palette would need to be allocated if the bitmap is 8bpp */ > + size = sizeof(BITMAPINFOHEADER); > + if (type == 1) > + size += sizeof(RGBQUAD)* 256; > + > + ZeroMemory(&file_header, sizeof(BITMAPFILEHEADER)); Please use memset. Applies to other places as well. > + file_header.bfType = 0x4d42; Other places in Wine add a /* "BM" */ comment to show what the magic number is. dlls/comctl32/imagelist.c uses (('M' << 8) | 'B'). > + buffer[i] = (i + rand()) % 255; Generally it is a bad idea to use random numbers in tests. It encourages random test failures :-) . I guess you want some kind of irregular pattern. You could e.g. use i % 251 (the highest prime < 256). > +static BOOL test_bitmap_data(const unsigned char *buffer1, const unsigned char *buffer2, const D3DRMIMAGE *img, const int depth, const int version) "BOOL upside_down" would be more explanatory than "version" IMO. That the upside down property is related to the version can easily be seen by checking who calls test_bitmap_data with that parameter. > + /* d3drm aligns the 24bpp texture to 4 bytes in the buffer, with one bype padding from 24bpp texture. */ > + /* The image is palettized if the total number of colors used is <= 256. */ Unless I am missing something the first comment isn't really of a concern in this codepath. > + for (i = 0; i < h; i++) > + { > + offset = version == 1 ? (w * i * 3) : (w * (h - i - 1) * 3); > + for (j = 0; j < w; j++) > + { > + val1 = buffer1[k] == buffer2[offset]; > + val2 = buffer1[k + 1] == buffer2[offset + 1]; > + val3 = buffer1[k + 2] == buffer2[offset + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + k += 4; > + offset += 3; > + } The 24bpp -> 32bpp comment would fit well above this code though. > + /* Test if image information matches that from the header by loading the bitmap seperately. */ "separately", according to my Thunderbird's dictionary. > + ok(check, "Cannot delete image stored in %s (error = %x).\n", file, GetLastError()); The way you're writing GetLastError values is inconsistent (%x vs %d). > +static void test_load_texture1(void) > ... > + file = create_bitmap("8bpp.bmp", 100, 100, 1); > ... > +static void test_load_texture2(void) > ... > + file = create_bitmap("palette.bmp", 3, 39, 2); > ... > +static void test_load_texture3(void) > ... > + file = create_bitmap("24bpp.bmp", 100, 100, 2); - From this it isn't obvious if e.g. the upside down reading of v2 and v3 are a property of the interface version or the input format. Please test all formats with all versions. Also consider testing what happens if a texture is created as IDirect3DRMTexture3 and QI'd to IDirect3DRMTexture1. Does it return upside down image data? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWeF7GAAoJEN0/YqbEcdMwnDsP/2rjF3YySneqr0EW+MURA7po RkUAhNBdtaLUo/iUgbAmaddv5yIm6dt0kkh02o1Ci/+iwOR+GpQ9d11B8s1R2sre T7Sg/WhObJcCVWxiUVOOppH+5Kf5HRs9SznOqPJU7K1ZhdF0+JzAAIR3+ujIb71N +YdCdS+VW1T0YoiJMFbzoO0jX0z9B/fT8DfGWFhiusWa6Be7hyXx6+N0hXh6r1BC hDTxLs91lHcPEUAkGlJVJUMwjlB2L+0YuVpZCoDF6nzrBZuOuf7oByUYgz3st5B/ nSFIc2OuW3r7U5oaGk2B/7U8fA1QJpKECJaerj1ki2LdmMplH+3Pecngizmmq4QY C8ns/DXt7szHNItM+sWTB8nvlI3lIppDV6jGJH1B/cBQDrXM5NC8V2DTqySucToV RNqCiLhiU7EDQ4TJycJJmfOonRix51qzt5fjbbrxQH53TI8mU2T9DtwklLRY3TT8 gV0SL17uiyoL3cexargXnIeov+BTOxmUYzgUpkOG4L1oPGht2ikhIQW/I5ZCs4x/ PJ3fLtMaF5lpyuXBjoThbhOzGc0TC/mXRValVvgePADNSRHbHnRnIRk12ZH7EwRI v38AtVTo83hsTZlAtgHoALy4TUkZU4wH8BPhLgC9+BRJVJ9qa+TRnugQZJYZGVDr j8860n5H0A790o6rbURT =7NBX -----END PGP SIGNATURE-----

1 0

Re: ntdll: Fix NtQueryDirectoryFile behavior on short file names on case insensitive file systems (try2)
by Ken Thomases 21 Dec '15

21 Dec '15

On Dec 21, 2015, at 11:42 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > @@ -2214,11 +2205,7 @@ static int read_directory_getattrlist( int fd, IO_STATUS_BLOCK *io, void *buffer > } > else io->u.Status = restart_scan ? STATUS_NO_SUCH_FILE : STATUS_NO_MORE_FILES; > } > - else if ((errno == ENOENT || errno == ENOTDIR) && !get_dir_case_sensitivity(".")) > - { > - io->u.Status = restart_scan ? STATUS_NO_SUCH_FILE : STATUS_NO_MORE_FILES; > - ret = 0; > - } > + else ret = -1; Setting ret to -1 here is redundant. It will already be -1 if getattrlist() failed. Other than that, looks good to me. > } > else ret = -1; > -Ken

1 0

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 21.12.2015 07:04, Anton Baskanov wrote: > You are right, this would fix the issue, but the Windows behavior is > different. The caret remains in it's current state if it's position is > unchanged. > I've attached a simple test application that demonstrates this. It calls > SetCaretPos on mouse button press with different positions for left and > right buttons. Thanks for providing the testcase. I didn't have time to test it on a Windows machine yet (will do that later), but under the assumption that it works as expected, your approach is indeed more correct. Nevertheless, another possible theory would be that SetCaretPos should leave the state untouched. Could you please check that, too?

1 0

Re: [PATCH 1/7] kernel32/tests: Add path tests for the unusual ./../foo case.
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 21.12.2015 17:51, Jeremy White wrote: > Signed-off-by: Jeremy White <jwhite(a)codeweavers.com> > --- > This patch series address issues found in GetLongPathName and GetShortPathName > as reported in bug https://bugs.winehq.org/show_bug.cgi?id=36859. > Thanks to Dmitry for pointing out GetShortPathName should be checked as well > and for the suggestion to use CheckNameLegalDOS8Dot3W. > --- > dlls/kernel32/tests/path.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c > index 85c4ec3..4504603 100644 > --- a/dlls/kernel32/tests/path.c > +++ b/dlls/kernel32/tests/path.c > @@ -2136,6 +2136,15 @@ static void test_relative_path(void) > ok(ret, "GetShortPathName error %d\n", GetLastError()); > ok(!strcmp(buf, "..\\foo\\file"), "expected ..\\foo\\file, got %s\n", buf); > > + strcpy(buf, "deadbeef"); > + ret = pGetLongPathNameA(".\\..\\foo\\file", buf, MAX_PATH); > + ok(ret, "GetLongPathName error %d\n", GetLastError()); > + ok(!strcmp(buf, ".\\..\\foo\\file"), "expected .\\..\\foo\\file, got %s\n", buf); > + strcpy(buf, "deadbeef"); > + ret = GetShortPathNameA(".\\..\\foo\\file", buf, MAX_PATH); > + ok(ret, "GetShortPathName error %d\n", GetLastError()); > + ok(!strcmp(buf, ".\\..\\foo\\file"), "expected .\\..\\foo\\file, got %s\n", buf); > + > SetCurrentDirectoryA(".."); > DeleteFileA("foo\\file"); > RemoveDirectoryA("foo"); > The patch causes test failures here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so path && touch path.ok path.c:2141: Test failed: GetLongPathName error 2 path.c:2142: Test failed: expected .\..\foo\file, got deadbeef [...] After applying all patches those are gone. Is todo_wine missing maybe?

1 0

Plans
by Alexandre Julliard 21 Dec '15

21 Dec '15

Folks, Wine 1.8 is released, congratulations to everybody! The development branch is now open for business, you can resend patches that had been deferred. However, I expect that things will be slow in the next couple of weeks, since many developers are leaving on vacation. I won't be around a whole lot myself either, so it may take a while before we are caught up. I will try to make a 1.9.0 release this Friday. Michael Stefaniuc is now in charge of maintaining the 1.8 stable branch. Please see http://wiki.winehq.org/StableRules for details. Happy holidays! -- Alexandre Julliard julliard(a)winehq.org

5 6

Re: [resend 2/4] ddraw7/tests: Test GetPriority() on cubemap surfaces.
by Marvin 21 Dec '15

21 Dec '15

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 https://testbot.winehq.org/JobDetails.pl?Key=19070 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. The test timed out

1 0