- wine-devel - winehq.org

Re: [PATCH] configure: Check for GnuTLS block size function
by Alexandre Julliard 16 Jun '16

16 Jun '16

Michael Cronenworth <mike(a)cchtml.com> writes: > diff --git a/configure.ac b/configure.ac > index 7f234b2..6ae8dde 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1268,6 +1268,9 @@ then > WINE_CHECK_LIB_FUNCS(gnutls_hash,[$GNUTLS_LIBS],, > [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no bcrypt hash support.])])])], > [GNUTLS_CFLAGS=""])]) > + WINE_PACKAGE_FLAGS(GNUTLS,[gnutls],,,, > + [WINE_CHECK_LIB_FUNCS(gnutls_cipher_get_block_size,[$GNUTLS_LIBS],, > + [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no block size support.])])]) This won't have any effect, since you don't check the resulting define. In any case I don't think this needs a configure check, since we already have a fallback. You can simply declare the function pointer without using the MAKE_FUNCPTR macro. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] tools: Use type BOOL where appropriate.
by Alexandre Julliard 16 Jun '16

16 Jun '16

Hadrien Boizard <h.boizard(a)gmail.com> writes: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > tools/wrc/parser.y | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) In general, tools don't use the Windows API, so BOOL is not necessarily appropriate either. Technically it's not wrong, but IMO it's not worth changing the code for it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Include system headers before winsock2.h in http.c.
by Alexandre Julliard 16 Jun '16

16 Jun '16

Jacek Caban <jacek(a)codeweavers.com> writes: > Fixes compilation on NetBSD, where zlib.h doesn't include stdlib.h. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/wininet/http.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) This breaks the mingw build: In file included from ../../../wine/include/winsock2.h:47:0, from ../../../wine/dlls/wininet/http.c:42: ../../../wine/include/winsock.h:445:19: error: redefinition of ‘struct timeval’ ../../../wine/include/winsock.h:136:19: note: in definition of macro ‘WS’ In file included from /usr/share/mingw-w64/include/time.h:246:0, from ../../../wine/dlls/wininet/http.c:39: /usr/share/mingw-w64/include/_timeval.h:10:8: note: originally defined here Makefile:296: recipe for target 'http.o' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 04/10] d3dx9_30: Share the source with d3dx9_36
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > @@ -75,3 +75,21 @@ D3DX_CPU_OPTIMIZATION WINAPI D3DXCpuOptimizations(BOOL enable) > FIXME("%i - stub\n", enable); > return D3DX_NOT_OPTIMIZED; > } It's probably better to move the D3DXCpuOptimizations() implementation to d3dx9_36 in this patch so you can then drop the forwards from <= d3dx9_29.dll in the following patches.

1 0

Re: [PATCH 01/10] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > -@ stdcall D3DXComputeNormalMap(ptr ptr ptr long long long) d3dx9_36.D3DXComputeNormalMap ... > +@ stub D3DXComputeNormalMap(ptr ptr ptr long long float) Nicely spotted (also for D3DXFrameFind), that should probably be applied to all the DLLs and separately from this patch though. I'm sending a patch for it. > +@ stdcall D3DXGetShaderConstantTableEx(ptr long ptr) This function shouldn't be exported by d3dx9_33.dll. WRT D3DXDebugMute() and D3DXGetDriverLevel(), I would move the implementation to util.c or some other file and avoid duplicating the code in every d3dx9_xx_main.c.

1 0

Re: [PATCH 3/5] d3drm/tests: Add refcount tests for IDirect3DRMFrame*. (v2)
by Stefan Dösinger 15 Jun '16

15 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > + ok(ref1 == ref2, "Expected ref1 == ref2, got ref1 = %u, ref2 = %u.\n", ref1, ref2); > + ok(ref2 == ref3, "Expected ref2 == ref3, got ref2 = %u, ref3 = %u.\n", ref2, ref3); > + ok(ref1 == ref3, "Expected ref1 == ref3, got ref1 = %u, ref3 = %u.\n", ref1, ref3); I think you can assume basic logic still applies to d3drm :-) . There's no need to test ref1 == ref3 after you made sure (ref1 == ref2 && ref2 == ref3) . More importantly though, patch 5 somewhat suggests that you're planning to have a full-blown QI and refcounting test for frames too. If that's the case there's no need to add this patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcYrAAoJEN0/YqbEcdMwudEP/1BMGtCEhuN9i8BbphtECIuF otKTT8qBR1LFP0QocHWntJtCteJ69vq70dfxp764++wqt7UWuGrZhPdKG+6Qjb1u 9kBU6PppQNX4V0tybDgCMIEOv4HcY00FuCN4ahPu5bfBFOskXwOhzs2ne3bYHX1v iDR2NIATu2wwTkA/s/ttj5ZYuKflSl5EUC8wELFwy6IjonaICfuubvgZCVEDBc+R POeJbGbbvn/7v9Q+mfTLNDFvTdDANgTCFkIFmBxrPu2b4erFtRJQV47DVhaLGmZg BwOxV8AYnq7yEltiOkpWKgUtIC4q6U1pf7tW2uUm/4kPMM3+RviiFbX2fNKTFP6f 5rW/5xIP68ymv+Z4su24BbbMcYJPBXkHNkyk1bdARmXtTtzRQbSchdVCLCaOs81k Vmwbl7A4ZqqshTqv40DTRAQq5NWYFcvTbXdUkWZav9EtO9a0hs8PMO9GqG+RBgOu lGk9GrW/jvoWXx/knMtSuoHpkLnpPy4RuJefzVyw1NaawBfakTuUElD0/nnC2f+j 528Ft8FKM9wmJLf3v8fl4IB0vsnExkjOrbKRdWJAuvpxuZJp0rkSdXE0JrEEum44 BlgKzwWvFDl46BX/OC0pzvGlZ6417c/5JgaaPCXus9nGBPBaJx44d2QJWD/UELMS jN9KRUNfGyfcNYS4yVH1 =2nxr -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3drm: Add stubs for IDirect3DRMFrame interface. (v3)
by Stefan Dösinger 15 Jun '16

15 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > +static HRESULT WINAPI d3drm_frame1_GetVisuals(IDirect3DRMFrame *iface, IDirect3DRMVisualArray **visuals) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + struct d3drm_visual_array *array; > + > + TRACE("iface %p, visuals %p.\n", iface, visuals); > + > + if (!visuals) > + return D3DRMERR_BADVALUE; > + > + if (!(array = d3drm_visual_array_create(frame->nb_visuals, frame->visuals))) > + return E_OUTOFMEMORY; > + > + *visuals = &array->IDirect3DRMVisualArray_iface; > + > + return D3DRM_OK; > +} This is a reimplementation instead of a thunk. Intentional? The same applies to d3drm_frame1_GetTransform. > +static HRESULT WINAPI d3drm_frame1_GetSceneBackgroundDepth(IDirect3DRMFrame *iface, > + IDirectDrawSurface **surface) The indentation here is different. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcT1AAoJEN0/YqbEcdMwUHcQAIAfKv2BAfasnwRACZsGBcK9 VAftr2zuIgmlMKtQaplsZuv2ZqcyUnydOgzuXQusFfBldeKeD1ukycLx/sONpuZI ggt7AbXcslw9T0wlprTnfl+1Pna/CSbRQWhVAjeB9dCCWblBslipsj9SLr3hTOwH ppQYvk+BtoXb7A+tvVI2ch/Q8HhwWh/Q9SvVg6tUV7gQLrPG0sj4NEjG50I7VN0c PjLgZHlT7JzVDxlGoefhTPXZdL+1muSIIuxVXho+oNx6qFqiyC0+7xxlJEVR2Eyo VBzdczdYd0UcLRb0GOqyJpRcGTpYE06zahKeDyODIXeorFB0NlYFqSTD2H32RVNU M2a+xKgFLqm4zu+cabfRIvFk9wGkIRykwfm8KUY4LyZCZmlQZ21nPCAIsuolRqV6 DrmQAParbMg/fAb6L9/uB0rb/CBPGIhm3mtv00TewBG8VG16uV4vLbvtoiIJJtD4 Z6iY6x948K+jjVVkhGDRfdEJn+nQRDTKIkgsRKic9S5x/nOEyfreVutjq4vULnGk l5hRAzyzOxjP/JTMHhvYtHYbLtqjgXPi3pwhjrfGMWLKAmeRPk3A2FdsUl9A1I3I INR8LmGAo3P7a1GZ21loc5A2iftn29vcAB0mDzcotczOEsinfx7Sc4oF5fIUDZla miBufY1gPaDENTTiRcz5 =hvk0 -----END PGP SIGNATURE-----

1 0

Re: ddraw/tests: A spelling fix for a d3d ok() message.
by Francois Gouget 15 Jun '16

15 Jun '16

Anything wrong with this patch? On Sun, 29 May 2016, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > dlls/ddraw/tests/d3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index d877020..0e9a43b 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -1155,7 +1155,7 @@ static void Direct3D1Test(void) > /* Interface consistency check. */ > hr = IDirect3DDevice_GetDirect3D(Direct3DDevice1, &Direct3D_alt); > ok(hr == D3D_OK, "IDirect3DDevice_GetDirect3D failed: %08x\n", hr); > - ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer missmatch: %p != %p\n", Direct3D_alt, Direct3D1); > + ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer mismatch: %p != %p\n", Direct3D_alt, Direct3D1); > IDirect3D_Release(Direct3D_alt); > > memset(&desc, 0, sizeof(desc)); > -- > 2.8.1 > > > > -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

3 4

Re: [PATCH 5/5] d3dx9: Turn an ERR into a WARN.
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 9:51 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Hello Matteo, > > I am afraid that if application passes effect data broken an > arbitrary way then probably almost every ERR and FIXME should be changed > to WARN (at least in my code, but probably in the rest of effect > framework either). E. g., we have FIXME on not yet supported relative > addressing, but it can also happen if the application passes broken > effect code. Or do you see any difference for this case with parameter > name? I do not yet, as actually preshader and effect are compiled > together, and it is no way to get such a situation (at least if there is > some feature in fxc compiler which I am not aware of) other than > modifying effect bytecode. > > Regards, > Paul. The general idea is that FIXME refers to something that isn't (completely / correctly) implemented in Wine, so e.g. FIXME is the right choice for relative addressing. ERR is the correct choice for "internal errors" in Wine (i.e. something that shouldn't happen unless there is a bug in Wine - the ERR("Unexpected register set %u.\n", ...) is a good example of that) and WARN should be used when the application can trigger the problematic condition by misusing the API or similar. Specifically WRT this patch I just happened to notice that ERR while looking through the code and it seems to me that WARN fits better. It's not a big deal either way.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Józef Kucia 15 Jun '16

