February 2016 - Wine-devel - list.winehq.org

Re: [PATCH v2] ntdll: Finish serial reads of size 0 immediately.
by Marvin 21 Feb '16

21 Feb '16

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=20800 Your paranoid android. === w2003std (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1553: test_AbortWaitCts timeout 500 handle 00000760 comm.c:1520: Changing CommMask on the fly for handle 00000760 after timeout 500 === w2008s64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting

1 0

Re: [PATCH 7/8] wined3d: Rotate through swapchain buffers.
by Henri Verbeet 21 Feb '16

21 Feb '16

On 14 February 2016 at 21:33, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Going back to square one and moving around texture resources. Anything > that's based on reassigning client library resources will make d3d11 > deferred contexts very difficult. > > So far I'm only moving around RGB textures and invalidating everything > else for simplicity. Does this do the right thing for multi-sampled swapchains?

2 2

RFC: Precompiled Headers for Wine Build (GSoC?)
by Kyle Auble 21 Feb '16

21 Feb '16

Hey everyone, Although I'm a student again, I don't really have the time or chops to apply for GSoC, at least not this year. I was randomly looking up things the other day though when I came across precompiled headers. I don't remember seeing any sight of them when I studied wine code in the past, and all I found on the mailing list was this: https://www.winehq.org/pipermail/wine-devel/2004-July/027933.html It might not be a hard-enough task to warrant a GSoC grant, and I don't know enough about the details to add an entry to the wiki (Would precompiled headers work for wine? Does wine actually use them already?) I just thought I would mention it because if it makes sense for the project, it might be an interesting change with a big payoff for build times. Kyle

5 6

Re: shell32/tests: Test ShellExecute()'s URL handling.
by Marvin 21 Feb '16

21 Feb '16

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=20796 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1588: Test failed: ShellExecuteEx(mask="0x808040", file="C:\Users\Public\Documents\shell32_test.exe", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt1045.tmp\wt1046.tmp" abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy") WaitForSingleObject(hProcess) returned 258 shlexec.c:1979: Test failed: ShellExecuteEx(mask="0x8640", file="shlproto://%TMPDIR%/bar") WaitForSingleObject returned 258 shlexec.c:1983: Test failed: ShellExecuteEx(mask="0x8640", file="shlproto://%TMPDIR%/bar") argvA3 expected 'URL', but key not found or empty shlexec.c:1984: Test failed: ShellExecuteEx(mask="0x8640", file="shlproto://%TMPDIR%/bar") argvA4 expected 'shlproto://C:\Users\winetest\AppData\Local\Temp\wt1045.tmp/bar', but key not found or empty

1 0

Re: user32/tests: Use todo_wine_if() in tests
by Marvin 20 Feb '16

20 Feb '16

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

1 0

Re: reg: Fail if the data value passed with REG_DWORD will cause an overflow
by Alexandre Julliard 20 Feb '16

20 Feb '16

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -243,8 +243,17 @@ static LPBYTE get_regdata(LPWSTR data, DWORD reg_type, WCHAR separator, DWORD *r > { > LPWSTR rest; > DWORD val; > + BOOL overflow = FALSE; > + if (data[1] == 'x') > + { > + WCHAR *ptr = &data[2]; > + while (*ptr == '0') > + ptr++; > + if (strlenW(ptr) > 8) > + overflow = TRUE; > + } > val = strtoulW(data, &rest, (data[1] == 'x') ? 16 : 10); You won't be able to catch base 10 overflows this way. It probably needs a more general solution (and some more test cases...) -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: urlmon/tests: Use todo_wine_if() in tests
by Marvin 19 Feb '16

19 Feb '16

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=20745 Your paranoid android. === w1064 (32 bit misc) === misc.c:756: Test failed: [52] wrong mime: L"image/x-icon"

1 0

Re: winmm/tests: Use todo_wine_if() in tests
by Marvin 19 Feb '16

19 Feb '16

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=20744 Your paranoid android. === w1064 (32 bit midi) === midi.c:290: Test failed: midiOutOpen(dev=0) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR midi.c:290: Test failed: midiOutOpen(dev=-1) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR === w1064 (32 bit mci) === mci: unhandled exception c0000005 at 7698851A

1 0

Re: [PATCH] packet: create packet.dll and Implement GetAdapterNames(try 4)
by Sebastian Lackner 19 Feb '16

19 Feb '16

Thanks for sending an updated version of your patch. I have some more comments below. Nevertheless, before you spent too much time to fix all the issues, I would suggest to discuss with André first, if packet.dll is acceptable for Wine. One reason why we might consider adding it is because the original version heavily reads information from the registry (SYSTEM\\CurrentControlSet), which is not populated by Wine, but still there might be alternative ways to solve it. If we really reimplement this DLL, we might also need tests in the long term, otherwise its difficult to say if everything is implemented correctly. On 18.02.2016 14:21, Jianqiu Zhang wrote: > > 0001-packet-create-packet.dll-and-Implement-GetAdapterNames.txt > > > From 06eb579dba41bc473429d262150677687f1f092a Mon Sep 17 00:00:00 2001 > From: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > Date: Sun, 14 Feb 2016 17:27:37 +0800 > Subject: [PATCH] packet: create packet.dll and Implement GetAdapterNames > > Signed-off-by: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > --- > configure.ac | 7 +++++++ > dlls/packet/Makefile.in | 5 +++++ > dlls/packet/packet.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/packet/packet.spec | 32 ++++++++++++++++++++++++++++ > 4 files changed, 100 insertions(+) > create mode 100644 dlls/packet/Makefile.in > create mode 100644 dlls/packet/packet.c > create mode 100644 dlls/packet/packet.spec > > diff --git a/configure.ac b/configure.ac > index c9445e7..504d46e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -69,6 +69,8 @@ AC_ARG_WITH(osmesa, AS_HELP_STRING([--without-osmesa],[do not use the OSMesa > AC_ARG_WITH(oss, AS_HELP_STRING([--without-oss],[do not use the OSS sound support])) > AC_ARG_WITH(pcap, AS_HELP_STRING([--without-pcap],[do not use the Packet Capture library]), > [if test "x$withval" = "xno"; then ac_cv_header_pcap_pcap_h=no; fi]) > +AC_ARG_WITH(packet, AS_HELP_STRING([--without-packet],[do not use the Packet DLL]), > + [if test "x$withval" = "xno"; then ac_cv_header_pcap_pcap_h=no; fi]) You can leave this part out, packet.dll does not require separate dependencies. > AC_ARG_WITH(png, AS_HELP_STRING([--without-png],[do not use PNG])) > AC_ARG_WITH(pthread, AS_HELP_STRING([--without-pthread],[do not use the pthread library]), > [if test "x$withval" = "xno"; then ac_cv_header_pthread_h=no; fi]) > @@ -1186,7 +1188,11 @@ then > fi > WINE_NOTICE_WITH(pcap,[test "x$ac_cv_lib_pcap_pcap_create" != xyes], > [pcap ${notice_platform}development files not found, wpcap won't be supported.]) > +WINE_NOTICE_WITH(packet,[test "x$ac_cv_lib_pcap_pcap_create" != xyes], > + [pcap ${notice_platform}development files not found, packet won't be supported.]) A separate WINE_NOTICE_WITH is also not necessary. Instead just modify the existing one, for example: """pcap ${notice_platform}development files not found, wpcap and packet won't be supported.""" > test "x$ac_cv_lib_pcap_pcap_create" != xyes && enable_wpcap=${enable_wpcap:-no} > +test "x$ac_cv_lib_pcap_pcap_create" != xyes && enable_packet=${enable_packet:-no} > + > > dnl **** Check for libxml2 **** > > @@ -3389,6 +3395,7 @@ WINE_CONFIG_DLL(wmvcore) > WINE_CONFIG_DLL(wnaspi32,,[implib]) > WINE_CONFIG_DLL(wow32,enable_win16,[implib]) > WINE_CONFIG_DLL(wpcap) > +WINE_CONFIG_DLL(packet) These lines are alphabetically sorted, so you would have to insert it at a different position. Please note that you can also use ./tools/make_makefiles to add this line for you, after you have added files for a new dll to git. > WINE_CONFIG_DLL(ws2_32,,[implib]) > WINE_CONFIG_TEST(dlls/ws2_32/tests) > WINE_CONFIG_DLL(wshom.ocx,,[clean]) > diff --git a/dlls/packet/Makefile.in b/dlls/packet/Makefile.in > new file mode 100644 > index 0000000..cecf07c > --- /dev/null > +++ b/dlls/packet/Makefile.in > @@ -0,0 +1,5 @@ > +MODULE = packet.dll > +IMPORTS = iphlpapi > + > +C_SRCS = \ > + packet.c > diff --git a/dlls/packet/packet.c b/dlls/packet/packet.c > new file mode 100644 > index 0000000..1074067 > --- /dev/null > +++ b/dlls/packet/packet.c > @@ -0,0 +1,56 @@ > +#include "config.h" > + > +#include "windows.h" > +#include "wine/debug.h" > + > +#include "iphlpapi.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(packet); > + > +BOOLEAN CDECL PacketGetAdapterNames(char *name_list, ULONG *size) > +{ > + IP_ADAPTER_INFO *adInfo, *adInfoList = NULL; > + DWORD errcode; > + ULONG needsize = 0, minDescLen = 0, minAdNameLen = 0, minTotLen = 0, nameOffset, descOffset; > + > + TRACE("name_list %p &size %p size %d\n", name_list, size, *size); > + > + errcode = GetAdaptersInfo(adInfoList, &needsize); > + adInfoList = HeapAlloc(GetProcessHeap(), 0, needsize); > + if(adInfoList == NULL) return FALSE; > + > + errcode = GetAdaptersInfo(adInfoList, &needsize); > + if(errcode) > + { > + HeapFree(GetProcessHeap(), 0, adInfoList); > + SetLastError(errcode); > + return FALSE; > + } > + for(adInfo = adInfoList; adInfo != NULL; adInfo = adInfo->Next) > + { > + minAdNameLen += lstrlenA(adInfo->AdapterName) + 1; > + minDescLen += lstrlenA(adInfo->Description) + 1; Usually a direct invocation of strlen() is preferred in the wine source. > + } > + minTotLen = minAdNameLen + minDescLen + 2; > + if(name_list == NULL || *size < minTotLen) > + { > + SetLastError(ERROR_INSUFFICIENT_BUFFER); > + HeapFree(GetProcessHeap(), 0, adInfoList); > + *size = minTotLen; When looking through the original implementation of packet.dll, I do not see any location which changes *size. > + return FALSE; > + } > + > + nameOffset = descOffset = 0; > + for(adInfo = adInfoList; adInfo != NULL; adInfo = adInfo->Next) > + { > + lstrcpyA(name_list + nameOffset, adInfo->AdapterName); > + lstrcpyA(name_list + minAdNameLen + descOffset + 1, adInfo->Description); > + nameOffset += lstrlenA(adInfo->AdapterName) + 1; > + descOffset += lstrlenA(adInfo->Description) + 1; strcpy / strlen would be preferred here. > + } > + name_list[minAdNameLen] = '\0'; > + name_list[minTotLen - 1] = '\0'; > + > + HeapFree(GetProcessHeap(), 0, adInfoList); > + return TRUE; > +} > diff --git a/dlls/packet/packet.spec b/dlls/packet/packet.spec > new file mode 100644 > index 0000000..32b9bc0 > --- /dev/null > +++ b/dlls/packet/packet.spec > @@ -0,0 +1,32 @@ > +@ stub PacketAllocatePacket > +@ stub PacketCloseAdapter > +@ stub PacketFreePacket > +@ cdecl PacketGetAdapterNames(ptr ptr) > +@ stub PacketGetAirPcapHandle > +@ stub PacketGetDriverVersion > +@ stub PacketGetNetInfoEx > +@ stub PacketGetNetType > +@ stub PacketGetReadEvent > +@ stub PacketGetStats > +@ stub PacketGetStatsEx > +@ stub PacketGetVersion > +@ stub PacketInitPacket > +@ stub PacketIsDumpEnded > +@ stub PacketLibraryVersion > +@ stub PacketOpenAdapter > +@ stub PacketReceivePacket > +@ stub PacketRequest > +@ stub PacketSendPacket > +@ stub PacketSendPackets > +@ stub PacketSetBpf > +@ stub PacketSetBuff > +@ stub PacketSetDumpLimits > +@ stub PacketSetDumpName > +@ stub PacketSetHwFilter > +@ stub PacketSetLoopbackBehavior > +@ stub PacketSetMinToCopy > +@ stub PacketSetMode > +@ stub PacketSetNumWrites > +@ stub PacketSetReadTimeout > +@ stub PacketSetSnapLen > +@ stub PacketStopDriver > -- 2.7.1 > > >

2 1

Re: [PATCH 1/2] msvcrt: Don't close HANDLE if stdout or stderr is sharing it
by Qian Hong 19 Feb '16

19 Feb '16

Hi Piotr, Thanks for your work! I didn't have time to improve the patches so I didn't sent it upstream, I appreciate a lot for your work, now I can remove it from my todo list :)

1 0