April 2017 - Wine-Devel - list.winehq.org

Re: [resend PATCH 1/4] d3dx9/tests: Add test implementation for ID3DXEffectStateManager interface.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct test_state_manager_update > +{ > + unsigned int state_op; > + DWORD param1; > + DWORD param2; > +}; > + > +struct test_ID3DXEffectStateManagerImpl Sorry for being a PITA but it would be better to avoid this kind of naming, at a first glance it might be confused with a MS structure. Just call it test_manager or similar. > +static HRESULT WINAPI test_ID3DXEffectStateManagerImpl_QueryInterface(ID3DXEffectStateManager *iface, > + REFIID riid, void **object) > +{ > + if (IsEqualGUID(riid, &IID_IUnknown) > + || IsEqualGUID(riid, &IID_ID3DXEffectStateManager)) > + { > + iface->lpVtbl->AddRef(iface); > + *object = iface; > + return S_OK; > + } > + > + return E_NOINTERFACE; > +} Do you know if this is called by d3dx9 at all? Either way, adding some ok() here would be nice. > + state_manager->update_record = new_alloc; > + state_manager->update_record_size = new_size; > + > + } Spurious blank line. Also I'm not sure it makes a lot of sense to use new_alloc / new_size and check that the allocation succeeded with ok() to then always assign the new variables to the struct fields anyway. Memory allocation should never legitimately fail there so I'd remove the vestigial error checking entirely and let the test crash if the allocation somehow fails.

1 0