15 Jun '16

This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 5

Re: [PATCH] wined3d: Properly handle immediate NaN and Inf in GLSL backend.
by Józef Kucia 15 Jun '16

15 Jun '16

In my opinion, we do not want to solve the issue with immediate constant buffers this way. However, this patch might still be useful. Some games (Magicka 2) use shaders which contain NaN values in immediate constants. This patch represents a one way to solve the issue with NaN values in immediate constants. If we decide that we want to apply this change we should be more careful though. We probably want to use this for SM4+ shaders only, or use it only when GL_ARB_shader_bit_encoding is available. On a side note, "uintBitsToFloat" cannot be used as a constant expression (at least in GLSL 1.30), so to make this work with the immediate constant buffers patch you would have to drop "const". On Mon, Jun 13, 2016 at 9:30 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 36 +++++++++++++++++++++++++----------- > 1 file changed, 25 insertions(+), 11 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index def224c..fde4c5e 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -34,6 +34,8 @@ > > #include <limits.h> > #include <stdio.h> > +#include <stdint.h> > +#include <inttypes.h> We avoid C99 in Wine. unsigned int and %#xu should be good enough. > #ifdef HAVE_FLOAT_H > # include <float.h> > #endif > @@ -321,14 +323,26 @@ static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info > return "#version 120"; > } > > +/* Allow raw NaN and Inf in GLSL code. */ > +void wined3d_glsl_ftoa(float value, char *s) The function should be static. > +{ > + if (!isfinite(value)) > + { > + /* We need a buffer of at least 28 characters. */ > + snprintf(s, 28, "uintBitsToFloat(%"PRIu32"u)", *(uint32_t *)&value); It seems that 29 bytes are needed at least (including the null character). > + } > + else > + wined3d_ftoa(value, s); > +} In wined3d, generally, if one block in if-else statement needs curly braces we use curly braces for all blocks in this statement. else { wined3d_ftoa(value, s); } > + > static void shader_glsl_append_imm_vec4(struct wined3d_string_buffer *buffer, const float *values) > { > - char str[4][17]; > + char str[4][28]; > > - wined3d_ftoa(values[0], str[0]); > - wined3d_ftoa(values[1], str[1]); > - wined3d_ftoa(values[2], str[2]); > - wined3d_ftoa(values[3], str[3]); > + wined3d_glsl_ftoa(values[0], str[0]); > + wined3d_glsl_ftoa(values[1], str[1]); > + wined3d_glsl_ftoa(values[2], str[2]); > + wined3d_glsl_ftoa(values[3], str[3]); > shader_addline(buffer, "vec4(%s, %s, %s, %s)", str[0], str[1], str[2], str[3]); > } > > @@ -2299,7 +2313,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > const struct wined3d_gl_info *gl_info = ins->ctx->gl_info; > const char *prefix = shader_glsl_get_prefix(version->type); > struct glsl_src_param rel_param0, rel_param1; > - char imm_str[4][17]; > + char imm_str[4][28]; > > if (reg->idx[0].offset != ~0U && reg->idx[0].rel_addr) > shader_glsl_add_src_param(ins, reg->idx[0].rel_addr, WINED3DSP_WRITEMASK_0, &rel_param0); > @@ -2513,7 +2527,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)reg->immconst_data, register_name); > + wined3d_glsl_ftoa(*(const float *)reg->immconst_data, register_name); > break; > case WINED3D_DATA_INT: > sprintf(register_name, "%#x", reg->immconst_data[0]); > @@ -2533,10 +2547,10 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > sprintf(register_name, "vec4(%s, %s, %s, %s)", > imm_str[0], imm_str[1], imm_str[2], imm_str[3]); It looks like shader_glsl_append_imm_vec4() could be called there instead.

4 8

Re: [PATCH] wined3d: Correct memory size for Geforece 9600 GT (resend)
by Henri Verbeet 15 Jun '16

15 Jun '16

On 15 June 2016 at 09:48, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/wined3d/directx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > This isn't necessarily wrong, but why is this needed/more correct?

2 2

Fwd: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by DavidL 15 Jun '16

15 Jun '16

Sorry, keep hitting reply instead of reply-all to make sure the list-serve has a copy. ---------- Forwarded message ---------- From: DavidL <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 12:05 AM Subject: Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping To: Ken Thomases <ken(a)codeweavers.com> As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be. On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote: > > > On Mon, Jun 13, 2016 at 2:46 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Is there reason to expect that these elements (sliders, dials, wheels) >> will be listed after the "proper" axes (x, y, z, etc.) in the children >> array? Since the proper axes are specific and these elements should only >> be mapped to unused axes, I think they should be enumerated in a separate >> pass after everything else has had a shot. Note that >> collect_joystick_elements() is recursive, so it's not right to do it in a >> separate loop within collect_joystick_elements(). Probably, you'll want to >> call it twice from open_joystick(), with a flag to indicate which mode it >> should operate in. > > > This where the Microsoft source documentation get *really* fuzzy. There > are all sorts of possible mappings in the rare case where there is both a > HID/Dinput Z-axis and a slider/dial/wheel. Microsoft gave 4-5 different > variations of how it could go and in some of these mappings, the slider > would take precedence over the reported HID Z-axis when mapping to the > Winmm Z-axis such that slider -> WinmmZ is correct and the HID Z-axis is > then ignored. So I decided to follow the Linux Winmm version and simply > have whichever element is listed by the joystick first, wins. If it is the > axis, it's the axis, if it is the slider, it's the slider. This actually is > one of the ways Microsoft says to decide proper HID mappings to Winmm (and > it seems like that for the elements within a joystick, the elements are > always reported in the same order such that a user shouldn't experience the > axes mappings changing each time they start up Wine/reconnect a device*). > There is no 1 correct mapping for all cases. I guess ideally we would have > a way of allowing the user to remap the joystick axes in the registry > (maybe that would work even now? I don't know - I've seen some emails on > that already in the wine-devel list serve but I don't know what the status > of that kind of capability is) but even Microsoft states on of their pages > that this is a pretty rare corner case. > > > OK, fine by me. > > > *Note: in my testing this is *not* the same for OS X (I guess macOS now) > reporting back devices - which human interface device is reported first > seems to be random in my testing when I had both a virtual and physical > joystick setup. Historically Winmm games would only take input from the > first reported device - under Mac-Wine, I've noticed the games seem to be > taking input from both my physical and virtual joysticks (sometimes > regardless of what the game was saying it was doing!). This has both good > and bad potential and is not necessarily behavior we should spend effort > trying to get rid of. Not sure how the Linux version behaves in this > situation in terms of joystick order and input from multiple sources. > > > It was taking input from both joysticks in the same run? At the same > time? If so, can you figure out how that's happening? It really > shouldn't, as near as I can see. > > Or was it just arbitrarily picking which was first and therefore active > for any given run? If this, then it's < > https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less. > > -Ken > >

2 4

Re: [v2 02/10] msvcirt: Implement ostream constructors/destructors
by Piotr Caban 15 Jun '16

15 Jun '16

On 06/14/16 19:01, Iván Matellanes wrote: > On 14/06/16 16:20, Piotr Caban wrote: >> On 06/14/16 16:40, Iván Matellanes wrote: >>> /* ??_Dostream@@QAEXXZ */ >>> @@ -2287,23 +2341,48 @@ ostream* __thiscall ostream_assign(ostream >>> *this, const ostream *rhs) >>> DEFINE_THISCALL_WRAPPER(ostream_vbase_dtor, 4) >>> void __thiscall ostream_vbase_dtor(ostream *this) >>> { >>> - FIXME("(%p) stub\n", this); >>> + ios *base = ostream_to_ios(this); >>> + >>> + TRACE("(%p)\n", this); >>> + >>> + ostream_dtor(base); >>> + ios_dtor(base); >>> } >> The base should be computed using ostream_get_ios while calling ios_dtor: >> TRACE("(%p)\n", this); >> ostream_dtor(ostream_to_ios(this)); >> ios_dtor(ostream_get_ios(this)); > Do you mind explaining why is that required? I can't see the reason ostream_vbase_dtor can be used to destroy object that has virtual base in any position pointer by vbtable. ostream_get_ios computes it using object's vbtable. You can easily see it by overwriting ostream->vbtable with garbage, the application will crash then on Windows. On the other hand ostream_dtor is a virtual function that assumes "this" is at fixed offset from "base" that is passed to it. It's done this way because it has no access to vbtable. It's why you need to use ostream_to_ios in this case. There's no real need to call ostream_dtor here because it's an empty function (I don't know if it should be called here or if ostream_vbase_dtor should only destroy the vbase). Thanks, Piotr

2 2

Re: [PATCH] riched20: Remove duplicated condition and duplicated test
by Huw Davies 15 Jun '16

15 Jun '16

On Tue, Jun 14, 2016 at 08:56:41PM +0300, Nikolay Sivov wrote: > diff --git a/dlls/riched20/richole.c b/dlls/riched20/richole.c > index 1013e67..a2f23c9 100644 > --- a/dlls/riched20/richole.c > +++ b/dlls/riched20/richole.c > @@ -1976,7 +1976,7 @@ static HRESULT range_Collapse(LONG bStart, LONG *start, LONG *end) > if (*end == *start) > return S_FALSE; > > - if (bStart == tomEnd || bStart == tomFalse) > + if (bStart == tomEnd) > *start = *end; > else > *end = *start; > > diff --git a/dlls/riched20/tests/richole.c b/dlls/riched20/tests/richole.c > index 6da3ce3..33043fd 100644 > --- a/dlls/riched20/tests/richole.c > +++ b/dlls/riched20/tests/richole.c > @@ -1361,18 +1361,6 @@ static void test_ITextRange_Collapse(void) > first = 4, lim = 8; > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomTrue); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 4, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 4, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomStart); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); > @@ -1385,18 +1373,6 @@ static void test_ITextRange_Collapse(void) > > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomFalse); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 8, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 8, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomEnd); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); I don't think we should remove the extra tests, especially as tomTrue != tomStart and it's documentented to work with either. Leaving the tomFalse tests in is fine too. Huw.

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Sebastian Lackner 15 Jun '16

