October 2014 - Wine-Devel - list.winehq.org

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

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/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Wine 64 bit
by Kevin Davies June 5, 2015

June 5, 2015

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard April 23, 2015

April 23, 2015

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: [4/6] msvcrt: Added _fread_nolock_s implementation
by Alexandre Julliard Nov. 2, 2014

Nov. 2, 2014

"Iván Matellanes" <matellanesivan(a)gmail.com> writes: > { > + MSVCRT_size_t ret; > + > + MSVCRT__lock_file(stream); > + ret = MSVCRT__fread_nolock_s(buf, buf_size, elem_size, count, stream); > + MSVCRT__unlock_file(stream); The parameter validation has to be done before locking the file. -- Alexandre Julliard julliard(a)winehq.org

2 2

[PATCH] Mystery hang reduction -- clear new allocations
by mtewoodbury＠gmail.com Nov. 2, 2014

Nov. 2, 2014

From: Max TenEyck Woodbury <max+git(a)mtew.isa-geek.net> I was getting mystery frozen processes that cleared when a total screen redraw was forced. This has been reported numerous times over several years. It came and went with various releases. I have been getting it consistantly recently. I had an idea that it might have something to do with partially uninitialized drawing data structures, so I started adding HEAP_ZERO_MEMORY flags in various places. This particular set cleared the problem, at least for now... diff --git a/dlls/wined3d/vertexdeclaration.c b/dlls/wined3d/vertexdeclaration.c index cf5378c..cf1c814 100644 --- a/dlls/wined3d/vertexdeclaration.c +++ b/dlls/wined3d/vertexdeclaration.c @@ -178,7 +178,8 @@ static HRESULT vertexdeclaration_init(struct wined3d_vertex_declaration *declara declaration->parent = parent; declaration->parent_ops = parent_ops; declaration->device = device; - declaration->elements = HeapAlloc(GetProcessHeap(), 0, sizeof(*declaration->elements) * element_count); + declaration->elements = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + sizeof(*declaration->elements) * element_count); if (!declaration->elements) { ERR("Failed to allocate elements memory.\n"); @@ -316,7 +317,7 @@ static unsigned int convert_fvf_to_declaration(const struct wined3d_gl_info *gl_ has_psize + has_diffuse + has_specular + num_textures; state.gl_info = gl_info; - state.elements = HeapAlloc(GetProcessHeap(), 0, size * sizeof(*state.elements)); + state.elements = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size * sizeof(*state.elements)); if (!state.elements) return ~0U; state.offset = 0; state.idx = 0; -- 1.8.0.rc0.18.gf84667d

2 1

Re: [PATCH] vbscript: Implemented String(try 2)
by Piotr Caban Nov. 2, 2014

Nov. 2, 2014

Hi, Some of the tests are not working on windows: E:\>vbscript_crosstest.exe run run.c:1043: Test failed: api.vbs: L"String(1, 564) = 4" run.c:1043: Test failed: api.vbs: L"String(1, 16895.49) = \00ff" run.c:1043: Test failed: api.vbs: L"String(1, CSng(16895.5)) = " run.c:1043: Test failed: api.vbs: L"755826670, w: Err.number = 0" run: 26885 tests executed (0 marked as todo, 4 failures), 0 skipped. On 10/25/14 10:10, Shuai Meng wrote: > +Call ok(String(1, 65.5) = "B", "String(1, 65.5) = " & String(1, 65.5)) > +Call ok(getVT(String(1, 65.5)) = "VT_BSTR", "getVT(String(1, 65.5)) = " & getVT(String(1, 65.5))) > +Call ok(String(1, 66.5) = "B", "String(1, 66.5) = " & String(1, 66.5)) > +Call ok(getVT(String(1, 66.5)) = "VT_BSTR", "getVT(String(1, 66.5)) = " & getVT(String(1, 66.5))) You have added exactly the same test twice. > +Call testStringError(2147483648, "w", 6) > +Call testStringError(2147483647, "w", 5) > +Call testStringError(1073741824, "w", 5) > +Call testStringError(1073741823, "w", 14) > +Call testStringError(755826670, "w", 14) > +Call testStringError(755826669, "w", 0) You can't assume it's possible to allocate ~700mb of memory in tests. The function never returns E_OUTOFMEMORY. You can't test it in wine tests suite but you can see it by calling the function in loop until system runs out of memory and then checking the error. You should simply try to allocate the string and if it fails return VBSE_OUT_OF_STRING_SPACE. Cheers, Piotr

3 3

Re: comctl32: Avoid magic numbers
by Nikolay Sivov Oct. 31, 2014

Oct. 31, 2014

> /* FIXME: This flag is undocumented and unknown by our CompareString. > - * We need a define for it. > */ > - dwFlags = 0x10000000; > + dwFlags = LOCALE_RETURN_GENITIVE_NAMES; > if (!bCase) dwFlags |= NORM_IGNORECASE; It makes no sense to use this flag from CompareString(). I think it's better to remove it along with this comment.

3 2

Re: [PATCH 2/2] user32/tests: Test exception handling for timer callbacks.
by Marvin Oct. 31, 2014

Oct. 31, 2014

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=9924 Your paranoid android. === w7u (32 bit msg) === msg.c:12154: Test failed: unexpected hwnd 0014013C msg.c:12176: Test failed: bad time 325e7/325f6

1 0

Re: [2/2] oleaut32: Implement TLB dependencies lookup in resources (resend 3 - last submit before abandon)
by Alexandre Julliard Oct. 30, 2014

Oct. 30, 2014

Guillaume Charifi <guillaume.charifi(a)sfr.fr> writes: > + strcpyW(szTLBPath, szPath); > + snprintfW(szStringName, sizeof(szStringName)/sizeof(WCHAR), resFormatStrW, PtrToInt(lpszIntName)); > + strcatW(szTLBPath, szStringName); > + > + ret = TLB_PEFile_Open(szPath, PtrToInt(lpszIntName), &pBase, &dwTLBLength, &pFile); > + if (ret == TYPE_E_CANTLOADLIBRARY) > + ret = TLB_NEFile_Open(szPath, PtrToInt(lpszIntName), &pBase, &dwTLBLength, &pFile); > + if (ret == TYPE_E_CANTLOADLIBRARY) > + ret = TLB_Mapping_Open(szPath, &pBase, &dwTLBLength, &pFile); > + if (SUCCEEDED(ret)) > + { > + if (dwTLBLength >= 4) > + { > + DWORD dwSignature = FromLEDWord(*((DWORD*) pBase)); > + if (dwSignature == MSFT_SIGNATURE) > + pTLib = ITypeLib2_Constructor_MSFT(pBase, dwTLBLength); > + else if (dwSignature == SLTG_SIGNATURE) > + pTLib = ITypeLib2_Constructor_SLTG(pBase, dwTLBLength); > + else > + { > + FIXME("Header type magic 0x%08x not supported.\n", dwSignature); > + ret = E_FAIL; > + } > + } > + else > + ret = E_FAIL; > + IUnknown_Release(pFile); > + } You should avoid duplicating all that code. > + if(pTLib) { > + ITypeLibImpl *impl = impl_from_ITypeLib2(pTLib); > + ret = UuidEqual((UUID *)This->guid, (UUID *)TLB_get_guid_null(impl->guid), &rpc_stat); > + ITypeLib_Release((ITypeLib *)pTLib); > + > + ret = (ret == TRUE) ? LoadTypeLibEx(szTLBPath, REGKIND_NONE, (ITypeLib **)&pTLib) : E_FAIL; > + } That's pretty ugly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/5] d3d9/tests: Add a test for ATI1N and ATI2N texture formats.
by Henri Verbeet Oct. 30, 2014

Oct. 30, 2014

On 29 October 2014 18:01, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6145,6 +6145,7 @@ static void test_lockrect_offset(void) > {D3DFMT_DXT3, "D3DFMT_DXT3", 4, 4, 16}, > {D3DFMT_DXT4, "D3DFMT_DXT4", 4, 4, 16}, > {D3DFMT_DXT5, "D3DFMT_DXT5", 4, 4, 16}, > + {MAKEFOURCC('A','T','I','1'), "ATI1N", 1, 1, 1}, > {MAKEFOURCC('A','T','I','2'), "ATI2N", 1, 1, 1}, Mostly just curiosity, but there are other tests in device.c for ATI2N, any reason for not adding ATI1N coverage to those as well? > + static const DWORD expected_colors_ati[] = {0x003f3f3f, 0x003f3f3f, 0x00007fff, 0x007f00ff}; > + static const DWORD expected_colors_nvidia[] = {0x007f0000, 0x007f0000, 0x00007fff, 0x007f00ff}; Conceptually I might have preferred this as static const struct { struct vec2 position; D3DCOLOR amd; D3DCOLOR nvidia; } expected_colors[] { ... } but it's not a big deal. > + for (i = 0; i < 4; ++i) > + { > + color = getPixelColor(device, 80 + 160 * i, 240); > + trace("Got 0x%08x.\n", color); Is this leftover debug code?

2 2

Need feedback on first four UTF-7 patches
by Alex Henrie Oct. 30, 2014

Oct. 30, 2014

Alexandre, I submitted four UTF-7 patches on October 19 and am still waiting for feedback. I was hoping that these patches would not be controversial because they only add encoding tests. I have six additional patches waiting in https://github.com/alexhenrie/wine/commits/master - four patches for adding decoding tests and two patches to make all the tests pass - but I will not submit them until I get feedback about the first four that I have already submitted. -Alex

8 13

Re: msi: Format registry values before interpreting value type.
by Marvin Oct. 30, 2014

Oct. 30, 2014

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=9898 Your paranoid android. === wxppro (32 bit action) === The test timed out === w7u (32 bit action) === The test timed out

1 0

Re: [PATCH 3/5] wined3d: Dirtify pixel shader on texture format change.
by Henri Verbeet Oct. 30, 2014

Oct. 30, 2014

On 29 October 2014 18:01, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (!prev || op->texture->target != prev->target > + || op->texture->resource.format != prev->resource.format) Shouldn't this just check the color_fixup? And in principle I think this would apply to vertex shaders as well, except that we don't track color fixups in struct vs_compile_args at all. The real pain will come with d3d10 of course, since you can access a much larger amount of resources there.

2 1

Re: dplayx: Fix some crashes and wine_todo's ( try 3)
by Marvin Oct. 30, 2014

Oct. 30, 2014

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=9894 Your paranoid android. === w8 (32 bit dplayx) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [PATCH 1/4] kernel32/tests: Add simple UTF-7 encoding tests.
by Sebastian Lackner Oct. 29, 2014

Oct. 29, 2014

On 20.10.2014 06:41, Alex Henrie wrote: > --- > dlls/kernel32/tests/codepage.c | 134 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 134 insertions(+) > > diff --git a/dlls/kernel32/tests/codepage.c b/dlls/kernel32/tests/codepage.c > index 8423c75..684ede1 100644 > --- a/dlls/kernel32/tests/codepage.c > +++ b/dlls/kernel32/tests/codepage.c > @@ -412,6 +412,138 @@ static void test_string_conversion(LPBOOL bUsedDefaultChar) > ok(GetLastError() == 0xdeadbeef, "GetLastError() is %u\n", GetLastError()); > } > > +static void test_utf7_encoding(void) > +{ > + struct simple_test > + { > + WCHAR utf16[1024]; > + int utf16_len; > + char utf7[1024]; > + int utf7_len; 1024 is unnecessary big. A couple of bytes would be sufficient for all these tests. > + }; > + > + static const struct simple_test simple_tests[] = { No need to give that struct a name. You can simply do: static const struct { ... } simple_tests[] = { ... } > + /* tests some valid UTF-16 */ > + { > + {0x4F60,0x597D,0x5417,0}, > + 4, > + "+T2BZfVQX-", > + 11 > + }, > + /* tests some invalid UTF-16 */ > + /* (stray lead surrogate) */ That looks ugly, either put it in a single line or use: /* line1 * line2 */ > + { > + {0xD801,0}, > + 2, > + "+2AE-", > + 6 > + }, > + /* tests some more invalid UTF-16 */ > + /* (codepoint does not exist) */ > + { > + {0xFF00,0}, > + 2, > + "+/wA-", > + 6 > + } > + }; > + > + int i; > + > + for (i = 0; i < sizeof(simple_tests) / sizeof(simple_tests[0]); i++) > + { > + char c_buffer[1024]; > + WCHAR w_buffer[1024]; Same as above, way too big. > + int len; > + > + c_buffer[sizeof(c_buffer) - 1] = 0; > + w_buffer[sizeof(w_buffer) / sizeof(WCHAR) - 1] = 0; It probably makes more sense to initialize the buffers before each test, instead of one time at the beginning. > + > + /* test string conversion with srclen=-1 */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, c_buffer, sizeof(c_buffer), NULL, NULL); > + if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + { > + skip("UTF-7 encoding not implemented\n"); > + return; > + } At my opinion it would be better to do one basic test at the beginning, and then abort immediately, instead of doing that inside of the for loop, if its not too complicated. > + ok(len == simple_tests[i].utf7_len && > + strcmp(c_buffer, simple_tests[i].utf7) == 0 && > + c_buffer[len] == '#', > + "simple_test failure i=%i dst=\"%s\" len=%i\n", i, c_buffer, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); > + > + /* test string conversion with srclen=-2 */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -2, c_buffer, sizeof(c_buffer), NULL, NULL); > + ok(len == simple_tests[i].utf7_len && > + strcmp(c_buffer, simple_tests[i].utf7) == 0 && > + c_buffer[len] == '#', > + "simple_test failure i=%i dst=\"%s\" len=%i\n", i, c_buffer, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); You are testing a lot of things in a single ok(...) block. It will be very difficult to find out whats wrong if we get test failures in the future. I think it would be better to split that into multiple checks, probably with some more meaningful message about what is wrong (wrong len, wrong content, ...) > + > + /* test string conversion with dstlen=len-1 */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, c_buffer, simple_tests[i].utf7_len - 1, NULL, NULL); > + ok(len == 0 && > + memcmp(c_buffer, simple_tests[i].utf7, simple_tests[i].utf7_len - 1) == 0 && > + c_buffer[simple_tests[i].utf7_len - 1] == '#', > + "simple_test failure i=%i dst=\"%s\" len=%i\n", i, c_buffer, len); > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "error=%x\n", GetLastError()); > + > + /* test string conversion with dstlen=len */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, c_buffer, simple_tests[i].utf7_len, NULL, NULL); > + ok(len == simple_tests[i].utf7_len && > + strcmp(c_buffer, simple_tests[i].utf7) == 0 && > + c_buffer[len] == '#', > + "simple_test failure i=%i dst=\"%s\" len=%i\n", i, c_buffer, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); > + > + /* test string conversion with dstlen=len+1 */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, c_buffer, simple_tests[i].utf7_len + 1, NULL, NULL); > + ok(len == simple_tests[i].utf7_len && > + strcmp(c_buffer, simple_tests[i].utf7) == 0 && > + c_buffer[len] == '#', > + "simple_test failure i=%i dst=\"%s\" len=%i\n", i, c_buffer, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); > + > + /* test dry run with dst=NULL and dstlen=0 */ > + memset(c_buffer, '#', sizeof(c_buffer)); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, NULL, 0, NULL, NULL); > + ok(len == simple_tests[i].utf7_len && > + c_buffer[0] == '#', > + "simple_test failure i=%i len=%i\n", i, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); > + > + /* test dry run with dst!=NULL and dstlen=0 */ > + memset(c_buffer, '#', sizeof(c_buffer) - 1); > + SetLastError(0xdeadbeef); > + len = WideCharToMultiByte(CP_UTF7, 0, simple_tests[i].utf16, -1, c_buffer, 0, NULL, NULL); > + ok(len == simple_tests[i].utf7_len && > + c_buffer[0] == '#', > + "simple_test failure i=%i len=%i\n", i, len); > + ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); > + > + /* all simple utf16-to-utf7 tests can be reversed to make utf7-to-utf16 tests */ > + memset(w_buffer, '#', sizeof(w_buffer) - sizeof(WCHAR)); > + SetLastError(0xdeadbeef); > + len = MultiByteToWideChar(CP_UTF7, 0, simple_tests[i].utf7, -1, w_buffer, sizeof(w_buffer) / sizeof(WCHAR)); > + todo_wine ok(len == simple_tests[i].utf16_len && > + memcmp(w_buffer, simple_tests[i].utf16, len * sizeof(WCHAR)) == 0 && > + w_buffer[len] == 0x2323, > + "simple_test failure i=%i dst=%s len=%i\n", i, wine_dbgstr_w(w_buffer), len); > + todo_wine ok(GetLastError() == 0xdeadbeef, "error=%x\n", GetLastError()); Why do you use todo_wine when the whole test block is skipped? Moreover, it should probably go into the later patches which add the MultibyteToWideChar tests. > + } > +} > + > static void test_undefined_byte_char(void) > { > static const struct tag_testset { > @@ -618,6 +750,8 @@ START_TEST(codepage) > test_string_conversion(NULL); > test_string_conversion(&bUsedDefaultChar); > > + test_utf7_encoding(); > + > test_undefined_byte_char(); > test_threadcp(); > } >

1 0

Re: [2/2] oleaut32: Implement TLB dependencies lookup in resources (resend 3 - last submit before abandon)
by Andrew Eikum Oct. 29, 2014

Oct. 29, 2014

On Sat, Sep 27, 2014 at 08:10:28PM +0200, Guillaume Charifi wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34184 > > This is the last time without a review before I give up. > I'm not sure why this is hung up, but to reiterate, it seems acceptable to me. Andrew

1 0

Re: [PATCH 1/6] reg: Sanitize key paths in main
by Stefan Dösinger Oct. 29, 2014

Oct. 29, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch is a lot more readable than the past version IMO. I'll look at the other patches tomorrow. Am 2014-10-27 13:10, schrieb Jonathan Vollebregt: > +static WCHAR *sanitize_path(WCHAR *key){ Inconsistent curly bracket placement. The other patches have more cases of that. > + else > + reg_message(STRING_INVALID_KEY); Doesn't get_rootkey() implicitly take care of this? I don't see why you need an extra check for a single leading backslash. There's one (intended?) side effect of this check though: It ensures that the code below doesn't crash on the input string "\\". > + i = strlenW(key); > + if (key[i - 1] == '\\') > + key[i - 1] = 0; Why do you need this? The existing code and the todo_wine test suggests that RegCreateKey accepts any number of trailing slashes. Adding a test for this in dlls/advapi32/tests/registry.c would be a good idea. This is the only case where you modify the input string. If it indeed is not necessary you can change the parameter to a const WCHAR * and return a BOOL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUTs1oAAoJEN0/YqbEcdMw0rsP/3XocRwBZ2zPgs/0ERHMOL0q 84+09LlpOMMBzEQDue4WnxLgNwT6EUdP1W+CpMLtjdh6r35qePWRuHwrieuRoKsF 7SoZhAqB1XGfSTfHC5yaSlC3a3didsGn8wCvb9R66wFcBstWY+wW9cdnyUzRhXeK oowmLBioiKlWGHBX84k7pvxLEzokeW+yEj0D/NXaVeFJ5ATfsqRynIiMJOeMJzJj XcnrH9YBDzvOy36zSREclwEtwt73dZ9dRYiLO4fHaaqsBMM0xiuZYl5CkfUxGjtm /c33mOOUl4l9EEpQLdu6kMtrT6kF13XbT2ume0AcqTbL4KrJVl7j173wck0vt1e7 kaLS1ViU4TGxHHo7mkqfMUjDpJM1tR5etV9DqQGQYui+BQ1ZOTpISrmuFxbXPAOd ecwvZGXEePGWrZlsV4lECc25/1BJQfEpxKK/5pc6fTv0TYd+JGOOnOSlTR9xlOSW rs/mjTuedQDNIFr+RvfMK+OpJIXXA9ve0jkpDX0XLnl3lZWG0p+rGholQXwHC5VS 1YUucH8moIW/8kN1s39/RSzcBgkxvAEDgiFsIigYqyEnPpafTbSQn3rNIVD5DQ0X +Fy7gBffr+uaOSKAh8ShdMGvRFGipd4WNQTelemCVcD1Pku2X01ImBImyHeMxBzW 2JdXxGTtZT8PribxigHn =eTay -----END PGP SIGNATURE-----

2 6

Re: [1/2] ndis.sys: add a stub dll
by Alistair Leslie-Hughes Oct. 29, 2014

Oct. 29, 2014

Hi Austin, On 29/10/14 06:10, Austin English wrote: > > -- > -Austin This file should be installed into the system32\drivers directory by default. Modify wine.in.inf, look for mountmgr.sys as an example. Best Regards Alistair Leslie-Hughes

2 1

Re: [PATCH] mshtml: check null before release the elem object
by Jacek Caban Oct. 29, 2014

Oct. 29, 2014

Hi Hao, On 10/24/14 11:37, Hao Peng wrote: > Check null pointer before release the script elem object, prevent to > release them twice. The real problem is that stop_binding is called twice. I sent a patch fixing that. Jacek

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByName (try 2 - resend)
by Stefan Dösinger Oct. 29, 2014

Oct. 29, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-29 05:26, schrieb Alistair Leslie-Hughes: > + switch (entry->type) + { + > case DPNA_DATATYPE_DWORD: + memcpy(pvBuffer, > &entry->data.value, sizeof(DWORD)); + break; + > case DPNA_DATATYPE_GUID: + memcpy(pvBuffer, > &entry->data.guid, sizeof(GUID)); + break; + > case DPNA_DATATYPE_STRING: + memcpy(pvBuffer, > &entry->data.string, entry->size); + break; + > case DPNA_DATATYPE_STRING_ANSI: + > memcpy(pvBuffer, &entry->data.ansi, entry->size); + > break; + case DPNA_DATATYPE_BINARY: + > memcpy(pvBuffer, &entry->data.binary, entry->size); + > break; + } Using assignments like in AddComponent would be nicer. Since you're replacing everything but the function declaration you can rename the parameter names to get rid of the lpFoo names. The string types need some tests for the terminating 0 character. AddComponent currently does not check if the string length matches the input size. (It doesn't overflow though since it allocates according to the string length.) > + size = sizeof(GUID)-1; + hr = > IDirectPlay8Address_GetComponentByName(localaddr, UNKNOWN, > &compguid, &size, &type); + ok(hr == DPNERR_BUFFERTOOSMALL, > "got 0x%08x\n", hr); + ok(size == sizeof(GUID), "got %d > expected %d\n", size, sizeof(GUID)); Does it return DPNERR_BUFFERTOSMALL if pvBuffer is NULL? The d3d private data API returns D3D_OK in this case. This is worth a check. Does GetComponentByName correct the size downward when *pdwBufferSize > size? Also test this with pvBuffer != NULL Your implementation suggests pdwDataType is only set if the buffer has an appropriate size. Is this the case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUUPfSAAoJEN0/YqbEcdMwlBoP/jL3jPsPavfF4iQEr/fKe5y3 HLT67L/yqgriTCo4soOECoa+9fh9+8YFvBKrDvN7ISpZyni+paK38kxifAtwR0Xl QB7yrk3x+TVvIy8f3+QxwbqI7b/CX6AxEYcXG7Y30QNZchw+qN396HOs8XPU+HCG umYrNcnknizbASMQwkl0vaoZgun0JJP3L1jSEFnuLSZkl3f9CTIq5exS3q+ndqn7 0P0iqvo1CI1Pry/5qQGCYYxKqoFRfrqKbF0q1kGcImnwjpz211iuEQyVo23UICVI 0iMX1X2KueFQ4r9QrzRJmo+/8H5PpKsEQrWlhdBZyhhOX6m3BMxOrQK9/7OIzpua l8cYkrKpLCgMsvhF5hZchX1CY5ZomFdhOjFAQldYCpSVHuupnFqOPXx2qqmjGzU3 38h/liv4VgHLvpckLgvjsD8SGqtkBH/nk4WTk50fzWupegtLqnQ1gxILTNuh+e9Y kX4PWcMbbMQ6t1rjrdjBz4hDX/wAF44vx4NDLnht59aV3of9xtKfVWW8SFV9il40 2WDPhHESojF8BU/Nt/qx70YokSPIqpmwXdg1RQPXi5FNj2W5uqZoGCxCTeFfnY60 a68+EOaZaQhdSW5VSjGGWprs9jfBN4wB5SPoUU24adu5ygjcUsGj3IHj9H6ssBPN vwscAjUYyZDTzkgRQYAE =OHT3 -----END PGP SIGNATURE-----