Re: [PATCH] d3dx11: Add D3DX11FilterTexture stub.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-03 18:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > diff --git a/include/d3dx11tex.h b/include/d3dx11tex.h > index 16b280a..81a43cc 100644 > --- a/include/d3dx11tex.h > +++ b/include/d3dx11tex.h > @@ -93,6 +93,8 @@ HRESULT WINAPI D3DX11CreateShaderResourceViewFromMemory(ID3D11Device *device, co > HRESULT WINAPI D3DX11CreateTextureFromMemory(ID3D11Device *device, const void *src_data, SIZE_T src_data_size, > D3DX11_IMAGE_LOAD_INFO *loadinfo, ID3DX11ThreadPump *pump, ID3D11Resource **texture, HRESULT *hresult); > > +HRESULT WINAPI D3DX11FilterTexture(ID3D11DeviceContext *context, ID3D11Resource *texture, UINT src_level, UINT filter); > + > HRESULT WINAPI D3DX11GetImageInfoFromMemory(const void *src_data, SIZE_T src_data_size, ID3DX11ThreadPump *pump, > D3DX11_IMAGE_INFO *img_info, HRESULT *hresult); > > -- > 2.7.4 Could you please also add the D3DX11_FILTER_FLAG definition to d3dx11tex.h? Looks okay otherwise.

1 0

GSoC Mentors
by André Hentschel April 9, 2017

April 9, 2017

Hi, for those who had not had a look at the proposals yet, please review them and comment. Thanks!

1 0

Re: [PATCH v5] ntdll/tests: Check debug registers of a newly created thread
by Marvin April 9, 2017

April 9, 2017

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

1 0

Wine-Staging Performance Regression since 2.0rc6
by Bjoern Bidar/Thaodan April 8, 2017

April 8, 2017

Hello guys I hope this is the right place to ask. Since after 2.0rc6 many Wow user getting worse performance. For comparsion: 2.0rc6: 65fps 2.1/2.2: about 40 2.4: no change either even the main menu lags when you look close. To test just download the game and open it even the main menu lags as said before. Me and many users don't know how to help in debugging the issue, so im asking here. Greetings Björn

1 0

Re: [PATCH 2/4] winex11: move XDestroyWindow() after free_gl_drawable() in set_win_format()
by Alexandre Julliard April 8, 2017

April 8, 2017

Miklós Máté <mtmkls(a)gmail.com> writes: > @@ -1334,21 +1334,21 @@ static void free_gl_drawable( struct gl_drawable *gl ) > /*********************************************************************** > * create_gl_drawable > */ > -static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl ) > +static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl, struct x11drv_win_data *data ) > { > gl->drawable = 0; > > if (GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow()) /* top-level window */ > { > - struct x11drv_win_data *data = get_win_data( hwnd ); > - > if (data) > { > gl->type = DC_GL_WINDOW; > gl->window = create_client_window( data, gl->visual ); > if (gl->window) > + { > gl->drawable = pglXCreateWindow( gdi_display, gl->format->fbconfig, gl->window, NULL ); > - release_win_data( data ); > + XSync( gdi_display, False ); Do you really need all the extra XSync calls? We try to avoid server round-trips as much as possible. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v4] ntdll/tests: Check debug registers of a newly created thread
by Dmitry Timoshkov April 8, 2017

April 8, 2017

Hi Christian, Christian Inci <chris.wine(a)broke-the-inter.net> wrote: > + thread = CreateThread(NULL, 0, dummy_thread, NULL, CREATE_SUSPENDED, NULL); > + ok(thread != INVALID_HANDLE_VALUE, "CreateThread failed with %d\n", GetLastError()); > + memset(&ctx, 0, sizeof(ctx)); > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + status = pNtGetContextThread(thread, &ctx); > + ok(status == STATUS_SUCCESS, "NtGetContextThread failed with %x\n", status); > + ok(!ctx.Dr0, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr0); > + ok(!ctx.Dr1, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr1); > + ok(!ctx.Dr2, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr2); > + ok(!ctx.Dr3, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr3); > + todo_wine ok(!ctx.Dr6, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr6); > + todo_wine ok(!ctx.Dr7, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr7); > + CloseHandle(thread); > +} The thread needs to be explicitly terminated. -- Dmitry.

2 1

Re: [PATCH] tools/winedump: Change duplicate flag.
by Alexandre Julliard April 7, 2017

April 7, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > diff --git a/tools/winedump/main.c b/tools/winedump/main.c > index a4ebb43..5c683f6 100644 > --- a/tools/winedump/main.c > +++ b/tools/winedump/main.c > @@ -226,7 +226,7 @@ static const struct my_option option_table[] = { > {"-v", SPEC, 0, do_verbose, "-v Show lots of detail while working (verbose)."}, > {"dump", DUMP, 0, do_dump, "dump <file> Dump the contents of 'file' (dll, exe, lib...)"}, > {"-C", DUMP, 0, do_symdmngl, "-C Turn on symbol demangling"}, > - {"-f", DUMP, 0, do_dumphead, "-f Dump file header information"}, > + {"-F", DUMP, 0, do_dumphead, "-F Dump file header information"}, Not a big deal, but is there a reason for changing this? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v2] ntdll/tests: Check debug registers of a newly created thread
by Christian Inci April 7, 2017

April 7, 2017

Forgot to send the response to wine-devel too. On 04/07/2017 10:01 PM, Christian Inci wrote: > Thank you very much for letting me know. > > Setting Dr7 with the "wrong" bits set will result into this error. > I'm going to change the testcase right now. > > On 04/07/2017 09:07 PM, Alexandre Julliard wrote: >> Christian Inci <chris.wine(a)broke-the-inter.net> writes: >> >>> +static void test_thread_debug_registers(void) >>> +{ >>> + HANDLE thread; >>> + CONTEXT ctx; >>> + NTSTATUS status; >>> + >>> + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; >>> + ctx.Dr0 = 0xffffffff; >>> + ctx.Dr1 = 0xffffffff; >>> + ctx.Dr2 = 0xffffffff; >>> + ctx.Dr3 = 0xffffffff; >>> + ctx.Dr6 = 0xffffffff; >>> + ctx.Dr7 = 0xffffffff; >>> + status = pNtSetContextThread(GetCurrentThread(), &ctx); >>> + todo_wine ok(status == STATUS_SUCCESS, "NtSetContextThread failed with %x\n", status); >> >> It would be a more convincing test if setting the context succeeded. The >> failure is of course interesting too, but that could be a separate test. >>

1 0

Re: [PATCH v4 4/4] user32/tests: Fix an intermittent failure. (resend)
by Marvin April 7, 2017

April 7, 2017

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=30041 Your paranoid android. === w7u (32 bit msg) === msg.c:12062: Test failed: WmMouseHoverSeq: 0: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:12064: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:12064: Test failed: wrong tme.hwndTrack 0018017E, expected 00000000 msg.c:12064: Test failed: wrong tme.dwHoverTime 400, expected 0 === w7pro64 (32 bit msg) === msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 4: in msg 0x0047 expecting wParam 0x8170 got 0x1803 msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 5: the msg 0x0003 was expected, but got msg 0x0047 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 6: the msg 0x0005 was expected, but got msg 0x0003 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 7: the msg sequence is not complete: expected 0000 - actual 0005

1 0

Re: [PATCH] tools/winedump: Change duplicate flag.
by Austin English April 7, 2017

April 7, 2017

On Apr 7, 2017 2:22 PM, "Zebediah Figura" <z.figura12(a)gmail.com> wrote: On 04/07/2017 02:09 PM, Alexandre Julliard wrote: > Zebediah Figura <z.figura12(a)gmail.com> writes: > >> diff --git a/tools/winedump/main.c b/tools/winedump/main.c >> index a4ebb43..5c683f6 100644 >> --- a/tools/winedump/main.c >> +++ b/tools/winedump/main.c >> @@ -226,7 +226,7 @@ static const struct my_option option_table[] = { >> {"-v", SPEC, 0, do_verbose, "-v Show lots of detail while working (verbose)."}, >> {"dump", DUMP, 0, do_dump, "dump <file> Dump the contents of 'file' (dll, exe, lib...)"}, >> {"-C", DUMP, 0, do_symdmngl, "-C Turn on symbol demangling"}, >> - {"-f", DUMP, 0, do_dumphead, "-f Dump file header information"}, >> + {"-F", DUMP, 0, do_dumphead, "-F Dump file header information"}, > > Not a big deal, but is there a reason for changing this? > The -f flag is assigned to two different options, yielding this one unreachable. Please also update the manpage. Thanks for catching this!

1 0

Re: [PATCH 1/2 v2] ntdll/tests: Check debug registers of a newly created thread
by Alexandre Julliard April 7, 2017

April 7, 2017

Christian Inci <chris.wine(a)broke-the-inter.net> writes: > +static void test_thread_debug_registers(void) > +{ > + HANDLE thread; > + CONTEXT ctx; > + NTSTATUS status; > + > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + ctx.Dr0 = 0xffffffff; > + ctx.Dr1 = 0xffffffff; > + ctx.Dr2 = 0xffffffff; > + ctx.Dr3 = 0xffffffff; > + ctx.Dr6 = 0xffffffff; > + ctx.Dr7 = 0xffffffff; > + status = pNtSetContextThread(GetCurrentThread(), &ctx); > + todo_wine ok(status == STATUS_SUCCESS, "NtSetContextThread failed with %x\n", status); It would be a more convincing test if setting the context succeeded. The failure is of course interesting too, but that could be a separate test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] regedit: Correctly handle the importing of DWORD strings that are followed by a comment
by Alexandre Julliard April 7, 2017

April 7, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 29 ++++++++++++++++++++++++----- > programs/regedit/tests/regedit.c | 4 ++-- > 2 files changed, 26 insertions(+), 7 deletions(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index e0049c6..c8149f5 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -146,15 +146,34 @@ static char* GetMultiByteStringN(const WCHAR* strW, int chars, DWORD* len) > */ > static BOOL convertHexToDWord(WCHAR* str, DWORD *dw) > { > - char buf[9]; > + char *buf; > char dummy; > + BOOL ret = TRUE; > > - WideCharToMultiByte(CP_ACP, 0, str, -1, buf, 9, NULL, NULL); > - if (lstrlenW(str) > 8 || sscanf(buf, "%x%c", dw, &dummy) != 1) { > + buf = GetMultiByteString(str); > + if (!buf) return FALSE; > + > + if (strlen(buf) > 8) /* Look for any characters after the DWORD string */ > + { > + char *p = buf + 8; > + > + while (*p == ' ' || *p == '\t') p++; > + if (*p != ';') > + { > + HeapFree(GetProcessHeap(), 0, buf); > + return FALSE; > + } > + buf[8] = 0; > + } > + > + if (sscanf(buf, "%x%c", dw, &dummy) != 1) > + { > output_message(STRING_INVALID_HEX); > - return FALSE; > + ret = FALSE; > } It may be a good idea to write tests for dwords with different numbers of digits, it's not clear to me that this would be doing the right thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/8] server: Pass async_data_t as varargs in write request.
by Jacek Caban April 7, 2017

April 7, 2017

On 06.04.2017 17:58, Jacek Caban wrote: > This is needed for later patch that adds APCs to async_data_t, causing > request to exceed allowed size. Having second thoughts about it, I think there is a solution that doesn't require changing async_data_t size. We could require that the first field of callback argument is a pointer to callback. This way we could have just one pointer for callback and its argument, saving space for APC in async_data_t. Please let me know if that would be preferred. Thanks, Jacek

2 1

Re: [PATCH] odbccp32: Implement SQLConfigDriver/W
by Huw Davies April 7, 2017

April 7, 2017

On Fri, Apr 07, 2017 at 12:48:17AM +0000, Alistair Leslie-Hughes wrote: > v2 - Use worker function to load DLL > - Correctly set error when required. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 115 ++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 105 insertions(+), 10 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 773c5d2..041170a 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -62,6 +62,12 @@ static const WCHAR odbc_error_component_not_found[] = {'C','o','m','p','o','n',' > static const WCHAR odbc_error_out_of_mem[] = {'O','u','t',' ','o','f',' ','m','e','m','o','r','y',0}; > static const WCHAR odbc_error_invalid_param_sequence[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','e','q','u','e','n','c','e',0}; > static const WCHAR odbc_error_invalid_param_string[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','t','r','i','n','g',0}; > +static const WCHAR odbc_error_invalid_dsn[] = {'I','n','v','a','l','i','d',' ','D','S','N',0}; > +static const WCHAR odbc_error_load_lib_failed[] = {'L','o','a','d',' ','L','i','b','r','a','r','y',' ','F','a','i','l','e','d',0}; > +static const WCHAR odbc_error_request_failed[] = {'R','e','q','u','e','s','t',' ','F','a','i','l','e','d',0}; > + > +static BOOL (WINAPI *pConfigDriverW)(HWND hwnd, WORD request, const WCHAR *driver, const WCHAR *args, const WCHAR *msg, WORD msgmax, WORD *msgout); > +static BOOL (WINAPI *pConfigDriverA)(HWND hwnd, WORD request, const char *driver, const char *args, const char *msg, WORD msgmax, WORD *msgout); Is there a reason why pConfigDriverA/W are not local variables? Huw.

1 0

Re: [PATCH 2/2] wmvcore: Add WMReader stubs
by Nikolay Sivov April 7, 2017

April 7, 2017

On 07.04.2017 6:51, Jefferson Carpenter wrote: > Adds interfaces used by IMesh in bug 42416, except for these: > > 5c938aeb-6378-479e-bfd5-eafba63dc6e9 > 7af7d5ed-4ef9-48da-a4b6-8ea7eb38f5cc > --- > dlls/wmvcore/wmvcore_main.c | 1301 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 1301 insertions(+) > Hi, this is too much for a single patch. Please split it up and add some tests that shows such interfaces are actually supported. To add tests create a 'tests' directory, Makefile.in in it, and wmvcore.c (file name could be different), where you place tests. You'll have to modify configure.ac to add WINE_CONFIG_TEST line in it. If you need to link to wmvcore.dll from your test, you'll need to modify WINE_CONFIG_DLL too, to include implib directive.

2 1

Re: shell32: Fix the 'OK' button is always gray when call SHBrowseForFolder with flags BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS (try 2)
by Xu Wenlong April 7, 2017

April 7, 2017

------------------ Original ------------------ From: "Marvin"<testbot(a)winehq.org>; Date: Fri, Apr 7, 2017 04:05 AM To: "Xu Wenlong"<xuwenlong(a)deepin.com>; Subject: Re: shell32: Fix the 'OK' button is always gray when call SHBrowseForFolder with flags BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS (try 2) Thank you for your contribution to Wine! This is an automated notification to let you know that your patch has been reviewed and its status set to "No patch". This means that no patch was found in your mail. If you do not understand the reason for this status, disagree with our assessment, or are simply not sure how to proceed next, please ask for clarification by replying to this email.

1 0

Mailing List Issues
by Jeremy Newman April 6, 2017

April 6, 2017

We have been having issues with bounces and people getting removed from the list subscriptions as of late. It seems to mostly affect Gmail users, but some others have been getting kicked as well. Gmail is getting particularly picky about valid mail headers. I'm looking into ways of preventing this from happening. I've done the following to prevent further issues: * Raise the bounce threshold in mailman to 10.0 * Add SPF record to DNS * Add DMARC policy to DNS * Add DKIM key signing to all outbound mail, and matching key in DNS We also have been hitting our bandwidth threshold at our co-lo. When this happens they start to drop packets on us as a form of throttling. This always happens when I do a full CDN flush. As this really chews up the bits when the mirrors re-sync. To prevent that, we now have a background process watching for changed files on our master, and only changes will be flushed. If you notice any further issues, or have suggestions, let me know. Thanks. -N

1 0

Re: [PATCH 2/2] odbccp32: Implement SQLRemoveTranslator/W
by Huw Davies April 6, 2017

April 6, 2017

On Wed, Apr 05, 2017 at 09:51:15AM +0000, Alistair Leslie-Hughes wrote: > v3 - Fix trace message. > v4 - Fixed assignment of usage_count > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 69 +++++++++++++++++++++++++++++++++++++++++----- > dlls/odbccp32/tests/misc.c | 8 +++--- > 2 files changed, 66 insertions(+), 11 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 7b2f020bbe..161f2c2bd2 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -1229,20 +1229,75 @@ BOOL WINAPI SQLRemoveDSNFromIni(LPCSTR lpszDSN) > return FALSE; > } > > -BOOL WINAPI SQLRemoveTranslatorW(LPCWSTR lpszTranslator, LPDWORD lpdwUsageCount) > +BOOL WINAPI SQLRemoveTranslatorW(const WCHAR *translator, DWORD *usage_count) > { > + HKEY hkey; > + DWORD usagecount = 1; > + > clear_errors(); > - FIXME("%s %p\n", debugstr_w(lpszTranslator), lpdwUsageCount); > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return FALSE; > + TRACE("%s %p\n", debugstr_w(translator), usage_count); > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if (RegOpenKeyW(hkey, translator, &hkeydriver) == ERROR_SUCCESS) > + { > + DWORD size, type; > + DWORD count; > + > + size = sizeof(usagecount); > + RegGetValueA(hkeydriver, NULL, "UsageCount", RRF_RT_DWORD, &type, &usagecount, &size); > + TRACE("Usage count %d\n", usagecount); > + count = usagecount - 1; > + if (count) > + { > + if (RegSetValueExA(hkeydriver, "UsageCount", 0, REG_DWORD, (BYTE*)&count, sizeof(count)) != ERROR_SUCCESS) > + ERR("Failed to write registry UsageCount key\n"); > + } > + > + RegCloseKey(hkeydriver); > + } > + > + if (usagecount) > + usagecount--; > + > + if (!usagecount) > + { > + if(RegDeleteKeyW(hkey, translator) != ERROR_SUCCESS) > + ERR("Failed to delete registry key: %s\n", debugstr_w(translator)); > + > + if (RegOpenKeyW(hkey, odbctranslators, &hkeydriver) == ERROR_SUCCESS) > + { > + if(RegDeleteValueW(hkeydriver, translator) != ERROR_SUCCESS) > + ERR("Failed to delete registry value: %s\n", debugstr_w(translator)); > + > + RegCloseKey(hkeydriver); > + } > + } > + > + RegCloseKey(hkey); > + } > + > + if (usage_count) > + *usage_count = usagecount; > + > + return TRUE; > } Sorry, I've just noticed that this returns TRUE even if the requested translator isn't installed, which is not correct. A test for that would be good too. Huw.

1 0

Re: gdi32: Change default interface font to Gothic typeface for CJK.
by Akihiro Sagawa April 6, 2017

April 6, 2017

> On Tue, Apr 04, 2017 at 11:25:18PM +0800, Jactry Zeng wrote: > > This patch changes default interface typeface of CJK from Mincho font to > > Gothic font. > > Windows had made this change since Windows Vista. macOS and most of Linux > > distros are using Gothic typeface by default for CJK, too. > > This seems to be confirmed by the great oracle of truth that is Wikipedia. > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> I'm not sure about this. On my Japanese Windows 7, MS Shell Dlg points to MS UI Gothic, not Meiryo. If I remember correctly, it also points to legacy Mincho font in Chinese/Korean environment. I'm afraid that this change also affects dialog base units (e.g. GetDialogBaseUnits). A lot of application dialogs depend on default font's dialog units. Though Windows 7 introduces new type faces, we should use legacy font face in GDI for that reason. Instead of MS Shell Dlg, how about using "MS Shell Dlg 2" for system dialog windows? Regards, Akihiro Sagawa

3 3

Re: [PATCH 2/6] comctl32/tests: Test messages sent to the pager child.
by Nikolay Sivov April 5, 2017

April 5, 2017

On 05.04.2017 10:15, Stefan Dösinger wrote: > --- > dlls/comctl32/tests/msg.h | 19 ++++++++++-- > dlls/comctl32/tests/pager.c | 70 ++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 83 insertions(+), 6 deletions(-) > > diff --git a/dlls/comctl32/tests/msg.h b/dlls/comctl32/tests/msg.h > index b30b5d8..a3c789b 100644 > --- a/dlls/comctl32/tests/msg.h > +++ b/dlls/comctl32/tests/msg.h > @@ -39,7 +39,8 @@ typedef enum > hook = 0x100, > winevent_hook =0x200, > id = 0x400, > - custdraw = 0x800 > + custdraw = 0x800, > + child1 = 0x1000, > } msg_flags_t; > Maybe I don't see a full picture yet, but doesn't this duplicate 'id' flag? We use it for ListView/Header combined sequences for example. > struct message > @@ -182,6 +183,8 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > { > if (expected->message == actual->message) > { > + const char *expected_win = NULL; > + > if (expected->flags & wparam) > { > if (expected->wParam != actual->wParam && todo) > @@ -304,11 +307,23 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > context, expected->message, (expected->flags & posted) ? "posted" : "sent"); > if ((expected->flags & (sent|posted)) != (actual->flags & (sent|posted))) dump++; > > + if (expected->flags & parent) > + expected_win = "parent"; > + else if (expected->flags & child1) > + expected_win = "child 1"; > + else > + expected_win = "pager"; This has to be generic, something neutral like "control" instead of "pager" is better, if we'll end up using new flag.

2 2

Re: [PATCH 1/4] regedit: Concatenate the next line when a comment follows the backslash
by Alexandre Julliard April 5, 2017

April 5, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -715,7 +715,7 @@ static char *get_lineA(FILE *fp) > > while (next) > { > - char *p = strpbrk(line, "\r\n"); > + char *p = strpbrk(line, "\r\n"), *s; > if (!p) > { > size_t len, count; > @@ -741,10 +741,11 @@ static char *get_lineA(FILE *fp) > next = p + 1; > if (*p == '\r' && *(p + 1) == '\n') next++; > *p = 0; > - if (p > buf && *(p - 1) == '\\') > + if ((s = strchr(line, ':')) && (*(s - 1) == 'x' || *(s - 1) == ')')) > { > - while (*next == ' ' || *next == '\t') next++; > - memmove(p - 1, next, strlen(next) + 1); > + s = strchr(s, '\\'); > + if (!s) return line; > + memmove(s, next, strlen(next) + 1); This looks wrong. I assume it's meant to check for hex() and the like, but this would have to be done in the parser, not in the line reading code. There could just as well be a "hex:" inside a value string for instance. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Store render target info instead of surfaces in "blit_targets".
by Henri Verbeet April 5, 2017

April 5, 2017

On 5 April 2017 at 15:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -2678,17 +2713,17 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > > if (!rt_count || wined3d_resource_is_offscreen(rts[0]->resource)) > { > + memset(context->blit_targets, 0, gl_info->limits.buffers * sizeof(context->blit_targets)); Is that sizeof missing a '*'?

1 0

Re: [PATCH 1/6] comctl32/tests: Don't dump successful sequences on Windows.
by Nikolay Sivov April 5, 2017

April 5, 2017

On 05.04.2017 10:15, Stefan Dösinger wrote: > --- > dlls/comctl32/tests/msg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/comctl32/tests/msg.h b/dlls/comctl32/tests/msg.h > index 3fa0fae..b30b5d8 100644 > --- a/dlls/comctl32/tests/msg.h > +++ b/dlls/comctl32/tests/msg.h > @@ -369,7 +369,7 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > context, expected->message, actual->message); > } > > - if(todo && !failcount) /* succeeded yet marked todo */ > + if(todo && !failcount && !broken(TRUE)) /* succeeded yet marked todo */ > { > dump++; > todo_wine > This patch is marked is failed by testbot, but it looks like bot inability to deal with header file change in tests directory, as it still tries to run some tests. Anyway, could you make it look similar to user32/tests/msg.c? It's using: --- if( todo && !failcount) /* succeeded yet marked todo */ todo_wine { if (!strcmp(winetest_platform, "wine")) dump++; --- Platform is tested directly. It's not the only place where it's done like that, and it's more readable than broken(1), I think.

3 2

Re: [PATCH 2/4] ws2_32/tests: Added WSARecv tests using completion function.
by Marvin April 5, 2017

April 5, 2017

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=29976 Your paranoid android. === w2008s64 (64 bit sock) === sock.c:6817: Test failed: got 0

1 0