15 Jun '16

On 14.06.2016 09:09, Marcus Meissner wrote: > From: Austin English <austinenglish(a)gmail.com> > > https://bugs.winehq.org/show_bug.cgi?id=18745 > > Report 2MB minimum page size on x86 32bit and 64bit on Linux. > > This assumes that all x86 processors and the 64/32bit emulation mode > have hugetable support and it is always enabled. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > Signed-off-by: Austin English <austinenglish(a)gmail.com> As pointed out on IRC, the order of the sign-offs is wrong here. Your own signoff should always be the last because you have to take responsibility when you send a patch. > --- > dlls/kernel32/cpu.c | 15 +++++++++++++++ > dlls/kernel32/kernel32.spec | 2 +- > dlls/kernel32/tests/process.c | 16 ++++++++++++++++ > 3 files changed, 32 insertions(+), 1 deletion(-) > > diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c > index f48fcf0..f8b2c3d 100644 > --- a/dlls/kernel32/cpu.c > +++ b/dlls/kernel32/cpu.c > @@ -291,3 +291,18 @@ err: > } > return TRUE; > } > + > +/*********************************************************************** > + * GetLargePageMinimum (KERNEL32.@) > + */ > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux I do not see any need for that #ifdef linux. Its more architecture specific than linux specific. Dmitry already mentioned the same concern on the mailing list. > +#if defined(__i386___) || defined(__x86_64__) > + /* Linux x86 hugepages are minimum 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index ec7155b6e..0fc4dcb 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -696,7 +696,7 @@ > @ stdcall GetHandleInformation(long ptr) > @ stub -i386 GetLSCallbackTarget > @ stub -i386 GetLSCallbackTemplate > -# @ stub GetLargePageMinimum > +@ stdcall GetLargePageMinimum() > @ stdcall GetLargestConsoleWindowSize(long) > @ stdcall GetLastError() > @ stub GetLinguistLangSize > diff --git a/dlls/kernel32/tests/process.c b/dlls/kernel32/tests/process.c > index 61dcdc2..e9acfd3 100644 > --- a/dlls/kernel32/tests/process.c > +++ b/dlls/kernel32/tests/process.c > @@ -88,6 +88,7 @@ static BOOL (WINAPI *pProcess32Next)(HANDLE, PROCESSENTRY32*); > static BOOL (WINAPI *pThread32First)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pThread32Next)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pGetLogicalProcessorInformationEx)(LOGICAL_PROCESSOR_RELATIONSHIP,SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX*,DWORD*); > +static SIZE_T (WINAPI *pGetLargePageMinimum)(void); > > /* ############################### */ > static char base[MAX_PATH]; > @@ -252,6 +253,7 @@ static BOOL init(void) > pThread32First = (void *)GetProcAddress(hkernel32, "Thread32First"); > pThread32Next = (void *)GetProcAddress(hkernel32, "Thread32Next"); > pGetLogicalProcessorInformationEx = (void *)GetProcAddress(hkernel32, "GetLogicalProcessorInformationEx"); > + pGetLargePageMinimum = (void *)GetProcAddress(hkernel32, "GetLargePageMinimum"); > > return TRUE; > } > @@ -3138,6 +3140,19 @@ static void test_GetLogicalProcessorInformationEx(void) > HeapFree(GetProcessHeap(), 0, info); > } > > +static void test_largepages(void) > +{ > + SIZE_T size; > + > + if (!pGetLargePageMinimum) { > + skip("No GetLargePageMinimum support.\n"); > + return; > + } > + size = pGetLargePageMinimum(); > + > + ok((size == 0) || (size == 2*1024*1024) || (size == 4*1024*1024), "GetLargePageMinimum reports %ld size\n", size); > +} > + > START_TEST(process) > { > HANDLE job; > @@ -3210,6 +3225,7 @@ START_TEST(process) > test_GetNumaProcessorNode(); > test_session_info(); > test_GetLogicalProcessorInformationEx(); > + test_largepages(); > > /* things that can be tested: > * lookup: check the way program to be executed is searched >

3 3

Re: [v4 4/4] winejoystick.drv/joystick_osx.c: adds sim page element controls
by Ken Thomases 15 Jun '16

15 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Adds support for input features defined by HID Simulation page: Rudder > (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz). > +static int axis_for_usage_Sim(int usage) > +{ > + switch (usage) > + { > + case kHIDUsage_Sim_Rudder: return AXIS_RZ; > + case kHIDUsage_Sim_Throttle: return AXIS_Z; > + case kHIDUsage_Sim_Steering: return AXIS_X; > + case kHIDUsage_Sim_Accelerator: return AXIS_Y; > + case kHIDUsage_Sim_Brake: return AXIS_RZ; > + } Is it intentional that Rudder and Brake both map to the same axis? Later, when enumerating elements, which comes first and thus "wins" the collision (if they ever appear on the same device) is arbitrary based on enumeration order. That OK? > @@ -404,66 +418,100 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kIOHIDElementTypeInput_Axis: > - { > - TRACE("kIOHIDElementTypeInput_Axis; ignoring\n"); > - break; > - } > case kIOHIDElementTypeInput_Misc: It seems that treating kIOHIDElementTypeInput_Axis the same as kIOHIDElementTypeInput_Misc is a separate issue from adding support for the Sim page inputs. Or is there an interrelationship that I'm not aware of? Is it the case that both Axis and Misc elements can be present with either GD or Sim usage pages? Some of the debug logging statements have been changed to say "kIOHIDElementTypeInput_Axis/Misc" while others have been left as "kIOHIDElementTypeInput_Misc". Is that indicative of something or just an oversight? > @@ -614,7 +662,7 @@ LRESULT driver_joyGetDevCaps(DWORD_PTR device_id, JOYCAPSW* caps, DWORD size) > { > int i; > > - /* complete 95 structure */ > + /* complete Win95 structure */ This is an unrelated change. -Ken

2 3

Fwd: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements
by DavidL 15 Jun '16

15 Jun '16

I made the changes to the patches we talked about and added the patch below. All it does is ignore "feature"-type elements which aren't meant for end user consumption, suppressing the FIXME message in Trace logs for those elements. Since these element types are un-handled by Winmm, I don't think a FIXME message is necessary for them. However, if you feel we should keep the fixme messages in place, I'm fine with that too. Cheers, David ---------- Forwarded message ---------- From: David Lawrie <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 8:33 PM Subject: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements To: wine-patches <wine-patches(a)winehq.org> Cc: David Lawrie <david.dljunk(a)gmail.com> "Describes input and output elements not intended for consumption by the end user." Ignore, as otherwise, comes up as a FIXME in Trace logs. Source: https://developer.apple.com/library/mac/documentation/IOKit/Reference/ IOHIDKeys_iokit_header_reference/#//apple_ref/c/tdef/IOHIDElementType Tested on OS X 10.10.5. Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> --- dlls/winejoystick.drv/joystick_osx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c index ad82dd7..12ccff7 100644 --- a/dlls/winejoystick.drv/joystick_osx.c +++ b/dlls/winejoystick.drv/joystick_osx.c @@ -514,6 +514,9 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll } break; } + case kIOHIDElementTypeFeature: + /* Describes input and output elements not intended for consumption by the end user. Ignoring. */ + break; default: FIXME("Unhandled type %i\n",type); break; -- 1.7.12.4 (Apple Git-37)

1 0

Re: [v4 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
by Ken Thomases 15 Jun '16

15 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Ry now maps to U, Rx now maps to V. Windows defines Winmm U as Dinput Ry > and V as Dinput Rx. Original joystick_osx.c mapping was other way > around. This is also a bug in the Linux Winmm joystick version (not > fixed with this patch). > > Sources: > https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85)… > https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85)… > > Tested on OS X 10.10.5. > > Tested on Red Baron 3D, X-wing vs Tie Fighter, X-wing Alliance, > Independence War deluxe w/ Logitech Extreme 3D pro and ControllerMate > virtual joystick with 5/6 axes. I originally wrote this code, but I think I was largely basing it on the Linux code without having a strong handle on the behavior of the R* axes. Your testing is probably the most thorough that's been done for the Mac code, although I would expect the Linux code to have been tested pretty well. Maybe the Linux code is correct and it's only the comments about what the joystick device is providing that are wrong. So, the code changes appear to properly implement the logic you've described above, but I don't know if that's correct. The cited MSDN pages are not terribly clear. That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead. -Ken

2 3

Re: d3dx10_43: Add D3DX10FilterTexture stub
by Matteo Bruni 14 Jun '16

14 Jun '16

2016-06-13 17:02 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: Can you please also add the D3DX10_FILTER_FLAG type declaration to d3dx10tex.h? > + FIXME("texture %p, src_level %u, filter %u stub!\n", texture, src_level, filter); filter is a flags bitmask, please trace it with %#x or similar.

1 0

Re: [PATCH] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni 14 Jun '16

14 Jun '16

2016-06-10 10:33 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=21817 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx9_33/Makefile.in | 22 +- > dlls/d3dx9_33/d3dx9_33.spec | 667 +++++++++++++++++++++--------------------- > dlls/d3dx9_33/d3dx9_33_main.c | 19 ++ > tools/make_specfiles | 1 - > 4 files changed, 373 insertions(+), 336 deletions(-) > > diff --git a/dlls/d3dx9_33/Makefile.in b/dlls/d3dx9_33/Makefile.in > index 0934eab..1106d11 100644 > --- a/dlls/d3dx9_33/Makefile.in > +++ b/dlls/d3dx9_33/Makefile.in > @@ -1,7 +1,25 @@ > MODULE = d3dx9_33.dll > -IMPORTS = d3d9 > +IMPORTS = d3d9 d3dcompiler dxguid d3dxof ole32 gdi32 user32 wined3d You don't want to import wined3d here. It looks good otherwise, at a quick glance. Do you mind also writing similar patches for the other d3dx9_xx and d3dcompiler_xx DLLs?

1 0

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Nikolay Sivov 14 Jun '16

14 Jun '16

