August 2017 - Wine-Devel - list.winehq.org

Re: [4/6] wsdapi: Implement "Hello" message creation support. [try 3]

by Vincent Povirk

Why would it be the same for each interface and protocol? If the purpose is to prevent one big spike of traffic, it seems like you'd want different delays. On Fri, Aug 4, 2017 at 4:34 AM, Owen Rudge <owen(a)owenrudge.net> wrote: >> I think it would make more sense to do the initial random delay on the >> background threads. > > I did consider that. The delay is only intended to be once per message. I could do simultaneous identical delays on each background thread, or I could have a 'delay' thread that then spawns the background threads, instead. For simplicity though I felt I'd just leave the initial delay on the main thread. It does mean there is a slight delay on the main thread compared with Windows when a 'hello' or 'probe matches' message is sent, but compared with the initial version of my patch (which included retransmission delays for every adapter on the main thread) it is much improved. > > If however you feel strongly that this should be altered, I can submit an updated version. > > Cheers, > > -- > Owen Rudge > http://www.owenrudge.net/ > >

Aug. 4, 2017

Re: [4/6] wsdapi: Implement "Hello" message creation support. [try 3]

by Owen Rudge

> I think it would make more sense to do the initial random delay on the > background threads. I did consider that. The delay is only intended to be once per message. I could do simultaneous identical delays on each background thread, or I could have a 'delay' thread that then spawns the background threads, instead. For simplicity though I felt I'd just leave the initial delay on the main thread. It does mean there is a slight delay on the main thread compared with Windows when a 'hello' or 'probe matches' message is sent, but compared with the initial version of my patch (which included retransmission delays for every adapter on the main thread) it is much improved. If however you feel strongly that this should be altered, I can submit an updated version. Cheers, -- Owen Rudge http://www.owenrudge.net/

Aug. 4, 2017

Re: shell32: Implement SHCreateItemInKnownFolder.

by Jactry Zeng

2017-08-02 16:04 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > This is presumably a bug in SHGetKnownFolderIDList(), which we should fix. > Yes, there is a bug in SHGetKnownFolderIDList(), but I find it will not hinder implementing SHCreateItemInKnownFolder(). I will send tests and possible fix for SHGetKnownFolderIDList() later. Thanks! -- Regards, Jactry Zeng

Aug. 4, 2017

Re: [4/6] wsdapi: Implement "Hello" message creation support. [try 3]

by Vincent Povirk

I think it would make more sense to do the initial random delay on the background threads.

Aug. 3, 2017

Re: [4/4] kernel32/tests: Add tests for LoadLibrary with LIBRARY_SEARCH_* flags

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=32575 Your paranoid android. === w2003std (32 bit module) === module.c:443: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x), got 87 module.c:471: Test failed: Could not load test library testFlags.dll from C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ module.c:472: Test failed: Expected 0xdeadbeef or ERROR_SUCCESS, got 87 module.c:481: Test failed: Expected ERROR_MOD_NOT_FOUND or ERROR_DLL_NOT_FOUND (win9x), got 87 module.c:496: Test failed: Library testFlags.dll was expected to be loaded from 'system32' module.c:497: Test failed: Expected 0xdeadbeef or ERROR_SUCCESS, got 87 module.c:505: Test failed: Library testFlags.dll was expected to be loaded from 'system32' module.c:506: Test failed: Expected 0xdeadbeef or ERROR_SUCCESS, got 87 === w7u (32 bit loader) === loader.c:2199: Test failed: expected WAIT_OBJECT_0, got 0x102 loader.c:2209: Test failed: expected thread exit code 196, got 259 loader.c:1713: Test failed: expected thread exit code 196, got 195

Aug. 3, 2017

Re: [PATCH 2/2] winebrowser: Open the default browser if called without an argument.

by Zebediah Figura

