January 2016 - Wine-devel - list.winehq.org

Re: [PATCH] avifil32: Use typed pointers in sizeof() (Coverity)
by Bruno Jesus 10 Jan '16

10 Jan '16

On Sun, Jan 10, 2016 at 10:35 PM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/avifil32/api.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/api.c b/dlls/avifil32/api.c > index c71efb4..a88e3bf 100644 > --- a/dlls/avifil32/api.c > +++ b/dlls/avifil32/api.c > @@ -2332,8 +2332,8 @@ HRESULT WINAPIV AVISaveW(LPCWSTR szFile, CLSID * pclsidHandler, AVISAVECALLBACK > > if (nStreams <= 0) return AVIERR_BADPARAM; > > - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *)); > - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *)); > + streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*streams)); > + options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*options)); Hi, Nikolay. What about AviSaveA? The structure of code is identical. Also in the loop I used void * to get the next arg from the list, could that be a problem? Best wishes, Bruno

2 1

Re: winhttp: Avoid -Wmisleading-indentation warning in test_IWinHttpRequest_Invoke.
by Nikolay Sivov 10 Jan '16

10 Jan '16

On 10.01.2016 14:26, Gerald Pfeifer wrote: > This is a bit unusual formatting, though I understand where it's coming > from. Adding braces silences GCC 6's new -Wmisleading-indentation. > > Gerald > > Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> > --- > dlls/winhttp/tests/winhttp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index d676dd8..1408f35 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -3820,8 +3820,9 @@ static void test_IWinHttpRequest_Invoke(void) > ok(hr == DISP_E_UNKNOWNINTERFACE, "error %#x\n", hr); > > VariantInit(&ret); > -if (0) /* crashes */ > +if (0) /* crashes */ { > hr = IWinHttpRequest_Invoke(request, DISPID_HTTPREQUEST_OPTION, &IID_NULL, 0, DISPATCH_PROPERTYPUT, NULL, &ret, NULL, &err); > +} > > params.cArgs = 1; > hr = IWinHttpRequest_Invoke(request, DISPID_HTTPREQUEST_OPTION, &IID_NULL, 0, DISPATCH_PROPERTYPUT, &params, &ret, NULL, &err); > I think we have tons of those, I myself almost always use todo_wine this way, to reduce diff that remove todo_wine when implementation is fixed. Actually not sure if todo_wine will trigger this check, does it?

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 10).
by Stefan Dösinger 09 Jan '16

09 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-04 um 18:51 schrieb Aaryaman Vasishta: > + file_header.bfSize = ((((w * bpp + 31) & ~31) >> 3) * h) + > file_header.bfOffBits; This suggests (if I understand it right) that the on-disk bmp is written with 4 byte aligned rows (i.e., similar to bytes_per_line being 4 byte aligned in some cases). The actual image you generate doesn't match that though, so you have some unused data at the end. It's possible that this size alignment is necessary though. Why are you using it instead of just using w * h * (bpp / 8)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWkEqmAAoJEN0/YqbEcdMwKhEP/2OjRx6dtXxfqOoLPFb6687p cOBr5nCzJYMHKvNL1yD1Wb1T3jNjQWduOpAuUZV9QfcEsOzwYpMAO0wprFslNEVo r/aPwMnAAjjW/xXQD30s4McXKIdRQdo7myXbVbtyv4n7+PG4ROaHrqxdAcIyEAHe 1APXsX3hXXVSBxxeSwFDxQlos+50T0AmGZOjJL3gK0dZt8yu/Wokk6iuVrSERuu2 x/D2mtOEbhpu2i4YXbgHMAEXayxYr/t+88PC8StAb6CicM4LmbNGNG8JAFrSW+q5 AoXreMs5aM4jjvOrCL/lDYADDzgN/M41eT5vYNAv6KWGA57upAhENg5ar+ukhi9l QiDsjPDL64LfZtTaRrxV76PCBMoP/BVMhumtY0TCu8QvvxuKCFcIQ+5LHExt+Q2l XmF5woFzCtgVI8P4KTCU3eWi+QT5+TSgGQqHd7VrK6qRI7Jc/fh6JpQxrOo0x+j7 wJPS3uk99IcCwh2w0Z8jA3oiCEOKpxfjb8EP4udyVN6BsPX2qKcyQ/lRJJRHOuQi rEkTV8Vy0MC1WC6rfNaOeWphyNvsbzP0lm8sNjgxDjSb8egr507aTkjJxE8AsrCP F+nUMg336lM5Ww/VCAYaw8jVaCRnKcsuoPDulaHPG3Te6pa0BFzM4+6eWFAK0xz+ sLFNfCkHNgGDKHoubKnL =SEdW -----END PGP SIGNATURE-----