On 14.06.2016 21:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > index 18ca9d4..85b2b83 100644 > --- a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > @@ -7,7 +7,7 @@ > @ cdecl _aligned_realloc(ptr long long) ucrtbase._aligned_realloc > @ stub _aligned_recalloc > @ cdecl _callnewh(long) ucrtbase._callnewh > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) ucrtbase._calloc_base > @ cdecl _expand(ptr long) ucrtbase._expand > @ stub _free_base > @ cdecl _get_heap_handle() ucrtbase._get_heap_handle > diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec > index 690072b..365674b 100644 > --- a/dlls/ucrtbase/ucrtbase.spec > +++ b/dlls/ucrtbase/ucrtbase.spec > @@ -211,7 +211,7 @@ > @ cdecl _c_exit() MSVCRT__c_exit > @ cdecl _cabs(long) MSVCRT__cabs > @ cdecl _callnewh(long) > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) MSVCRT_calloc > @ cdecl _cexit() MSVCRT__cexit > @ cdecl _cgets(ptr) > @ stub _cgets_s > Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.

3 3

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Sebastian Lackner 14 Jun '16

14 Jun '16

On 14.06.2016 20:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Martin Storsjo tried the same approach already, and it was rejected. If I remember correctly separate wrapper functions were preferred in this case.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Henri Verbeet 14 Jun '16

14 Jun '16

On 12 June 2016 at 22:21, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > +static HRESULT WINAPI is_warp_cb(GUID *guid, char *description, char *name, > + D3DDEVICEDESC *hal_desc, D3DDEVICEDESC *hel_desc, void *ctx) > +{ > + BOOL *is_warp = ctx; > + if (IsEqualGUID(guid, &IID_IDirect3DHALDevice)) > + { > + *is_warp = !!(hal_desc->dwDevCaps & D3DDEVCAPS_TEXTURESYSTEMMEMORY); > + return DDENUMRET_CANCEL; > + } > + return DDENUMRET_OK; > +} > + > static void test_p8_blit(void) > { > IDirectDrawSurface *src, *dst, *dst_p8; > DDSURFACEDESC surface_desc; > IDirectDraw *ddraw; > + IDirect3D *d3d; > IDirectDrawPalette *palette, *palette2; > ULONG refcount; > HWND window; > @@ -5305,6 +5318,7 @@ static void test_p8_blit(void) > PALETTEENTRY palette_entries[256]; > unsigned int x; > DDBLTFX fx; > + BOOL is_warp = FALSE; > static const BYTE src_data[] = {0x10, 0x1, 0x2, 0x3, 0x4, 0x5, 0xff, 0x80}; > static const BYTE src_data2[] = {0x10, 0x5, 0x4, 0x3, 0x2, 0x1, 0xff, 0x80}; > static const BYTE expected_p8[] = {0x10, 0x1, 0x4, 0x3, 0x4, 0x5, 0xff, 0x80}; > @@ -5322,6 +5336,16 @@ static void test_p8_blit(void) > hr = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > > + /* Locking a P8 surface crashes on WARP if a d3d device has been created. So we > + * need to find the caps via enumeration. */ > + hr = IDirectDraw_QueryInterface(ddraw, &IID_IDirect3D, (void **)&d3d); > + if (SUCCEEDED(hr)) > + { > + hr = IDirect3D_EnumDevices(d3d, is_warp_cb, &is_warp); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + IDirect3D_Release(d3d); > + } Can't you just use ddraw4/7's GetDeviceIdentifier()?

2 1

Re: [PATCH] msvcrt/tests: Add tests for mbstowcs and wcstombs with a negative count.
by Piotr Caban 14 Jun '16

14 Jun '16

Hi Alex, On 06/12/16 22:07, Alex Henrie wrote: > + ret = mbstowcs(wOut, mSimple, -1); > +todo_wine > + ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); This will cause compilation warning: ../../../../wine_src/dlls/msvcrt/tests/string.c:1863:5: warning: format '%i' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=] ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); I'm also not sure if Windows XP behavior should be marked as broken. For me newer systems behavior is broken (doesn't handle strings longer then INT_MAX). Do you have an application that depends on it? Thanks, Piotr

2 4

Re: [v2 02/10] msvcirt: Implement ostream constructors/destructors
by Piotr Caban 14 Jun '16

14 Jun '16

On 06/14/16 16:40, Iván Matellanes wrote: > /* ??_Dostream@@QAEXXZ */ > @@ -2287,23 +2341,48 @@ ostream* __thiscall ostream_assign(ostream *this, const ostream *rhs) > DEFINE_THISCALL_WRAPPER(ostream_vbase_dtor, 4) > void __thiscall ostream_vbase_dtor(ostream *this) > { > - FIXME("(%p) stub\n", this); > + ios *base = ostream_to_ios(this); > + > + TRACE("(%p)\n", this); > + > + ostream_dtor(base); > + ios_dtor(base); > } The base should be computed using ostream_get_ios while calling ios_dtor: TRACE("(%p)\n", this); ostream_dtor(ostream_to_ios(this)); ios_dtor(ostream_get_ios(this)); Thanks, Piotr

1 0

Re: secur32/tests: Don't load crypt32.dll function dynamically.
by Marvin 14 Jun '16

14 Jun '16

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=23615 Your paranoid android. === w1064 (32 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308. === w1064 (64 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Guillaume Charifi 14 Jun '16

14 Jun '16

Hello, thank you for your feedback :) I just sent a patch that fixes the NaN issue in all places it can happen (at least in the GLSL backend). Well, stupid drivers... It seems to work really well with Mesa, but I just saw some 1 fps benchmarks, so I guess it's a *nope*. I'll do a test to make you happy, and try to fix the other things. :) <div>-------- Message d'origine --------</div><div>De : Józef Kucia <joseph.kucia(a)gmail.com> </div><div>Date :13/06/2016 20:32 (GMT+01:00) </div><div>À : wine-devel <wine-devel(a)winehq.org> </div><div>Cc : Guillaume Charifi <guillaume.charifi(a)sfr.fr> </div><div>Objet : Re: [PATCH] wined3d: Implement icb dcl support in GLSL. </div><div> </div>This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Marvin 14 Jun '16

14 Jun '16

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=23604 Your paranoid android. === w864 (32 bit process) === process.c:2859: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Alexandre Julliard 14 Jun '16

14 Jun '16

Marcus Meissner <marcus(a)jet.franken.de> writes: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > + FILE *f; > + unsigned long hugepagesize = 0; > + > + f = fopen( "/proc/meminfo", "r" ); > + if (f) > + { > + char buffer[256]; > + > + while (fgets( buffer, sizeof(buffer), f )) > + { > + if (sscanf( buffer, "Hugepagesize: %lu", &hugepagesize )) > + break; > + } > + fclose( f ); > + } > + return (SIZE_T)hugepagesize*1024; > +#else > + FIXME("stub: not implemented on your platform.\n"); > + return 0; > +#endif This could probably be simply hard-coded based on the CPU architecture. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by Ken Thomases 14 Jun '16

14 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Sliders, Dials, and Wheels now map to Z, U (Ry), or V (Rx) depending on > availability. Thus, also adds support for up to 3 such HID elements. > dlls/winejoystick.drv/joystick_osx.c | 20 +++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c > index 77dbef8..4e59ca3 100644 > --- a/dlls/winejoystick.drv/joystick_osx.c > +++ b/dlls/winejoystick.drv/joystick_osx.c > @@ -442,8 +442,26 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kHIDUsage_GD_Slider: > - TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_Slider; ignoring\n"); > + case kHIDUsage_GD_Dial: > + case kHIDUsage_GD_Wheel: > + { > + //if one axis is taken, fall to the next until axes are filled Line comments (//) are not allowed in most of Wine. > + int possible_axes[3] = {AXIS_Z,AXIS_RY,AXIS_RX}; > + int axis = 0; > + TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_<axis> (%d)", usage); > + while(axis < 3 && joystick->axes[possible_axes[axis]].element) > + axis++; > + if (axis == 3) > + TRACE(" ignoring\n"); > + else > + { > + TRACE(" axis %d\n", possible_axes[axis]); Rather than breaking the trace line across multiple TRACEs, you should just move the TRACE to after the selection of an axis. Note that in the existing code, the "ignoring" TRACEs are on a separate line, which is why they are indented. It doesn't make sense to have that extra space if that isn't on a separate line. Alternatively, you could put a newline on the first TRACE and indent the axis trace as a subordinate line. > + joystick->axes[possible_axes[axis]].element = (IOHIDElementRef)CFRetain(child); > + joystick->axes[possible_axes[axis]].min_value = IOHIDElementGetLogicalMin(child); > + joystick->axes[possible_axes[axis]].max_value = IOHIDElementGetLogicalMax(child); > + } > break; > + } Is there reason to expect that these elements (sliders, dials, wheels) will be listed after the "proper" axes (x, y, z, etc.) in the children array? Since the proper axes are specific and these elements should only be mapped to unused axes, I think they should be enumerated in a separate pass after everything else has had a shot. Note that collect_joystick_elements() is recursive, so it's not right to do it in a separate loop within collect_joystick_elements(). Probably, you'll want to call it twice from open_joystick(), with a flag to indicate which mode it should operate in. -Ken

2 3

Re: [MASSMAIL][PATCH] kernel32: implement GetLargePageMinimum
by Dmitry Timoshkov 14 Jun '16

14 Jun '16

Marcus Meissner <marcus(a)jet.franken.de> wrote: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > +#ifdef __i386__ > + /* Linux x86 hugepages are 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} What's the reason of making it linux only and excluding x86_64? -- Dmitry.

1 0

Differences between named pipes in Windows and Wine
by Ryan Prichard 14 Jun '16

14 Jun '16

