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

Re: [PATCH 3/4] d3d9/tests: Accept alpha channel differences in shadow_test.
by Marvin April 21, 2017

April 21, 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=30337 Your paranoid android. === w8 (32 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

2 1

Re: [PATCH 1/4] ddraw/tests: Don't use DDBLT_COLORFILL in test_flip (v2).
by Marvin April 21, 2017

April 21, 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=30335 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6945: Test failed: Got unexpected color 0x00000000. ddraw1.c:6949: Test failed: Got unexpected color 0x00000000. ddraw1.c:7012: Test failed: Got unexpected color 0x00000000. ddraw1.c:7014: Test failed: Got unexpected color 0x00000000.

2 1

Re: [Tools v2] winetest/dissect: Check the build id and get its details in one Git call.
by Alexandre Julliard April 21, 2017

April 21, 2017

Francois Gouget <fgouget(a)codeweavers.com> writes: > get_build_info() only returns an empty subject if the commit does not > exist. It may still exist but not be a proper commit SHA-1. I'm not sure it's a good idea to relax that test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/8] d3dx9: Support parameters sharing in effect.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 11 ++- > dlls/d3dx9_36/effect.c | 197 +++++++++++++++++++++++++++++++++++++++++- > dlls/d3dx9_36/tests/effect.c | 17 ++-- > 3 files changed, 211 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index da4564d..d6d4280 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -215,15 +215,22 @@ struct d3dx_parameter > struct d3dx_parameter *annotations; > struct d3dx_parameter *members; > > - struct d3dx_parameter *referenced_param; > struct d3dx_param_eval *param_eval; > > struct d3dx_parameter *top_level_param; > + union > + { > + struct d3dx_parameter *referenced_param; > + struct d3dx_parameter *shared_param; > + }; > + LONG shared_refcount; > }; I think you mentioned this before but it shouldn't be necessary to store the whole parameter structure in the pool. I guess it could be improved after the fact but it shouldn't be too complicated to do it right away. Probably it could just be shared_param_list[] from patch 8/8 and shared_refcount (which at that point won't need to be in struct d3dx_parameter anymore), in addition to data. You could access the other parameter fields through shared_param_list[0]. > +static void d3dx_pool_sync_shared_parameter(struct ID3DXEffectPoolImpl *pool, struct d3dx_parameter *param) > +{ > + unsigned int i, free_entry_index; > + LONG new_refcount; > + > + if (!(param->flags & PARAMETER_FLAG_SHARED) || !pool > + || is_param_type_sampler(param->type)) > + return; > + > + free_entry_index = pool->parameter_count; > + for (i = 0; i < pool->parameter_count; ++i) > + { > + if (!pool->parameters[i]->shared_refcount) > + free_entry_index = i; > + else if (is_same_parameter(param, pool->parameters[i])) > + break; > + } > + if (i == pool->parameter_count) > + { > + i = free_entry_index; > + if (i >= pool->table_size) > + { > + struct d3dx_parameter ** new_alloc; No whitespace after "**", please. > + else > + { > + new_size = pool->table_size * 2; > + new_alloc = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, pool->parameters, > + sizeof(*pool->parameters) * new_size); > + if (!new_alloc) > + { > + ERR("Out of memory.\n"); > + return; > + } > + } > + pool->parameters = new_alloc; > + pool->table_size = new_size; > + } > + pool->parameters[i] = HeapAlloc(GetProcessHeap(), > + HEAP_ZERO_MEMORY, sizeof(*pool->parameters[i])); > + copy_parameter_structure(param, pool->parameters[i], NULL, FALSE); > + param_set_data_pointer(pool->parameters[i], (unsigned char *)param->data, FALSE, FALSE); > + if (i == pool->parameter_count) > + pool->parameter_count++; > + } I don't think this works. HeapReAlloc might move the memory block and that would break the preexisting effects using the pool (and also the previous parameters of the new effect). HEAP_REALLOC_IN_PLACE_ONLY would avoid that but it also makes it easier for the reallocation to fail. I see two ways to fix this: - refresh all the parameters of the effects that are in the pool when you have to reallocate (shared_param_list[] might help here) - allocate the memory in chunks, keeping an array (or list) of chunks which you allocate (but never resize) as needed

2 1

Re: [Tools v2] winetest: Get rid of $gitdir.
by Alexandre Julliard April 21, 2017

April 21, 2017

Francois Gouget <fgouget(a)codeweavers.com> writes: > WineHQ appears to use /home/winehq/opt/source/git/wine.git as the Wine > checkout directory. After this patch the scripts will use > $workdir/wine.git so this should most likely symlink to the above > location. I'm not sure that's an improvement. > However any non-official site will actually need write access to it from > the scripts to ensure that wine.git is up to date before processing > reports. Otherwise the reports risk being rejected due to the not yet > known commit id. This could still work with a placement in tools/winehq: > one would just have to symlink that to a writable location but it does > imply placing it in $workdir may make more sense. I don't think it makes sense to put it in the website directory, it's not meant to be accessed from the web. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/8] d3dx9: Reference top level parameter instead of dirty flag.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > -static BOOL param_set_dirty_flag_ptr(void *dirty_flag_ptr, struct d3dx_parameter *param) > +static BOOL param_set_top_level_param(void *top_level_param, struct d3dx_parameter *param) > { > - param->dirty_flag_ptr = (DWORD *)dirty_flag_ptr; > + param->top_level_param = (struct d3dx_parameter *)top_level_param; > return FALSE; > } The cast is unnecessary (yeah, it was already unnecessary, I missed that earlier). It might make sense to store both? Avoiding the extra indirection in is_param_dirty() might help a tiny bit. It's fine to tackle this later on.

