October 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] msvcrt: Implement __std_type_info_hash

by Piotr Caban

Hi Alexandre, On 10/04/16 22:49, GOUJON Alexandre wrote: > - MSVCRT_size_t hash = 0x811c9dc5; > + MSVCRT_size_t hash; > + MSVCRT_size_t fnvPrime; > const char *p; > > + if(sizeof(void*) == sizeof(int)) > + { > + hash = 0x811c9dc5; > + fnvPrime = 0x1000193; > + } > + else > + { > + hash = 0xcbf29ce484222325; > + fnvPrime = 0x100000001b3; > + } > + Please change name of fnvPrime variable to something like fnv_prime. Also you will need to initialize it using #ifdef, something like this should work: #ifdef _WIN64 MSVCRT_size_t hash = ... #else MSVCRT_size_t hash = ... #endif > + return hash ^ (hash >> 32); This will also cause compilation warning during 32-bit compilation. > diff --git a/dlls/ucrtbase/tests/cpp.c b/dlls/ucrtbase/tests/cpp.c > index 1a01fea..659269c 100644 > --- a/dlls/ucrtbase/tests/cpp.c > +++ b/dlls/ucrtbase/tests/cpp.c > @@ -163,7 +163,7 @@ static void test___std_type_info(void) > ti1.mangled[2] = 0; > hash1 = p___std_type_info_hash(&ti1); > #ifdef _WIN64 > - todo_wine ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); > + ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); And this. Thanks, Piotr

Oct. 5, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Józef Kucia

On Tue, Oct 4, 2016 at 10:43 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 3 October 2016 at 17:27, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> I think this fix is correct. The device keeps a reference to the implicit >> swapchain. The implicit swapchain is destroyed just before leaving from >> wined3d_device_uninit_3d() so it should be safe to call context_acquire(). >> >> This problem occurs only for additional swapchains and that's why it happens >> only in test_swapchain_flip(). > > You're probably right. (Although that's not to say the code wouldn't > benefit from being a little more robust. I think it's hard to reason > about.) Is state_unbind_shaders() required? I assume it's because > unbinding the shaders needs to happen before destroying the shader > backend, but would delaying the context_acquire() call until after the > wine_rb_clear() call also work? Yes, delaying context_acquire() would also work.

Oct. 5, 2016

wine-1.8.5-rc2 Available

by Michael Stefaniuc

Hello guys, wine-1.8.5-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ The commit "user32: Prevent resetting WS_MINIMIZE through SetWindowLong." was deferred as Józef and Alexandre were not convinced about that one. bye michael

Oct. 5, 2016

Re: [PATCH] winebus.sys: Implement common IRP_MJ_POWER handling

by Sebastian Lackner

On 05.10.2016 02:23, Aric Stewart wrote: > +NTSTATUS WINAPI common_power_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE("Device entering power state %i\n", irpsp->Parameters.Power.State.DeviceState); You are ignoring the MinorFunction parameter here. DeviceState is only valid for IRP_MN_SET_POWER, but there are also other IRP_MJ_POWER requests. For those it would be better to keep irp->IoStatus.u.Status set the original value, similar to how its done in common_pnp_dispatch. I would also suggest to add a TRACE with device and irp here (and to common_pnp_dispatch), otherwise it is difficult to interpret the meaning of the logged values. The TRACE in handle_IRP_MN_QUERY_ID could be removed then. Regards, Sebastian > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + return STATUS_SUCCESS; > +} > +

Oct. 5, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Alex Henrie

Thanks for the feedback! -Alex

Oct. 4, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Alex Henrie

2016-10-04 3:06 GMT-06:00 Hugh McMaster <hugh.mcmaster(a)outlook.com>: > On Monday, 3 October 2016 5:14 PM, Alex Henrie wrote: > >> msinfo32 does not take any command line arguments, so I changed >> WINE_FIXME to WINE_TRACE. > > No. msinfo32 accepts many command line arguments. See, for example, https://support.microsoft.com/en-au/kb/300887. Thanks, I should have googled it. I ran `msinfo32 /?` and when nothing appeared on the console, I assumed that the program had no command line mode. I see now that the /? switch actually opened a help window. >> +#include <shlwapi.h> >> + >> +#include "resource.h" >> +#include "shellapi.h" >> #include "wine/debug.h" > > resource.h should come after wine/debug.h. You might also like to put shellapi.h before shlwapi.h. Okay, will do. >> int wmain(int argc, WCHAR *argv[]) >> { >> + static const WCHAR wineSystemInfoW[] = >> + {'W','i','n','e',' ','S','y','s','t','e','m',' ','I','n','f','o','r','m','a','t','i','o','n',0}; >> + WCHAR systemInfo[64]; >> int i; >> >> - WINE_FIXME("stub:"); >> for (i = 0; i < argc; i++) >> - WINE_FIXME(" %s", wine_dbgstr_w(argv[i])); >> - WINE_FIXME("\n"); >> + WINE_TRACE(" %s", wine_dbgstr_w(argv[i])); >> + WINE_TRACE("\n"); >> + >> + LoadStringW(GetModuleHandleW(NULL), STRING_SYSTEM_INFO, systemInfo, sizeof(systemInfo)/sizeof(WCHAR)); >> + ShellAboutW(NULL, systemInfo, wineSystemInfoW, NULL); > > The dialog box text should also be translatable. Add it to the string table as well. I modeled this after Notepad, where "Wine Notepad" is not translatable. After looking at more examples, I think I'd prefer to make the third parameter NULL. >> +#include "resource.h" >> + >> +STRINGTABLE >> +{ >> + STRING_SYSTEM_INFO, "System Information" >> +} > >> +#define STRING_SYSTEM_INFO 0x170 > > Why #define this as 0x170? We normally start string tables from, e.g., 100, 101, 1000 or 1001. Also modeled after Notepad, where this string happens to be 0x170. I'll change it to 100. -Alex