2 1

Re: [PATCH] quartz: Handle NULL target format in FilterGraph::ConvertTimeFormat. (try 2)
by Nikolay Sivov 09 Jan '16

09 Jan '16

Looks good, thanks.

1 0

Re: winedbg: Add disassembly_flavor option to use the intel disassembly style like gdb's disassembly-flavor option.
by Michael Müller 08 Jan '16

08 Jan '16

Am 08.01.2016 um 04:28 schrieb Changhui LIU: > The disassembler source is cloned from https://github.com/vmt/udis86. > It is Simplified BSD License. I think your code has a much higher probability in getting accepted if you do not fork the source code but instead link dynamically or statically against this library, i.e. search for the library in configure.ac. I have to admit though that not many distros seem to ship the library as package. You should also put your implementation into #if defined(__i386__) || defined(__amd64__) blocks since Wine also supports other architectures like ARM which are not supported by udis86. The option should be unavailable on these platforms and it also does not make much sense to link against the library in this case. Regards, Michael

1 0

Re: [PATCH 1/3] d3dx9: Implement D3DXCreateAnimationController with a stubbed ID3DXAnimationController interface. (try 2)
by Matteo Bruni 08 Jan '16

08 Jan '16

2016-01-06 3:52 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Correct QI to be like the IDevice11 one. > Changed DOUBLE to double in the interface. > Adjusted parameter names in D3DXCreateAnimationController > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > +static inline struct d3dx9_animation_controller *impl_from_ID3DXAnimationController(ID3DXAnimationController *iface) Not a big deal but I think it's better to avoid the "inline" here, it's unnecessary in this case since the function isn't in a .h file. > +static HRESULT WINAPI d3dx9_animation_controller_AdvanceTime(ID3DXAnimationController *iface, double time_delta, > + ID3DXAnimationCallbackHandler **callback_handler) I think callback_handler only wants one '*' here. > +static HRESULT WINAPI d3dx9_animation_controller_GetTrackPriority(ID3DXAnimationController *iface, > + UINT track, D3DXPRIORITY_TYPE *priority) This one should be called SetTrackPriority, at least according to the header from the June 2010 DirectX SDK. The header currently in Wine has the same GetTrackPriority prototype you used here (it's there since the header was first introduced by Dylan Smith in 5cccad1311745117628b9a5f10652b5211151b51). I guess this is simply a typo in our header and it "propagated" here but if anyone knows better please speak up ;) Quite reasonably, in a sense, the "priority" parameter for the SetTrackPriority method is not supposed to be a pointer. > +static HRESULT WINAPI d3dx9_animation_controller_SetTrackPosition(ID3DXAnimationController *iface, > + UINT track, double position) > +{ > + FIXME("iface %p, track %u, position %g stub.\n", iface, track, position); It doesn't seem a good choice to me to use %g instead of %f for double parameters. > +static HRESULT WINAPI d3dx9_animation_controller_SetTrackEnable(ID3DXAnimationController *iface, > + UINT track, BOOL enable) > +{ > + FIXME("iface %p, track %u, enable %u stub.\n", iface, track, enable); BOOL is defined as long i.e. signed. > +static D3DXEVENTHANDLE WINAPI d3dx9_animation_controller_GetUpcomingPriorityBlend(ID3DXAnimationController *iface, > + D3DXEVENTHANDLE handle) > +{ > + FIXME("iface %p, handle %u stub.\n", iface, handle); Not too important but you called all the other occurrences "event" instead of "handle". > +static HRESULT WINAPI d3dx9_animation_controller_CloneAnimationController(ID3DXAnimationController *iface, UINT max_num_anim_outputs, > + UINT max_num_anim_sets, UINT max_num_tracks, UINT max_num_events, ID3DXAnimationController **anim_controller) You can probably drop the "num_" part of those parameter names for brevity.

2 2

Re: [PATCH 1/4] include: Add declarations for D3DUSAGEs added with d3d9ex.
by Henri Verbeet 08 Jan '16

08 Jan '16

On 7 January 2016 at 16:22, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +/* Parts added with d3d9ex */ > +#if !defined(D3D_DISABLE_9EX) > +#define D3DUSAGE_RESTRICTED_CONTENT __MSABI_LONG(0x00000800) > +#define D3DUSAGE_RESTRICT_SHARED_RESOURCE_DRIVER __MSABI_LONG(0x00001000) > +#define D3DUSAGE_RESTRICT_SHARED_RESOURCE __MSABI_LONG(0x00002000) > +#define D3DUSAGE_TEXTAPI __MSABI_LONG(0x10000000) That's a bit of a problem, D3DUSAGE_TEXTAPI conflicts with WINED3DUSAGE_TEXTURE. These would also get masked out by WINED3DUSAGE_MASK.

2 1

Re: [PATCH] comctl32: Update Thumb Rect when position changes
by Nikolay Sivov 08 Jan '16

08 Jan '16

On 08.01.2016 10:33, Alistair Leslie-Hughes wrote: > --- > dlls/comctl32/trackbar.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/trackbar.c b/dlls/comctl32/trackbar.c > index 6d092a3..3a92794 100644 > --- a/dlls/comctl32/trackbar.c > +++ b/dlls/comctl32/trackbar.c > @@ -1225,13 +1225,17 @@ TRACKBAR_SetPos (TRACKBAR_INFO *infoPtr, BOOL fPosition, LONG lPosition) > infoPtr->lPos = lPosition; > > if (infoPtr->lPos < infoPtr->lRangeMin) > - infoPtr->lPos = infoPtr->lRangeMin; > + infoPtr->lPos = infoPtr->lRangeMin; > > if (infoPtr->lPos > infoPtr->lRangeMax) > - infoPtr->lPos = infoPtr->lRangeMax; > + infoPtr->lPos = infoPtr->lRangeMax; > infoPtr->flags |= TB_THUMBPOSCHANGED; > > - if (fPosition && oldPos != lPosition) TRACKBAR_InvalidateThumbMove(infoPtr, oldPos, lPosition); > + if (fPosition && oldPos != lPosition) > + { > + TRACKBAR_UpdateThumb(infoPtr); > + TRACKBAR_InvalidateThumbMove(infoPtr, oldPos, infoPtr->lPos); > + } > > return 0; > } > It's updated indirectly later I think. What does this fix? Visually SETPOS works as it is for me.