2 2

Re: [PATCH 8/8] d3dx9: Use local dirty flags for shared parameters.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: As I somewhat hinted at in the previous patch, this one should probably be merged with 7/8. It did help to keep them separated for the first review pass though :) > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index d6d4280..f9cbf7c 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -222,15 +222,14 @@ struct d3dx_parameter > { > struct d3dx_parameter *referenced_param; > struct d3dx_parameter *shared_param; > + struct d3dx_parameter **shared_param_list; This name is a bit confusing given that it is an array of (pointers to) matching parameters from different effects and shared_param is a pointer to the shared pool parameter. It becomes less of an issue if the new field moves to the separate shared parameter structure I mentioned. Maybe just call it "parameters"? > @@ -3193,7 +3196,16 @@ static void d3dx_pool_sync_shared_parameter(struct ID3DXEffectPoolImpl *pool, st > param_set_data_pointer(param, (unsigned char *)pool->parameters[i]->data, FALSE, TRUE); > } > new_refcount = InterlockedIncrement(&pool->parameters[i]->shared_refcount); > + if (new_refcount == 1) > + pool->parameters[i]->shared_param_list = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*pool->parameters[i]->shared_param_list)); > + else > + pool->parameters[i]->shared_param_list = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + pool->parameters[i]->shared_param_list, > + sizeof(*pool->parameters[i]->shared_param_list) * new_refcount); It's probably better to make an initial allocation for > 1 elements and then expand by doubling the size, as usual with this kind of stuff.

1 0