Hi, I noticed a handful of differences in the "lifecycle" of named pipes between Windows and Wine, and I figured I'd post about them here. I wrote a standalone one-file C++ program that demonstrates the differences I found. (In that test, the pipe handles are always overlapped and PIPE_WAIT.) I tested using wine-1.9.12. The differences were: 1. With Windows, there can be multiple concurrent ConnectNamedPipe operations on a pipe. With Wine, the second ConnectNamedPipe call fails with ERROR_INVALID_HANDLE. 2. With Windows, DisconnectNamedPipe aborts ConnectNamedPipe operations with the error ERROR_PIPE_NOT_CONNECTED. The DisconnectNamedPipe call succeeds, and the pipe is no longer listening. With Wine, the DisconnectNamedPipe call itself fails with ERROR_PIPE_LISTENING, and the pipe is still listening. 3. With Windows, if the server breaks the pipe by closing its handle, the client can finish reading the remaining data in the pipe. Once the data is gone, reading from a broken pipe fails with ERROR_BROKEN_PIPE. Writing to a broken pipe fails with ERROR_NO_DATA. With Wine, once the server breaks the pipe, the client cannot read the remaining data, and I/O on a broken pipe fails with ERROR_PIPE_NOT_CONNECTED. (Exception: ReadFile on a server pipe still returns ERROR_BROKEN_PIPE.) 4. Calling ConnectNamedPipe on a broken server pipe fails with ERROR_NO_DATA on Windows, but ERROR_NO_DATA_DETECTED on Wine. My test program is at: https://gist.github.com/rprichard/8dd8ca134b39534b7da2733994aa07ba. It passes on XP, Vista, Win7, and Win10, with the exception of testChangeMaxInstancesAfterClosingLastServerHandle, which passes on Vista and up. A couple of the more interesting tests are testDisconnectAtStartup and testReadFromBrokenClientPipe: testDisconnectAtStartup: // Calling DisconnectNamedPipe on a new pipe successfully transitions it to a // "Not Connected" state. The second DisconnectNamedPipe call fails, and the // client can't connect. void testDisconnectAtStartup() { const HANDLE server = assertValid(openServer(name(0))); CHECK_SUCCESS(DisconnectNamedPipe(server)); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_FAILURE(DisconnectNamedPipe(server), ERROR_PIPE_NOT_CONNECTED); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_SUCCESS(CloseHandle(server)); } // If a client pipe is broken, rather than disconnected, the remaining data can // still be read. void testReadFromBrokenClientPipe() { DWORD actual = 0; Over over; char buf[2] = {}; const HANDLE server = assertValid(openServer(name(0))); const HANDLE client = assertValid(createFile(name(0))); CHECK_SUCCESS(WriteFile(server, buf, 1, &actual, &over)); CHECK_SUCCESS(CloseHandle(server)); CHECK_SUCCESS(ReadFile(client, buf, 2, &actual, &over)); CHECK(actual == 1); CHECK_FAILURE(ReadFile(client, buf, 2, &actual, &over), ERROR_BROKEN_PIPE); CHECK_SUCCESS(CloseHandle(client)); } I know that item #3 above breaks my winpty project (in principle), where a pipe server signals EOF by closing a pipe without disconnecting it. The winpty client can read all the output before hitting the broken pipe. I suspect winpty may not run on Wine anyway, though. -Ryan

2 1

wine-1.8.3-rc2 Available
by Michael Stefaniuc 13 Jun '16

13 Jun '16

Hello guys, wine-1.8.3-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ There is just a small change compared to rc1 but that required a rebase and thus you'll see a forced upgrade. Changes to rc1: --------------- The two ole32 patches were deferred to a future 1.8.x version. They need more testing in the wild to make them less risky for Stable: - ole32: Implement StgOpenPropStg. - ole32: Implement StgCreatePropStg. This should be the final rc for 1.8.3 (famous last words...) bye michael

1 0

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Marvin 13 Jun '16

13 Jun '16

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=23562 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw1) === ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw7) === ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw2) === ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw4) === ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result.

2 1

Re: [PATCH 3/3] msscript: Implement Timeout property
by Jacek Caban 13 Jun '16

13 Jun '16

Hi Nikolay, On 06/11/2016 12:02 PM, Nikolay Sivov wrote: > static HRESULT WINAPI ScriptControl_put_Timeout(IScriptControl *iface, LONG milliseconds) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%d)\n", This, milliseconds); > - return E_NOTIMPL; > + > + TRACE("(%p)->(%d)\n", This, milliseconds); > + > + if (milliseconds < -1) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + This->timeout = milliseconds; > + return S_OK; > } Getter/setter implementation seems fine, but it's not full implementation and I'm pretty sure that at least first versions that will be able to execute script code won't support that (builtin jscript nor vbscript supports that, so there is very little point in implementing it here), so FIXME or WARN here would be more appropriate here. Thanks, Jacek

2 2

Re: [PATCH 2/3] msscript: Added basic script hosting stub support
by Jacek Caban 13 Jun '16

13 Jun '16

