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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe Oct. 11, 2015

Oct. 11, 2015

Hi, I had a problem with Majesty Gold HD running at glacial speed on my machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. I profiled wine (Instruments time profile) and noticed that most time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine with an optimized sse2 version from pixman did not make much of a difference. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

[PATCH] Use asserts for mmap failure modes
by Michael Gilbert July 26, 2015

July 26, 2015

Hi, Using exit in shared libraries is a discouraged practice, and wine's mmap implementation currently does that. I attach a proposed change using asserts instead. Let me know if you have any feedback. Best wishes, Mike (btw I'm the debian wine maintainer)

2 2

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)
by Alexandre Julliard June 12, 2015

June 12, 2015

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > I found the solution to typedef the struct pollfd just like it's done > with fd_set. Unfortunately that doesn't work on mingw: In file included from ../../../wine/include/winsock2.h:50:0, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:284:8: note: originally defined here -- Alexandre Julliard julliard(a)winehq.org

3 4

mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.
by Joerg-Cyril.Hoehle＠t-systems.com June 9, 2015

June 9, 2015

Aki, if I understand your critical section well, you serialize all accesses to the individual player thread. This may be ok for commands that return immediately, e.g. STATUS, but the MCI knows commands that may take a long time, in particular PLAY, RECORD and even SEEK. Did you run a test like this: CreateTask { SetEvent started MCICommand(MCI_PLAY, "av_file_that_takes_3_minutes.avi", MCI_WAIT); } Wait(started); Repeat 10 times { MCICommand(MCI_STATUS,MCI_POSITION); printf MCICommand(MCI_STATUS,MCI_MODE); Printf Sleep(2s); } Wait(thread); I would expect all MCI commands "STATUS POSITION" etc. to work while another thread is busy playing a file synchronously (using MCI_WAIT). Furthermore +static LRESULT MCIQTZ_relayTaskMessage [...] + if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0) Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop that also pumps the MS-Windows message queue and dispatches messages? E.g. there may be a need to dispatch REFRESH and PAINT messages? Did you cross-check what MS-Windows does here? On a related note, IIRC some wine devices use a more reliable approach to waiting: WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE); That way, should the player crash or exit somehow, the main (user) task doesn't hang. Regards, Jörg Höhle

2 4

Wine 64 bit
by Kevin Davies June 5, 2015

June 5, 2015

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

programs/regsvr32 patches
by Hugh McMaster June 4, 2015

June 4, 2015

Excuse me, I've looked through patches 111564-111568 and have only found one minor issue. In patch 111565 I forgot to include ctype.h for tolower(). Was there a problem with the input comparison handling, or something else? The changes to the input handling make conversion to unicode much easier and cleaner. I realise that patch 111565 looks complex, but it's just the indenting. -- Hugh McMaster

1 1

Fix GetRawInputDeviceList() to return ERROR_INSUFFICIENT_BUFFER
by achurch＠achurch.org June 1, 2015

June 1, 2015