Re: [PATCH 6/8] d3dx9: Factor out free_parameter_data() function.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void free_parameter(struct d3dx_parameter *param, BOOL element, BOOL child) > +{ > + unsigned int i; > + > + TRACE("Free parameter %p, name %s, type %s, child %s\n", param, param->name, > + debug_d3dxparameter_type(param->type), child ? "yes" : "no"); Again, given that it's a chance for some cleanup, please add the period at the end of the message. Also I'd change the "child" part, either just using %#x or child ? "child" : "" (or something else, the point being that the current "child yes" vs "child no" looks pretty awkward). Maybe you can also trace the "element" parameter. > + if (param->param_eval) > + { > + d3dx_free_param_eval(param->param_eval); > + param->param_eval = NULL; Is setting the field to NULL necessary? Same for the others below.

1 0

Re: [PATCH 5/8] d3dx9: Reference effect pool implementation in d3dx9_base_effect structure.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct ID3DXEffectPoolImpl > +{ > + ID3DXEffectPool ID3DXEffectPool_iface; > + LONG ref; > +}; Please rename it to "d3dx_effect_pool" or similar, while you're at it. Same for the interface methods (d3dx_effect_pool_QueryInterface(), ...) We want to get rid of the MS-like names for our implementation and this seems like a good chance to clean this one up. > - TRACE("base %p, data %p, data_size %lu, effect %p\n", base, data, data_size, effect); > + TRACE("base %p, data %p, data_size %lu, effect %p, pool %p\n", base, data, data_size, effect, pool); Since you're touching it, please add a period at the end of the message.

1 0

Re: [PATCH 2/8] d3dx9/tests: Add more tests for IsParameterUsed() function.
by Matteo Bruni April 21, 2017

April 21, 2017

2017-04-20 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + todo_wine > + ok(effect3->lpVtbl->IsParameterUsed(effect3, "vs_arr2", "tech0"), > + "Unexpected IsParameterUsed result FALSE.\n"); > + todo_wine > + ok(!effect3->lpVtbl->IsParameterUsed(effect3, "vs_arr2[0]", "tech0"), > + "Unexpected IsParameterUsed result FALSE.\n"); Typo. I'd just leave out the TRUE / FALSE from these messages, one has to look up the code anyway if there is a test failure.

1 0

Re: [2/2] [v2] secur32: Add support for SECPKG_ATTR_KEY_INFO.
by Jacek Caban April 21, 2017

April 21, 2017

Hi Akihiro, The patch looks mostly good now, thanks. I have a few minor comments. On 20.04.2017 13:58, Akihiro Sagawa wrote: > +struct schan_alg_id_name { > + ALG_ID alg_id; > + const char* name; > + const WCHAR *nameW; > +}; Using an array here like const WCHAR nameW[8]; would make later initialization nicer by not requiring multiple string variables. > + > +static int comp_alg_id(const void *a, const void *b) > +{ > + const struct schan_alg_id_name *lhs = a; > + const struct schan_alg_id_name *rhs = b; > + return (int)lhs->alg_id - (int)rhs->alg_id; > +} > + > +static void* get_alg_name(ALG_ID id, BOOL wide) > +{ > + static const WCHAR ecdsaW[] = {'E','C','D','S','A',0}; > + static const WCHAR rsaW[] = {'R','S','A',0}; > + static const WCHAR desW[] = {'D','E','S',0}; > + static const WCHAR rc2W[] = {'R','C','2',0}; > + static const WCHAR triple_desW[] = {'3','D','E','S',0}; > + static const WCHAR aesW[] = {'A','E','S',0}; > + static const WCHAR rc4W[] = {'R','C','4',0}; > + static const struct schan_alg_id_name alg_name_map[] = { > + { CALG_ECDSA, "ECDSA", ecdsaW }, > + { CALG_RSA_SIGN, "RSA", rsaW }, > + { CALG_DES, "DES", desW }, > + { CALG_RC2, "RC2", rc2W }, > + { CALG_3DES, "3DES", triple_desW }, > + { CALG_AES_128, "AES", aesW }, > + { CALG_AES_192, "AES", aesW }, > + { CALG_AES_256, "AES", aesW }, > + { CALG_RC4, "RC4", rc4W }, > + }; > + const struct schan_alg_id_name *res; > + struct schan_alg_id_name key; > + > + key.alg_id = id; > + res = bsearch(&key, alg_name_map, > + sizeof(alg_name_map)/sizeof(alg_name_map[0]), sizeof(alg_name_map[0]), > + comp_alg_id); You could use id directly as a key. You don't need it to be of schan_alg_id_name* type, the key may be just ALG_ID. Thanks, Jacek

1 0

Re: [PATCH] tests: Don't evaluate the todo condition when not running on Wine.
by Sebastian Lackner April 21, 2017

April 21, 2017

On 21.04.2017 15:01, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > This cropped up because I wanted to write a todo condition involving > IsProcessDPIAware(), since this doesn't exist in XP, its address is > loaded dynamically. I could have written the condition as > pIsProcessDPIAware && pIsProcessDPIAware(), but since I know the > function is always present in Wine, that's unnecessary. Perhaps > more to the point, I didn't expect the current behaviour. > > include/wine/test.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/wine/test.h b/include/wine/test.h > index af602c0fac..fa3f90c932 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -123,7 +123,7 @@ extern void __winetest_cdecl winetest_trace( const char *msg, ... ) WINETEST_PRI > winetest_loop_todo(); \ > winetest_end_todo()) > #define todo_wine todo_if(!strcmp(winetest_platform, "wine")) > -#define todo_wine_if(is_todo) todo_if((is_todo) && !strcmp(winetest_platform, "wine")) > +#define todo_wine_if(is_todo) todo_if(!strcmp(winetest_platform, "wine") && (is_todo)) > > > #ifdef NONAMELESSUNION > I don't mind if its changed, but please note that it was intentional to check "is_todo" first. The idea was that side effects (like assigning variables, changing last error, ...) are applied on both Wine and Windows. Just think about something like: FirstCall(); todo_wine_if(SecondCall()) ok(GetLastError() == ..., "\n"); With your patch applied, it will test two entirely different things on Windows (error from FirstCall) and Wine (error from SecondCall), which would also be confusing. Best regards, Sebastian

3 3

Re: [PATCH] msvcrt: Handle synchronous flag for x64 C++ exceptions
by Piotr Caban April 21, 2017

April 21, 2017

Hi, On 04/20/17 16:42, Daniel Lehman wrote: > + if (descr->magic >= CXX_FRAME_MAGIC_VC8 && > + (descr->flags & FUNC_DESCR_SYNCHRONOUS) && > + (rec->ExceptionCode != CXX_EXCEPTION && rec->ExceptionCode != STATUS_UNWIND_CONSOLIDATE)) > + return ExceptionContinueSearch; /* handle only c++ exceptions */ I think the condition for STATUS_UNWIND_CONSOLIDATE should also check number of parameters and ExceptionInformation[0]==(ULONG_PTR)call_catch_block like it's done during unwinding. Also the code breaks unwinding for longjump when FUNC_DESCR_SYNCHRONOUS flag is set. Thanks, Piotr

1 0

Re: [PATCH 08/12] d3d10core/tests: Allow passing any interface to get_refcount().
by Henri Verbeet April 21, 2017

April 21, 2017

On 21 April 2017 at 10:59, Józef Kucia <jkucia(a)codeweavers.com> wrote: > -static ULONG get_refcount(IUnknown *iface) > +#define get_refcount(iface) get_refcount_((IUnknown *)iface) > +static ULONG get_refcount_(IUnknown *iface) You don't really need that macro.

1 0

Linux desktop integration: Fill StartupWMClass in .desktop menu entries
by Eike Hein April 21, 2017

April 21, 2017

Hi, I maintain the taskbar in Plasma 5 and would like to poke folks about a desktop integration pain point we (and our friends at other DEs) face with apps run via wine. Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699 Let me give some broader context on this. Modern DEs have a swath of UX going on that relies on being able to identify the application owning a particular window in the windowing system. "Identify the application" in practice means "map the window to a .desktop file installed in the menu file system". We want to do this because: a) Many a taskbar/dock-like UI tries to form a smooth life cycle across "launcher button", "startup notification" and "window button(s)". For each of those we need to work out the app they are associated with to be able to match them up. If it fails, ugly things like co-existing task buttons or missing startup throbbers and similar happen. b) UI these days tends to prefer to load assets such as app icons via the values defined in .desktop files instead of using the window icon, to ensure consistent results (apps may load icon assets differently from the shell, leading to asset quality issues, inconsistent theming, the icon changing between the lifecycle states mentioned in 'a', etc.) Plus the Wayland windowing system we're all migrating towards currently doesn'ㅅ have window icons. c) DEs do things like track app starts/quits for things like "Most used apps" launcher lists. To match a window to a .desktop file we rely on window and process metadata. On X11, there's the WM_CLASS window property: https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS Ideally, the second part of a X11 window's WM_CLASS matches the name of a .desktop file installed on the system. Failing that, it matches the value of StartupWMClass in that .desktop file (this is the key part I'll get back to soon). Here's some more documentation by our friends at Gnome on this standard scheme: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased (Look for WM_CLASS / StartupWMClass.) In practice, we pull many other tricks to cope with broken meta data. We try to match things by names, we grab process command lines from /proc and check them against Exec keys in .desktop files in complicated ways, ... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome does that we don't do (because I think it's brittle) is to store the name of the .desktop file an app was launched with as a private window hint on the next window that comes up (which then doesn't work when the app was launched from CLI instead of shell UI). None of these things currently allow us to handle wine very well. As of now (perhaps thanks to the patch mentioned in the linked ticket), wine sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But the .desktop files it generates don't match this by name, and they don't contain a StartupWMClass key. The process command line is the Windows-like path to the .exe, which we also can't easily match up to the complicated Exec values in wine's .desktop files. (Aside: On Wayland, there's a more modern version of this: Windows have an appid property, which should be set to a .desktop file name. I don't know what the status of Wayland support in wine is -- currently the wine clients we encounter run over Xwayland, so we're back to WM_CLASS. We hope wine will set this property correctly when the time comes, or we're happy to work with you guys to find a way to support wine.) Long story short ... could this be picked up? The goal must be to have either .desktop file names or their StartupWMClass values match whatever is set as WM_CLASS. Currently, the easiest fix would be to set StartupWMClass to the executable name set as WM_CLASS. I assume the .desktop file generator has access to this, as the .lnk file referred to by Exec should presumably contain the name of the executable to be launched. Cheers, Eike

1 0

Re: [Tools] winetest: Get rid of $gitdir.
by Francois Gouget April 21, 2017

April 21, 2017

Actually this patch depends on the next one 'winetest/dissect: Check the build id and get its details in one Git call.' I'll resubmit them in a cleaner way. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 1/4] regedit: Validate REG_SZ import data before processing it any further (v2)
by Alexandre Julliard April 21, 2017

April 21, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 6 ++++++ > programs/regedit/tests/regedit.c | 14 +++++++------- > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index 96c4564..ccd9ebe 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -293,6 +293,12 @@ static int REGPROC_unescape_string(WCHAR* str) > str[val_idx] = str[str_idx]; > break; > } > + } else if (str[str_idx] == '"') { > + WCHAR *p = str + str_idx + 1; > + while (*p == ' ' || *p == '\t') p++; > + if (*p && *p != ';') return 0; > + str[val_idx++] = str[str_idx]; > + break; That would work, but it seems to me that the comment check would be better in the caller, so that you can use the same code for validating value names. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] user32: add GetAutoRotationState/GetDisplayAutoRotationPreferences stubs
by Huw Davies April 21, 2017

