- wine-devel - winehq.org

Re: [PATCH 1/4] ntdll: Use correct parameter types instead of casting.
by Sebastian Lackner 31 Dec '15

31 Dec '15

On 30.12.2015 06:37, Alex Henrie wrote: > Casting has not been necessary here ever since this code was converted > to use wineserver requests circa Wine 1.0. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ntdll/file.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 1027b54..6524f32 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -411,10 +411,8 @@ static struct async_fileio *alloc_fileio( DWORD size, HANDLE handle, PIO_APC_ROU > } > > /* callback for irp async I/O completion */ > -static NTSTATUS irp_completion( void *user, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > +static NTSTATUS irp_completion( struct async_irp *async, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > { It would no longer match the prototype in dlls/ntdll/server.c then: NTSTATUS (*func)(void *, IO_STATUS_BLOCK *, NTSTATUS, void **, void **) = wine_server_get_ptr( call->async_io.func );

2 1

Re: [PATCH 2/2] odbccp32: Implement SQLRemoveDriver/SQLRemoveDriverW
by Marvin 31 Dec '15

31 Dec '15

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=19279 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH 1/2] odbccp32: Implement SQLInstallDriverEx correctly
by Marvin 31 Dec '15

31 Dec '15

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=19278 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH v2] ole32: Properly implement OleRegGetUserType()
by Marvin 30 Dec '15

30 Dec '15

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=19269 Your paranoid android. === wvistau64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7u (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w8 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === wvistau64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null)

2 1

Plug and Play and Wine
by Aric Stewart 30 Dec '15

30 Dec '15

Hello All, Yay 1.8! So in discussions with Alexandre, he expressed that he would really like there to be a Plug and Play system in wine to support the HID work I have been doing. Others at WineConf also expressed a desire for a plug and play system. So I have been doing research, reading and work to try to design out how this system will work. I promised him that while I would do research and testing I would wait until after the release before initiating this conversation. We also discussed at WineConf that design processes like this should happen more out in the open so here is my proposed design, with my thinking, so that people who have interest and maybe more knowledge about parts of this than I can help improve the design. I have done some basic proof of concept coding on most of this so that I know it can work, but have flexibility. Long discussion below. The main thing I have learned is that this side of Plug and Play (The system side) is very complicated and pretty much completely undocumented. So this beginning design is going to be greatly simplified but hopefully in enough of a good framework state that it can be expanded as needed. A few definitions, these are borrowed terms but may not be specifically defined exactly the same as on windows: Bus driver : this is whatever lump of code that it talking to the underlying devices, this should be talking to platform native devices. For the purposes of our PnP the bus driver will be only really responsible for enumerating devices, detecting addition and removal of devices and being able to generate device IDs for these devices. This will all be wine code as far as I can determine. Device Driver: This is the code that is actually trying to do something with the device enumerated but the bus driver. This too will likely be wine code. Think a hid minidriver or usb.sys. Generally any supported native drivers will have to sit above this particular device driver level. But that could maybe change, we will see Plug and Play manager: This is the chunk of code that manages all the driver, devices and does the plug and play work. I have chosen to make the existing Programs/plugplay.exe be the plug and play manager. No INF processing or install: The most important part of this that is missing and that I am not addressing is anything about driver installation or inf files. Right now everything in this process is wine builtin code, so there is no need to have inf processing, and that is a seriously complicated part of this process. I have not fully figured out how we should manage the driver store and do the full driver on demand installation and such. But a basic framework can be put together without it. The Plug and Play process, (As I see it for wine) Ok, here is the meat of what is interesting. Starting at the bottom. Plug and Play bus drivers will be written for OS/X HID devices as well as udev hidraw devices. When I discussed this with Alexandre he did not feel like these need to be individual dlls, so they will be included in the plugplay.exe manager. However they will be designed in such a way that if a compelling reason why we need to pull them out becomes apparent it will not be difficult. These bus drivers will not be full device driver really, they just handle the Plug and play aspects of the bus, the device->DeviceExtension will be simply be a handle to the native device in question. The driver will only handle IRP_MJ_PNP ioctls. Having these be loaded into the plugplay.exe manager process space makes many things much easier. When the bus driver detects a new device it will call PNP_IoInvalidateDeviceRelations, and internal function inside of plugplay.exe that mirrors IoInvalidateDeviceRelations. Because the bus drivers are living inside of the plugplay manager there is no need to implement and deal with the ntoskrnl.exe version of IoInvalidateDeviceRelations. Again this will be coded to be able to be pulled out if needed. If we decide to handle any bus drivers that live outside of the plugplay.exe process space then we will need to have this functionality, probably via RPC like the service manager. Here is where the fun comes. Because we are not handling installing drivers (yet) we can just make use of the critical device store. These are drivers that, on windows, are automatically loaded on boot every time. This database is maintained in [CurrentControlSet/Control/CriticalDeviceDatabase] The keys in this registry key represent a HardwareID that will match a device. We query the IDs from the bus device’s BusQueryHardwareIDs and if we find a match (from most specific to most general) we look at that registry key. The CriticalDeviceDatabase entry will specify a [Service] value. All the first round builtin drivers will specify the [Service]. Further implementations when we start supporting inf files will also look at supporting the [ClassGUID] value where a driver inf can be specified. That Service will specify a key in [CurrentControlSet\Services]. These services will need to be [type] of 0x1 (device driver) and [start] of 0x3 (on demand), finally they will have an [ImagePath] that points to the .sys file for this driver. The plug and play manager will determine if it has loaded that driver or not, and if not then it will load the driver into its process space and call the drivers DriverEntry. Part of this will be done via the advapi service APIs to query the service and then I was planing to reuse code from winedevice.exe for the actual loading of the driver.sys into the plugplay.exe process space. With the loaded driver we then call the driver’s extension.AddDevice entry point with the new bus device. The drivers AddDevice function will be well behaved and call IoAttachDeviceToDeviceStack. The Plug and Play manager will look at the bus device after AddDevice and if there is an AttachedDevice then will proceed to call IRP_MN_START_DEVICE on the attached device. Then a IRP_MJ_POWER/IRP_MN_SET_POWER to PowerDeviceD0. It is an important point that having the bus drivers and function drivers all loaded into the same process space means that they have a common process stack for sharing memory and handles and such. Driver will expect this so if we end up having to change this we will have to deal with the complexities of the memory management. Device removal will be more simplistic. When the bus driver detects that a device has been removed then we again make a PNP_IoInvalidateDeviceRelations. Then the plug and play manager will send a IRP_MN_SURPRISE_REMOVAL followed by a IRP_MN_REMOVE_DEVICE ioctl to the AttachedDevice. That will represent the entirety of the process, as I see it on the first pass, for plug and play. Some of the many things this does not do, it does not make use of or maintain a driver store (I think maintained as keys under the [CurrentControlSet/Control/Class/<GUID>] keys). It does not do any of the complicated driver INF, install on demand work and it does not allow for new drivers to be installed via any of the installation processes. But it does not prevent this from being expanded on for next passes. Another big unanswered part of this is the integration with the Plug and Play configuration manager (cfgmgr32.dll) and all the CM_XXX functions. I am only working on the HID bus and drivers, however I feel like we could expand this pretty easily into USB or even mountmgr bus and driver architectures as we move forward. Comments? Thoughts? Anyone actually get to the end here? -aric

2 2

Re: configure: Detect MinGW-w64 Clang cross toolchain
by Alexandre Julliard 30 Dec '15

30 Dec '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -171,17 +171,19 @@ LIBS="$ac_wine_check_funcs_save_LIBS"]) > > dnl **** Check for a mingw program, trying the various mingw prefixes **** > dnl > -dnl Usage: WINE_CHECK_MINGW_PROG(variable,prog,[value-if-not-found],[path]) > +dnl Usage: WINE_CHECK_MINGW_PROG(variable,progs,[value-if-not-found],[path]) > dnl > AC_DEFUN([WINE_CHECK_MINGW_PROG], > [case "$host_cpu" in > i[[3456789]]86*) > ac_prefix_list="m4_foreach([ac_wine_prefix],[w64-mingw32, pc-mingw32, mingw32msvc, mingw32], > - m4_foreach([ac_wine_cpu],[i686,i586,i486,i386],[ac_wine_cpu-ac_wine_prefix-$2 ])) > + m4_foreach([ac_wine_cpu],[i686,i586,i486,i386], > + m4_foreach([ac_wine_prog],[$2],[ac_wine_cpu-ac_wine_prefix-ac_wine_prog ]))) > mingw32-$2" ;; Do we need to duplicate all the names? Or would it be sufficient to check only the w64-mingw one? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] kernel32: add tests for GetSystemPreferredUILanguages
by Marvin 30 Dec '15

30 Dec '15

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=19262 Your paranoid android. === w1064 (32 bit locale) === locale.c:2339: Test failed: LCMapStringEx should fail with bad locale name locale.c:2340: Test failed: unexpected error code -559038737 locale.c:2431: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4154: Test failed: IsValidLocaleName should have failed locale.c:4156: Test failed: IsValidLocaleName should have failed locale.c:4521: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4523: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message(). (resend)
by Marvin 30 Dec '15

30 Dec '15

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

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message().
by Marvin 30 Dec '15

30 Dec '15

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

1 0

Re: [PATCH] ole32: Properly implement OleRegGetUserType()
by Dmitry Timoshkov 30 Dec '15

30 Dec '15

> dlls/ole32/ole2.c | 85 +++++++++++++++++++++++++++++-------------------------- > 1 file changed, 45 insertions(+), 40 deletions(-) It would be helpful to know why this implementaion is considered more "proper" than an existing one, especially taking into account lack of any tests or reference to a bug report. -- Dmitry.

2 2

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Jactry Zeng 30 Dec '15

30 Dec '15

Hi Changhui, I like this patch, too. '&Debug' and 'Show &Details' use a same shortcut key here. @@ -58,6 +50,7 @@ BEGIN IDC_STATIC_TXT2,"SysLink",0,27,60,224,100 DEFPUSHBUTTON "Close", IDOK, 205, 151, 60, 16, WS_TABSTOP PUSHBUTTON "Show &Details", ID_DETAILS, 140, 151, 60, 16, WS_TABSTOP + PUSHBUTTON "&Debug", ID_DEBUG, 75, 151, 60, 16, WS_TABSTOP END I think push this debug button in the left corner seems better? Maybe we also need some text in IDC_STATIC_TXT2 to let users know what it means. Thanks. 2015-12-28 17:21 GMT+08:00 Changhui LIU <liuchanghui(a)linuxdeepin.com>: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > > -- Regards, Jactry Zeng

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Alex Henrie 30 Dec '15

30 Dec '15

I'm pretty sure that the Debug button on the crash dialog is hidden so that people who don't know what they're doing don't try to use it. -Alex

2 1

Re: [PATCH 1/1] msvcr120: Enable MSVCRT__nextafterf when _MSVCR_VER>=120.
by Piotr Caban 29 Dec '15

29 Dec '15

Hi, On 12/28/15 08:19, YongHao Hu wrote: > dlls/msvcr120/msvcr120.spec | 6 +++--- > dlls/msvcr120_app/msvcr120_app.spec | 6 +++--- > dlls/msvcrt/math.c | 18 +++++++++--------- > 3 files changed, 15 insertions(+), 15 deletions(-) Please also update: ucrtbase/ucrtbase.spec api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec files. Thanks, Piotr

2 2

Re: [PATCH] ole32: Zero out pointer in CreateFileMoniker() on error
by Marvin 29 Dec '15

29 Dec '15

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=19236 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w1064 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w1064 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Francois Gouget 29 Dec '15

29 Dec '15

On Tue, 29 Dec 2015, Francois Gouget wrote: [...] > + > + if ((sei_tmp.lpVerb && *sei_tmp.lpVerb) || PathIsExeW(wszApplicationName)) Please don't apply. I think this test is wrong. It should probably be checking that no was specified, or maybe that no class was specified. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Bugzilla changes
by Austin English 29 Dec '15

29 Dec '15

Howdy all, As Alexandre mentioned [1], at WineConf we made several decisions to modify bugzilla in a few ways. I've now implemented those changes, which are outlined below: * New wine-staging product: This should be used for bugs caused by patches that are in wine-staging, but that do not occur in wine-development (i.e., wine-staging patch regressions) * New STAGED resolution: This is to differentiate bugs that are FIXED (in wine-development) from bugs that are not present in wine-staging because of one or more patches. The anticipated workflow is: UNCONFIRMED > bug confirmed, NEW > patch written and sent to wine-patches, if it's accepted, FIXED. If not, and the patch is integrated into wine-staging, then the bug is STAGED. When the patch is revised and eventually integrated into wine-development, the bug should move to FIXED. * New NEEDINFO resolution: There's a lot of confusion and different handling by triagers for what to do with bug reports that are incomplete (i.e., leaving it open versus closing invalid). To mitigate this, I've added a NEEDINFO resolution. If a bug report lacks needed information, set it to this status. Bug that have been open NEEDINFO for more than 1 year can be closed. * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other projects do, and eliminates confusion about the upstream/downstream distinction. Please let me know if there are any questions or ideas for further enhancements. [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html -- -Austin

6 11

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled.
by Aric Stewart 29 Dec '15

29 Dec '15

Sorry for the delayed review, I have been traveling. I understand the issue your trying to fix, but I worry that you could get yourself into a bad state where if a driver is misbehaving and is blocked or crashes while processing an IRP then the halt event will never get processed as we will be waiting INFINITE on an event that may never come. I dont know which is the more likely or problematic case. What I may suggest is keep the WaitForMultipleObjects(2, events, FALSE, INFINITE) and instead of relying on the return code you could do an additional WaitForSingleObject(ext->halt_event, 0) to determine if exit_now should be set. -aric

2 1

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message. (try 3)
by Marvin 29 Dec '15

29 Dec '15

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

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Marvin 29 Dec '15

29 Dec '15

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=19232 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:142: Test failed: ShellExecute(verb="QuotedUpperL", file="C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec") WaitForSingleObject returned 258 shlexec.c:1566: Test failed: argvA3 expected 'QuotedUpperL', but key not found or empty shlexec.c:1574: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec', but key not found or empty === w1064 (32 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2667: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2668: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', but key not found or empty shlexec.c:556: childTimeout called shlexec.c:2679: Test failed: argcA expected 4, but got 3 shlexec.c:2680: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2681: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', got 'C:\Users\winetest\Documents\shell32_test64.exe'

1 0

Re: [1/2] shell32/tests: Make sure the test executable has an executable name.
by Marvin 28 Dec '15

28 Dec '15

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=19231 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2300: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde")]' shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Qian Hong 28 Dec '15

28 Dec '15

I like this change, thank you for the patch. On Mon, Dec 28, 2015 at 5:21 PM, Changhui LIU <liuchanghui(a)linuxdeepin.com> wrote: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > -- Regards, Qian Hong - http://www.winehq.org

1 0

Out-of-date gcc and ld on the testbot build VM
by Hugh McMaster 28 Dec '15

28 Dec '15

The testbot seems to have an out-of-date version of mingw32, or at least, its linker, ld.exe. I'm trying to run tests for GetConsoleScreenBufferInfoEx, a function available on Vista and higher. But the build VM's linker is failing with an undefined reference: reg.o: In function `test_GetConsoleScreenBufferInfoEx': /home/winetest/tools/testbot/var/build-mingw32/programs/reg/tests/../../../../wine/programs/reg/tests/reg.c:489: undefined reference to `__imp__GetConsoleScreenBufferInfoEx@8' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed My machine is able to compile the tests. It also has no trouble building a separate .exe using i686-w64-mingw32-gcc. My machine has: - mingw32 gcc version 4.8.2 (GCC) - mingw32 ld version: GNU ld (GNU Binutils) 2.23.52.20130620 -- Hugh McMaster

3 5

Re: shell32: add SHCreateSessionKey stub (try 2)
by Nikolay Sivov 28 Dec '15

28 Dec '15

> +/************************************************************************* > + * SHCreateSessionKey [SHELL32.723] NT 4.0 > + * > + */ > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %u %p\n", access, hkey); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} 'access' is a 32bit bit mask, return value is HRESULT.

1 0

Re: shell32: add SHCreateSessionKey stub
by Nikolay Sivov 28 Dec '15

28 Dec '15

On 28.12.2015 8:15, Austin English wrote: > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %d %p\n", access, hkey); > + return ERROR_SUCCESS; > +} This is wrong regarding tracing format, return value and formatting. I'll try to find time this week to send an actual implementation. It's fine to have fixed stub in before that of course.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 4).
by Stefan Dösinger 27 Dec '15

27 Dec '15

> Am 23.12.2015 um 16:46 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + file = create_bitmap("palette.bmp", 3, 39, TRUE); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRM2 interface (hr = %x)\n", hr); > + > + file = create_bitmap("8bpp.bmp", 100, 100, FALSE); The first line here seems to be a leftover from the last patch version. The same applies to the V3 function

2 4

Re: ntdll: add RtlCreateUserProcess stub
by Dmitry Timoshkov 27 Dec '15

27 Dec '15

Austin English <austinenglish(a)gmail.com> wrote: > +NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *path, ULONG attributes, RTL_USER_PROCESS_PARAMETERS *parameters, > + PSECURITY_DESCRIPTOR *process_descriptor, PSECURITY_DESCRIPTOR *thread_descriptor, > + HANDLE parent, BOOLEAN inherit, HANDLE debug, HANDLE exception, > + PRTL_USER_PROCESS_INFORMATION info) Some of the parameters use wrong pointer information. Probably it would be better to completely avoid Pxxx prefixes and use normal pointers for all parameters? -- Dmitry.

2 1

Re: pdh: Fix prototype of PdhGetLogFileType[A/W].
by Austin English 27 Dec '15

27 Dec '15

Thanks for fixing it so quickly Sebastian. I came back from holiday and it was already done :). On Thu, Dec 24, 2015 at 4:08 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > As pointed out on the mailing list yesterday, the first parameter can't be a handle. > Output after this patch: > > fixme:pdh:PdhGetLogFileTypeW L"dummy.log", 0x33fd9c: stub > > dlls/pdh/pdh.spec | 4 ++-- > dlls/pdh/pdh_main.c | 8 ++++---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/pdh/pdh.spec b/dlls/pdh/pdh.spec > index 529b92d..41900c8 100644 > --- a/dlls/pdh/pdh.spec > +++ b/dlls/pdh/pdh.spec > @@ -62,8 +62,8 @@ > @ stub PdhGetFormattedCounterArrayW > @ stdcall PdhGetFormattedCounterValue(ptr long ptr ptr) > @ stub PdhGetLogFileSize > -@ stdcall PdhGetLogFileTypeA(ptr ptr) > -@ stdcall PdhGetLogFileTypeW(ptr ptr) > +@ stdcall PdhGetLogFileTypeA(str ptr) > +@ stdcall PdhGetLogFileTypeW(wstr ptr) > @ stub PdhGetLogSetGUID > @ stub PdhGetRawCounterArrayA > @ stub PdhGetRawCounterArrayW > diff --git a/dlls/pdh/pdh_main.c b/dlls/pdh/pdh_main.c > index 036d28b..8854fd7 100644 > --- a/dlls/pdh/pdh_main.c > +++ b/dlls/pdh/pdh_main.c > @@ -1273,17 +1273,17 @@ PDH_STATUS WINAPI PdhSetDefaultRealTimeDataSource( DWORD source ) > /*********************************************************************** > * PdhGetLogFileTypeA (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeA(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeA(const char *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_a(log), type); > return PDH_NOT_IMPLEMENTED; > } > > /*********************************************************************** > * PdhGetLogFileTypeW (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeW(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeW(const WCHAR *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_w(log), type); > return PDH_NOT_IMPLEMENTED; > } > -- > 2.6.4 > > -- -Austin

