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

Re: wbemprox: Add a partial implementation of Win32_IP4RouteTable.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/wbemprox/builtin.c | 75 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/wbemprox/tests/query.c | 63 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 138 insertions(+) This doesn't build on Mingw: i686-w64-mingw32-gcc -c -o builtin.o ../../../wine/dlls/wbemprox/builtin.c -I. -I../../../wine/dlls/wbemprox \ -I../../include -I../../../wine/include -D__WINESRC__ -DUSE_WS_PREFIX -D_REENTRANT -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer \ -g -O2 -fno-diagnostics-show-caret -D_WIN32 In file included from ../../../wine/dlls/wbemprox/builtin.c:38:0: ../../../wine/include/ws2tcpip.h:176:104: warning: ‘struct timeval’ declared inside parameter list will not be visible outside of this definition or declaration ../../../wine/include/ws2tcpip.h:178:107: warning: ‘struct timeval’ declared inside parameter list will not be visible outside of this definition or declaration ../../../wine/dlls/wbemprox/builtin.c: In function ‘fill_ip4routetable’: ../../../wine/dlls/wbemprox/builtin.c:2074:47: warning: implicit declaration of function ‘ntohl’ [-Wimplicit-function-declaration] ../.././../obj-elf64/tools/winegcc/winegcc -o wbemprox.dll -B../.././../obj-elf64/tools/winebuild \ --sysroot=../.. -b i686-w64-mingw32 -fasynchronous-unwind-tables -shared ../../../wine/dlls/wbemprox/wbemprox.spec \ builtin.o class.o main.o process.o qualifier.o query.o reg.o security.o service.o services.o \ table.o wbemlocator.o wql.tab.o wbemprox_r.res ../../dlls/winspool.drv/libwinspool.a \ ../../dlls/version/libversion.a ../../dlls/iphlpapi/libiphlpapi.a ../../dlls/dxgi/libdxgi.a \ ../../dlls/oleaut32/liboleaut32.a ../../dlls/ole32/libole32.a ../../dlls/advapi32/libadvapi32.a \ ../../dlls/user32/libuser32.a ../../dlls/gdi32/libgdi32.a ../../dlls/ws2_32/libws2_32.a \ ../../dlls/rpcrt4/librpcrt4.a ../../libs/port/libwine_port.a -lwine builtin.o: In function `fill_ip4routetable': /home/julliard/wine/build/obj-pe32/dlls/wbemprox/../../../wine/dlls/wbemprox/builtin.c:2074: undefined reference to `ntohl' /home/julliard/wine/build/obj-pe32/dlls/wbemprox/../../../wine/dlls/wbemprox/builtin.c:2076: undefined reference to `ntohl' collect2: error: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed Makefile:638: recipe for target 'wbemprox.dll' failed -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: [PATCH] user32:add SIZEALL_BIG cursor, reusing SIZEALL resource Fixes bug#42303

by Anton Romanov

On Thu, Jan 26, 2017 at 11:02 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Anton Romanov <theli.ua(a)gmail.com> writes: > >> @@ -2227,6 +2227,7 @@ typedef struct tagCBTACTIVATESTRUCT >> #define IDC_HAND MAKEINTRESOURCE(32649) >> #define IDC_APPSTARTING MAKEINTRESOURCE(32650) >> #define IDC_HELP MAKEINTRESOURCE(32651) >> +#define IDC_SIZEALL_BIG MAKEINTRESOURCE(32654) > > There's no such definition in Windows. > >> @@ -1011,6 +1011,7 @@ >> #define OCR_NO 32648 >> #define OCR_HAND 32649 >> #define OCR_APPSTARTING 32650 >> +#define OCR_SIZEALL_BIG 32654 > > This is already defined as OCR_RDR2DIM. Alright, I've now drawn all OCR_RDR* cursors and submitted updated patch with them to use already defined OCR_RDR* defines. Thanks!

Jan. 31, 2017

Re: [PATCH] wined3d: Implement buffer texture range.

by Guillaume Charifi

Thank you for your detailed answer :) Le 31/01/2017 à 00:19, Józef Kucia a écrit : > I'll explain in more details to encourage you ;-) > > On Sun, Jan 29, 2017 at 1:12 PM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> Please add a test. > Adding a test should be very easy. In test_buffer_srv() everything is > ready to add a test with an offset. You can use "rgba16_buffer" as > data, set size to {2.0f, 2.0f} or {1.0f, 1.0f}, and test with > different values of "srv_first_element" and "srv_element_count". Try > to come up with interesting test cases and test edge cases. Looks easier than I thought, indeed. I'll be doing this. > >> On Sun, Jan 29, 2017 at 12:25 AM, Guillaume Charifi >> <guillaume.charifi(a)sfr.fr> wrote: >>> + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object, >>> + desc->u.buffer.start_idx, desc->u.buffer.count)); >> This is wrong. > glTexBufferRange() accepts offsets and sizes in bytes, but in D3D11 > offsets and sizes for typed buffers are expressed as the number of > elements. You have to multiply "start_idx" and "count" by > "view_format->byte_count". A test would also help you to find this > mistake. Oh, I see, I'm fixing it. > > Another advice: start small. It's better to send a few well tested > patches and get them accepted first. > > I'll hope to see some patches from you committed soon. > > Cheers, > Józef >

Jan. 31, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > On Mon, 30 Jan 2017, Alexandre Julliard wrote: > [...] >> I don't think the test framework should be modifying the environment in >> all the tests. It already breaks some things: >> >> ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok >> environ.c:198: Test failed: Expected environment block pointer element to be non-NULL >> wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... > > Damn. > > I still think making the child process result lines different from > their parent's is necessary to fix bug 32354 but I'm open to > alternatives if someone has any idea. > https://bugs.winehq.org/show_bug.cgi?id=32354 Couldn't you simply print the pid, have winetest print it too on the 'done' line, and check that they match? -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Francois Gouget

On Mon, 30 Jan 2017, Alexandre Julliard wrote: [...] > I don't think the test framework should be modifying the environment in > all the tests. It already breaks some things: > > ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok > environ.c:198: Test failed: Expected environment block pointer element to be non-NULL > wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... Damn. I still think making the child process result lines different from their parent's is necessary to fix bug 32354 but I'm open to alternatives if someone has any idea. https://bugs.winehq.org/show_bug.cgi?id=32354 Maybe creating a named object would be less likely to break the tests and be acceptable? For instance this could be a mutex called something like "winetest${bitness}_${dll}_${test}" to avoid problems in case different tests are run in parallel, and the idea would be to check for GetLastError() == ERROR_ALREADY_EXISTS. The nice thing about named objects is they should just go away when the last process referencing them goes away. Creating a file instead would certainly avoid nasty side-effects but to avoid trouble with left-over files after crashes one would have to check for locks on it which seems much more complex. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 31, 2017

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Andrew Eikum

On Tue, Jan 31, 2017 at 04:16:17AM -0200, Bruno Jesus wrote: > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. > Looking at this spec, should Tune Request be handled the same way as these system real time messages? I also noticed Reset is still handled as a SysEx after your patch. Should it be? Aside from that, I also noticed an old patch that unfortunately never got merged: https://www.winehq.org/pipermail/wine-patches/2013-January/121366.html If you understand this MIDI stuff a little bit, you might be a good person to review and re-submit that patch :) Thanks, Andrew

Jan. 31, 2017

Re: [PATCH 2/2] winspool/tests: Test for LastError also on success of AddMonitor

by Huw Davies

On Mon, Jan 30, 2017 at 07:43:35PM +0100, Detlef Riekenberg wrote: > dlls/winspool.drv/tests/info.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/dlls/winspool.drv/tests/info.c b/dlls/winspool.drv/tests/info.c > index f6527c5..602e935 100644 > --- a/dlls/winspool.drv/tests/info.c > +++ b/dlls/winspool.drv/tests/info.c > @@ -435,6 +435,12 @@ static void test_AddMonitor(void) > SetLastError(MAGIC_DEAD); > res = AddMonitorA(NULL, 2, (LPBYTE) &mi2a); > ok(res, "returned %d with %d (expected '!= 0')\n", res, GetLastError()); > + if (res) > + { > + /* Some apps depend on the result of GetLastError() */ > + res = GetLastError(); > + ok(res == ERROR_SUCCESS, "got 0x%x/%u (expected ERROR_SUCCESS)\n", res, res); > + } There's no need to have this test conditional on res. Also, don't reassign res to the error, just use GetLastError() directly. And just print the error in decimal. Huw.

Jan. 31, 2017

Re: [PATCH 1/2] localspl: Clear LastError on success in AddMonitor

by Huw Davies

On Mon, Jan 30, 2017 at 07:43:34PM +0100, Detlef Riekenberg wrote: > dlls/localspl/provider.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/localspl/provider.c b/dlls/localspl/provider.c > index f359b73..f370b9f 100644 > --- a/dlls/localspl/provider.c > +++ b/dlls/localspl/provider.c > @@ -1541,6 +1541,9 @@ static BOOL WINAPI fpAddMonitor(LPWSTR pName, DWORD Level, LPBYTE pMonitors) > RegCloseKey(hentry); > } > > + if (res) > + SetLastError(ERROR_SUCCESS); /* Monitor installer depend on this */ > + > RegCloseKey(hroot); > return (res); > } I think unconditionally resetting the error after monitor_unload() would be cleaner. Huw.

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > On 01/30/2017 11:07 PM, André Hentschel wrote: >> True, thx! >> The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it... > Most handles are pointer types. But of course there are exceptions. Even when the actual type is a pointer, most handles are conceptually ints, they don't point to anything. In any case, it doesn't matter which type we use for handles, and we definitely don't want to start "fixing" them. Maybe we should just get rid of the ptr type once and for all... -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by Michael Stefaniuc

On 01/30/2017 11:07 PM, André Hentschel wrote: > True, thx! > The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it... Most handles are pointer types. But of course there are exceptions. bye michael

Jan. 31, 2017