2 1

Re: ntdll: add RtlCreateUserProcess stub (try 2)
by Sebastian Lackner 08 Jan '16

08 Jan '16

On 28.12.2015 00:58, Austin English wrote: > Using info from http://www.rohitab.com/discuss/topic/40191-ntcreateuserprocess/ > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38722 > > Try 2: fix prototypes > > -- -Austin > > > 0001-ntdll-add-RtlCreateUserProcess-stub-try-2.patch > > > From 27f4ac611c2d7c9b0d778519fc6eb9675dbd6b09 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Tue, 15 Dec 2015 01:51:05 -0600 > Subject: [PATCH] ntdll: add RtlCreateUserProcess stub (try 2) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/ntdll/ntdll.spec | 2 +- > dlls/ntdll/rtl.c | 13 +++++++++++++ > include/winternl.h | 10 ++++++++++ > 3 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index c3b6bf0..b8abc9c 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -505,7 +505,7 @@ > @ stdcall RtlCreateTimerQueue(ptr) > @ stdcall RtlCreateUnicodeString(ptr wstr) > @ stdcall RtlCreateUnicodeStringFromAsciiz(ptr str) > -@ stub RtlCreateUserProcess > +@ stdcall RtlCreateUserProcess(ptr long ptr ptr ptr long long long long ptr) > @ stub RtlCreateUserSecurityObject > @ stdcall RtlCreateUserThread(long ptr long ptr long long ptr ptr ptr ptr) > @ stub RtlCustomCPToUnicodeN > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 8eb3e9f..1c9b50d 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1595,3 +1595,16 @@ void WINAPI RtlGetCurrentProcessorNumberEx(PROCESSOR_NUMBER *processor) > processor->Number = NtGetCurrentProcessorNumber(); > processor->Reserved = 0; > } This needs rebasing, your RtlInsertElementGenericTableAvl() implementation conflicts here. > + > +/********************************************************************** > + * RtlCreateUserProcess [NTDLL.@] > + */ > +NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *path, ULONG attributes, RTL_USER_PROCESS_PARAMETERS *parameters, > + SECURITY_DESCRIPTOR *process_descriptor, SECURITY_DESCRIPTOR *thread_descriptor, > + HANDLE parent, BOOLEAN inherit, HANDLE debug, HANDLE exception, > + RTL_USER_PROCESS_INFORMATION *info) > +{ > + FIXME("(%p %u %p %p %p %p %d %p %p %p): stub\n", path, attributes, parameters, process_descriptor, thread_descriptor, > + parent, inherit, debug, exception, info); > + return STATUS_NOT_IMPLEMENTED; > +} > diff --git a/include/winternl.h b/include/winternl.h > index ecd5791..69b7b2d 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -1892,6 +1892,15 @@ typedef struct _LPC_MESSAGE { > UCHAR Data[ANYSIZE_ARRAY]; > } LPC_MESSAGE, *PLPC_MESSAGE; > > +typedef struct _RTL_USER_PROCESS_INFORMATION > +{ > + ULONG Length; Most definitions I have found call this field "Size", not "Length". Based on which header files is your patch? > + HANDLE Process; > + HANDLE Thread; > + CLIENT_ID ClientId; > + SECTION_IMAGE_INFORMATION ImageInformation; > +} RTL_USER_PROCESS_INFORMATION, *PRTL_USER_PROCESS_INFORMATION; > + > typedef enum _SHUTDOWN_ACTION { > ShutdownNoReboot, > ShutdownReboot, > @@ -2391,6 +2400,7 @@ NTSYSAPI NTSTATUS WINAPI RtlCreateTimerQueue(PHANDLE); > NTSYSAPI NTSTATUS WINAPI RtlCreateTimer(PHANDLE, HANDLE, RTL_WAITORTIMERCALLBACKFUNC, PVOID, DWORD, DWORD, ULONG); > NTSYSAPI BOOLEAN WINAPI RtlCreateUnicodeString(PUNICODE_STRING,LPCWSTR); > NTSYSAPI BOOLEAN WINAPI RtlCreateUnicodeStringFromAsciiz(PUNICODE_STRING,LPCSTR); > +NTSYSAPI NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *, ULONG, RTL_USER_PROCESS_PARAMETERS *, SECURITY_DESCRIPTOR *, SECURITY_DESCRIPTOR *, HANDLE, BOOLEAN, HANDLE, HANDLE, RTL_USER_PROCESS_INFORMATION *); > NTSYSAPI NTSTATUS WINAPI RtlCreateUserThread(HANDLE,const SECURITY_DESCRIPTOR*,BOOLEAN,PVOID,SIZE_T,SIZE_T,PRTL_THREAD_START_ROUTINE,void*,HANDLE*,CLIENT_ID*); > NTSYSAPI void WINAPI RtlDeactivateActivationContext(DWORD,ULONG_PTR); > NTSYSAPI PVOID WINAPI RtlDecodePointer(PVOID); > -- 2.6.4 >

2 2

[RFC] Removing 200XXXXX versions from Bugzilla
by Austin English 08 Jan '16

08 Jan '16

Howdy all, I'd like to remove the old 200XXXXX from Bugzilla, and replace them with a pre-0.9 version instead. My reasoning is that it's obnoxious to have to find the latest release in the middle of the list (or type it in to find it), but if we removed all the 200XXXXX versions, it would be the second to last (next to -unknown). For that matter, I'd be okay with merging everything pre-1.0, but I'm mostly concerned about the 200XXXXX versions. Comments would be appreciated. -- -Austin

3 3