April 21, 2017

On Thu, Apr 20, 2017 at 05:33:15PM -0500, Austin English wrote: > diff --git a/dlls/user32/misc.c b/dlls/user32/misc.c > index fa0502e..3581235 100644 > --- a/dlls/user32/misc.c > +++ b/dlls/user32/misc.c > @@ -910,3 +910,24 @@ LRESULT WINAPI ImeWndProcW( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) > > return DefWindowProcW(hwnd, msg, wParam, lParam); > } > + > +/********************************************************************** > + * GetAutoRotationState [USER32.@] > + */ > +BOOL WINAPI GetAutoRotationState( AR_STATE *state ) > +{ > + *state = AR_NOT_SUPPORTED; > + FIXME("(%p): stub\n", state); > + return TRUE; > +} > + I think these would be better in sysparams.c. I realise that there are already functions of this nature in misc.c - they could probably be moved across too. User32 does indeed have some odd 'misc' like functions, but these aren't them. Also, we'd generally put the FIXME() at the start of the function, not after the assignment. Apart from that, this looks good to me. Huw.

1 0

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS
by 许文龙 April 20, 2017

April 20, 2017

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS

2 1

Re: [05/10] webservices: Add support for outgoing TCP connections.
by Alexandre Julliard April 20, 2017

April 20, 2017

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/webservices/channel.c | 286 ++++++++++++++++++++++++++------- > dlls/webservices/listener.c | 16 +- > dlls/webservices/webservices_private.h | 5 + > 3 files changed, 240 insertions(+), 67 deletions(-) This breaks the Android build: x86_64-linux-android-gcc -m64 -c -o proxy.o ../../../wine/dlls/webservices/proxy.c -I. -I../../../wine/dlls/webservices \ -I../../include -I../../../wine/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret In file included from ../../../wine/dlls/webservices/webservices_private.h:19:0, from ../../../wine/dlls/webservices/proxy.c:29: ../../../wine/include/ws2tcpip.h:57:16: error: conflicting types for 'socklen_t' ../../../wine/include/ws2tcpip.h:29:18: note: in definition of macro 'WS' In file included from /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/stdio.h:50:0, from ../../../wine/dlls/webservices/proxy.c:19: /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/sys/types.h:127:21: note: previous declaration of 'socklen_t' was here -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin April 20, 2017