(Note: I am not subscribed to the list; please CC me on any replies.) When GetRawInputDeviceList() is passed a buffer which is too small, the function should set the last error code to ERROR_INSUFFICIENT_BUFFER and return failure (see <http://msdn.microsoft.com/en-us/library/windows/desktop/ms645598(v=vs.85).a…>). However, the current Wine implementation does not set the last error code, meaning that callers expecting to see ERROR_INSUFFICIENT_BUFFER will behave incorrectly. I've confirmed that Windows itself (at least XP and 8) matches the documented behavior. See also: https://bugs.winehq.org/show_bug.cgi?id=37667 --Andrew Church http://achurch.org/ diff -urN wine-1.7.43-orig/dlls/user32/input.c wine-1.7.43/dlls/user32/input.c --- wine-1.7.43-orig/dlls/user32/input.c 2015-05-15 22:36:39 +0900 +++ wine-1.7.43/dlls/user32/input.c 2015-05-25 22:47:49 +0900 @@ -507,6 +507,7 @@ if (*device_count < 2) { *device_count = 2; + SetLastError(ERROR_INSUFFICIENT_BUFFER); return ~0U; } diff -urN wine-1.7.43-orig/dlls/user32/tests/Makefile.in wine-1.7.43/dlls/user32/tests/Makefile.in --- wine-1.7.43-orig/dlls/user32/tests/Makefile.in 2015-05-15 22:36:39 +0900 +++ wine-1.7.43/dlls/user32/tests/Makefile.in 2015-05-25 22:48:27 +0900 @@ -17,6 +17,7 @@ menu.c \ monitor.c \ msg.c \ + rawinput.c \ resource.c \ scroll.c \ static.c \ diff -urN wine-1.7.43-orig/dlls/user32/tests/rawinput.c wine-1.7.43/dlls/user32/tests/rawinput.c --- wine-1.7.43-orig/dlls/user32/tests/rawinput.c 1970-01-01 09:00:00 +0900 +++ wine-1.7.43/dlls/user32/tests/rawinput.c 2015-05-25 22:44:36 +0900 @@ -0,0 +1,43 @@ + /* Unit test suite for the rawinput functions + * + * Copyright 2015 Andrew Church + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#define WINVER 0x0501 + +#include "wine/test.h" +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +static void GRIDLShortArrayTest() +{ + RAWINPUTDEVICELIST devices[1]; + UINT device_count = 1; + int result, error; + + result = GetRawInputDeviceList(devices, &device_count, sizeof(*devices)); + ok(result == ~0U, "wrong result: %d\n", result); + ok(device_count >= 2, "wrong device_count: %d\n", device_count); + error = GetLastError(); + ok(error == ERROR_INSUFFICIENT_BUFFER, "wrong error code: %d\n", error); +} + +START_TEST(rawinput) +{ + GRIDLShortArrayTest(); +}

2 1

Re: [PATCH 2/5] riched20/tests: Small test for GetClientSite()
by Marvin May 31, 2015

May 31, 2015

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=13718 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wxppro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === w2003std (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wvistau64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at A574D492 === w2008s64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 00000000 === w7u (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 10000000 === w8 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer === wvistau64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0000000000426DF0 === w2008s64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 000007FEFEE619B8

1 0

Re: [PATCH 1/2] msvcp110: Add _File_size implementation and test.(try 2)
by YongHao Hu May 29, 2015

May 29, 2015

Sry, Slackner found that I still used %llx /%llu as I misunderstood Piotr's comment and there are typos in the patch. I will fix all the issues later. :P On 2015年05月29日 21:16, YongHao Hu wrote: > try2: > Improve the patch according to Piotr's advices. > Add errno and SetLastError test. > --- > dlls/msvcp110/msvcp110.spec | 4 +- > dlls/msvcp120/msvcp120.spec | 4 +- > dlls/msvcp120/tests/msvcp120.c | 75 > +++++++++++++++++++++++++++++++++---- > dlls/msvcp120_app/msvcp120_app.spec | 4 +- > dlls/msvcp90/ios.c | 20 ++++++++++ > 5 files changed, 94 insertions(+), 13 deletions(-) > >

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)
by Stefan Dösinger May 29, 2015

May 29, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This version of the patch looks good to me. Stefan Am 2015-05-29 um 12:06 schrieb Alistair Leslie-Hughes: > Hi, Add WARN on errors. > > I'll add more tests in another patch, which simplifies the > component list. > > Changelog: dpnet: Implement IDirectPlay8Address > GetComponentByIndex > > > Best Regards Alistair Leslie-Hughes > > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaE3VAAoJEN0/YqbEcdMwqIAP/iHHkRWQmGrZnoKbvuXuYJ9i caO0PB0akO3CvyLDcC68CMtT7jQ7gthTGPiXTHe4sEjmSR3KLoqajV2TX+JluWYj s/uTxbmPjNvafeXmflSpaoy0BRq5H/D+99AkKqo/GFPlCNT0UJpR9sD7OsXXA1E9 Cq7VpKMGqgnWoLf4/pRge/rBfV2vV0FOLhHTzboEyUOTgGegOI8v345vMw/Ph7RM YPEdLYUBkIwZZuZaDtaZ9DV5HyFG1fH65cYftkQFmM7tH4Sn1NiQcNHEUmPeX3Bc hv5Q9QOshwtWgQKhWe98YyGayP16Ip0iKDpxRZ28LEcOcKfK9URX66lBNWZjL/Ci IixsgZw12okh8Wn+Q76LwIh1PakpQSHZ/iQW8qDYlyWIRboFC+VyQoemkXxvUfVS VwqAe/D1uWAf1o6BD6vHNarH7A5ymHvxmcxw/1PxTGSZg4RBqOmt4/4gCWIuPXzX 564O8wrDn1msVhwS6tqpP85Sg3ydDYiPDVZNVigJAU/kMCiPH2WbXPxUGB/Pc7hA 4QaOK6FDTxXlTqEO0FHm12DU2bYzBMogOd0N6usKzVQe2kdy9hB4/hUo8+vojamS AI0agXg+a6UjVhTpNZvoZAxC0rFF6nEJaL6MgDS64LtmT6wrrri6hEtmPJM6aC/O 2bdo052EPFKWbfytsTK+ =jq9B -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)
by Marvin May 29, 2015

May 29, 2015

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=13666 Your paranoid android. === w8 (32 bit address) === Failure running script in VM: timed out waiting for the child process

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)
by Stefan Dösinger May 29, 2015

May 29, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There's one major problem I missed previously: Am 2015-05-29 um 10:22 schrieb Alistair Leslie-Hughes: > + case DPNA_DATATYPE_STRING: > + memcpy(pvBuffer, &entry->data.string, entry->size); > + break; This won't work. There's a & too much. Please consider adding tests for String and Binary types to catch this kind of thing. GetComponentByName once had the same problem I believe. Minor stuff: > + TRACE("(%p)->(%d %p %p %p %p %p)\n", This, dwComponentID, pwszName, pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); A DWORD is unsigned, %u is better. > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + *pdwDataType = entry->type; > + return DPNERR_BUFFERTOOSMALL; > + } You forgot to add a WARN here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaCrwAAoJEN0/YqbEcdMwypEP/RttOLSqc6fQQW4XeMkBgVaS aiKUyYSysq9MnRoqP32A6lKq9LHpW23liKsvpwoWegdarTc35ENYwG7pLSLJuOIy i/e7AlWGLDphN9qdYMU0oCQ8PXGU8Y3Mb7kozZcnYm9EuYoJEFIiAYHtx4nFeGMj rVx/mruLmYTdgyR378iE4cYqNeMwzK7YtGNRHMPz8FNTzdLyzUu1blYQ8cYEbzAk Mm4RaIixByzKiGO7qUPCX4OOgYoohBOgMRiVWTJfZLrhKY0vyj0x2Jt5GWCzWeht 7mszNRRpvW+v60axT2xwemXmQSobjgjnddF0bwxC/vHZisfXF8H52lLgupXv9KRo efOsvX3lTpJstEL1Wt61NL/MqF4vwRjbrWeKD45DxHEzPX8wzUg4yFodz/yxAAN1 /l4fuX8BEjr9tttV4uup4fdOlVhlX95ZujQFT5Ue1zF97SSLOC9id/8Uy8xlHYmY Ou0H9GG5rILqG5+r9m3OghjuQcwomL6T7BSLYJ+WncdTgtxRbarhMI/mq9m0MiB2 OHkUddm/zn9EFPboQsCjqRuPFa6fcbx+b/XUmyLeBjosO3j7Otws4TGUEkzjbvWF f3fOORfbxpknZH9GxVaEFWlyUerNSJ4C4hYp5J+pHS9N5u+L9KsN0fXYT9jqpvh2 Tmu94XyHSblAoeS1ORgq =M5Sz -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)
by Marvin May 29, 2015

May 29, 2015

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=13665 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: [PATCH 5/5] wined3d: Always enable GL_PROGRAM_POINT_SIZE in the GLSL backend.
by Henri Verbeet May 29, 2015

May 29, 2015

On 28 May 2015 at 23:23, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6987,6 +7006,13 @@ static void shader_glsl_select(void *shader_priv, struct wined3d_context *contex > GLuint program_id = 0, prev_id = 0; > GLenum old_vertex_color_clamp, current_vertex_color_clamp; > > + if (!ctx_data->backend_init_done) > + { > + gl_info->gl_ops.gl.p_glEnable(GL_PROGRAM_POINT_SIZE); > + checkGLcall("GL_PROGRAM_POINT_SIZE"); > + ctx_data->backend_init_done = TRUE; > + } > + Is this shared state between contexts? Otherwise you need to do this once for every context. Also, shader_glsl_select() is kind of a hot path, it may be better to just add an entry to struct wined3d_shader_backend_ops for this kind of initialization.

2 2

Re: [PATCH 9/11] qcap: add the SmartTee filter automatically as necessary, and test this
by Marvin May 28, 2015

May 28, 2015

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=13651 Your paranoid android. === w2008s64 (32 bit smartteefilter) === smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 === w2008s64 (64 bit smartteefilter) === smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154

1 0

Re: [PATCH 8/11] qcap: get the SmartTee filter to a minimally functional level
by Marvin May 28, 2015

May 28, 2015

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=13650 Your paranoid android. === w2000pro (32 bit smartteefilter) === The test timed out

1 0

Re: [PATCH 7/11] qcap: implement the SmartTee allocator functions
by Marvin May 28, 2015

May 28, 2015

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=13649 Your paranoid android. === w2000pro (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === wxppro (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === w7u (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === w8 (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time

1 0

Re: winex11: Fix ctrl-<symbol> to generate codes below 0x20 where necessary.
by Marvin May 28, 2015

May 28, 2015

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=13631 Your paranoid android. === wvistau64 (32 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

2 1

Save the Date: WineConf on September 19, 20 in Vienna
by Stefan Dösinger May 28, 2015

May 28, 2015

Hi, I am happy to announce that we will have a WineConf again this year: It will be on Saturday September 19th and Sunday September 20th 2015 in Vienna, in the InterCityHotel Wien. I have added some basic information to http://wiki.winehq.org/WineConf2015 , and more detailed information will follow soon. Please help by suggesting talk topics and adding them to the list. I will write another mail to the list once we have an RSVP page set up. Cheers, Stefan

1 2

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 10)
by Stefan Dösinger May 28, 2015

May 28, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm sorry for the late review. I completely forgot about this patch (also in the private mail you sent me). It looks good to me, except one issue noted below that I missed earlier. Am 2015-05-23 um 13:22 schrieb Alistair Leslie-Hughes: > index 7e10136..bad84ef 100644 > --- a/dlls/dpnet/address.c > +++ b/dlls/dpnet/address.c > @@ -405,9 +405,58 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { > - IDirectPlay8AddressImpl *This = impl_from_IDirectPlay8Address(iface); > - TRACE("(%p): stub\n", This); > - return DPN_OK; > + IDirectPlay8AddressImpl *This = impl_from_IDirectPlay8Address(iface); > + struct component *entry; > + int namesize; > + > + TRACE("(%p)->(%p %p %p %p)\n", This, pwszName, pvBuffer, pdwBufferSize, pdwDataType); You're not tracing dwComponentID and pdwNameLen here. In particular dwComponentID seems important, as it is the thing that the method call retrieves. > + if(!pdwNameLen || !pdwBufferSize || !pdwDataType) > + return DPNERR_INVALIDPOINTER; > + > + if(dwComponentID > This->comp_count) > + return DPNERR_DOESNOTEXIST; As I've noted in other patches it would be a good idea to write a WARN in error cases, especially in a COM method where +relay can't be used to check return values. You can also print the available and required size in case of DPNERR_BUFFERTOSMALL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVZvMGAAoJEN0/YqbEcdMww2sP+gJRvmzLAZ4oXx3FJFSPIvpn JsbdhoKeZkmdsTCPQjvfPVAUKj1qSQcm1w9rRFBthZhkVWNgXGDTbsbTmtVRiATz qqoX+MjKKQeguWmgnEiQY0k/NW15kAvUkP/vT1qQfKOyqadXJs1a6gli0zfqHSqO uviq2P5mQ82vvIYbv5rS8tAGBTh/FHd1802tSPcMGXQqrqqjW3UH/rV4DymP33FF IsSpPBt2niCz7jSt6QGg/8R9Q2xK8D2sOOe1CcLvtRzrh7Ws+j0p1B8Y73aX8047 s7Pp/oUgfmcEUGheeD+c1YlAQOW6Xp9urjiCc9Pqp+sJBv9fJ5p40r9A6wXrP/Jb Zkei91cF+XcwuhZysQX/qJCwff2VyqG55cDdS1R7DTva/DSamhFB6jYrRAjotgrT g4ulnkbVR4khDzJRVk4K9rxJ2OPwoUkPVpspjrKzuT7oEm2U31PVHPUQa8qeIWzr b1vLyDnG/Zz+B27yHc9sLfwZm5olWz2XTDht7kZKGMU2FRy1Q2wK0wZ6Q6ekB/f5 jnnQep7DmgsMe4EN175k5L5e3yW/SISk0U2O/VtukKMbZQ/hoIhHw8ieiaAo16MM S6nvCRbHxRCe9vB/0zKt5+5SAzWrTTsdw03qdeFg82PSGi6I/F7RrrQnY76GtYKB gtjHMs5QPp0FZRriR0T0 =MUbC -----END PGP SIGNATURE-----

1 0