On 08/03/2017 01:24 AM, Alexandre Julliard wrote: > Vincent Povirk <madewokherd(a)gmail.com> writes: > >>> I'd suggest to simply open the default start page in that case. That's >>> what iexplore does when there are no arguments. >> >> That's the intent. We don't know what the default start page is for >> the user's default browser, but it should open it when started with no >> arguments. > > I don't mean the default page for the Unix browser, the behavior is > apparently not guaranteed in that case. I mean get the default page > configured on the Windows side, and open that. This way we don't need to > worry about what the Unix browser will do with no arguments. > The program in question loads the value of HKCR/htmlfile/shell/open/command and calls it with no arguments. If I change that to something other than iexplore, the behaviour is left up to that program. So I'm not sure that just following iexplore's behaviour is necessarily appropriate.

Aug. 3, 2017

Re: [PATCH 2/2] winebrowser: Open the default browser if called without an argument.

by Alexandre Julliard

Vincent Povirk <madewokherd(a)gmail.com> writes: > So, we'd just load winehq.org? Seems pretty weird to me. You can open the default search page instead. > I think it's reasonable to expect that a browser will open when its > desktop file is called with no arguments. Whether it loads to its > default start page is unimportant. It's reasonable to expect that winebrowser will open, yes. That's precisely what's broken if we simply pass through to the Unix browser, so providing a default argument seems like an obvious fix. I don't see any benefit in adding complexity to try to make the Unix browser use its default page instead of ours. -- Alexandre Julliard julliard(a)winehq.org

Aug. 3, 2017

Re: [PATCH 2/2] winebrowser: Open the default browser if called without an argument.

by Vincent Povirk

So, we'd just load winehq.org? Seems pretty weird to me. I think it's reasonable to expect that a browser will open when its desktop file is called with no arguments. Whether it loads to its default start page is unimportant. On Thu, Aug 3, 2017 at 1:24 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Vincent Povirk <madewokherd(a)gmail.com> writes: > >>> I'd suggest to simply open the default start page in that case. That's >>> what iexplore does when there are no arguments. >> >> That's the intent. We don't know what the default start page is for >> the user's default browser, but it should open it when started with no >> arguments. > > I don't mean the default page for the Unix browser, the behavior is > apparently not guaranteed in that case. I mean get the default page > configured on the Windows side, and open that. This way we don't need to > worry about what the Unix browser will do with no arguments. > > -- > Alexandre Julliard > julliard(a)winehq.org

Aug. 3, 2017

Re: [1/2] msvcrt/tests: Add tests for mbstowcs and wcstombs with empty strings.

by Piotr Caban

Hi, the patch causes compilation warnings on 64-bit wine. ../../../../wine_src/dlls/msvcrt/tests/string.c: In function 'test_mbstowcs': ../../../../wine_src/dlls/msvcrt/tests/string.c:1869:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1872:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1887:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1890:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1903:228: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1911:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1932:228: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] ../../../../wine_src/dlls/msvcrt/tests/string.c:1951:123: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=] Thanks, Piotr

Aug. 3, 2017

Re: ntdll: Support receiving server reply data to memory with write watch.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > On 03.08.2017 09:48, Alexandre Julliard wrote: >> Jacek Caban <jacek(a)codeweavers.com> writes: >> >>> @@ -256,6 +256,7 @@ static void read_reply_data( void *buffer, size_t size ) >>> if (!ret) break; >>> if (errno == EINTR) continue; >>> if (errno == EPIPE) break; >>> + if (errno == EFAULT && virtual_uninterrupted_write_memory( buffer, NULL, size ) >= size) continue; >>> server_protocol_perror("read"); >> You can't enter a critical section in the middle of a server call. > > Oh, right, we could need to do another server call there. Unless I'm > missing something, it should work fine for platforms that have optimized > CS implementation (Linux and Mac) as they don't do server calls. We > could limit effect of the patch to those platform, but that would be ugly. > > Could we just use pthread mutexes for > server_enter_uninterrupted_section/server_leave_uninterrupted_section > instead of critical sections? I don't think you should be doing that sort of thing inside server calls at all. Some sort of lock/unlock_buffer methods that could be wrapped around server calls where necessary would probably work better. -- Alexandre Julliard julliard(a)winehq.org

Aug. 3, 2017