April 20, 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=30284 Your paranoid android. === w864 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8096: Test failed: Got unexpected color 0x00000080 for no color attribute test. === w1064 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [v3 PATCH 1/2] wined3d: Add dirty region tracking.
by Marvin April 20, 2017

April 20, 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=30282 Your paranoid android. === w864 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [PATCH] mfplat: Implement MFCreateAttributes
by Nikolay Sivov April 20, 2017

April 20, 2017

On 04/20/2017 10:44 AM, Alistair Leslie-Hughes wrote: > +{ > + mfattributes *This = impl_from_IMFAttributes(iface); > + > + if(IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_IMFAttributes)) > + { > + TRACE("(IID_IUnknown %p)\n", object); > + *object = This; > + } > + else > + { > + FIXME("(%s, %p)\n", debugstr_guid(riid), object); > + *object = NULL; > + return E_NOINTERFACE; > + } > + > + IUnknown_AddRef((IUnknown*)*object); > + return S_OK; > +} Please add a regular TRACE for this method, and return iface or interface pointer from This, instead of This itself. Trace you have now is inaccurate. > +HRESULT WINAPI MFCreateAttributes(IMFAttributes **attributes, UINT32 size) > +{ > + mfattributes *object; > + > + TRACE("%p, %d\n", attributes, size); > + > + object = HeapAlloc( GetProcessHeap(), 0, sizeof(*attributes) ); > + if(!object) > + return E_OUTOFMEMORY; This should use sizeof(*object).

2 1

Re: [v2 PATCH] mfplat: Implement MFCreateAttributes
by Dmitry Timoshkov April 20, 2017

April 20, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +typedef struct _mfattributes > +{ > + IMFAttributes IMFAttributes_iface; > + LONG ref; > +} mfattributes; Please try to exchange these two lines in the structure above and see what happens. -- Dmitry.

1 0

Review | endproc.c: Implement ProcessPage_OnEndProcessTree
by Akarsha Sehwag April 19, 2017

April 19, 2017

Hi Could someone take out a little time to review the code once? Bug I intend to solve: https://bugs.winehq.org/show_bug.cgi?id=39640 I am new to wine. So, I would appreciate suggestions regarding my coding style if that's not-so-perfect according to wine standards. Or any other problems with the code I have written. I apologize for submitting an untested code earlier. I hope now it works fine. /*-------------------------------------------CODE--------------------------------------------------*/ typedef struct process_list { DWORD *pid; /*dynamic array to store the process IDs*/ SIZE_T count; /*index to maintain the last entry of the array;*/ SIZE_T size; /*the current size of the pid array*/ } process_list; static void init_process_list(process_list *list) { list->size = 4; /*initialise size with 4. Will increase if necessary.*/ list->pid = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, list->size * sizeof(list->pid)); list->count = 0; } static void increase_list_size(process_list *list) { list->size *= 2; list->pid = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, list->pid, list->size * sizeof(list->pid)); *//DOUBT: *Would sizeof(list->pid) be better or sizeof(int)? //Since in the former case, since list->pid is actually a pointer to DWORD, so //sizeof(list->pid) would return 8 bytes and not 4 bytes. } static void process_list_append(process_list *list, DWORD id) { if(list->count == list->size) increase_list_size(list); list->pid[list->count] = id; list->count += 1; } static void free_process_list(process_list *list) { HeapFree(GetProcessHeap(), 0, list->pid); } static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) { PROCESSENTRY32 entry; SIZE_T start, end, i ; start = list->count; entry.dwSize = sizeof(entry); if(!Process32First(snapshot, &entry)) return; do { if(entry.th32ParentProcessID == pid) process_list_append(list, entry.th32ProcessID); } while (Process32Next(snapshot, &entry)); end = list->count; for(i = start; i < end; ++i) { enum_process_children(snapshot, list, list->pid[i]); } } void ProcessPage_OnEndProcessTree(void) { {...} process_list list; SIZE_T i; HANDLE snapshot; {...} init_process_list(&list); if(list.pid == NULL) return; process_list_append(&list, dwProcessId); snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(!snapshot) return; enum_process_children(snapshot, &list, dwProcessId); CloseHandle(snapshot); for(i = 0; i < list.count; ++i) { hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list.pid[i]); if (!hProcess) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); break; } if (!TerminateProcess(hProcess, 0)) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); } CloseHandle(hProcess); } free_process_list(&list); } /*---------------------------------------END OF CODE------------------------------------------*/ Thanks and regards -- Akarsha Sehwag

1 0