1 1

Re: dplayx: Fix some crashes and wine_todo's ( try 2)
by Stefan Dösinger Oct. 29, 2014

Oct. 29, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-29 06:13, schrieb Alistair Leslie-Hughes: > hr = IDirectPlayX_InitializeConnection( pDP, pAddress, 0 ); > - todo_wine checkHR( DP_OK, hr ); > + checkHR( DP_OK, hr ); Apparently running those tests only in interactive mode caused quite a bit of bitrot :-\ . According to ab448df3 the tests were too slow. Is this still the case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUUPlaAAoJEN0/YqbEcdMwYHsP/jwHawWB1Y+iGVlg+fT56yaI kYJ5knxAn2JaLwPB9DVyt2JRMG2SqvWmS0glqKfOVvWR8RFOGzUL/S1nS0H1VpgD drKtxFJFq1KOYFsgsBxHZdvsPnlayB/GXwAmIRXn6rI4rvkvuWDM2q7ovM9ZNsW+ 0zgiV5z9JMMiC/UOVedS4WF5ScoHjJfwW6S9bk4KAWltaybDFQA1Txo4OT+wpW0t 34p+GOB8uAoqqpyzONA5O2MpOdtodhFT03++6FLU3Y26+pyeKDqMP+TpX3MTRB70 JwIk09OBxSlqHjKUiU/4shd4bFSY0Pf/yzGpvFEsXTDHlcodvpBEHMKQj+8RXqqL PglmiK/Xy1J4OmrDmrTRMuGn/FmD1Mkj4WfQTsZ17ODHcubRlVhdNxsHqgDZDEVB krHYGcAJ5t6ZjVnM8m7uGLyvyJbsMeefHiR1+SFHi1VyBJnlD6Iu+osDQPKRSDK7 vcMciPMuXI0e3UUIzf5Kuz0gXDHdWuNerMI8j+6s3hyjc4zQnSd4GRL3fKV0GQOv lMEYS9DiF9ESUhjqC/9NFb233sbPmxabkVaoA+9C6vXgDdDhbE2rAQ75HFDoXh52 856Mq5tMuQQVFaZxHVd0A8bArNlb1ZLksuN02b5bo/q4Q0mN7oJEjxybgSxuHKAd yODcTxiiPmIVo1IWzKYJ =wqXw -----END PGP SIGNATURE-----

1 0