Oct. 4, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Hugh McMaster

On Monday, 3 October 2016 5:14 PM, Alex Henrie wrote: > msinfo32 does not take any command line arguments, so I changed > WINE_FIXME to WINE_TRACE. No. msinfo32 accepts many command line arguments. See, for example, https://support.microsoft.com/en-au/kb/300887. > +#include <shlwapi.h> > + > +#include "resource.h" > +#include "shellapi.h" > #include "wine/debug.h" resource.h should come after wine/debug.h. You might also like to put shellapi.h before shlwapi.h. > int wmain(int argc, WCHAR *argv[]) > { > + static const WCHAR wineSystemInfoW[] = > + {'W','i','n','e',' ','S','y','s','t','e','m',' ','I','n','f','o','r','m','a','t','i','o','n',0}; > + WCHAR systemInfo[64]; > int i; > > - WINE_FIXME("stub:"); > for (i = 0; i < argc; i++) > - WINE_FIXME(" %s", wine_dbgstr_w(argv[i])); > - WINE_FIXME("\n"); > + WINE_TRACE(" %s", wine_dbgstr_w(argv[i])); > + WINE_TRACE("\n"); > + > + LoadStringW(GetModuleHandleW(NULL), STRING_SYSTEM_INFO, systemInfo, sizeof(systemInfo)/sizeof(WCHAR)); > + ShellAboutW(NULL, systemInfo, wineSystemInfoW, NULL); The dialog box text should also be translatable. Add it to the string table as well. > +#include "resource.h" > + > +STRINGTABLE > +{ > + STRING_SYSTEM_INFO, "System Information" > +} > +#define STRING_SYSTEM_INFO 0x170 Why #define this as 0x170? We normally start string tables from, e.g., 100, 101, 1000 or 1001.

Oct. 4, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Henri Verbeet

On 3 October 2016 at 17:27, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > 03.10.2016 3:47 PM "Henri Verbeet" <hverbeet(a)gmail.com>: >> I think it may be harder to fix than this. If state_unbind_resources() >> can end up destroying the (primary) swapchain, it's not safe to call >> context_acquire() afterwards. Which means it's unsafe to unload >> resources or even unload a different SRV. The reason destroying the >> RTVs is currently safe, is that we unloaded resources earlier, so >> releasing the references to the resources for those views shouldn't >> acquire a context to destroy e.g. the GL texture again, but that's >> already more fragile than I'd like. Perhaps we should just delay >> destroying the context until leaving the last level. > > I think this fix is correct. The device keeps a reference to the implicit > swapchain. The implicit swapchain is destroyed just before leaving from > wined3d_device_uninit_3d() so it should be safe to call context_acquire(). > > This problem occurs only for additional swapchains and that's why it happens > only in test_swapchain_flip(). You're probably right. (Although that's not to say the code wouldn't benefit from being a little more robust. I think it's hard to reason about.) Is state_unbind_shaders() required? I assume it's because unbinding the shaders needs to happen before destroying the shader backend, but would delaying the context_acquire() call until after the wine_rb_clear() call also work?

Oct. 4, 2016

Re: [3/3] winebus.sys: Add implementation for device removal. (v9)

by Aric Stewart

On 10/3/16 2:05 PM, Sebastian Lackner wrote: > On 03.10.2016 17:27, Aric Stewart wrote: >> >> On 10/3/16 6:29 AM, Sebastian Lackner wrote: >>>> From: Aric Stewart <aric(a)codeweavers.com> >>>> >>>> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >>>> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >>>> --- >>>> >>>> Second part of 126774. Besides splitting, I've also done the following changes: >>>> >>>> * Rename find_hid_device -> bus_find_hid_device, for consistency with other bus_*_hid_*() functions. >>>> * Do not append timestamp to the device names. To make the code more robust, I've modified >>>> bus_remove_hid_device() to defer the release of the pnp_device pointer. If there are more >>>> problems I would prefer to fix them properly, adding the timestamp seems more like a hack to me. >>>> * Some style improvements. >>>> >>>> @Aric: I'm not sure if you are aware of it, but there is currently still a bug somewhere which >>>> causes a crash during RemovalRelations when trying to remove a driver which was never added properly. >>>> I feel like the right place to fix that is somewhere in ntoskrnl. Are you aware of this issue? >>>> >> Yes, that bug is fixed by patch 126650, which has not been reviewed or committed yet. > > The patch does not help here. It also sounds like you are trying to fix a different > problem because the issue I have can be reproduced without winehid/hidclass. > Nevertheless, one way to improve 126650 would be to remove the unnecessary "break;" > after the return. > Ahh yes, Got ahead of myself. I will try to get a chance to circle up on that and fix 126650, As for this crash I am betting it has to do with not handling the power ioctls in the base device. I will try to dig into that also when I get a chance. Traveling for the next 3 weeks so my time may be intermittent but I will try to carve out a chance to get to this. -aric > Regards, > Sebastian >

Oct. 4, 2016

Re: [PATCH 3/7] wined3d: Bind dummy textures to all texture image units.

by Józef Kucia

On Mon, Oct 3, 2016 at 3:46 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> >> --- >> dlls/wined3d/context.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> > Not that there's anything wrong with this, but what's the idea behind it? > > It should be useful when we remove hardcoded sampler limits for D3D10+.

Oct. 3, 2016