December 2015 - Wine-Devel - list.winehq.org

Re: [PATCH v2] ole32: Properly implement OleRegGetUserType()

by Nikolay Sivov

On 30.12.2015 22:05, Marvin wrote: > 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. > > Nice, so the ones that fail are logged in with privileged user, and for regular user it works fine.

Dec. 30, 2015

Re: [PATCH v2] ole32: Properly implement OleRegGetUserType()

by Marvin

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)

Dec. 30, 2015

Re: Plug and Play and Wine

by Aric Stewart

Thanks for the reply! Sorry for my delay I am on vacation so e-mail and think about complicated things like this time is more scarce. On 12/22/15 12:13 PM, Damjan Jovanovic wrote: > > I've already done that. Attached are 2 patches that make driver loading independent of global variables, and move driver loading code from winedevice.exe to ntoskrnl.exe where it can be reused to load drivers from anything that links to ntoskrnl.exe. > That is pretty cool! Have you submitted these for review and comment? It would be nice to move the driver loading somewhere like ntoskrnl > > My work on USB uses a similar idea. > > In my design, usbhub.sys (my "bus driver") is loaded at Wine start-up. It is loaded by winedevice.exe, in its own separate winedevice.exe process just like every driver currently is, but it is able to (using my previously mentioned patches) load USB device drivers into its own process, and leading to a hybrid driver architecture where copy protection drivers should continue to work as they get loaded into their own winedevice processes and crashes won't affect other drivers, while usbhub.sys can load USB drivers into its own process as needed to provide hardware support. That should plug into this structure pretty easily, that is good to know. the usbhub.sys will no longer be loaded by winedevice.exe but instead it will be integrated into plugplay.exe, still in driver style for later pull out if we want. > > Also I planned to detect device additions and removals by listing all USB devices every second, and detecting what changed since the previous listing. This is because there is no other portable way to read device addition/removal events: there used to be HAL but now we've degenerated to the Linux-only udev :-(. I was planning to hack the plug and play side of things ;-). A background thread in usbhub.sys would do this polling for USB devices and build device objects and load drivers. > If you are using udev then you should be able to to listen for device removal and insertion without having to poll. In my proof of concept Plug and Play setup I have a udev setup that does this for hidraw devices and it quite straight forward. > We should probably develop the plug and play system before USB though? I agree. So far I am looking at the lack of much comment as people not having any problem with this, and since it works with your concept and artecheture I will start cleaning it up and try to submit patches soon after the new year. -aric

Dec. 30, 2015

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it

by Alexandre Julliard

Kira Backes <kira.backes(a)nrwsoft.de> writes: > On Tue, Dec 22, 2015 at 11:32 PM, Kira Backes <kira.backes(a)nrwsoft.de> wrote: >> Hello @André and @Nikolay, >> >> please note that I defined the struct this exact way because of this >> MSDN article: >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms644969%28v=vs.85… >> >> So if you think it's a bad idea to follow the definition of the MSDN >> article then please tell me what I should change so I can improve the >> patch. >> >> kind regards, Kira >> >> On Tue, Dec 22, 2015 at 8:13 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>> Hello again. >>> >>>> +typedef struct >>>> +{ >>>> + MOUSEHOOKSTRUCT MOUSEHOOKSTRUCT; >>>> + DWORD mouseData; >>>> +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; >>> >>> Apparently that's not how Windows SDK defines it. For some obscure >>> reason they didn't define EX struct simply as non-EX + extra field, >>> but used cpp style, kind of. Older versions don't even have field name >>> for MOUSEHOOKSTRUCT portion, only type, but this won't work, not with >>> gcc at least. SDK 10 uses DUMMYSTRUCTNAME as a field name, which >>> resolves to 's', if NONAMELESSSTRUCT is defined. I guess we have to >>> follow version 10 definition. > > How should we proceed here? One suggestion that came up was to just > add the fields of MOUSEHOOKSTRUCT to the ..EX struct, and I'm fine > with that solution. If the latest SDK is using DUMMYSTRUCTNAME that's what we should use too. -- Alexandre Julliard julliard(a)winehq.org

Dec. 30, 2015

Re: configure: Detect MinGW-w64 Clang cross toolchain

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > Am 30.12.2015 um 10:09 schrieb Alexandre Julliard: >> 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? >> > > It's possible to use clang with the classic MinGW.org > But if you still want to, I'd also reduce it to i686-w64-mingw32-clang and x86_64-w64-mingw32-clang, > because I think these are the most likely configurations. But then I'd avoid touching prog and would just append those to the list if that's what you want. > (Maybe we should drop the prog parameter all together?) I'd rather not check for a million different combinations if they don't exist in the wild. We can still keep the cpu variants check though. If you want to get rid of the prog parameter, that's fine. -- Alexandre Julliard julliard(a)winehq.org

Dec. 30, 2015

Re: [2/2] kernel32: add tests for GetSystemPreferredUILanguages

by Marvin

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 ''

Dec. 30, 2015

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message(). (resend)

by Marvin

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

Dec. 30, 2015

Re: configure: Detect MinGW-w64 Clang cross toolchain

by André Hentschel

Am 30.12.2015 um 10:09 schrieb Alexandre Julliard: > 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? > It's possible to use clang with the classic MinGW.org But if you still want to, I'd also reduce it to i686-w64-mingw32-clang and x86_64-w64-mingw32-clang, because I think these are the most likely configurations. But then I'd avoid touching prog and would just append those to the list if that's what you want. (Maybe we should drop the prog parameter all together?)

Dec. 30, 2015

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message().

by Marvin

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

Dec. 30, 2015

Re: [PATCH] ole32: Properly implement OleRegGetUserType()

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> 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. > > > > String 'form' argument was ignored before, and it's wrong. When there's > no additional forms registered it falls back to form 1 as it always did. How do you know that it was not an intended behaviour? -- Dmitry.

Dec. 30, 2015