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

Re: [PATCH] advapi32/tests: Simplify tests using todo_wine_if()
by Marvin Feb. 11, 2016

Feb. 11, 2016

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=20371 Your paranoid android. === w1064 (32 bit security) === security.c:3753: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:3794: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:3798: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:3807: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0)

1 0

GSoC Ideas page
by André Hentschel Feb. 11, 2016

Feb. 11, 2016

Hi, please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Some things can be dropped I think, OpenMP maybe? Thanks!

5 5

Re: [PATCH 1/2] wpcap: Implement pcap_dump_open and pcap_dump(try 2)
by Sebastian Lackner Feb. 11, 2016

Feb. 11, 2016

I'm not the maintainer of wpcap, nevertheless I hope its fine to give some suggestions how to improve the code. On 11.02.2016 09:55, Jianqiu Zhang wrote: > From 770a1250794833aa7d9a9596a7fc56bfc19c65f0 Mon Sep 17 00:00:00 2001 > From: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > Date: Thu, 29 Oct 2015 15:33:28 +0800 > Subject: [PATCH 1/2] wpcap: Implement pcap_dump_open and pcap_dump > > Signed-off-by: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > --- > dlls/wpcap/wpcap.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/wpcap/wpcap.spec | 4 ++-- > 2 files changed, 56 insertions(+), 2 deletions(-) > > diff --git a/dlls/wpcap/wpcap.c b/dlls/wpcap/wpcap.c > index ae9e482..e03e18e 100644 > --- a/dlls/wpcap/wpcap.c > +++ b/dlls/wpcap/wpcap.c > @@ -22,6 +22,8 @@ > #include "winsock2.h" > #include "windef.h" > #include "winbase.h" > +#include "winternl.h" > +#include "ntstatus.h" > #include "wine/debug.h" > > WINE_DEFAULT_DEBUG_CHANNEL(wpcap); > @@ -40,6 +42,8 @@ WINE_DECLARE_DEBUG_CHANNEL(winediag); > #define PCAP_SRC_IFLOCAL 3 > #endif > > +#define MAX_LENGTH 1024 In this case copying is not necessary at all. In other cases you would want to use MAX_PATH instead of own definitions. > + > void CDECL wine_pcap_breakloop(pcap_t *p) > { > TRACE("(%p)\n", p); > @@ -339,3 +343,53 @@ int CDECL wine_wsockinit(void) > if (WSAStartup(MAKEWORD(1,1), &wsadata)) return -1; > return 0; > } > + > +pcap_dumper_t* CDECL wine_pcap_dump_open(pcap_t *p, const char *fname) > +{ > + UNICODE_STRING nt_name, dospathW; > + ANSI_STRING fname_dos; > + ANSI_STRING fname_unix; > + CHAR fpath[MAX_LENGTH] = { 0 }; You don't need this char array (see comment below). > + NTSTATUS res; Not really critical, but "status" is often a bit more meaningful. > + TRACE("(%p %s)\n", p, fname); > + RtlInitAnsiString(&fname_dos, fname); > + res = RtlAnsiStringToUnicodeString(&dospathW, &fname_dos, TRUE); > + if(res) Minor issue, but the coding style in this file seems to be with a space between "if" and "(". > + { > + SetLastError(RtlNtStatusToDosError(res)); > + return NULL; > + } > + if(!RtlDosPathNameToNtPathName_U(dospathW.Buffer, &nt_name, NULL, NULL)) > + { > + RtlFreeUnicodeString(&dospathW); > + SetLastError(ERROR_FILENAME_EXCED_RANGE); Basically all places in wine use ERROR_PATH_NOT_FOUND in this case. > + return NULL; > + } > + res = wine_nt_to_unix_file_name(&nt_name, &fname_unix, FILE_OPEN_IF, FALSE); > + if(res) > + { > + if(res == STATUS_NO_SUCH_FILE) > + SetLastError(ERROR_SUCCESS); Setting error code in case of success is not useful. > + else > + { > + RtlFreeUnicodeString(&dospathW); > + RtlFreeUnicodeString(&nt_name); > + SetLastError(RtlNtStatusToDosError(res)); > + return NULL; > + } > + } > + else > + { > + SetLastError(ERROR_FILE_EXISTS); Similar to above, we don't care about the error code in case of success. > + } > + memcpy(fpath, fname_unix.Buffer, fname_unix.Length); > + RtlFreeUnicodeString(&nt_name); > + RtlFreeUnicodeString(&dospathW); > + RtlFreeAnsiString(&fname_unix); > + return pcap_dump_open(p, fpath); Instead of copying the string, please store the return value of pcap_dump_open in a variable. > +} > + > +void CDECL wine_pcap_dump(u_char *user, const struct pcap_pkthdr *h, const u_char *sp) > +{ > + return pcap_dump(user, h, sp); > +} > diff --git a/dlls/wpcap/wpcap.spec b/dlls/wpcap/wpcap.spec > index 66303b4..541fc49 100644 > --- a/dlls/wpcap/wpcap.spec > +++ b/dlls/wpcap/wpcap.spec > @@ -16,12 +16,12 @@ > @ cdecl pcap_datalink_val_to_description(long) wine_pcap_datalink_val_to_description > @ cdecl pcap_datalink_val_to_name(long) wine_pcap_datalink_val_to_name > @ cdecl pcap_dispatch(ptr long ptr ptr) wine_pcap_dispatch > -@ stub pcap_dump > +@ cdecl pcap_dump(ptr ptr ptr) wine_pcap_dump > @ stub pcap_dump_close > @ stub pcap_dump_file > @ stub pcap_dump_flush > @ stub pcap_dump_ftell > -@ stub pcap_dump_open > +@ cdecl pcap_dump_open(ptr str) wine_pcap_dump_open > @ stub pcap_file > @ stub pcap_fileno > @ cdecl pcap_findalldevs(ptr ptr) wine_pcap_findalldevs > > > >

1 0

Re: [v2 PATCH] user32/text: Show Color message isn't send during startup
by Alexandre Julliard Feb. 11, 2016

Feb. 11, 2016

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -214,6 +218,12 @@ static INT_PTR CALLBACK edit_dialog_proc(HWND hdlg, UINT msg, WPARAM wparam, LPA > PostMessageA(hdlg, WM_USER, 0xdeadbeef, 2); > break; > > + /* Set Text During startup */ > + case 11: > + SendMessageA(hok, WM_SETTEXT, 0, (WPARAM)"Testing"); > + PostMessageA(hdlg, WM_USER, 0xdeadbeef, 2); > + break; Why are you setting the text on a button, and not touching the edit control? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] msvcp110: Add tr2_sys__Symlink implementation and test.
by Piotr Caban Feb. 11, 2016

Feb. 11, 2016

On 01/11/16 14:56, YongHao Hu wrote: > + delete_flag = 1; > + for(i=0; i<sizeof(tests)/sizeof(tests[0]); i++) { > + errno = 0xdeadbeef; > + SetLastError(0xdeadbeef); > + ret = p_tr2_sys__Symlink(tests[i].existing_path, tests[i].new_path); > + if(ret==ERROR_PRIVILEGE_NOT_HELD || ret==ERROR_INVALID_FUNCTION) { > + delete_flag = 0; > + tests[i].last_error = ret; > + win_skip("Privilege not held or symbolic link not supported, skipping symbolic link tests.\n"); I think it would be nicer if the tests are really skipped in this case. Please detect such case and return from the function instead of adding workarounds in the code for it. Thanks, Piotr

2 3

Re: [PATCH 1/2] wpcap: Implement pcap_dump_open and pcap_dump
by André Hentschel Feb. 11, 2016

Feb. 11, 2016

Hi, Sorry for the delay, but I haven't noticed that I got assigned for reviewing. Could you please tell me the name of the application so I can do some testing? Further reviewing inlined below: Am 07.01.2016 um 09:49 schrieb Jianqiu Zhang: > + > +pcap_dumper_t* CDECL wine_pcap_dump_open(pcap_t *p, const char *fname) > +{ > + return pcap_dump_open(p, fname); > +} This can't work, the wpcap function might be called with fname set to "C:\dump.pcap" and the native function will be confused by that. > +void CDECL wine_pcap_dump(u_char *user, const struct pcap_pkthdr *h, const u_char *sp) > +{ > + return pcap_dump(user, h, sp); > +} This should work, but where are pcap_dump_close and friends? > diff --git a/dlls/wpcap/wpcap.spec b/dlls/wpcap/wpcap.spec > index 0e1e208..d7efd5e 100644 > --- a/dlls/wpcap/wpcap.spec > +++ b/dlls/wpcap/wpcap.spec > @@ -16,12 +16,12 @@ > @ cdecl pcap_datalink_val_to_description(long) wine_pcap_datalink_val_to_description > @ cdecl pcap_datalink_val_to_name(long) wine_pcap_datalink_val_to_name > @ cdecl pcap_dispatch(ptr long ptr ptr) wine_pcap_dispatch > -@ stub pcap_dump > +@ cdecl pcap_dump(str ptr str) wine_pcap_dump Should be (ptr ptr ptr), there are no strings to be displayed

3 9

Re: [PATCH] user32/tests: Simplify some tests using todo_wine_if()
by Marvin Feb. 11, 2016

Feb. 11, 2016

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=20354 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2499: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2499: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2 === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different === w2008s64 (32 bit win) === win.c:8627: Test failed: Expected foreground window 00020078, got 00030040

1 0

Re: [PATCH] gdi32/tests: Simplify tests using todo_wine_if()
by Marvin Feb. 11, 2016

Feb. 11, 2016

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=20353 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [3/3] advapi32/tests: Add tests for Win8 pseudo handles.
by Marvin Feb. 11, 2016

Feb. 11, 2016

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=20338 Your paranoid android. === w1064 (32 bit security) === security.c:3774: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:3815: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:3819: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:3828: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0)

2 1

Re: [PATCH 5/7] wined3d: Copy channel info for typed formats from typeless formats.
by Henri Verbeet Feb. 10, 2016

Feb. 10, 2016

On 10 February 2016 at 02:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1436,8 +1408,7 @@ static inline int getFmtIdx(enum wined3d_format_id format_id) > { > /* First check if the format is at the position of its value. > * This will catch the argb formats before the loop is entered. */ > - if (format_id < (sizeof(formats) / sizeof(*formats)) > - && formats[format_id].id == format_id) > + if (format_id < ARRAY_SIZE(formats) && formats[format_id].id == format_id) > { > return format_id; > } > @@ -1445,10 +1416,10 @@ static inline int getFmtIdx(enum wined3d_format_id format_id) > { > unsigned int i; > > - for (i = 0; i < (sizeof(formats) / sizeof(*formats)); ++i) > - { > + for (i = 0; i < ARRAY_SIZE(formats); ++i) > if (formats[i].id == format_id) return i; > - } > + for (i = 0; i < ARRAY_SIZE(typed_formats); ++i) > + if (typed_formats[i].id == format_id) return ARRAY_SIZE(formats) + i; > } > return -1; > } I'm not sure this is really the way to go. I'd prefer to just reorder things in such a way that the format id is the index in all cases except for FourCC formats. Patch 7/7 goes a long way in that direction, but to me it looks more complicated than just having a small table to remap the FourCC formats to an index. One additional advantage would be that we could then also remap e.g. DXT2 and DXT3 to BC2. E.g.: struct { enum wined3d_format_id id; unsigned int idx; } remap[] = { {UYVY, FOURCC_BASE} {YUY2, FOURCC_BASE + 1} {YV12, FOURCC_BASE + 2} {DXT1, BC1}, {DXT2, BC2}, {DXT3, BC2}, {DXT4, BC3}, {DXT5, BC3}, };

2 2

Re: [PATCH 7/7] wined3d: Use format id as index in formats table whenever possible.
by Henri Verbeet Feb. 10, 2016

Feb. 10, 2016

On 10 February 2016 at 02:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/wined3d/utils.c | 182 +++++++++++++++++++++++++++++++-------------------- > 1 file changed, 110 insertions(+), 72 deletions(-) > For what it's worth, I think there are a number of places that could just use wined3d_get_format(). If you did that as a separate patch before this one, this one could be a bit smaller.

1 0

Re: [PATCH 4/7] wined3d: Introduce table with typed format channels.
by Henri Verbeet Feb. 10, 2016

Feb. 10, 2016

On 10 February 2016 at 02:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +enum wined3d_channel_type > +{ > + C_UNUSED, > + C_UNORM, > + C_SNORM, > + C_UINT, > + C_SINT, > + C_FLOAT, > + C_DEPTH, > + C_STENCIL > +}; These would need to be called something like WINED3D_CHANNEL_TYPE_UNORM, etc. Those are a bit longer to type, but we could use a scheme similar to the opcode table in shader_sm4.c to keep the table readable. (Perhaps "I" -> SINT, "i" -> SNORM, "S" -> STENCIL, etc.) > +struct wined3d_typed_format_info > { > enum wined3d_format_id id; > enum wined3d_format_id typeless_id; > + enum wined3d_channel_type red_channel; > + enum wined3d_channel_type green_channel; > + enum wined3d_channel_type blue_channel; > + enum wined3d_channel_type alpha_channel; > }; Just a thought, but would it make things easier if the channel types were an array? It would probably make sense for struct wined3d_format at least to have something like struct { unsigned int size; unsigned int offset; enum wined3d_channel_type type; } channels[4];

1 0

Re: [PATCH 3/7] wined3d: Add remaining sRGB formats.
by Henri Verbeet Feb. 10, 2016

Feb. 10, 2016

On 10 February 2016 at 02:14, Józef Kucia <jkucia(a)codeweavers.com> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index df95da9..f314af3 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -214,6 +214,13 @@ enum wined3d_format_id > WINED3DFMT_B5G5R5A1_UNORM, > WINED3DFMT_B8G8R8A8_UNORM, > WINED3DFMT_B8G8R8X8_UNORM, > + WINED3DFMT_B8G8R8A8_TYPELESS, > + WINED3DFMT_B8G8R8A8_UNORM_SRGB, > + WINED3DFMT_B8G8R8X8_TYPELESS, > + WINED3DFMT_B8G8R8X8_UNORM_SRGB, > + WINED3DFMT_BC7_TYPELESS, > + WINED3DFMT_BC7_UNORM, > + WINED3DFMT_BC7_UNORM_SRGB, Not an issue with this patch per se, but note that these aren't actually usable by anything until you update the conversion functions in dxgi and d3d11. (And I notice debug_dxgi_format() is missing a few formats as well.)

1 0

Re: ntdll: Skip unused import descriptors when loading libraries.
by Alexandre Julliard Feb. 10, 2016

Feb. 10, 2016

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -901,7 +901,18 @@ static NTSTATUS fixup_imports( WINE_MODREF *wm, LPCWSTR load_path ) > status = STATUS_SUCCESS; > for (i = 0; i < nb_imports; i++) > { > - if (!(wm->deps[i] = import_dll( wm->ldr.BaseAddress, &imports[i], load_path ))) > + const IMAGE_IMPORT_DESCRIPTOR *descr = &imports[i]; > + const IMAGE_THUNK_DATA *import_list = get_rva( wm->ldr.BaseAddress, descr->u.OriginalFirstThunk ? > + (DWORD)descr->u.OriginalFirstThunk : (DWORD)descr->FirstThunk ); > + if (!import_list->u1.Ordinal) I feel it would be cleaner to do these checks inside import_dll(). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] winebuild: When building implibs, invoke dlltool with a machine type. (try 2)
by Alexandre Julliard Feb. 10, 2016

Feb. 10, 2016

Charles Davis <cdavis5x(a)gmail.com> writes: > That way, if the installed MinGW toolchain is multilib enabled (as mine > is), the import libraries will get built for the correct architecture. > > Try 2: Correct machine name for x86-64. I'm afraid this doesn't work either: /usr/bin/x86_64-w64-mingw32-dlltool: Machine 'x86-64' not supported winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 The help says: -m --machine <machine> Create as DLL for <machine>. [default: i386:x86-64] possible <machine>: arm[_interwork], i386, mcore[-elf]{-le|-be}, ppc, thumb -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10: ScriptPlace should honour the fZeroWidth attribute.
by Marvin Feb. 10, 2016

Feb. 10, 2016

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=20325 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1437: Test failed: 0: uJustification incorrect (0) usp10.c:1437: Test failed: 1: uJustification incorrect (0) usp10.c:1437: Test failed: 2: uJustification incorrect (0) usp10.c:1437: Test failed: 3: uJustification incorrect (0) usp10.c:1437: Test failed: 4: uJustification incorrect (0) usp10.c:1437: Test failed: 5: uJustification incorrect (0) usp10.c:1437: Test failed: 6: uJustification incorrect (0) usp10.c:1437: Test failed: 7: uJustification incorrect (0) usp10.c:1437: Test failed: 8: uJustification incorrect (0) usp10.c:1437: Test failed: 9: uJustification incorrect (0) usp10.c:1453: Test failed: 3: uJustification incorrect (0) usp10.c:1453: Test failed: 5: fDiacritic incorrect (1) usp10.c:1453: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1453: Test failed: 15: fDiacritic incorrect (1) usp10.c:1453: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: ntdll/tests: Simplify exception tests by using todo_wine_if.
by Marvin Feb. 10, 2016

Feb. 10, 2016

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=20310 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:485: Test failed: 42: Wrong exception address 77BAED97/003C0001 === w7u (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003F0000/003F0001 exception: unhandled exception 80000004 at 003F0000 exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/003F0001 === w1064 (32 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === w1064 (64 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

2 1

Re: wlanapi: add a stub for WlanEnumInterfaces
by Sebastian Lackner Feb. 10, 2016

Feb. 10, 2016

Hiho Austin, here some feedback on the patch as inline comments: On 05.02.2016 06:19, Austin English wrote: > Should fix https://bugs.winehq.org/show_bug.cgi?id=40034. Unfortunately, > the user is having issues building wine, and there's no download to verify > myself.. > > > attachment.txt > > > From 060d3427b61058fe7dc4da447743008d030da331 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Sun, 24 Jan 2016 20:18:24 -0600 > Subject: [PATCH] wlanapi: add WlanOpenHandleFunction stub > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/wlanapi/main.c | 8 ++++++++ > dlls/wlanapi/wlanapi.spec | 2 +- > include/wlanapi.h | 36 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 45 insertions(+), 1 deletion(-) > create mode 100644 include/wlanapi.h > > diff --git a/dlls/wlanapi/main.c b/dlls/wlanapi/main.c > index 0b0d100..cba9864 100644 > --- a/dlls/wlanapi/main.c > +++ b/dlls/wlanapi/main.c > @@ -24,6 +24,8 @@ > #include "winbase.h" > #include "wine/debug.h" > > +# include "wlanapi.h" Why is there a space between "#" and include? > + > WINE_DEFAULT_DEBUG_CHANNEL(wlanapi); > > DWORD WINAPI WlanOpenHandle(DWORD clientVersion, PVOID reserved, > @@ -49,3 +51,9 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > > return TRUE; > } I would suggest to add your implementation above, below the other Wlan* functions. > + > +DWORD WINAPI WlanEnumInterfaces(HANDLE client, void *reserved, WLAN_INTERFACE_INFO_LIST *interface_list) MSDN says the second argument is a double-pointer. > +{ > + FIXME("%p, %p, %p) stub\n",client, reserved, interface_list); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > \ No newline at end of file > diff --git a/dlls/wlanapi/wlanapi.spec b/dlls/wlanapi/wlanapi.spec > index 79f9e43..22264c5 100644 > --- a/dlls/wlanapi/wlanapi.spec > +++ b/dlls/wlanapi/wlanapi.spec > @@ -3,7 +3,7 @@ > @ stub WlanConnect > @ stub WlanDeleteProfile > @ stub WlanDisconnect > -@ stub WlanEnumInterfaces > +@ stdcall WlanEnumInterfaces(ptr ptr ptr) HANDLEs should be specified as "long" in spec files. > @ stub WlanExtractPsdIEDataList > @ stub WlanFreeMemory > @ stub WlanGetAvailableNetworkList > diff --git a/include/wlanapi.h b/include/wlanapi.h > new file mode 100644 > index 0000000..15a52ac > --- /dev/null > +++ b/include/wlanapi.h > @@ -0,0 +1,36 @@ > +/* > + * Copyright (C) 2016 Austin English > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + Some header-guard wouldn't hurt. > +typedef enum _WLAN_INTERFACE_STATE { > + WLAN_INTERFACE_STATE_UNUSED, Typically all new files use 4 space indentation. Did you copy it from somewhere? Also, where are all the enum fields listed on MSDN? https://msdn.microsoft.com/en-us/library/windows/desktop/ms706877(v=vs.85).… > +} WLAN_INTERFACE_STATE; > + > +typedef struct _WLAN_INTERFACE_INFO { > + GUID InterfaceGuid; > + WCHAR strInterfaceDescription[256]; > + WLAN_INTERFACE_STATE isState; > +} WLAN_INTERFACE_INFO, *PWLAN_INTERFACE_INFO; > + > +typedef struct _WLAN_INTERFACE_INFO_LIST { > + DWORD dwNumberOfItems; > + DWORD dwIndex; > + WLAN_INTERFACE_INFO InterfaceInfo[1]; > +} WLAN_INTERFACE_INFO_LIST, *PWLAN_INTERFACE_INFO_LIST; > + > +DWORD (WINAPI *WlanOpenHandleFunction)(DWORD, VOID *, DWORD *, HANDLE *); This declares a variable and doesn't belong in a header file. > +DWORD WINAPI WlanEnumInterfaces(HANDLE, VOID *, WLAN_INTERFACE_INFO_LIST *); Should also be a double-pointer here. > -- 2.7.0.rc3 > > >

1 0

Re: [v2 PATCH] include: Add IColumnsInfo interface
by Nikolay Sivov Feb. 10, 2016

Feb. 10, 2016

Now you removed size_is() completely. Why?

1 0

Re: [PATCH v2 1/7] d3d11/tests: Test creation of typeless resources.
by Dmitry Timoshkov Feb. 10, 2016

Feb. 10, 2016

Józef Kucia <jkucia(a)codeweavers.com> wrote: > + todo_wine_if(tests[i].todo) > + ok(tests[i].succeeds ? SUCCEEDED(hr) : FAILED(hr), "Test %u: Got unexpected hr %#x.\n", i, hr); Isn't an actual behaviour well defined and particular error/success codes should be used instead of generic SUCCEEDED()/FAILED()? -- Dmitry.

1 0

Running WineTest every day the easy way
by Francois Gouget Feb. 10, 2016

Feb. 10, 2016

So this time I've done things in the right order: first publish the code and then announce it. So here's wt-daily, a script to "orchestrate all the daily WineTest runs and related tasks." Here's the 'quickstart guide': git clone https://github.com/fgouget/wt-daily.git cd wt-daily vi wt-daily.config In this file set the following environment variables: email="your email address here" tag="a-tag" desc="A description of your system for Wine developers" shutdown="suspend" Then when you know you won't be needing your computer for a while, just type ./wt-daily. This will update and rebuild Wine, run the tests and finally suspend your machine. It's that simple! If you'd rather not suspend your machine you can set shutdown to "poweroff", "reboot" or even leave it out to keep the computer on. By default wt-daily will ask for your green light before starting the tests. So you can start it while still using the computer and click 'Ok' once you take off. To have the tests run automatically (e.g. from cron), pass --auto-test on the command line or set default_options="--auto-test" in the configuration file. If you have a 64-bit system then you can also set the {tag,desc}wow32 and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run the tests using the Mac driver instead of (or in addition to) X11. The script should work on OS/X though I have obviously not tested it in a long time. I'ĺl be happy to get feedback on that, particularly in the form of patches. Now you can totally stop reading here. But there's a ton more that the script can do. Read on if you want to discover more. You can have the script start an application that will prevent the tests from running until you close it. I used that to run the tests on a MythTV client box. Wine would get updated and rebuilt in the background while I was watching TV and once that was done the script would run the tests and finally power off the computer. You can also take an image of a suitably configured Windows partition and have wt-daily restore that image to the partition, reboot to Windows which will automatically run WineTest (you'll find the batch script for that in the repository), then reboot back to Linux (or shutdown the computer). This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers boxes to run the tests on Linux, then Windows 8.1 and then Windows 10. All automatically. The script actually runs every hour and skips the tests (and rebooting) if nothing changed since the last run. I also have this Windows image thing set up on my fg-acer64 laptop but there I interactively select which Windows image to restore, with a choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going through a reboot). You can also extend wt-daily to add non Wine tasks. For instance on my laptops it runs another script that synchronizes the Documents folder with my desktop and runs 'git fetch --all' in all my Git repositories. This way the next time I go offline everything is up to date. The repository also contains a number or scripts that you may find useful in your own automation tasks as they support not just Linux but OS/X too. wt-image Creates, checks, restores or reboots to a disk image. wt-bot Update, build and check the Wine source code, and run the tests. wt-make Seeks to automatically fully use CPU and I/O parallelism when running make. wt-ask Asks a simple Yes/No question to the user. wt-notify Displays a notification to the user. wt-power Powers off, reboots, suspends or hibernates the computer. wt-screensaver Controls the screensaver. In particular it can prevent it from triggering. wt-nice Runs the specified command with the lowest possible CPU and I/O priority. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

1 1

Re: [PATCH] gdi32: Fix otmfsSelection to have bold style set in case of bold simulation
by Marvin Feb. 10, 2016

Feb. 10, 2016

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=20292 Your paranoid android. === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

finalizing 64-bit mixed mode issues
by Paul Gofman Feb. 9, 2016

Feb. 9, 2016

Hi Vincent, I currently have all my cases with 64-bit mixed assemblies calling pure .Net working just fine under Wine/Mono (well, almost fine, it looks like I found a bug in Mono System.Windows.Forms cs code, but this is a separate issue), but not with vanilla ones. The following issues are not fixed upstream yet: 1. Loading 32-bit pure assemblies in 64-bit code. The patch you attached some time ago (which includes CorValidateImage implementation) works just fine for me. Do you have any plans for pushing it upstream soon? 2. Mono JIT compiler PTR/I8 issues. I've extended a bit your test case and updated the patch in the Mono bug info. While we are waiting for some reply on this in Mono maybe it is possible to send my patch for wine-mono? I am not sure that it is fully correct (it would in fact require to get familiar with the whole JIT code generation path to make sure), but I presume it is safe to use as: - the changes relate to 64-bit code generation only, 32 bit is not affected anyhow; - as for 64 bit, the changes solely extend what instruction/call parameters are considered valid for JIT code generator. If something was valid without this patch, it will not be affected. If something was invalid and gets touched by the patch incorrectly for some cases, it will likely result in segfault instead of 'invalid il code' exception in the worst case. 3. 64-bit .Net programs constantly crashing on process exit for me (this affects test case with exe and dll you sent previously as well). The crash happens in Mono GC finalizing code triggered by System.Process.Exit call from mscoree CorExitProcess. The immediate crash reason is that some objects touched by GC through its hash tables get NULL vtable pointer somewhere earlier in deinitialization. I did not find the exact reason for this yet, but looked at coree.c in Mono where they just call ExitProcess without anything else, and comment says: "FIXME: This is not currently supported by the runtime.". If I do the same in mscoree CorExitProcess it fixes the issue with crash. Do you think this is a right way to do for now? If yes I could send a patch for this. Thanks, Paul.

2 6

Re: [PATCH 1/2] gdi32: Fix otmfsSelection to have italic style set in case of oblique simulation
by Dmitry Timoshkov Feb. 9, 2016

Feb. 9, 2016

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + hdc = GetDC(0); > + hfont = CreateFontIndirectA(lf); > + ok(hfont != NULL, "failed to create a font\n"); > + > + hfont_old = SelectObject(hdc, hfont); Please avoid using GetDC(0) for all kinds of graphics tests, this may lead (inadvertently) to graphics artifacts because it's basically an eqivalent of CreateDC("display"). I'd suggest to use CreateCompatibleDC(0) instead, and create a dedicated window if painting is really desired. -- Dmitry.

2 1

Re: [PATCH 2/2] gdi32/tests: Turn some asserts in font tests into regular tests
by Marvin Feb. 9, 2016

Feb. 9, 2016

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=20287 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [PATCH 5/5] d3d11/tests: Test creation of typeless resources.
by Henri Verbeet Feb. 9, 2016

Feb. 9, 2016

On 9 February 2016 at 11:24, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + enum resource_type > + { > + rt_texture_2d, > + rt_texture_3d, > + }; > + > + static const struct > + { > + DXGI_FORMAT format; > + D3D11_BIND_FLAG bind_flags; > + enum resource_type type; Why not D3D11_RESOURCE_DIMENSION?

2 2

Re: [PATCH] winebuild: When building implibs, invoke dlltool with a machine type.
by Alexandre Julliard Feb. 9, 2016

Feb. 9, 2016

Charles Davis <cdavis5x(a)gmail.com> writes: > That way, if the installed MinGW toolchain is multilib enabled (as mine > is), the import libraries will get built for the correct architecture. This breaks the build for me: /usr/bin/x86_64-w64-mingw32-dlltool: Machine 'x86_64' not supported winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Gecko 2.44 not there yet?
by Gerald Pfeifer Feb. 9, 2016

Feb. 9, 2016

I noticed that the release notes of Wine 1.9.3 announced a "new version of the Geck engine based on Firefox 44". Alas, none of the many sf.net mirrors I tried carries http://*.dl.sourceforge.net/project/wine/Wine%20Gecko/2.44/ . The Wiki at https://wiki.winehq.org/Gecko refers to http://dl.winehq.org/wine/wine-gecko/2.40//wine_gecko-2.44-x86.msi which does not exist either. (Note 2.40 vs 2.44.) And http://sourceforge.net/projects/wine/files/Wine%20Gecko/ does not seem to carry a trace, either. Gerald

2 2

Re: [PATCH 1/5] wined3d: Add support for WINED3DFMT_R16_UINT format.
by Józef Kucia Feb. 9, 2016

Feb. 9, 2016

On Tue, Feb 9, 2016 at 10:53 AM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > struct wined3d_format_block_info > @@ -1138,6 +1139,10 @@ static const struct wined3d_format_texture_info format_texture_info[] = > WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING > | WINED3DFMT_FLAG_RENDERTARGET, > ARB_TEXTURE_RG, NULL}, > + {WINED3DFMT_R16_UINT, GL_R16UI, GL_R16UI, 0, > + GL_RED_INTEGER, GL_UNSIGNED_SHORT, 0, > + WINED3DFMT_FLAG_TEXTURE, > + WINED3D_GL_VERSION_3_0, NULL}, Actually, it should depend on ARB_TEXTURE_RG.

1 0

Re: [PATCH 2/2 v2] odbccp32: Implement SQLRemoveDriver/SQLRemoveDriverW
by Sebastian Lackner Feb. 9, 2016

Feb. 9, 2016

On 07.01.2016 08:15, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 57 ++++++++++++++++++++++++++++++++++++++++------ > dlls/odbccp32/tests/misc.c | 4 ++-- > 2 files changed, 52 insertions(+), 9 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 3d150a1..a55947b 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -1105,22 +1105,65 @@ BOOL WINAPI SQLRemoveDefaultDataSource(void) > return FALSE; > } > > -BOOL WINAPI SQLRemoveDriverW(LPCWSTR lpszDriver, BOOL fRemoveDSN, > - LPDWORD lpdwUsageCount) > +BOOL WINAPI SQLRemoveDriverW(LPCWSTR lpszDriver, BOOL removeDSN, LPDWORD usage_count) When you are refactoring code like this, please also use "const WCHAR *" and "DWORD *" instead of LP* types. Any reason why you keep the ugly name for lpszDriver? > { > + DWORD usage_cnt = 0; > + HKEY hkey; > + > clear_errors(); > - FIXME("%s %d %p\n", debugstr_w(lpszDriver), fRemoveDSN, lpdwUsageCount); > - if (lpdwUsageCount) *lpdwUsageCount = 1; > + TRACE("%s %d %p\n", debugstr_w(lpszDriver), removeDSN, usage_count); > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if (RegOpenKeyW(hkey, lpszDriver, &hkeydriver) == ERROR_SUCCESS) > + { > + if (usage_count) > + { > + if (RegGetValueA(hkeydriver, NULL, "UsageCount", RRF_RT_DWORD, NULL, &usage_cnt, NULL) == ERROR_SUCCESS) > + { > + usage_cnt--; Implementing UsageCount handling only here doesn't seem very useful. It also has to be set / updated, and depending on the result the code below should behave different. > + } > + } > + > + RegCloseKey(hkeydriver); > + } > + > + if(RegDeleteKeyW(hkey, lpszDriver) != ERROR_SUCCESS) > + ERR("Failed to delete registry key: %s\n", debugstr_w(lpszDriver)); > + > + if (RegOpenKeyW(hkey, odbcdrivers, &hkeydriver) == ERROR_SUCCESS) > + { > + if(RegDeleteValueW(hkeydriver, lpszDriver) != ERROR_SUCCESS) > + ERR("Failed to delete registry value: %s\n", debugstr_w(lpszDriver)); > + > + RegCloseKey(hkeydriver); > + } > + > + } > + > + if (usage_count) > + *usage_count = usage_cnt; > + > return TRUE; > } > > BOOL WINAPI SQLRemoveDriver(LPCSTR lpszDriver, BOOL fRemoveDSN, > LPDWORD lpdwUsageCount) > { > + WCHAR *driver; > + BOOL ret; > + > clear_errors(); > - FIXME("%s %d %p\n", debugstr_a(lpszDriver), fRemoveDSN, lpdwUsageCount); > - if (lpdwUsageCount) *lpdwUsageCount = 1; > - return TRUE; > + TRACE("%s %d %p\n", debugstr_a(lpszDriver), fRemoveDSN, lpdwUsageCount); > + > + driver = SQLInstall_strdup(lpszDriver); > + > + ret = SQLRemoveDriverW(driver, fRemoveDSN, lpdwUsageCount); > + > + HeapFree(GetProcessHeap(), 0, driver); > + return ret; > } > > BOOL WINAPI SQLRemoveDriverManager(LPDWORD pdwUsageCount) > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index 3ae1fd3..e3adffd 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c > @@ -462,12 +462,12 @@ void test_SQLInstallDriverEx(void) > cnt = 100; > ret = SQLRemoveDriver("WINE ODBC Driver", FALSE, &cnt); > ok(ret, "SQLRemoveDriver failed\n"); > - todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > + ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > > cnt = 100; > ret = SQLRemoveDriver("WINE ODBC Driver Path", FALSE, &cnt); > ok(ret, "SQLRemoveDriver failed\n"); > - todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > + ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > } > > START_TEST(misc) >

1 0

Re: [PATCH 1/2 v2] odbccp32: Implement SQLInstallDriverEx correctly
by Sebastian Lackner Feb. 9, 2016

Feb. 9, 2016

Sorry for the late reply, didn't see that this patch was assigned to me. Below is some feedback on this iteration. On 07.01.2016 08:15, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 90 +++++++++++++++++++++++++++++++++++++++++----- > dlls/odbccp32/tests/misc.c | 59 ++++++++++++++++++++++++++++++ > 2 files changed, 140 insertions(+), 9 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index bc643d4..3d150a1 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -29,6 +29,7 @@ > #include "winbase.h" > #include "winreg.h" > #include "winnls.h" > +#include "wine/unicode.h" > #include "wine/debug.h" > > #include "odbcinst.h" > @@ -38,6 +39,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(odbc); > /* Registry key names */ > static const WCHAR drivers_key[] = {'S','o','f','t','w','a','r','e','\\','O','D','B','C','\\','O','D','B','C','I','N','S','T','.','I','N','I','\\','O','D','B','C',' ','D','r','i','v','e','r','s',0}; > static const WCHAR odbcW[] = {'S','o','f','t','w','a','r','e','\\','O','D','B','C',0}; > +static const WCHAR odbcini[] = {'S','o','f','t','w','a','r','e','\\','O','D','B','C','\\','O','D','B','C','I','N','S','T','.','I','N','I','\\',0}; > +static const WCHAR odbcdrivers[] = {'O','D','B','C',' ','D','r','i','v','e','r','s',0}; > > /* This config mode is known to be process-wide. > * MSDN documentation suggests that the value is hidden somewhere in the registry but I haven't found it yet. > @@ -626,12 +629,85 @@ BOOL WINAPI SQLInstallDriver(LPCSTR lpszInfFile, LPCSTR lpszDriver, > pcbPathOut, ODBC_INSTALL_COMPLETE, &usage); > } > > +static void write_registry_values(const WCHAR *regkey, const WCHAR *driver, const WCHAR *path_in, WCHAR *path) > +{ > + static const WCHAR installed[] = {'I','n','s','t','a','l','l','e','d',0}; > + static const WCHAR slash[] = {'\\', 0}; > + static const WCHAR driverW[] = {'D','r','i','v','e','r',0}; > + static const WCHAR setupW[] = {'S','e','t','u','p',0}; > + HKEY hkey, hkeydriver; > + > + if (RegCreateKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + if (RegCreateKeyW(hkey, regkey, &hkeydriver) == ERROR_SUCCESS) > + { > + if(RegSetValueExW(hkeydriver, driver, 0, REG_SZ, (BYTE*)installed, > + (lstrlenW(installed)+1)*sizeof(WCHAR)) != ERROR_SUCCESS) > + ERR("Failed to write registry installed key\n"); I think it would be better to let SQLInstallDriverExW fail when things go wrong. > + > + RegCloseKey(hkeydriver); > + } > + > + if (RegCreateKeyW(hkey, driver, &hkeydriver) == ERROR_SUCCESS) > + { > + WCHAR entry[1024]; > + WCHAR value[MAX_PATH]; > + const WCHAR *p; > + > + /* Skip name entry */ > + p = driver; > + p += lstrlenW(p) + 1; > + > + if(!path_in) > + GetSystemDirectoryW(path, MAX_PATH); > + else > + lstrcpyW(path, path_in); If one of the registry operations above fails, path will be unset, without propagating this failure to the parent function. > + > + for (; *p; p += lstrlenW(p) + 1) > + { > + WCHAR *divider = strchrW(p,'='); > + > + if (divider) > + { > + /* Write pair values to the registry. */ > + lstrcpynW(entry, p, divider - p + 1); The size limit for entry / value could lead to buffer overflows. I'm aware that wine already contains a lot of similar issues, but usually it is recommended to avoid such design decisions for new code (unless Windows has the same limitiation). > + > + divider++; > + TRACE("Writing pair %s,%s\n", debugstr_w(entry), debugstr_w(divider)); > + > + /* Driver and Setup entries use the system path unless a path is specified. */ > + if(lstrcmpiW(driverW, entry) == 0 || lstrcmpiW(setupW, entry) == 0) > + { > + lstrcpyW(value, path); > + lstrcatW(value, slash); > + lstrcatW(value, divider); > + } > + else > + lstrcpyW(value, divider); > + > + if(RegSetValueExW(hkeydriver, entry, 0, REG_SZ, (BYTE*)value, > + (lstrlenW(value)+1)*sizeof(WCHAR)) != ERROR_SUCCESS) > + ERR("Failed to write registry data %s %s\n", debugstr_w(entry), debugstr_w(value)); > + } > + else > + { > + ERR("No pair found. %s\n", debugstr_w(p)); > + break; > + } > + } > + > + RegCloseKey(hkeydriver); > + } > + > + RegCloseKey(hkey); > + } > +} > + > BOOL WINAPI SQLInstallDriverExW(LPCWSTR lpszDriver, LPCWSTR lpszPathIn, > LPWSTR lpszPathOut, WORD cbPathOutMax, WORD *pcbPathOut, > WORD fRequest, LPDWORD lpdwUsageCount) > { > UINT len; > - LPCWSTR p; > WCHAR path[MAX_PATH]; > > clear_errors(); > @@ -639,15 +715,15 @@ BOOL WINAPI SQLInstallDriverExW(LPCWSTR lpszDriver, LPCWSTR lpszPathIn, > debugstr_w(lpszPathIn), lpszPathOut, cbPathOutMax, pcbPathOut, > fRequest, lpdwUsageCount); > > - for (p = lpszDriver; *p; p += lstrlenW(p) + 1) > - TRACE("%s\n", debugstr_w(p)); > + write_registry_values(odbcdrivers, lpszDriver, lpszPathIn, path); > > - len = GetSystemDirectoryW(path, MAX_PATH); > + len = lstrlenW(path); > > if (pcbPathOut) > *pcbPathOut = len; > > - len = GetSystemDirectoryW(path, MAX_PATH); > + if(lpdwUsageCount) > + *lpdwUsageCount = 1; This is probably fine for a first version, but usage count handling is also very important and will require various changes to the registry code (for example, checking for other matching drivers and incrementing usage count) - so I would suggest to look at this early enough to avoid huge rewrites. > > if (lpszPathOut && cbPathOutMax > len) > { > @@ -661,7 +737,6 @@ BOOL WINAPI SQLInstallDriverEx(LPCSTR lpszDriver, LPCSTR lpszPathIn, > LPSTR lpszPathOut, WORD cbPathOutMax, WORD *pcbPathOut, > WORD fRequest, LPDWORD lpdwUsageCount) > { > - LPCSTR p; > LPWSTR driver, pathin; > WCHAR pathout[MAX_PATH]; > BOOL ret; > @@ -672,9 +747,6 @@ BOOL WINAPI SQLInstallDriverEx(LPCSTR lpszDriver, LPCSTR lpszPathIn, > debugstr_a(lpszPathIn), lpszPathOut, cbPathOutMax, pcbPathOut, > fRequest, lpdwUsageCount); > > - for (p = lpszDriver; *p; p += lstrlenA(p) + 1) > - TRACE("%s\n", debugstr_a(p)); > - > driver = SQLInstall_strdup_multi(lpszDriver); > pathin = SQLInstall_strdup(lpszPathIn); > > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index 505ce1b..3ae1fd3 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c > @@ -412,6 +412,64 @@ static void test_SQLGetPrivateProfileStringW(void) > } > } > > +void test_SQLInstallDriverEx(void) > +{ > + char path[MAX_PATH]; > + char syspath[MAX_PATH]; > + WORD size = 0; > + BOOL ret, sql_ret; > + DWORD cnt, error_code = 0; > + HKEY hkey; > + DWORD reg_ret; > + > + GetSystemDirectoryA(syspath, MAX_PATH); > + > + ret = SQLInstallDriverEx("WINE ODBC Driver\0Driver=sample.dll\0Setup=sample.dll\0\0", NULL, path, MAX_PATH, &size, ODBC_INSTALL_COMPLETE, NULL); Wouldn't it make sense to check ret? Otherwise you can remove this unnecessary assignment. Also, one terminating null "\0" at the end should be sufficient because the second one is added by the compiler. > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + if (sql_ret && error_code == ODBC_ERROR_WRITING_SYSINFO_FAILED) > + { > + win_skip("not enough privileges\n"); > + return; > + } > + ok(sql_ret && error_code == SQL_SUCCESS, "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > + ok(!strcmp(path, syspath), "invalid path %s\n", path); > + > + ret = SQLInstallDriverEx("WINE ODBC Driver Path\0Driver=sample.dll\0Setup=sample.dll\0\0", "c:\\temp", path, MAX_PATH, &size, ODBC_INSTALL_COMPLETE, NULL); > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + ok(sql_ret && error_code == SQL_SUCCESS, "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > + ok(!strcmp(path, "c:\\temp"), "invalid path %s\n", path); > + > + if(ret) > + { If this code should always execute fine, you can remove the check for "ret". Otherwise, if it doesn't run on some systems, please add a win_skip(...) message. > + reg_ret = RegOpenKeyExA(HKEY_LOCAL_MACHINE, "Software\\ODBC\\ODBCINST.INI\\WINE ODBC Driver", 0, KEY_READ, &hkey); > + ok(reg_ret == ERROR_SUCCESS, "RegOpenKeyExW failed\n"); > + if (reg_ret == ERROR_SUCCESS) > + { > + DWORD type, size = MAX_PATH; > + char driverpath[MAX_PATH]; > + > + strcpy(driverpath, syspath); > + strcat(driverpath, "\\sample.dll"); > + > + reg_ret = RegGetValueA(hkey, NULL, "Driver", RRF_RT_REG_SZ, &type, &path, &size); > + ok(reg_ret == ERROR_SUCCESS, "RegGetValueA failed\n"); > + ok(!strcmp(path, driverpath), "invalid path %s\n", path); > + > + RegCloseKey(hkey); > + } > + } > + > + cnt = 100; > + ret = SQLRemoveDriver("WINE ODBC Driver", FALSE, &cnt); > + ok(ret, "SQLRemoveDriver failed\n"); > + todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > + > + cnt = 100; > + ret = SQLRemoveDriver("WINE ODBC Driver Path", FALSE, &cnt); > + ok(ret, "SQLRemoveDriver failed\n"); > + todo_wine ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > +} > + > START_TEST(misc) > { > test_SQLConfigMode(); > @@ -420,4 +478,5 @@ START_TEST(misc) > test_SQLWritePrivateProfileString(); > test_SQLGetPrivateProfileString(); > test_SQLGetPrivateProfileStringW(); > + test_SQLInstallDriverEx(); > } >

1 0

Re: [PATCH 2/7] reg: Split reg_printfW into separate functions
by Alexandre Julliard Feb. 9, 2016

Feb. 9, 2016

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > +static void __cdecl output_array(const WCHAR *fmt, ...) > +{ > + __ms_va_list va_args; > + > + __ms_va_start(va_args, fmt); > + output_formatstring(fmt, va_args); > + __ms_va_end(va_args); > } That's a strange name, why "array"? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH] msvcr120: Implement atoll, _atoll_l, _wtoll, _wtoll_l.
by Piotr Caban Feb. 8, 2016

Feb. 8, 2016

On 02/07/16 23:36, Rafał Harabień wrote: > dlls/msvcr120/msvcr120.spec | 8 ++++---- > dlls/msvcr120_app/msvcr120_app.spec | 8 ++++---- > dlls/msvcrt/string.c | 16 ++++++++++++++++ > dlls/msvcrt/wcs.c | 16 ++++++++++++++++ Please also update: dlls/api-ms-win-crt-convert-l1-1-0/api-ms-win-crt-convert-l1-1-0.spec dlls/ucrtbase/ucrtbase.spec files. > /****************************************************************** > + * _atoll_l (MSVCRT.@) Since it's not exported from MSVCRT please change the comment to "... (MSVCR120.@)" Thanks, Piotr

1 0

Re: shell32/tests: Allow the short and long forms when checking a ShellExecute() path.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20248 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1691: Test failed: WaitForSingleObject returned 258 === w1064 (32 bit shlexec) === shlexec.c:2458: Test failed: failed: rc=29 err=2 shlexec.c:2456: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2458: Test failed: failed: rc=29 err=32 shlexec.c:2458: Test failed: failed: rc=29 err=2 shlexec.c:2456: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2458: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2458: Test failed: failed: rc=29 err=2 shlexec.c:2458: Test failed: failed: rc=29 err=2 shlexec.c:2456: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2458: Test failed: failed: rc=29 err=32 shlexec.c:2470: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtA1B2.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtA1B2.tmp\test file.sde")]' shlexec.c:2458: Test failed: failed: rc=29 err=2 shlexec.c:2458: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Fix the ShellExecute() environment variable inheritance checks.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20247 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2453: Test failed: failed: rc=29 err=2 shlexec.c:2451: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2453: Test failed: failed: rc=29 err=32 shlexec.c:2453: Test failed: failed: rc=29 err=2 shlexec.c:2451: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2453: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2453: Test failed: failed: rc=29 err=2 shlexec.c:2453: Test failed: failed: rc=29 err=2 shlexec.c:2451: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2453: Test failed: failed: rc=29 err=32 shlexec.c:2465: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt87E1.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt87E1.tmp\test file.sde")]' shlexec.c:2453: Test failed: failed: rc=29 err=2 shlexec.c:2453: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Move a test_argify() check so it is run even if we could not create associations.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20246 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 shlexec.c:2454: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt5289.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt5289.tmp\test file.sde")]' shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2442: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Skip a few ShellExecute() tests when the process has insufficient privileges.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20245 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2448: Test failed: failed: rc=29 err=2 shlexec.c:2446: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2448: Test failed: failed: rc=29 err=32 shlexec.c:2448: Test failed: failed: rc=29 err=2 shlexec.c:2446: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2448: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2448: Test failed: failed: rc=29 err=2 shlexec.c:2448: Test failed: failed: rc=29 err=2 shlexec.c:2446: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2448: Test failed: failed: rc=29 err=32 shlexec.c:2460: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt477D.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt477D.tmp\test file.sde")]' shlexec.c:2448: Test failed: failed: rc=29 err=2 shlexec.c:2448: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Remove support for a todo_wine flag in ShellExecute()'s test_lnks() loop.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20244 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1683: Test failed: WaitForSingleObject returned 258 === w1064 (32 bit shlexec) === shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2433: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2435: Test failed: failed: rc=29 err=32 shlexec.c:2447: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt9F9F.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt9F9F.tmp\test file.sde")]' shlexec.c:2435: Test failed: failed: rc=29 err=2 shlexec.c:2435: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Fix a ShellExecute() race condition.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20243 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1675: Test failed: WaitForSingleObject returned 258 shlexec.c:1704: Test failed: argvA3 expected 'Open', but key not found or empty shlexec.c:1712: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDD72.tmp\test file.noassoc.shlexec', but key not found or empty shlexec.c:1704: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1712: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDD72.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtDD72.tmp\test file.noassoc.shlexec' shlexec.c:1704: Test failed: argvA3 expected 'QuotedUpperL', got 'QuotedLowerL' === w1064 (32 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2455: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt48B4.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt48B4.tmp\test file.sde")]' shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2443: Test failed: failed: rc=29 err=2

1 0

Re: shell32/tests: Fix test_dde_default_app() on Windows XP SP1.
by Marvin Feb. 8, 2016

Feb. 8, 2016

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=20242 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32 shlexec.c:2442: Test failed: failed: rc=29 err=2 shlexec.c:2440: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2442: Test failed: failed: rc=29 err=32

1 0

Re: [v2] shell32: fix two bugs in IQueryAssocations
by Nikolay Sivov Feb. 8, 2016

Feb. 8, 2016

On 08.02.2016 3:07, Theodore Dubois wrote: > >> On Feb 7, 2016, at 4:25 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> >> Why do you need this? > > So I can assert in Init. That's not necessary. > >> >>> This->hkeyProgID = This->hkeySource; >> >> I know it's not something you introduced, but it's dirty and should be >> fixed, because it leads to double free on a same handle. > > I’ll fix that in the next version. > >> Basically you remove everything, and tests don't show that you should do >> that. For example looking at Win7 registry I see HKCR\.exe with default >> value of "exefile", then default value for HKCR\exefile is Application >> (and also there is a FriendlyTypeName key that's most likely localized). >> Current code will return "Application" and that seems like a better >> candidate for a friendly name. > > In that case, hkeyProgID would refer to HKCR\exefile, and then I return the > default value from that key which is “Application”. It used to start with hkeySource > (would point to HKCR\.exe) and do some digging, but my code does that work in Init. > + if (*pszAssoc == '.') > + { > + /* for a file extension, the progid is the default value */ > + hr = ASSOC_GetValue(This->hkeySource, NULL, (void**)&progId, NULL); > + if (FAILED(hr)) > + return hr; > + } What happens if default value is not set? > + else /* if (*pszAssoc == '{') */ > + { > + assert(*pszAssoc == '{'); > + > + HKEY progIdKey; > + /* for a clsid, the progid is the default value of the ProgID subkey */ > + ret = RegOpenKeyExW(This->hkeySource, > + szProgID, > + 0, > + KEY_READ, > + &progIdKey); > + if (ret != ERROR_SUCCESS) > + return HRESULT_FROM_WIN32(ret); > + hr = ASSOC_GetValue(progIdKey, NULL, (void**)&progId, NULL); > + if (FAILED(hr)) > + return hr; > + RegCloseKey(progIdKey); > + } Now Init() will fail on missing progid subkey, and it didn't before. Also this introduces leaks. > >> A convincing test should create a custom extension key, and test all >> possible combinations of empty default values, missing keys with default >> value name etc. > > Yes, more tests is always good. I’ll try and figure out how to test things on Windows and add some more tests in the next version. > > ~Theodore >

2 1

Re: [v2] shell32: fix two bugs in IQueryAssocations
by Theodore Dubois Feb. 8, 2016

Feb. 8, 2016

> On Feb 7, 2016, at 4:25 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > > Why do you need this? So I can assert in Init. > >> This->hkeyProgID = This->hkeySource; > > I know it's not something you introduced, but it's dirty and should be > fixed, because it leads to double free on a same handle. I’ll fix that in the next version. > Basically you remove everything, and tests don't show that you should do > that. For example looking at Win7 registry I see HKCR\.exe with default > value of "exefile", then default value for HKCR\exefile is Application > (and also there is a FriendlyTypeName key that's most likely localized). > Current code will return "Application" and that seems like a better > candidate for a friendly name. In that case, hkeyProgID would refer to HKCR\exefile, and then I return the default value from that key which is “Application”. It used to start with hkeySource (would point to HKCR\.exe) and do some digging, but my code does that work in Init. > A convincing test should create a custom extension key, and test all > possible combinations of empty default values, missing keys with default > value name etc. Yes, more tests is always good. I’ll try and figure out how to test things on Windows and add some more tests in the next version. ~Theodore

1 0

Re: [PATCH 4/5] wined3d: Introduce wined3d_texture_get_overlay_position().
by Stefan Dösinger Feb. 7, 2016

Feb. 7, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-02-05 um 20:31 schrieb Henri Verbeet: > dlls/wined3d/texture.c | 32 ++++++++++++++++++++++++++++++++ I think the overlay API would be much nicer in swapchains, either textures overlaying swapchains or swapchains overlaying swapchains. Unfortunately the fact that you can assign an overlay to an offscreenplain surface makes that very difficult. A solution similar to palettes where we do most tracking in ddraw and only forward "useful" setups to wined3d might be feasible. Fwiw, the only non video player app that uses overlays that I know is settlers 3, which uses them to draw the mouse pointer if certain options are set. (Feel free to completely ignore this concern, I don't think overlays should be a side quest for CSMT...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWt33BAAoJEN0/YqbEcdMwiAoP/2uQ2ieAcs6PnFDTpwFhXMxf nYthS9pQfhmLSKPfyp69sj1QJvGLkfwtRJD4xqdu0TkJp3YMYsHIzFktT6wODcOd hqnMcN+8S0EYLFg7CYWgbwN+b+stUUzyFxML5DkLglnU6zC2nfid5Vv0h8o27o/D ySUKnSMqyhIzU5N1KL1qTaucnLYG9zW9Sgtw05zCpBZ86wy2X12ylyhRvofslqPj Cm6TPT5RPcgDw7TGSDfF1nFIp4c3nO6DIl4mWMBP6VCl+Z69Q2CqvSGBqW4ZWd3U Zs1Kae+6iF8FghwNtXx68o/gi/hcab648mA6Jc1ybnwGupv3i27/7ayQPB4Wb4R3 rx/37cJNz4FS9X5/reQJEOhoJR9wDzbBqmyctMOoMp8lOJCcpUaACdFDYvxVhvcv C4T0nMA8nmJ+uW5fgscsduEUFqPAN9QHwHDpn9AzzGVnjrpCEvFwXYFfuLZdhU9r NqMaxpyllA7S8GGuF4gmPPKopKl5C9+ZlNyTEadzhtksgZ9vqtXYbrxYaJryIMwG CPakKX5VHVP48IFxbFgzi7/0iq51njkS0BmTKc65+ZCa6bO3sVAcbu29N1UOFOYU T0XfO6PDUgljCCDLm/9+wrbpGd23yu9HQnUHcwyh41H06L1rBcun52P7PSdoC8Jh vGSx0aSmRCCBYTM9RpWi =XqoV -----END PGP SIGNATURE-----

2 1

Re: [v2] shell32: fix two bugs in IQueryAssocations
by Nikolay Sivov Feb. 7, 2016

Feb. 7, 2016

On 07.02.2016 1:09, Theodore Dubois wrote: > Basically, returns the correct value for > ASSOCSTR_FRIENDLYDOCNAME and ASSOCSTR_DEFAULTICON > when passed a ProgID instead of a file extension. > > Also adds some tests to make sure it works. > > Signed-off-by: Theodore Dubois <tblodt(a)icloud.com> > --- > dlls/shell32/assoc.c | 115 +++++++++++++++++++++++---------------------- > dlls/shell32/tests/assoc.c | 12 ++++- > 2 files changed, 70 insertions(+), 57 deletions(-) > > diff --git a/dlls/shell32/assoc.c b/dlls/shell32/assoc.c > index 90d00a8..49af3c3 100644 > --- a/dlls/shell32/assoc.c > +++ b/dlls/shell32/assoc.c > @@ -18,6 +18,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > #include <stdarg.h> > +#include <assert.h> Why do you need this? > This->hkeyProgID = This->hkeySource; I know it's not something you introduced, but it's dirty and should be fixed, because it leads to double free on a same handle. > + return S_OK; > + } > + > + /* if it's not a progid, it's a file extension or clsid */ > + if (*pszAssoc == '.') > + { > + /* for a file extension, the progid is the default value */ > + hr = ASSOC_GetValue(This->hkeySource, NULL, (void**)&progId, NULL); > + if (FAILED(hr)) > + return hr; > + } > + else /* if (*pszAssoc == '{') */ > + { > + assert(*pszAssoc == '{'); > + > + HKEY progIdKey; > + /* for a clsid, the progid is the default value of the ProgID subkey */ > + ret = RegOpenKeyExW(This->hkeySource, > + szProgID, > + 0, > + KEY_READ, > + &progIdKey); > + if (ret != ERROR_SUCCESS) > + return HRESULT_FROM_WIN32(ret); > + hr = ASSOC_GetValue(progIdKey, NULL, (void**)&progId, NULL); > + if (FAILED(hr)) > + return hr; > + RegCloseKey(progIdKey); > + } > + > + /* open the actual progid key, the one with the shell subkey */ > + ret = RegOpenKeyExW(HKEY_CLASSES_ROOT, > + progId, > + 0, > + KEY_READ, > + &This->hkeyProgID); > + if (ret != ERROR_SUCCESS) > + return HRESULT_FROM_WIN32(ret); > return S_OK; > } > else if (hkeyProgid != NULL) > @@ -507,33 +544,12 @@ static HRESULT WINAPI IQueryAssociations_fnGetString( > > case ASSOCSTR_FRIENDLYDOCNAME: > { > - WCHAR *pszFileType; > - DWORD ret; > - DWORD size; > + WCHAR *docName; > > - hr = ASSOC_GetValue(This->hkeySource, NULL, (void**)&pszFileType, NULL); > + hr = ASSOC_GetValue(This->hkeyProgID, NULL, (void**)&docName, NULL); > if (FAILED(hr)) > return hr; > - size = 0; > - ret = RegGetValueW(HKEY_CLASSES_ROOT, pszFileType, NULL, RRF_RT_REG_SZ, NULL, NULL, &size); > - if (ret == ERROR_SUCCESS) > - { > - WCHAR *docName = HeapAlloc(GetProcessHeap(), 0, size); > - if (docName) > - { > - ret = RegGetValueW(HKEY_CLASSES_ROOT, pszFileType, NULL, RRF_RT_REG_SZ, NULL, docName, &size); > - if (ret == ERROR_SUCCESS) > - hr = ASSOC_ReturnString(flags, pszOut, pcchOut, docName, strlenW(docName) + 1); > - else > - hr = HRESULT_FROM_WIN32(ret); > - HeapFree(GetProcessHeap(), 0, docName); > - } > - else > - hr = E_OUTOFMEMORY; > - } > - else > - hr = HRESULT_FROM_WIN32(ret); > - HeapFree(GetProcessHeap(), 0, pszFileType); > + hr = ASSOC_ReturnString(flags, pszOut, pcchOut, docName, strlenW(docName) + 1); > return hr; > } Basically you remove everything, and tests don't show that you should do that. For example looking at Win7 registry I see HKCR\.exe with default value of "exefile", then default value for HKCR\exefile is Application (and also there is a FriendlyTypeName key that's most likely localized). Current code will return "Application" and that seems like a better candidate for a friendly name. A convincing test should create a custom extension key, and test all possible combinations of empty default values, missing keys with default value name etc. > > @@ -623,41 +639,28 @@ get_friendly_name_fail: > case ASSOCSTR_DEFAULTICON: > { > static const WCHAR DefaultIconW[] = {'D','e','f','a','u','l','t','I','c','o','n',0}; > - WCHAR *pszFileType; > DWORD ret; > DWORD size; > - HKEY hkeyFile; > > - hr = ASSOC_GetValue(This->hkeySource, NULL, (void**)&pszFileType, NULL); > - if (FAILED(hr)) > - return hr; > - ret = RegOpenKeyExW(HKEY_CLASSES_ROOT, pszFileType, 0, KEY_READ, &hkeyFile); > + size = 0; > + ret = RegGetValueW(This->hkeyProgID, DefaultIconW, NULL, RRF_RT_REG_SZ, NULL, NULL, &size); > if (ret == ERROR_SUCCESS) > { > - size = 0; > - ret = RegGetValueW(hkeyFile, DefaultIconW, NULL, RRF_RT_REG_SZ, NULL, NULL, &size); > - if (ret == ERROR_SUCCESS) > + WCHAR *icon = HeapAlloc(GetProcessHeap(), 0, size); > + if (icon) > { > - WCHAR *icon = HeapAlloc(GetProcessHeap(), 0, size); > - if (icon) > - { > - ret = RegGetValueW(hkeyFile, DefaultIconW, NULL, RRF_RT_REG_SZ, NULL, icon, &size); > - if (ret == ERROR_SUCCESS) > - hr = ASSOC_ReturnString(flags, pszOut, pcchOut, icon, strlenW(icon) + 1); > - else > - hr = HRESULT_FROM_WIN32(ret); > - HeapFree(GetProcessHeap(), 0, icon); > - } > + ret = RegGetValueW(This->hkeyProgID, DefaultIconW, NULL, RRF_RT_REG_SZ, NULL, icon, &size); > + if (ret == ERROR_SUCCESS) > + hr = ASSOC_ReturnString(flags, pszOut, pcchOut, icon, strlenW(icon) + 1); > else > - hr = E_OUTOFMEMORY; > + hr = HRESULT_FROM_WIN32(ret); > + HeapFree(GetProcessHeap(), 0, icon); > } > else > - hr = HRESULT_FROM_WIN32(ret); > - RegCloseKey(hkeyFile); > + hr = E_OUTOFMEMORY; > } > else > hr = HRESULT_FROM_WIN32(ret); > - HeapFree(GetProcessHeap(), 0, pszFileType); > return hr; > } Same.

1 0

Re: shell32/tests: Fix okShell()'s tracing so it takes todo and other flags into account.
by Marvin Feb. 6, 2016

Feb. 6, 2016

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=20233 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec", topic="dde" failed: rc=29 err=2 shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail=""%1"", ddeexec="[open("%1")]", app="shlexec", topic="dde" failed: rc=29 err=2 shlexec.c:2422: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="%1", ddeexec="[open(%1)]", app="shlexec", topic="dde" ShlexecVar expected 'Present', but key not found or empty shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="%1", ddeexec="[open(%1)]", app="shlexec", topic="dde" failed: rc=29 err=32 shlexec.c:2436: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec", topic="dde", ifexec="[ifexec("%1")]" ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde")]' shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec" failed: rc=29 err=2 shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt7EA7.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", topic="dde" failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec", topic="dde" failed: rc=29 err=2 shlexec.c:2422: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail=""%1"", ddeexec="[open("%1")]", app="shlexec", topic="dde" ShlexecVar expected 'Present', but key not found or empty shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail=""%1"", ddeexec="[open("%1")]", app="shlexec", topic="dde" failed: rc=29 err=32 shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec", topic="dde", ifexec="[ifexec("%1")]" failed: rc=29 err=2 shlexec.c:2422: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec" ShlexecVar expected 'Present', but key not found or empty shlexec.c:2424: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtEC4F.tmp\test file.sde") Assoc ext=".sde", verb="Open", rawcmd="0", cmdtail="", ddeexec="[open("%1")]", app="shlexec" failed: rc=29 err=32

1 0

Re: [1/2] tests: Add winetest_status() which indicates what to do with a test result.
by Alexandre Julliard Feb. 6, 2016

Feb. 6, 2016

Francois Gouget <fgouget(a)codeweavers.com> writes: > winetest_status() takes into account not just the condition but also > the todo level, debug level, whether to report successful tests; and > returns the test status and whether to trace its result. > This allows individual tests to do their own logging taking into account all these flags. > > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> Honestly, this thing is getting out of hand. Not only is this adding a lot of complexity for a trivial difference in output, but it has actually made the traces less readable IMO. Can we please get rid of the fancy macros and go back to printing the relevant information in the ok() calls, like all other tests do? Pretty please? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] shell32: fix two bugs in IQueryAssocations
by Marvin Feb. 6, 2016

Feb. 6, 2016

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=20228 Your paranoid android. === wxppro (32 bit assoc) === assoc.c:144: Test failed: 3: got needed length 18 assoc.c:144: Test failed: 5: got needed length 18 === w2003std (32 bit assoc) === assoc.c:144: Test failed: 3: got needed length 18 assoc.c:144: Test failed: 5: got needed length 18 === wvistau64 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 19 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 19 === w2008s64 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w7u (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 16 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 16 === w7pro64 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w8 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w864 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w1064 (32 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === wvistau64 (64 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 19 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 19 === w2008s64 (64 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w7pro64 (64 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w864 (64 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18 === w1064 (64 bit assoc) === assoc.c:140: Test failed: 2: GetString failed, 0x8007007a assoc.c:144: Test failed: 3: got needed length 18 assoc.c:140: Test failed: 4: GetString failed, 0x8007007a assoc.c:144: Test failed: 5: got needed length 18

1 0

Re: [PATCH] shell32: fix two bugs in IQueryAssocations
by Marvin Feb. 6, 2016

Feb. 6, 2016

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=20227 Your paranoid android. === wvistau64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w2008s64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7u (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7pro64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w8 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w864 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w1064 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === wvistau64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w2008s64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7pro64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w864 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w1064 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a

1 0

Re: [PATCH] shell32: fix two bugs in IQueryAssocations
by Marvin Feb. 6, 2016

Feb. 6, 2016

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=20226 Your paranoid android. === wvistau64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w2008s64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7u (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7pro64 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w8 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w864 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w1064 (32 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === wvistau64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w2008s64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w7pro64 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w864 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a === w1064 (64 bit assoc) === assoc.c:136: Test failed: 2: GetString failed, 0x8007007a

1 0

Re: [PATCH 3/5] ddraw/tests: Rewrite rectangle_settings().
by Marvin Feb. 6, 2016

Feb. 6, 2016

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=20225 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 2/5] ddraw/tests: Rewrite offscreen_test().
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20224 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 1/5] ddraw/tests: Rewrite yv12_test().
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20223 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 1/7] wined3d: Move internal format queries to separate function.
by Henri Verbeet Feb. 5, 2016

Feb. 5, 2016

On 5 February 2016 at 15:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > adapter->fragment_pipe->get_caps(gl_info, &fragment_caps); > adapter->shader_backend->shader_get_caps(gl_info, &shader_caps); > srgb_write = (fragment_caps.wined3d_caps & WINED3D_FRAGMENT_CAP_SRGB_WRITE) > && (shader_caps.wined3d_caps & WINED3D_SHADER_CAP_SRGB_WRITE); > It seems wasteful to do this for each format.

1 0

Re: [PATCH] usp10: Implement fOverrideDirection
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20222 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1437: Test failed: 0: uJustification incorrect (0) usp10.c:1437: Test failed: 1: uJustification incorrect (0) usp10.c:1437: Test failed: 2: uJustification incorrect (0) usp10.c:1437: Test failed: 3: uJustification incorrect (0) usp10.c:1437: Test failed: 4: uJustification incorrect (0) usp10.c:1437: Test failed: 5: uJustification incorrect (0) usp10.c:1437: Test failed: 6: uJustification incorrect (0) usp10.c:1437: Test failed: 7: uJustification incorrect (0) usp10.c:1437: Test failed: 8: uJustification incorrect (0) usp10.c:1437: Test failed: 9: uJustification incorrect (0) usp10.c:1453: Test failed: 3: uJustification incorrect (0) usp10.c:1453: Test failed: 5: fDiacritic incorrect (1) usp10.c:1453: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1453: Test failed: 15: fDiacritic incorrect (1) usp10.c:1453: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [2/2] shell32/tests: Fix okShell() so it takes all logging options into account.
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20213 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32

1 0

Re: uxtheme: test and fix CloseThemeData with invalid handle value
by Alexandre Julliard Feb. 5, 2016

Feb. 5, 2016

Piet Jankbal <xerox.xerox2000x(a)gmail.com> writes: > Hi, this fixes https://bugs.winehq.org/show_bug.cgi?id=29862 > > signed off: Louis Lenders Please add a Signed-off-by header in the correct format. Also why are you sending this under a different name? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add test MultiByteToWideChar for code page is 936. (try 2)
by Alexandre Julliard Feb. 5, 2016

Feb. 5, 2016

Changhui LIU <chliu027028(a)gmail.com> writes: > + BOOL vistaOrLater = FALSE; > + OSVERSIONINFOA osvi; > + > + memset(&osvi, 0, sizeof(osvi)); > + osvi.dwOSVersionInfoSize = sizeof(osvi); > + GetVersionExA(&osvi); > + vistaOrLater = (osvi.dwMajorVersion > 5); Please don't do version checks in tests. You can mark the old behavior as broken if necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v5 PATCH 1/2] gdiplus: Implement GdipSetPenTransform
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20197 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [v5 PATCH 2/2] gdiplus: Implement GdipResetPenTransform
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20198 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v5 PATCH 2/2] gdiplus: Implement GdipResetPenTransform
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20195 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v5 PATCH 1/2] gdiplus: Implement GdipSetPenTransform
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20194 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] dwrite/tests: Remove failing test line, we have skips for this now
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20191 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v4 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 4, 2016

Feb. 4, 2016

Why did you remove the TRACE from this function?

1 0

Re: [PATCH 3/6] wined3d: Add support for separate sRGB formats.
by Henri Verbeet Feb. 4, 2016

Feb. 4, 2016

On 4 February 2016 at 01:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > - factory->wined3d = wined3d_create(0); > + factory->wined3d = wined3d_create(WINED3D_SEPARATE_SRGB_FORMATS); In some ways I like this, although I wonder if it wouldn't make more sense to handle this in terms of a flag to enable support for SRGB_READ/SRGB_WRITE. I.e., when WINED3D_SAMP_SRGB_TEXTURE and WINED3D_RS_SRGBWRITEENABLE are supported, WINED3DFMT_R8G8B8A8_UNORM and WINED3DFMT_R8G8B8A8_UNORM_SRGB would effectively be the same, while when they aren't you'd get the d3d10+ behaviour. > @@ -5993,7 +5994,7 @@ HRESULT wined3d_init(struct wined3d *wined3d, DWORD flags) > return WINED3D_OK; > } > > - if (!wined3d_adapter_init(&wined3d->adapters[0], 0)) > + if (!wined3d_adapter_init(&wined3d->adapters[0], wined3d, 0)) I'm not a huge fan of this, although I could probably live with it. I guess it's mostly to get at wined3d->flags during format initialization, in which case it may be sufficient to just pass the flags to wined3d_adapter_init(). > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index 1904dd1..718aa18 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -58,8 +58,11 @@ static const struct wined3d_format_channels formats[] = > {WINED3DFMT_DXT4, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_DXT5, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC1_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC1_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC2_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC2_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC3_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC3_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_MULTI2_ARGB8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_G8R8_G8B8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_R8G8_B8G8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, One thought I have about this is that we could just store the channel sizes and shifts for the typeless formats, and then have the typed formats copy the information from there, perhaps instead of the format_base_flags[] table we have now. So you'd have something like this: {WINED3DFMT_R8G8B8A8_UNORM, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_UNORM_SRGB, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_SNORM, WINED3DFMT_R8G8B8A8_TYPELESS, SNORM, SNORM, SNORM, SNORM} {WINED3DFMT_R8G8B8A8_UINT, WINED3DFMT_R8G8B8A8_TYPELESS, UINT, UINT, UINT, UINT} {WINED3DFMT_R8G8B8A8_SINT, WINED3DFMT_R8G8B8A8_TYPELESS, SINT, SINT, SINT, SINT} > @@ -2237,7 +2255,7 @@ static void query_internal_format(struct wined3d_adapter *adapter, > format_clear_flag(format, WINED3DFMT_FLAG_SRGB_WRITE); > > if (!gl_info->supported[ARB_DEPTH_TEXTURE] > - && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) > + && !!texture_info && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) The "!!" before texture_info seems unnecessary. > +static inline BOOL should_use_separate_srgb_gl_texture(const struct wined3d_context *context) That's a fairly long function name. Not that I have a better suggestion though. > +{ > + return !context->gl_info->supported[EXT_TEXTURE_SRGB_DECODE] > + && !(context->swapchain->device->wined3d->flags & WINED3D_SEPARATE_SRGB_FORMATS); > +} The number of pointer dereferences in here is scary. :) (Yeah, I know, there are other places that are just as bad.) Maybe it makes sense to store a copy of the flags in struct d3d_info?

2 1

Re: kernel32: Add test MultiByteToWideChar for code page is 936.
by Alexandre Julliard Feb. 4, 2016

Feb. 4, 2016

Changhui LIU <chliu027028(a)gmail.com> writes: > +static void test_cp936_to_widechar(void) > +{ > + int count = 0; > + int count2 = 0; > + WCHAR wide_buf[4]; > + unsigned char buf[] = {0xbf, 0xb4, 0xc7}; > + > + count = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), NULL, 0); > + ok(count > 0, "returned %d (expected > '0')\n", count); > + > + count2 = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), wide_buf, count); > + todo_wine ok(count2 > 0, "returned %d (expected > '0')\n", count2); > + > + todo_wine ok(count == count2, "expected twice call result is same\n"); That test could be more strict, I expect that there's a defined behavior, not just > 0. Comparing with the results from MB_ERR_INVALID_CHARS would also be interesting. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: hhctrl.ocx: Store window position in registry so that it's persistent between runs.
by Jacek Caban Feb. 4, 2016

Feb. 4, 2016

On 02/04/16 13:05, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/hhctrl.ocx/help.c | 71 > +++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 3 deletions(-) Please ignore this patch. It's not the right fix. Jacek

1 0

Re: [PATCH] include: Add IColumnsInfo interface (resend)
by Nikolay Sivov Feb. 4, 2016

Feb. 4, 2016

On 04.02.2016 12:31, Alistair Leslie-Hughes wrote: > +[ > + object, > + uuid(0c733a11-2a1c-11ce-ade5-00aa0044773d), > + pointer_default(unique) > +] > +interface IColumnsInfo : IUnknown > +{ > + [local] > + HRESULT GetColumnInfo([in, out] DBORDINAL *columns,[out, size_is(*columns)] DBCOLUMNINFO **colinfo, > + [out] OLECHAR *stringsbuffer); > + > + [call_as(GetColumnInfo)] > + HRESULT RemoteGetColumnInfo([in, out] DBORDINAL *columns, [out, size_is((ULONG)*columns)] DBCOLUMNINFO **col_info, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **name_offsets, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **columnid_offsets, > + [in, out] DBLENGTH *string_len, [in, out, unique, size_is((ULONG)*string_len)] OLECHAR **stringsbuffer, > + [out] IErrorInfo **error); > + ULONG in SDK comes from DBORDINAL being ULONGLONG vs ULONG depending on bitness, I agree we probably don't have to duplicate that, and can always use cast. In any case size_is attribute is used in a wrong way, and at least one method prototype does not match SDK.

1 0

Re: [PATCH] usp10: Correct math punctuation handling in itemization
by Marvin Feb. 3, 2016

Feb. 3, 2016

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=20174 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1284: Test failed: 0: uJustification incorrect (0) usp10.c:1284: Test failed: 1: uJustification incorrect (0) usp10.c:1284: Test failed: 2: uJustification incorrect (0) usp10.c:1284: Test failed: 3: uJustification incorrect (0) usp10.c:1284: Test failed: 4: uJustification incorrect (0) usp10.c:1284: Test failed: 5: uJustification incorrect (0) usp10.c:1284: Test failed: 6: uJustification incorrect (0) usp10.c:1284: Test failed: 7: uJustification incorrect (0) usp10.c:1284: Test failed: 8: uJustification incorrect (0) usp10.c:1284: Test failed: 9: uJustification incorrect (0) usp10.c:1300: Test failed: 3: uJustification incorrect (0) usp10.c:1300: Test failed: 5: fDiacritic incorrect (1) usp10.c:1300: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1300: Test failed: 15: fDiacritic incorrect (1) usp10.c:1300: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: [v3 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 3, 2016

Feb. 3, 2016

I think we should keep the FIXME on this one until we use the transform in rendering, maybe change it to semi-stub.

1 0

Re: [PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().
by Henri Verbeet Feb. 3, 2016

Feb. 3, 2016

On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (sample_count > 32) > + return E_FAIL; I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT. > + if (sample_count > 16) > + { > + FIXME("sample_count %u not handled yet.\n", sample_count); > + return S_OK; > + } I think that belongs in wined3d_check_device_multisample_type(). > + hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device, > + wined3dformat_from_dxgi_format(format), sample_count, quality_level_count); > + if (hr == WINED3DERR_INVALIDCALL) > + return E_INVALIDARG; > + if (hr == WINED3DERR_NOTAVAILABLE) > + return S_OK; This is fine, but the d3d10+ API probably makes more sense in the long run. I.e., eventually we'd want to handle the difference in d3d8/9 instead. > +HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device, > + enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, > + DWORD *quality_level_count) I don't think we really want to introduce a new entry point for this. I guess the issue is that we can't get at the wined3d object that created the device from inside d3d11, but I think it would be preferable to do something about that instead. It seems likely that CheckFeatureSupport() and CheckFormatSupport() would run into this as well.

2 1

Re: [5/5] webservices: Implement WsWriteStartCData and WsWriteEndCData.
by Marvin Feb. 3, 2016

Feb. 3, 2016

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=20164 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH v5] user32: Add MOUSEHOOKSTRUCTEX to improve mouse wheel support
by Alex Henrie Feb. 3, 2016

Feb. 3, 2016

+typedef struct +{ + struct { /* MOUSEHOOKSTRUCT */ + POINT pt; + HWND hwnd; + UINT wHitTestCode; + ULONG_PTR dwExtraInfo; + } DUMMYSTRUCTNAME; + DWORD mouseData; +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; Other than the excessive indentation in "DWORD mouseData", this patch looks good, and the user32 tests still pass on my machine. -Alex

1 0

Re: [PATCH 6/6] ddraw: Replace wined3d_surface_preload() with wined3d_texture_preload().
by Henri Verbeet Feb. 1, 2016

Feb. 1, 2016

On 31 January 2016 at 11:22, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > Also removed wined3d_surface_preload as it's now unused > > Signed-off-by: Riccardo Bortolato <rikyz619(a)gmail.com> > --- > dlls/ddraw/device.c | 2 +- > dlls/wined3d/surface.c | 13 ------------- > dlls/wined3d/wined3d.spec | 1 - > include/wine/wined3d.h | 1 - > 4 files changed, 1 insertion(+), 16 deletions(-) > You may have noticed that I started working on this myself instead, and this patch is practically a duplicate of 118671.

2 3

Re: [PATCH 5/5] dwrite: Remove some redundant includes
by Marvin Feb. 1, 2016

Feb. 1, 2016

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=20128 Your paranoid android. === wvistau64 (32 bit layout) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [v3] msvcrt: handle of thread created by _beginthread should not be closed on thread detach.
by Piotr Caban Feb. 1, 2016

Feb. 1, 2016

Hi, On 02/01/16 12:00, Paul Gofman wrote: > + /* _beginthreadex: handle is not closed on _endthread */ > + hThread = (HANDLE)_beginthreadex(NULL,0, test_thread_func_ex, NULL, 0, NULL); > + ok(hThread != INVALID_HANDLE_VALUE, "_beginthreadex failed (%d)\n", errno); _beginthreadex returns 0 in case of error (not INVALID_HANDLE_VALUE). Except of it the patch looks good for me. Thanks, Piotr

1 0

Re: [v2] msvcrt: handle of thread created by _beginthread should not be closed on thread detach.
by Piotr Caban Feb. 1, 2016

Feb. 1, 2016

Hi Paul, On 01/31/16 22:58, Paul Gofman wrote: > + /* _beginthread: handle is not closed on ExitProcess and _endthreadex */ > + hThread = (HANDLE)_beginthread(test_thread_func, 0, (void*)0); > + Sleep(150); > + ret = WaitForSingleObject(hThread, INFINITE); > + ok(ret == WAIT_FAILED, "ret = %d\n", ret); This test may fail if for some reason thread has not finished during 150ms sleep. You can workaround this issue following way: hThread = (HANDLE)_beginthread(test_thread_func, 0, (void*)0); ok(hThread != INVALID_HANDLE_VALUE, "_beginthread failed (%d)\n", errno); WaitForSingleObject(hThread, INFINITE); ret = CloseHandle(hThread); ok(!ret, "ret = %d\n", ret); > @@ -69,6 +69,9 @@ static DWORD CALLBACK _beginthread_trampoline(LPVOID arg) > MSVCRT_free(arg); > > local_trampoline.start_address(local_trampoline.arglist); > + > + CloseHandle(data->handle); > + data->handle = NULL; According to MSDN _endthread should be called here. Because it's documented I think we should implement it in similar way. > @@ -136,8 +139,18 @@ MSVCRT_uintptr_t CDECL _beginthreadex( > */ > void CDECL _endthread(void) > { > + thread_data_t *tls; > + > TRACE("(void)\n"); > > + tls = TlsGetValue(msvcrt_tls_index); > + if (tls && tls->handle) You should check for INVALID_HANDLE_VALUE instead of NULL here. It's doesn't really matter but for sake of consistency tls->handle should be set to INVALID_HANDLE_VALUE after close. Thanks, Piotr

2 1

Re: [PATCH] server: Implement serial port read interval timeouts.
by Alexandre Julliard Feb. 1, 2016

Feb. 1, 2016

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Version 3 has all the logic in serial.c, even though this required > adding a getter in async.c and another getter in fd.c. The first > interval timeout no longer trashes subsequent interval timeouts or > the total timeout, and absolute timeouts are used exclusively. You should be able to do this without adding all the extra getter functions. I'd suggest something along these lines (completely untested): diff --git a/server/serial.c b/server/serial.c index 164a4b1fe717..04b517dd347e 100644 --- a/server/serial.c +++ b/server/serial.c @@ -62,12 +62,15 @@ static void serial_destroy(struct object *obj); static enum server_fd_type serial_get_fd_type( struct fd *fd ); static void serial_queue_async( struct fd *fd, const async_data_t *data, int type, int count ); +static void serial_reselect_async( struct fd *fd, struct async_queue *queue ); struct serial { struct object obj; struct fd *fd; + struct timeout_user *read_timer; + /* timeout values */ unsigned int readinterval; unsigned int readconst; @@ -115,7 +118,7 @@ static const struct fd_ops serial_fd_ops = no_fd_flush, /* flush */ default_fd_ioctl, /* ioctl */ serial_queue_async, /* queue_async */ - default_fd_reselect_async, /* reselect_async */ + serial_reselect_async, /* reselect_async */ default_fd_cancel_async /* cancel_async */ }; @@ -134,6 +137,7 @@ struct object *create_serial( struct fd *fd ) if (!(serial = alloc_object( &serial_ops ))) return NULL; + serial->read_timer = NULL; serial->readinterval = 0; serial->readmult = 0; serial->readconst = 0; @@ -157,6 +161,7 @@ static struct fd *serial_get_fd( struct object *obj ) static void serial_destroy( struct object *obj) { struct serial *serial = (struct serial *)obj; + if (serial->read_timer) remove_timeout_user( serial->read_timer ); release_object( serial->fd ); } @@ -203,6 +208,34 @@ static void serial_queue_async( struct fd *fd, const async_data_t *data, int typ } } +static void serial_read_timeout( void *arg ) +{ + struct serial *serial = arg; + + serial->read_timer = NULL; + fd_async_wake_up( serial->fd, ASYNC_TYPE_READ, STATUS_TIMEOUT ); +} + +static void serial_reselect_async( struct fd *fd, struct async_queue *queue ) +{ + struct serial *serial = get_fd_user( fd ); + + if (serial->read_timer) + { + if (!(default_fd_get_poll_events( fd ) & POLLIN)) + { + remove_timeout_user( serial->read_timer ); + serial->read_timer = NULL; + } + } + else if (!serial->read_timer && serial->readinterval && (default_fd_get_poll_events( fd ) & POLLIN)) + { + serial->read_timer = add_timeout_user( (timeout_t)serial->readinterval * -10000, + serial_read_timeout, serial ); + } + default_fd_reselect_async( fd, queue ); +} + DECL_HANDLER(get_serial_info) { struct serial *serial; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] user32: A window may be notified with WM_CAPTURECHANGED about itself gaining mouse capture if SetCapture() i
by Marvin Feb. 1, 2016

Feb. 1, 2016

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=20123 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:7246: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH] user32: Allow WM_CAPTURECHANGED indicating SetCapture() parameter
by Ken Thomases Feb. 1, 2016

Feb. 1, 2016

On Jan 31, 2016, at 7:18 PM, Christopher Thielen <cthielen(a)gmail.com> wrote: > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. > > Tested on Windows XP and Fedora Workstation 22. > > Revised to simplify based on wine-devel feedback. > Revised to address any side-effects of new WM_CAPTURECHANGED > messages. The changes to comctl32 should be in a separate patch. In general, changes to different DLLs should be in separate patches unless it can't be avoided. The comctl32 patch should come before the change to when WM_CAPTURECHANGED is sent so that things aren't broken part-way through the patch series. You might also put the button.c changes in a separate patch, too. > case WM_CAPTURECHANGED: > - return TOOLBAR_CaptureChanged(infoPtr); > + if(hwnd != lParam) > + { > + return TOOLBAR_CaptureChanged(infoPtr); > + } > + else > + { > + return 0; > + } The second return can be hoisted out of the else since the true branch can't fall through. Also, you can reverse the logic, so the code can look like: case WM_CAPTURECHANGED: if(hwnd == lParam) return 0; return TOOLBAR_CaptureChanged(infoPtr); I think that's clearer and also a smaller diff. Same for the other files. Cheers, Ken

2 1

Re: [PATCH] user32: Allow WM_CAPTURECHANGED indicating SetCapture() parameter
by Marvin Feb. 1, 2016

Feb. 1, 2016

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=20122 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0