1 0

Re: [PATCH 7/7] dwrite: Fix identical ranges merging
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 6/7] dwrite: Locale layout ranged attribute is case-insensitive
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 5/7] dwrite: Store optical alignment property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 4/7] dwrite: Store last line wrapping property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 2/7] dwrite: Store per-range typography property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 1/7] dwrite/tests: One more test for duplicates in IDWriteTypography
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (resend)
by Nikolay Sivov 26 Dec '15

26 Dec '15

On 25.12.2015 10:30, Zhenbo Li wrote: > +static void test_illegal_xml(IXMLDOMDocument *xmldom) > +{ > + IXMLDOMNode *first, *last; > + VARIANT variant; > + HRESULT hres; > + BSTR bstr; > + > + hres = IXMLDOMDocument_get_baseName(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_baseName(xmldom, &bstr); > + ok(hres == S_FALSE, "get_baseName failed: %08x\n", hres); > + ok(bstr == NULL, "bstr(%p): %s\n", bstr, wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_dataType(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_dataType(xmldom, &variant); > + ok(hres == S_FALSE, "get_dataType failed: %08x\n", hres); > + ok(V_VT(&variant) == VT_NULL, "got %s\n", debugstr_variant(&variant)); > + VariantClear(&variant); > + > + hres = IXMLDOMDocument_get_text(xmldom, &bstr); > + ok(!strcmp_wa(bstr, ""), "text = %s\n", wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_firstChild(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + > + first = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_firstChild(xmldom, &first); > + ok(hres == S_FALSE, "get_firstChild failed: %08x\n", hres); > + ok(first == NULL, "first != NULL\n"); > + > + last = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_lastChild(xmldom, &last); > + ok(hres == S_FALSE, "get_lastChild failed: %08x\n", hres); > + ok(last == NULL, "last != NULL\n"); > +} It makes no sense to test every method on empty tree, test for text string. > + hres = IXMLDOMDocument_QueryInterface(xmldoc, &IID_IObjectSafety, (void**)&safety); > + assert(SUCCEEDED(hres)); > + hres = IObjectSafety_SetInterfaceSafetyOptions(safety, NULL, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER); > + assert(SUCCEEDED(hres)); > + IObjectSafety_Release(safety); This looks weird to me, why the asserts? Did Jacek suggest that?

2 2

Re: [2/2] oleaut32: Align terminating null character in SysAllocStringByteLen.
by Nikolay Sivov 25 Dec '15

25 Dec '15

On 25.12.2015 8:38, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > If SysAllocStringByteLen() is used with an odd length, the two terminating > null bytes are not aligned properly, which means that strlenW() would not > find them. Tests show that Windows appends three terminating null bytes in > this case. > > There is no need to change the memory allocation part because we already > round up to the next bucket size. > > dlls/oleaut32/oleaut.c | 14 ++++++-------- > dlls/oleaut32/tests/vartype.c | 29 +++++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 8 deletions(-) > > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index 75f9cb4..78cb083 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -149,12 +149,9 @@ static bstr_t *alloc_bstr(size_t size) > > if(cache_entry) { > if(WARN_ON(heap)) { > - size_t tail; > - > - memset(ret, ARENA_INUSE_FILLER, FIELD_OFFSET(bstr_t, u.ptr[size+sizeof(WCHAR)])); > - tail = bstr_alloc_size(size) - FIELD_OFFSET(bstr_t, u.ptr[size+sizeof(WCHAR)]); > - if(tail) > - memset(ret->u.ptr+size+sizeof(WCHAR), ARENA_TAIL_FILLER, tail); > + size_t fill_size = (FIELD_OFFSET(bstr_t, u.ptr[size])+2*sizeof(WCHAR)-1) & ~(sizeof(WCHAR)-1); > + memset(ret, ARENA_INUSE_FILLER, fill_size); > + memset((char *)ret+fill_size, ARENA_TAIL_FILLER, bstr_alloc_size(size)-fill_size); > } > ret->size = size; > return ret; > @@ -418,10 +415,11 @@ BSTR WINAPI SysAllocStringByteLen(LPCSTR str, UINT len) > > if(str) { > memcpy(bstr->u.ptr, str, len); > - bstr->u.ptr[len] = bstr->u.ptr[len+1] = 0; > + bstr->u.ptr[len] = 0; > }else { > - memset(bstr->u.ptr, 0, len+sizeof(WCHAR)); > + memset(bstr->u.ptr, 0, len+1); > } > + bstr->u.str[(len+sizeof(WCHAR)-1)/sizeof(WCHAR)] = 0; > > return bstr->u.str; > } > diff --git a/dlls/oleaut32/tests/vartype.c b/dlls/oleaut32/tests/vartype.c > index 7cbb059..d905d37 100644 > --- a/dlls/oleaut32/tests/vartype.c > +++ b/dlls/oleaut32/tests/vartype.c > @@ -5444,7 +5444,9 @@ static void test_SysAllocStringByteLen(void) > { > const OLECHAR szTest[10] = { 'T','e','s','t','\0' }; > const CHAR szTestA[6] = { 'T','e','s','t','\0','?' }; > + char *buf; > BSTR str; > + int i; > > if (sizeof(void *) == 4) /* not limited to 0x80000000 on Win64 */ > { > @@ -5487,6 +5489,7 @@ static void test_SysAllocStringByteLen(void) > > ok (bstr->dwLen == 3, "Expected 3, got %d\n", bstr->dwLen); > ok (!lstrcmpA((LPCSTR)bstr->szString, szTestTruncA), "String different\n"); > + ok (!bstr->szString[2], "String not terminated\n"); > SysFreeString(str); > } > > @@ -5500,6 +5503,32 @@ static void test_SysAllocStringByteLen(void) > ok (!lstrcmpW(bstr->szString, szTest), "String different\n"); > SysFreeString(str); > } > + > + /* Make sure terminating null is aligned properly */ > + buf = HeapAlloc(GetProcessHeap(), 0, 1025); > + ok (buf != NULL, "Expected non-NULL\n"); > + for (i = 0; i < 1024; i++) > + { > + LPINTERNAL_BSTR bstr; > + > + str = SysAllocStringByteLen(NULL, i); > + ok (str != NULL, "Expected non-NULL\n"); > + bstr = Get(str); > + ok (bstr->dwLen == i, "Expected %d, got %d\n", i, bstr->dwLen); > + ok (!bstr->szString[(i+sizeof(WCHAR)-1)/sizeof(WCHAR)], "String not terminated\n"); > + SysFreeString(str); > + > + memset(buf, 0xaa, 1025); > + str = SysAllocStringByteLen(buf, i); > + ok (str != NULL, "Expected non-NULL\n"); > + bstr = Get(str); > + ok (bstr->dwLen == i, "Expected %d, got %d\n", i, bstr->dwLen); > + buf[i] = 0; > + ok (!lstrcmpA((LPCSTR)bstr->szString, buf), "String different\n"); > + ok (!bstr->szString[(i+sizeof(WCHAR)-1)/sizeof(WCHAR)], "String not terminated\n"); > + SysFreeString(str); > + } > + HeapFree(GetProcessHeap(), 0, buf); > } Does this work with disabled cache? > > static void test_SysReAllocString(void) >

4 4

Re: winedump: Add initial version of old (SLTG) typelib dumper.
by Alexandre Julliard 25 Dec '15

25 Dec '15

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +static int _isprint(unsigned char c) > { > - int i; > + return c >= 32 ? 1 : 0; Please don't do that. > + > + assert(print_hex("magic") == 0x47544c53); Please don't do that. > + while (offset < name_table_start + name_table_size) > + { > +/*printf("current offset: %08x (relative to name table start: %08x (%u))\n", > + offset, offset - name_table_start, offset - name_table_start);*/ > + dump_binary(8); > + print_string0(); > + printf("\n"); > +/*printf("current offset: %08x (relative to name table start: %08x (%u))\n", > + offset, offset - name_table_start, offset - name_table_start);*/ Please clean these up. > +#if 0 > + print_short_hex("unknown"); > + print_short_hex("byte order mark"); > + i = tlb_read_short(); > + printf("version = %u.%u\n", i & 0xff, i >> 8); > + print_short_hex("system identifier"); > + print_hex("unknown"); > + printf("\n"); > +#else > + printf("skipping 12 bytes\n"); > + dump_binary(12); > + printf("\n"); > +#endif Same here. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Alexandre Julliard 24 Dec '15

24 Dec '15

Anton Baskanov <baskanov(a)gmail.com> writes: > @@ -2977,7 +2977,8 @@ enum coords_relative > int x; /* caret x position */ > int y; /* caret y position */ > int hide; /* increment for hide count (can be negative to show it) */ > - int state; /* caret state (1=on, 0=off, -1=toggle current state) */ > + int state; /* caret state (1=on, 0=off, -1=toggle current state, > + * -2=on if the position differs, unchanged otherwise) */ Please define constants instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Implement wineserver call for SystemHandleInformation. (v2)
by Marvin 24 Dec '15

24 Dec '15

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

2 1

Re: [2/2] server: Implement wineserver call for SystemHandleInformation.
by Alexandre Julliard 24 Dec '15

24 Dec '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -3265,6 +3265,22 @@ enum coords_relative > VARARG(sd,security_descriptor); /* retrieved security descriptor */ > @END > > + > +struct handle_info > +{ > + process_id_t owner; > + obj_handle_t handle; > + unsigned int access; > +}; > + > +/* Return a list of all opened handles */ > +@REQ(get_system_handles) > +@REPLY > + unsigned int count; /* number of handles */ > + VARARG(data,bytes); /* array of handle_infos */ This is not a bytes array, please write a proper dumping function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] ole32/tests: Some tests for OleRegGetUserType()
by Marvin 24 Dec '15

24 Dec '15

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=19139 Your paranoid android. === wxppro (32 bit compobj) === compobj.c:2250: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 4, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 4, got L"CLSID_StdFont" === w2003std (32 bit compobj) === compobj.c:2250: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 4, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 4, got L"CLSID_StdFont"

1 0

Re: [PATCH] kernel32: Set error if dstlen < 0 in codepage conversion functions.
by Marvin 24 Dec '15

24 Dec '15

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=19138 Your paranoid android. === build (build) === Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" command returned 1

1 0

Re: README: add a note about 64-bit Wine and 32-bit apps (try 2)
by Alexandre Julliard 24 Dec '15

24 Dec '15

Austin English <austinenglish(a)gmail.com> writes: > @@ -80,7 +80,9 @@ Optional support libraries: > to make sure to install the 32-bit versions of these libraries; see > http://wiki.winehq.org/WineOn64bit for details. If you want a true > 64-bit Wine (or a mixed 32-bit and 64-bit Wine setup), see > - http://wiki.winehq.org/Wine64 for details. > + http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine > + build will not run 32-bit applications (which many 64-bit applications > + include and rely upon) without also building 32-bit Wine. I think this should go on the mentioned wiki page instead, preferably with a big warning sign. -- Alexandre Julliard julliard(a)winehq.org

3 9

Re: pdh: add PdhGetLogFileTypeA/W stubs
by Sebastian Lackner 23 Dec '15

23 Dec '15

On 23.12.2015 07:36, Austin English wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=23298 > > The function is undocumented, but from reading the documented > functions, especially PdhGetLogFileSize > (https://msdn.microsoft.com/en-us/library/windows/desktop/aa372639%28v=vs.85…), > I made an educated guess. > When there are two functions with A and W suffix, this strongly suggests that there must be a filename parameter somewhere. This means the current interpretation is definitely not correct. Did you verify if it prints useful values?

1 0

Re: [PATCH] oleaut32: Don't store non-heap-allocated strings in the BSTR cache
by Marvin 23 Dec '15

23 Dec '15

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=19120 Your paranoid android. === wxppro (32 bit vartype) === vartype: unhandled exception c0000005 at 7C929F07 === w2003std (32 bit vartype) === vartype: unhandled exception c0000005 at 7C80ED80 === wvistau64 (32 bit vartype) === vartype: unhandled exception c0000005 at 77BC1C9B vartype: unhandled exception c0000005 at 77BC25BD === w2008s64 (32 bit vartype) === vartype: unhandled exception c0000005 at 771E1C9B vartype: unhandled exception c0000005 at 771E25BD === w7u (32 bit vartype) === vartype: unhandled exception c0000005 at 77D161F6 vartype: unhandled exception c0000005 at 77D4A3CE === w7pro64 (32 bit vartype) === vartype: unhandled exception c0000005 at 770F3526 vartype: unhandled exception c0000005 at 7714AED1 === w8 (32 bit vartype) === vartype: unhandled exception c0000005 at 7712C2A7 vartype: unhandled exception c0000005 at 7719661E === w864 (32 bit vartype) === vartype: unhandled exception c0000005 at 77C00044 vartype: unhandled exception c0000005 at 77C58780 === w1064 (32 bit vartype) === vartype: unhandled exception c0000005 at 7728CCC4 vartype: unhandled exception c0000005 at 772DB260 === wvistau64 (64 bit vartype) === No test summary line found === w2008s64 (64 bit vartype) === No test summary line found === w7pro64 (64 bit vartype) === No test summary line found === w864 (64 bit vartype) === No test summary line found === w1064 (64 bit vartype) === No test summary line found

1 0

Re: [PATCH 1/2] dsound: Simplify error handling when creating a sound buffer.
by Sebastian Lackner 23 Dec '15

23 Dec '15

On 22.12.2015 10:49, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > I run into this and wasted time while fixing the bug during the freeze. > So I am submitting the dsound cleanups I have laying around. > > > dlls/dsound/buffer.c | 46 ++++++++++++++++------------------------------ > 1 file changed, 16 insertions(+), 30 deletions(-) > Are you sure this will work as expected? The destructor makes assumptions about specific variables to be initialized. If I don't miss anything, DirectSoundDevice_RemoveBuffer could trigger an assertion / corrupt nrofbuffers now. This->buffer->ref will also not be initialized. Could you please double check that?

2 1

Re: ole32: Print error message when IPersistStorage_Load fails (Coverity)
by Huw Davies 23 Dec '15

23 Dec '15

On Tue, Dec 22, 2015 at 07:35:08PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > CID 1336207 > > dlls/ole32/compobj.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index 2f55076..b146376 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -3443,7 +3443,9 @@ HRESULT WINAPI CoGetInstanceFromIStorage( > > if (ps) > { > - IPersistStorage_Load(ps, storage); > + hr = IPersistStorage_Load(ps, storage); > + if (FAILED(hr)) > + ERR("failed to load storage\n"); > IPersistStorage_Release(ps); > } I suspect Coverity is expecting us to do something more useful with the return value ;-) How about returning the failure in this case (obviously having released ps first)? Also, just above this hunk, we should probably just return if QI fails. While you're at it, there are other CoCreateInstanceFrom* functions that could do with similar love. Huw.

2 1

Re: winspool: Remove dead code (Clang)
by Alexandre Julliard 23 Dec '15

23 Dec '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -4092,8 +4092,6 @@ static BOOL WINSPOOL_GetPrinter_1(HKEY hkeyPrinter, PRINTER_INFO_1W *pi1, > if(WINSPOOL_GetStringFromReg(hkeyPrinter, DescriptionW, ptr, left, &size)) { > if(space && size <= left) { > pi1->pComment = (LPWSTR)ptr; > - ptr += size; > - left -= size; > } else > space = FALSE; > *pcbNeeded += size; There's a clear pattern to the code here, you don't want to break it. I'd suggest redesigning the helper functions to avoid all this duplication. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] shlwapi: implement URL_ESCAPE_AS_UTF8
by Alexandre Julliard 23 Dec '15

23 Dec '15

Daniel Lehman <dlehman(a)esri.com> writes: > @@ -925,6 +955,20 @@ static void test_UrlEscapeW(void) > FreeWideString(urlW); > FreeWideString(expected_urlW); > } > + > + for(i=0; i<sizeof(TEST_ESCAPEW)/sizeof(TEST_ESCAPEW[0]); i++) { > + WCHAR ret_url[INTERNET_MAX_URL_LENGTH]; > + > + size = INTERNET_MAX_URL_LENGTH; > + ret = pUrlEscapeW(TEST_ESCAPEW[i].url, ret_url, &size, TEST_ESCAPEW[i].flags); > + if(ret == E_POINTER || TEST_ESCAPEW[i].broken) /* <= Win7/Win2k8 */ > + continue; That's not going to test anything for the broken cases. > @@ -1188,10 +1194,29 @@ HRESULT WINAPI UrlEscapeW( > if(cur == '\\' && (int_flags & WINE_URL_BASH_AS_SLASH) && !stop_escaping) cur = '/'; > > if(URL_NeedEscapeW(cur, dwFlags, int_flags) && stop_escaping == FALSE) { > - next[0] = '%'; > - next[1] = hexDigits[(cur >> 4) & 0xf]; > - next[2] = hexDigits[cur & 0xf]; > - len = 3; > + if(dwFlags & URL_ESCAPE_AS_UTF8) { > + char utf[4]; > + int i, ret; > + ret = wine_utf8_wcstombs(WC_ERR_INVALID_CHARS, &cur, 1, utf, sizeof(utf)); This won't work for Unicode surrogates. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [resend v2 2/4] ddraw7/tests: Test GetPriority() on cubemap surfaces.
by Marvin 22 Dec '15

22 Dec '15

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=19110 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [resend 3/4] d3d9: Call wined3d_device_copy_sub_resource_region() instead of wined3d_device_update_surface() in d3d9_dev
by Marvin 22 Dec '15

22 Dec '15

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

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