Hi Nikolay, On 06/11/2016 12:02 PM, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > This deprecates patch 123111. > > dlls/msscript.ocx/msscript.c | 237 ++++++++++++++++- > dlls/msscript.ocx/tests/Makefile.in | 2 +- > dlls/msscript.ocx/tests/msscript.c | 488 ++++++++++++++++++++++++++++++++++++ > include/activscp.idl | 16 ++ > 4 files changed, 737 insertions(+), 6 deletions(-) > > diff --git a/dlls/msscript.ocx/msscript.c b/dlls/msscript.ocx/msscript.c > index 5a03f0c..b6764f4 100644 > --- a/dlls/msscript.ocx/msscript.c > +++ b/dlls/msscript.ocx/msscript.c > @@ -22,6 +22,7 @@ > #include "initguid.h" > #include "ole2.h" > #include "olectl.h" > +#include "activscp.h" > #include "rpcproxy.h" > #include "msscript.h" > > @@ -29,14 +30,21 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(msscript); > > +static const WCHAR vbscriptW[] = {'V','B','S','c','r','i','p','t',0}; > +static const WCHAR jscriptW[] = {'J','S','c','r','i','p','t',0}; > + > struct ScriptControl { > IScriptControl IScriptControl_iface; > IPersistStreamInit IPersistStreamInit_iface; > IOleObject IOleObject_iface; > IOleControl IOleControl_iface; > + IActiveScriptSite IActiveScriptSite_iface; > LONG ref; > IOleClientSite *site; > SIZEL extent; > + BSTR lang; > + IActiveScript *script; > + SCRIPTSTATE script_state; > }; It's a good moment to think a bit about the design here. I don't think you want to reuse IActiveScriptSite for all script engines you load. A separated object would allow better ref counting, would be cleaner and safer in my opinion. A quick test on Windows suggests that native does that. > static HINSTANCE msscript_instance; > @@ -120,6 +128,29 @@ static void release_typelib(void) > ITypeLib_Release(typelib); > } > > +static void release_script_engine(ScriptControl *sc) > +{ > + if (!sc->script) > + return; > + > + switch (sc->script_state) { > + case SCRIPTSTATE_CONNECTED: > + IActiveScript_SetScriptState(sc->script, SCRIPTSTATE_DISCONNECTED); > + > + case SCRIPTSTATE_STARTED: > + case SCRIPTSTATE_DISCONNECTED: > + case SCRIPTSTATE_INITIALIZED: > + IActiveScript_Close(sc->script); > + > + default: > + ; > + } Some "fall through" comments to avoid static analyser fixes follow ups would be nice. > -static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR language) > +static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR lang) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(language)); > - return E_NOTIMPL; > + HRESULT hr; > + GUID guid; > + > + TRACE("(%p)->(%s)\n", This, debugstr_w(lang)); > + > + if (!lang) { > + release_script_engine(This); > + set_script_name(This, NULL); > + return S_OK; > + } > + > + hr = CLSIDFromProgID(lang, &guid); > + if (FAILED(hr)) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + hr = CoCreateInstance(&guid, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IActiveScript, (void**)&This->script); > + if (FAILED(hr)) > + return CTL_E_INVALIDPROPERTYVALUE; > + else if (!init_script_engine(This)) { > + release_script_engine(This); > + return CTL_E_INVALIDPROPERTYVALUE; > + } > + > + /* store engine name */ > + if (!lstrcmpiW(lang, vbscriptW)) > + This->lang = SysAllocString(vbscriptW); > + else if (!lstrcmpiW(lang, jscriptW)) > + This->lang = SysAllocString(jscriptW); > + else Why do you need those? My guess is that returned script may have different upper/lower cases, but if that the case, then we should probably use ProgIDFromCLSID in getter and just store CLSID. > + This->lang = SysAllocString(lang); > + > + return S_OK; > } > > static HRESULT WINAPI ScriptControl_get_State(IScriptControl *iface, ScriptControlStates *p) > @@ -873,8 +1096,12 @@ static HRESULT WINAPI ScriptControl_CreateInstance(IClassFactory *iface, IUnknow > script_control->IPersistStreamInit_iface.lpVtbl = &PersistStreamInitVtbl; > script_control->IOleObject_iface.lpVtbl = &OleObjectVtbl; > script_control->IOleControl_iface.lpVtbl = &OleControlVtbl; > + script_control->IActiveScriptSite_iface.lpVtbl = &ActiveScriptSiteVtbl; > script_control->ref = 1; > script_control->site = NULL; > + script_control->lang = NULL; > + script_control->script_state = SCRIPTSTATE_UNINITIALIZED; > + script_control->script = NULL; > > hdc = GetDC(0); > dpi_x = GetDeviceCaps(hdc, LOGPIXELSX); > diff --git a/dlls/msscript.ocx/tests/Makefile.in b/dlls/msscript.ocx/tests/Makefile.in > index 8d769d3..cc62590 100644 > --- a/dlls/msscript.ocx/tests/Makefile.in > +++ b/dlls/msscript.ocx/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = msscript.ocx > -IMPORTS = user32 gdi32 ole32 > +IMPORTS = user32 gdi32 ole32 oleaut32 advapi32 > > C_SRCS = \ > msscript.c > diff --git a/dlls/msscript.ocx/tests/msscript.c b/dlls/msscript.ocx/tests/msscript.c > index 12f7003..d1d553b 100644 > --- a/dlls/msscript.ocx/tests/msscript.c > +++ b/dlls/msscript.ocx/tests/msscript.c > @@ -22,10 +22,411 @@ > #include <initguid.h> > #include <ole2.h> > #include <olectl.h> > +#include "dispex.h" > +#include "activscp.h" > +#include "activdbg.h" > +#include "objsafe.h" > > #include "msscript.h" > #include "wine/test.h" > > +#define TESTSCRIPT_CLSID "{178fc164-f585-4e24-9c13-4bb7faf80746}" > +static const GUID CLSID_TestScript = > + {0x178fc164,0xf585,0x4e24,{0x9c,0x13,0x4b,0xb7,0xfa,0xf8,0x07,0x46}}; > + > +#ifdef _WIN64 > + > +#define CTXARG_T DWORDLONG > +#define IActiveScriptParseVtbl IActiveScriptParse64Vtbl > +#define IActiveScriptSiteDebug_Release IActiveScriptSiteDebug64_Release > + > +#else > + > +#define CTXARG_T DWORD > +#define IActiveScriptParseVtbl IActiveScriptParse32Vtbl > +#define IActiveScriptSiteDebug_Release IActiveScriptSiteDebug32_Release > + > +#endif > + > +static IActiveScriptSite *site; > +static SCRIPTSTATE state; > + > +static HRESULT WINAPI ActiveScriptParse_QueryInterface(IActiveScriptParse *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + ok(0, "unexpected call\n"); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ActiveScriptParse_AddRef(IActiveScriptParse *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ActiveScriptParse_Release(IActiveScriptParse *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ActiveScriptParse_InitNew(IActiveScriptParse *iface) > +{ > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScriptParse_AddScriptlet(IActiveScriptParse *iface, > + LPCOLESTR pstrDefaultName, LPCOLESTR pstrCode, LPCOLESTR pstrItemName, > + LPCOLESTR pstrSubItemName, LPCOLESTR pstrEventName, LPCOLESTR pstrDelimiter, > + CTXARG_T dwSourceContextCookie, ULONG ulStartingLineNumber, DWORD dwFlags, > + BSTR *pbstrName, EXCEPINFO *pexcepinfo) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScriptParse_ParseScriptText(IActiveScriptParse *iface, > + LPCOLESTR pstrCode, LPCOLESTR pstrItemName, IUnknown *punkContext, > + LPCOLESTR pstrDelimiter, CTXARG_T dwSourceContextCookie, ULONG ulStartingLine, > + DWORD dwFlags, VARIANT *pvarResult, EXCEPINFO *pexcepinfo) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static const IActiveScriptParseVtbl ActiveScriptParseVtbl = { > + ActiveScriptParse_QueryInterface, > + ActiveScriptParse_AddRef, > + ActiveScriptParse_Release, > + ActiveScriptParse_InitNew, > + ActiveScriptParse_AddScriptlet, > + ActiveScriptParse_ParseScriptText > +}; > + > +static IActiveScriptParse ActiveScriptParse = { &ActiveScriptParseVtbl }; > + > +static HRESULT WINAPI ObjectSafety_QueryInterface(IObjectSafety *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + ok(0, "unexpected call %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ObjectSafety_AddRef(IObjectSafety *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ObjectSafety_Release(IObjectSafety *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ObjectSafety_GetInterfaceSafetyOptions(IObjectSafety *iface, REFIID riid, > + DWORD *pdwSupportedOptions, DWORD *pdwEnabledOptions) > +{ > + ok(IsEqualGUID(&IID_IActiveScriptParse, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + ok(pdwSupportedOptions != NULL, "pdwSupportedOptions == NULL\n"); > + ok(pdwEnabledOptions != NULL, "pdwEnabledOptions == NULL\n"); > + > + *pdwSupportedOptions = INTERFACESAFE_FOR_UNTRUSTED_DATA|INTERFACE_USES_DISPEX|INTERFACE_USES_SECURITY_MANAGER; > + *pdwEnabledOptions = INTERFACE_USES_DISPEX; > + > + return S_OK; > +} > + > +static HRESULT WINAPI ObjectSafety_SetInterfaceSafetyOptions(IObjectSafety *iface, REFIID riid, > + DWORD mask, DWORD options) > +{ > + ok(IsEqualGUID(&IID_IActiveScriptParse, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + > + ok(mask == INTERFACESAFE_FOR_UNTRUSTED_DATA, "option mask = %x\n", mask); > + ok(options == 0, "options = %x\n", options); > + > + return S_OK; > +} > + > +static const IObjectSafetyVtbl ObjectSafetyVtbl = { > + ObjectSafety_QueryInterface, > + ObjectSafety_AddRef, > + ObjectSafety_Release, > + ObjectSafety_GetInterfaceSafetyOptions, > + ObjectSafety_SetInterfaceSafetyOptions > +}; > + > +static IObjectSafety ObjectSafety = { &ObjectSafetyVtbl }; > + > +static HRESULT WINAPI ActiveScript_QueryInterface(IActiveScript *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + > + if(IsEqualGUID(&IID_IUnknown, riid) || IsEqualGUID(&IID_IActiveScript, riid)) { > + *ppv = iface; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IObjectSafety, riid)) { > + *ppv = &ObjectSafety; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IActiveScriptParse, riid)) { > + *ppv = &ActiveScriptParse; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IActiveScriptGarbageCollector, riid)) { > + return E_NOINTERFACE; > + } > + > + ok(0, "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ActiveScript_AddRef(IActiveScript *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ActiveScript_Release(IActiveScript *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ActiveScript_SetScriptSite(IActiveScript *iface, IActiveScriptSite *pass) > +{ > + IActiveScriptSiteInterruptPoll *poll; > + IActiveScriptSiteDebug *debug; > + IServiceProvider *service; > + ICanHandleException *canexpection; > + LCID lcid; > + HRESULT hres; > + > + ok(pass != NULL, "pass == NULL\n"); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IActiveScriptSiteInterruptPoll, (void**)&poll); > + ok(hres == E_NOINTERFACE, "Could not get IActiveScriptSiteInterruptPoll interface: %08x\n", hres); > + > + hres = IActiveScriptSite_GetLCID(pass, &lcid); > + ok(hres == S_OK, "GetLCID failed: %08x\n", hres); > + > + hres = IActiveScriptSite_OnStateChange(pass, (state = SCRIPTSTATE_INITIALIZED)); > +todo_wine > + ok(hres == E_NOTIMPL, "OnStateChange failed: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IActiveScriptSiteDebug, (void**)&debug); > + ok(hres == E_NOINTERFACE, "Could not get IActiveScriptSiteDebug interface: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_ICanHandleException, (void**)&canexpection); > + ok(hres == E_NOINTERFACE, "Could not get IID_ICanHandleException interface: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IServiceProvider, (void**)&service); > +todo_wine > + ok(hres == S_OK, "Could not get IServiceProvider interface: %08x\n", hres); > + if(SUCCEEDED(hres)) > + IServiceProvider_Release(service); > + > + site = pass; > + IActiveScriptSite_AddRef(site); > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptSite(IActiveScript *iface, REFIID riid, > + void **ppvObject) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_SetScriptState(IActiveScript *iface, SCRIPTSTATE ss) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptState(IActiveScript *iface, SCRIPTSTATE *pssState) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_Close(IActiveScript *iface) > +{ > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScript_AddNamedItem(IActiveScript *iface, > + LPCOLESTR pstrName, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_AddTypeLib(IActiveScript *iface, REFGUID rguidTypeLib, > + DWORD dwMajor, DWORD dwMinor, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptDispatch(IActiveScript *iface, LPCOLESTR pstrItemName, > + IDispatch **ppdisp) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetCurrentScriptThreadID(IActiveScript *iface, > + SCRIPTTHREADID *pstridThread) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptThreadID(IActiveScript *iface, > + DWORD dwWin32ThreadId, SCRIPTTHREADID *pstidThread) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptThreadState(IActiveScript *iface, > + SCRIPTTHREADID stidThread, SCRIPTTHREADSTATE *pstsState) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_InterruptScriptThread(IActiveScript *iface, > + SCRIPTTHREADID stidThread, const EXCEPINFO *pexcepinfo, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_Clone(IActiveScript *iface, IActiveScript **ppscript) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static const IActiveScriptVtbl ActiveScriptVtbl = { > + ActiveScript_QueryInterface, > + ActiveScript_AddRef, > + ActiveScript_Release, > + ActiveScript_SetScriptSite, > + ActiveScript_GetScriptSite, > + ActiveScript_SetScriptState, > + ActiveScript_GetScriptState, > + ActiveScript_Close, > + ActiveScript_AddNamedItem, > + ActiveScript_AddTypeLib, > + ActiveScript_GetScriptDispatch, > + ActiveScript_GetCurrentScriptThreadID, > + ActiveScript_GetScriptThreadID, > + ActiveScript_GetScriptThreadState, > + ActiveScript_InterruptScriptThread, > + ActiveScript_Clone > +}; > + > +static IActiveScript ActiveScript = { &ActiveScriptVtbl }; > + > +static HRESULT WINAPI ClassFactory_QueryInterface(IClassFactory *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + > + if(IsEqualGUID(&IID_IUnknown, riid) || IsEqualGUID(&IID_IClassFactory, riid)) { > + *ppv = iface; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IMarshal, riid)) > + return E_NOINTERFACE; > + > + ok(0, "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ClassFactory_AddRef(IClassFactory *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ClassFactory_Release(IClassFactory *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ClassFactory_CreateInstance(IClassFactory *iface, IUnknown *outer, REFIID riid, void **ppv) > +{ > + ok(!outer, "outer = %p\n", outer); > + ok(IsEqualGUID(&IID_IActiveScript, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + *ppv = &ActiveScript; > + return S_OK; > +} > + > +static HRESULT WINAPI ClassFactory_LockServer(IClassFactory *iface, BOOL dolock) > +{ > + ok(0, "unexpected call\n"); > + return S_OK; > +} > + > +static const IClassFactoryVtbl ClassFactoryVtbl = { > + ClassFactory_QueryInterface, > + ClassFactory_AddRef, > + ClassFactory_Release, > + ClassFactory_CreateInstance, > + ClassFactory_LockServer > +}; > + > +static IClassFactory script_cf = { &ClassFactoryVtbl }; > + > +static BOOL init_key(const char *key_name, const char *def_value, BOOL init) > +{ > + HKEY hkey; > + DWORD res; > + > + if(!init) { > + RegDeleteKeyA(HKEY_CLASSES_ROOT, key_name); > + return TRUE; > + } > + > + res = RegCreateKeyA(HKEY_CLASSES_ROOT, key_name, &hkey); > + if(res != ERROR_SUCCESS) > + return FALSE; > + > + if(def_value) > + res = RegSetValueA(hkey, NULL, REG_SZ, def_value, strlen(def_value)); > + > + RegCloseKey(hkey); > + > + return res == ERROR_SUCCESS; > +} > + > +static BOOL init_registry(BOOL init) > +{ > + return init_key("TestScript\\CLSID", TESTSCRIPT_CLSID, init) > + && init_key("CLSID\\"TESTSCRIPT_CLSID"\\Implemented Categories\\{F0B7A1A1-9847-11CF-8F20-00805F2CD064}", > + NULL, init) > + && init_key("CLSID\\"TESTSCRIPT_CLSID"\\Implemented Categories\\{F0B7A1A2-9847-11CF-8F20-00805F2CD064}", > + NULL, init); > +} > + > +static BOOL register_script_engine(void) > +{ > + DWORD regid; > + HRESULT hres; > + > + if(!init_registry(TRUE)) { > + init_registry(FALSE); > + return FALSE; > + } > + > + hres = CoRegisterClassObject(&CLSID_TestScript, (IUnknown *)&script_cf, > + CLSCTX_INPROC_SERVER, REGCLS_MULTIPLEUSE, &regid); > + ok(hres == S_OK, "Could not register script engine: %08x\n", hres); > + > + return TRUE; > +} > + > static HRESULT WINAPI OleClientSite_QueryInterface(IOleClientSite *iface, REFIID riid, void **obj) > { > if (IsEqualIID(riid, &IID_IOleClientSite) || IsEqualIID(riid, &IID_IUnknown)) > @@ -213,6 +614,92 @@ static void test_olecontrol(void) > IOleControl_Release(olecontrol); > } > > +static void test_Language(void) > +{ > + static const WCHAR vbW[] = {'V','B','S','c','r','i','p','t',0}; > + static const WCHAR jsW[] = {'J','S','c','r','i','p','t',0}; > + static const WCHAR vb2W[] = {'v','B','s','c','r','i','p','t',0}; > + static const WCHAR dummyW[] = {'d','u','m','m','y',0}; > + IScriptControl *sc; > + HRESULT hr; > + BSTR str; > + > + hr = CoCreateInstance(&CLSID_ScriptControl, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IScriptControl, (void**)&sc); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + hr = IScriptControl_get_Language(sc, NULL); > + ok(hr == E_POINTER, "got 0x%08x\n", hr); > + > + str = (BSTR)0xdeadbeef; > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(str == NULL, "got %s\n", wine_dbgstr_w(str)); > + > + str = SysAllocString(vbW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + str = SysAllocString(vb2W); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, vbW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + str = SysAllocString(dummyW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == CTL_E_INVALIDPROPERTYVALUE, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, vbW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + str = SysAllocString(jsW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, jsW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + hr = IScriptControl_put_Language(sc, NULL); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(str == NULL, "got %s\n", wine_dbgstr_w(str)); > + > + /* custom script engine */ > + if (register_script_engine()) { > + static const WCHAR testscriptW[] = {'t','e','s','t','s','c','r','i','p','t',0}; > + > + str = SysAllocString(testscriptW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); It's nice to have tests with emulated script engine, but please also add test of called callbacks. Please add something like CHECK_EXPECT()/CHECK_CALLED() macros or alike. Otherwise important informations that your tests already gather are hidden and not tested. > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(testscriptW, str), "%s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + init_registry(FALSE); > + } > + else > + skip("Could not register TestScript engine\n"); > + > + IScriptControl_Release(sc); > +} > + > START_TEST(msscript) > { > IUnknown *unk; > @@ -231,6 +718,7 @@ START_TEST(msscript) > test_oleobject(); > test_persiststreaminit(); > test_olecontrol(); > + test_Language(); > > CoUninitialize(); > } > diff --git a/include/activscp.idl b/include/activscp.idl > index 8a3d75d..e539b04 100644 > --- a/include/activscp.idl > +++ b/include/activscp.idl > @@ -71,6 +71,11 @@ typedef enum tagSCRIPTUICHANDLING { > SCRIPTUICHANDLING_NOUIDEFAULT = 2 > } SCRIPTUICHANDLING; > > +typedef enum tagSCRIPTGCTYPE { > + SCRIPTGCTYPE_NORMAL = 0, > + SCRIPTGCTYPE_EXHAUSTIVE = 1 > +} SCRIPTGCTYPE; > + > typedef DWORD SCRIPTTHREADID; > cpp_quote("#define SCRIPTTHREADID_CURRENT ((SCRIPTTHREADID)-1)") > cpp_quote("#define SCRIPTTHREADID_BASE ((SCRIPTTHREADID)-2)") > @@ -551,3 +556,14 @@ interface IActiveScriptProperty : IUnknown > [in] VARIANT *pvarIndex, > [in] VARIANT *pvarValue); > } > + > +[ > + object, > + uuid(6aa2c4a0-2b53-11d4-a2a0-00104bd35090), > + pointer_default(unique) > +] > +interface IActiveScriptGarbageCollector : IUnknown > +{ > + HRESULT CollectGarbage( > + [in] SCRIPTGCTYPE gctype); > +} It's not too important, but technically it deserves a separated patch. Thanks, Jacek

2 2

Re: [PATCH] inetcomm: Implement IMimeBody GetPropInfo
by Alexandre Julliard 13 Jun '16

13 Jun '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if(pInfo->dwMask | PIM_CHARSET) > + pInfo->hCharset = 0; > + if(pInfo->dwMask | PIM_FLAGS) > + pInfo->dwFlags = 0x00000000; > + if(pInfo->dwMask | PIM_ROWNUMBER) > + pInfo->dwRowNumber = 0; > + if(pInfo->dwMask | PIM_ENCODINGTYPE) > + pInfo->ietEncoding = 0; > + if(pInfo->dwMask | PIM_VALUES) > + pInfo->cValues = 0; > + if(pInfo->dwMask | PIM_PROPID) > + pInfo->dwPropId = header->prop->id; > + if(pInfo->dwMask | PIM_VTDEFAULT) > + pInfo->vtDefault = header->prop->default_vt; > + if(pInfo->dwMask | PIM_VTCURRENT) > + pInfo->vtCurrent = 0; This doesn't do what you want. You should initialize to some garbage value instead of 0 in your tests, that would have caught it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32/tests: Use wine_dbgstr_rect() in the win tests.
by Marvin 13 Jun '16

13 Jun '16

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=23566 Your paranoid android. === w2008s64 (32 bit win) === win.c:8861: Test failed: GetActiveWindow() = 00000000 win.c:8861: Test failed: GetFocus() = 00000000 win.c:8863: Test failed: Expected foreground window 00080124, got 000200E4 win.c:8866: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:8873: Test failed: Expected foreground window 00080124, got 00000000 win.c:8875: Test failed: GetActiveWindow() = 00000000 win.c:8875: Test failed: GetFocus() = 00000000 win.c:8883: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.

2 1

Wine for Android
by Jimmy Tamayo 13 Jun '16

13 Jun '16

Hi I use wine in wifislax which is a Linux based os and is awesome but maybe the developers can make wine for Android lollipop and marshmallow that would be great so we the users can execute Exe applications in our smartphones Thanks in advance for your attention Greetings

2 1

Re: [1/3] imm32, user32: Create and destroy the default IME window implicitly. (try 7)
by Alexandre Julliard 13 Jun '16

13 Jun '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 7: > - Remove the refcount argument from internal API. > - Introduce WIN_HAS_IME_WIN flag to remember IME window reference. > - To avoid test failures on wine, always create IME window (affects non-CJK locales). > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 97 +++++++++++++++++++++++++++++++++++----------- > dlls/imm32/imm32.spec | 1 + > dlls/imm32/tests/imm32.c | 12 +++--- > dlls/user32/misc.c | 4 +- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 26 +++++++++++++ > dlls/user32/win.h | 1 + > 7 files changed, 112 insertions(+), 30 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so msg && touch msg.ok msg.c:14206: Test failed: 0: got 0x80050 msg.c:14206: Test failed: 4: got 0x80050 msg.c:14206: Test failed: 5: got 0x80050 msg.c:12921: Tests skipped: Skipping DBCS WM_CHAR test in SBCS codepage 'ANSI Latin 1' msg.c:13237: Tests skipped: Unable to load Greek keyboard layout make: *** [msg.ok] Error 3 Implementing ImmDisableIME first would probably fix it, but the test succeeds for me on Windows even without calling ImmDisableIME, so there may be something else going on here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
by Alex Henrie 13 Jun '16

13 Jun '16

> Signed-off-by: David Lawrie david.dljunk(a)gmail.com This line is incorrectly formatted. Please use the format with angle brackets generated by `git commit -s`. See https://wiki.winehq.org/Submitting_Patches#The_commit_message for an example. -Alex

2 1

Re: [PATCH] comctl32: isolate condition to avoid compiler warnings.
by Nikolay Sivov 13 Jun '16

13 Jun '16

On 13.06.2016 4:53, Hadrien Boizard wrote: > Hi Nikolay, > > I'm using gcc 6.1.1 and I'm getting "-Wmisleading-indentation" warnings. > > I didn't notice when I sent the patch but there's an indent that I > didn't mean to be there. > It's weird because on my file, it looks like that : >> if (len == -1) goto end; >> buf += len; size -= len; > > Perhaps this format would be more appropriate : >> if (len == -1) >> goto end; >> buf += len; size -= len; > > > Is there a problem with this version of gcc ? > Should I try resending the patch with either of these 2 solutions ? Personally I don't think code needs fixing just to silence this warning. But if we care, looks like it's enough to have everything after 'goto end;' on a separate line, indented with spaces. > > > > 2016-06-12 21:46 GMT+02:00 Nikolay Sivov <bunglehead(a)gmail.com > <mailto:bunglehead@gmail.com>>: > > Hi, Hadrien. > > What is the compiler you're testing with and what kind of warnings do > you see? Is it misleading indentation from gcc 6 by any chance? > > > - if (len == -1) goto end; buf += len; size -= len; > > + if (len == -1) goto end; > > + buf += len; size -= len; > > Reformatting it like that is even more misleading. > >

1 0

Re: [PATCH 1/3] d3drm: Add stubs for IDirect3DRMFrame interface. (v2)
by Stefan Dösinger 12 Jun '16

12 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On the big picture this code is a copypaste of the frame2 -> frame3 thunks. There's nothing wrong with that on its own, but unfortunately the frame2 -> frame3 thunks have a number of issues. In particular some thunks are not trivial, e.g. AddVisual, which accepts a IDirect3DRMVisual in one version and an IUnknown in another. Or GetChildren - which interface is added in to the Children array? I think we had that discussion with other interfaces in the past - implement thunks for everything or implement thunks for the implemented frame3 functions only and make the others return an error. Judging from the existing code we decided on the latter option for IDirect3DRM* . I would suggest to make all frame1 functions return E_NOTIMPL in the first patch (except IUnknown), then implement the thunks that have sufficient existing tests (adding tests for version 1 in the same patches) and then add the rest of the thunks as you implement the version 3 function. That way you won't be blocked by discussions about thunks that aren't relevant to you yet. Am 2016-06-09 um 23:18 schrieb Aaryaman Vasishta: > +static HRESULT WINAPI d3drm_frame1_AddChild(IDirect3DRMFrame *iface, IDirect3DRMFrame *child) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + IDirect3DRMFrame3 *child3; > + HRESULT hr; > + > + TRACE("iface %p, child %p.\n", iface, child); > + > + if (!child) > + return D3DRMERR_BADOBJECT; > + hr = IDirect3DRMFrame_QueryInterface(child, &IID_IDirect3DRMFrame3, (void **)&child3); > + if (hr != S_OK) > + return D3DRMERR_BADOBJECT; > + IDirect3DRMFrame_Release(child); > + > + return IDirect3DRMFrame3_AddChild(&frame->IDirect3DRMFrame3_iface, child3); > +} This doesn't seem right. Right now you're releasing a reference you don't own (child's frame1) and leak one (child's frame3). Is there a reason why you're using QueryInterface instead of accessing child->IDirect3DRMFrame3_iface? If you stick to QI I think this should be more like this (error checking excluded): QI(child, IID_child3, &child3); hr = Frame3_AddChild(frame, child3); IDirect3DRMFrame3_Release(child3); d3drm_frame2_AddChild has the same problem, this is where your code seems to come from. > + hr = IDirect3DRM_CreateFrame(d3drm1, NULL, &frame1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMFrame interface (hr = %#x).\n", hr); > + > + hr = IDirect3DRMFrame_QueryInterface(frame1, &IID_IDirect3DRMObject, (void **)&obj); > + ok(SUCCEEDED(hr), "Could not get IDirect3DRMObject interface (hr = %#x).\n", hr); > + ok(obj == (IDirect3DRMObject *)frame1, "got object pointer %p, expected %p", obj, frame1); > + IDirect3DRMObject_Release(obj); > + IDirect3DRMFrame_Release(frame1); What's missing here is a test that frame1 != frame2 != frame3 and frame1 == visual and frame1 == IUnknown (I guess that one will be false). You could also consider making this and patch use the same kind of table as e.g. the IDirect3DRM tests. That would keep the tests for various interfaces similar to each other. On the other hand because there's only one refcount (thanks to aggregation support) I am fine with a smaller test for refcounts. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXXXYCAAoJEN0/YqbEcdMwFdcP/3D9Ldet3j2QS14fCOjsuamK bVzdTzr+WuYZlYAp6MUyiZUFCSy+tb8f8C1LO6wuxmuaJmgNzFXB4j+s7fUzH/PQ bljIsEOc0aDYRDrMLekxa86MaK25xfHFOsj7ixM72NZsCaRVsUpq9y993LNVRAEN cUazAn3SQWSQVXD97mZa1/4MjGExfKR6Sw932f5WOeUGoZRSAFUxZ1hlOKS7HJbp qIweKka1D8lz+DgJGpsVkSJqDUw4+uHhKlBPPcu5RDjgzzTefuk3k53I4ntasrY6 611gv+xkmo32cfewPcte0b+ttA5MW/DXyTrXWAhffrZ+kFpB327HusbdD3Wa+O2S yOvbPBPTbWwTr1wGaIvD6QB2MSEsBQLLVnB73gMO8Ref0yY+Q4ujV/2IITyFjRzB lJz3821uSB+RFyfBKgS7KN81KBs35a7OsfQi7EwyuUQtwXY0NuEF/s48D7dHMJdO fLeRv928WqYY+hmXkj4gQZD8mmEzjEGyT1PqAum/EJcr9tOzEXWbhwlKrgL9f0k9 g/u2WQh+OtwvAcueIWZaRgxNZZjsi6xi15Dnjwi7OSW5s19PCg5/g1qgyCA4nVCb jb9AHJX6HxhnGGGej5NTUw+uCW83y3ons9DV2s9lRprIFt58v5mb1tELO7TBFAGa VqA7RDllo5Zh3jOnYKyB =ll6/ -----END PGP SIGNATURE-----

2 3

Re: [1/1] winejoystick.drv/joystick_osx.c: fixed axes mapping, add feature support
by Hugh McMaster 12 Jun '16

12 Jun '16

On Friday, 10 June 2016 4:11 PM, David Lawrie wrote: > This patch fixes Slider and Ry/Rx axes mapping and adds support for > general multi-axis controllers (up to 6-axis controllers), steering > wheels w/ accelerators/brakes, multiple sliders/dials/wheels (up to 3), > rudder pedals, and throttles. > > Tested on OS X 10.10.5 > > Signed-off-by: David Lawrie david.dljunk(a)gmail.com > --- > dlls/winejoystick.drv/joystick_osx.c | 171 ++++++++++++++++++++++++----------- > 1 file changed, 119 insertions(+), 52 deletions(-) Hi David, Your patch contains a mixture of tab and space indentation. The tabs, in particular, make the lines long and difficult to read. Please resubmit your patch using four spaces for each level of indentation. -- Hugh McMaster

2 2

Re: [PATCH] comctl32: isolate condition to avoid compiler warnings.
by Nikolay Sivov 12 Jun '16

12 Jun '16

Hi, Hadrien. What is the compiler you're testing with and what kind of warnings do you see? Is it misleading indentation from gcc 6 by any chance? > - if (len == -1) goto end; buf += len; size -= len; > + if (len == -1) goto end; > + buf += len; size -= len; Reformatting it like that is even more misleading.

1 0

Questions about Wine explorer.exe desktop work
by Joel Holdsworth 12 Jun '16

12 Jun '16

Dear All, I've been watching AJ's work on improving wine when running in desktop mode with respect to the task bar and start menu. I was wondering what the motivation for this work was? but it's a cool feature whatever the reason. I'm also interested in the work the ReactOS guys have been doing on reactos and shell32. To my understanding, in the last couple of years, the reactos team have expended quite some effort to faithfully replicate the behavior of shell32+explorer as seen in XP and Server 2003. This diagram shows how all the undocumented shell32 COM objects fit together: https://www.reactos.org/node/780 I was interested to see if reactos explorer.exe could run in wine, and it fails because it doesn't have the undocumented shell32 StartMenu or TaskBar COM objects. Look at AJ's patches it looks like Wine's start menu and task bar are being done in an ad-hoc way in explorer.exe; not trying to replicate shell32 COM objects. According to this document: https://svn.reactos.org/svn/reactos/trunk/reactos/media/doc/README.WINE?vie… , it seems that reactos forked shell32 in 2007. And from browsing the code, it seems a lot of it is now written in C++. It would be cool if the reactos could be moved off their fork back onto wine's version, but it seems like their shell32 might be ahead of wine's in some places. I wanted to ask suggest/ask if it would be a good idea to import or base-off-of the ROS shell32 code, convert it to C and use that for the new desktop code? It seems to me that the architecture would more closely match windows, so the ROS and Microsoft explorer.exe would then run on Wine. Also this would move us towards having the ROS and Wine explorer.exe and shell32 merged - and the ROS guys seem to care quite a lot about that stuff, so it would be good to unite the two project's efforts. Best Regards Joel Holdsworth

2 1

Re: [v2 0/1] winejoystick.drv/joystick_osx.c: fixed axes mapping, add feature support
by Alexandre Julliard 11 Jun '16

11 Jun '16

David Lawrie <david.dljunk(a)gmail.com> writes: > This patch fixes Slider and Ry/Rx axes mapping and adds support for > general multi-axis controllers (up to 6-axis controllers), steering > wheels w/ accelerators/brakes, multiple sliders/dials/wheels (up to 3), > rudder pedals, and throttles. > > Fixes: > 1) Slider now maps to Z, U, or V depending on availability > 2) Ry now maps to U > 3) Rx now maps to V > > Windows defines Winmm U as Dinput Ry and V as Dinput Rx. Original joystick_osx.c mapping was other way around. This is also a bug in the Linux Winmm joystick version (not fixed with this patch). Sliders are supposed to map to the Z-axis (or U/V axes if Z is taken). > > Adds: > > 1) Driver will find Multi-axis controller type in addition to gamepad and joystick > > 2a) In function collect_joystick_elements, under Generic Desktop page, patch adds support for multiple Sliders, Dials, and Wheels up to 3. First Slider/Dial/Wheel maps to Z, Second -> U, Third -> V. > > 2b) Patch also adds support for controller features defined by HID Simulation page: Rudder (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz). Looks good, but please send separate fixes as separate patches. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/1] winejoystick.drv/joystick_osx.c: fixed axes mapping, add feature support
by DavidL 10 Jun '16

10 Jun '16

Hi, I recently submitted a patch which had at least one whitespace formatting issue. Looking over it, I found one on line 518, a bracket in the wrong place. Is there an easy way for me to check if there are more formatting issues before resubmitting? Or should I simply resubmit? Thanks! David On Fri, Jun 10, 2016 at 7:06 AM, Marvin <testbot(a)winehq.org> wrote: > 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 "Formatting". > > This means that there are some formatting issues with your > patch. Either the author's full name, email address, or Signed-off-by > headers are missing, indentation is messed up (usually from editing > with a non-standard tab size), or there are gratuitous formatting > changes to the code. You need to resend a fixed patch. > > 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. >

2 1

Re: ucrtbase: Add __fpe_flt_rounds implementation
by Marvin 10 Jun '16

10 Jun '16

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=23515 Your paranoid android. === wxppro (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w2003std (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w7u (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w7pro64 (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w8 (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === w864 (32 bit misc) === misc: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit misc) === misc: unhandled exception c0000005 at 0000000000000000 === w2008s64 (64 bit misc) === misc: unhandled exception c0000005 at 0000000000000000 === w7pro64 (64 bit misc) === misc: unhandled exception c0000005 at 0000000000000000 === w864 (64 bit misc) === misc: unhandled exception c0000005 at 0000000000000000 === w1064 (64 bit misc) === misc.c:233: Test failed: __fpe_flt_rounds returned 3 misc.c:237: Test failed: __fpe_flt_rounds returned 2

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel