June 2016 - 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

Re: user32: Avoid -Wmisleading-indentation warnings and fix comments in comments in test_AppendMenu.
by Dmitry Timoshkov Aug. 11, 2016

Aug. 11, 2016

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > diff --git a/dlls/user32/tests/menu.c b/dlls/user32/tests/menu.c > index 33d8eb8..ea965cd 100644 > --- a/dlls/user32/tests/menu.c > +++ b/dlls/user32/tests/menu.c > @@ -3992,13 +3992,15 @@ static void test_AppendMenu(void) > mii.wID = 206; > ret = InsertMenuItemA(hmenu, 0, TRUE, &mii); > ok(ret, "InsertMenuItem failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 206, MF_SEPARATOR, MFS_GRAYED); > +} > mii.wID = 207; > ret = SetMenuItemInfoA(hmenu, 0, TRUE, &mii); > ok(ret, "SetMenuItemInfo failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 207, MF_SEPARATOR, MFS_GRAYED); > +} > DestroyMenu(hmenu); > > hbmp = CreateBitmap(1, 1, 1, 1, NULL); Please don't make the code look uglier than it already is. I'd personally argue that checking and forcing indentation rules by a C compiler is pretty disappointing and actually misleading. That warning should be turned off by default IMHO. -- Dmitry.

3 2

WineHQ upgrade breaking dinput8:dinput?
by Francois Gouget Aug. 7, 2016

Aug. 7, 2016

This is a truly weird one. dinput8:dinput start failing on the 17th, the day after WineHQ was upgraded: https://test.winehq.org/data/tests/dinput8:dinput.html What makes this weird is that: * There has been no change to these tests between bd332f53f2d7 and 966a07149a02. In fact the last patch goes back to 2013. So it's not a bad patch. * The failures happen on every 32 bit test environment, from XP to Windows 10, VM or not, TestBot or not. Only 64 bit is spared. * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue. The official WineTest binaries are build on WineHQ so I suspect the MinGW upgrade is somehow responsible for the new failures. However I don't know if the old compiler was masking them, of if the new one is causing them. Any ideas? For reference: * Debian Testing (my environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 * Debian 7 (close to former WineHQ environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.9.1 -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

5 15

Wine's forked version of fontforge
by Jens Reyer Aug. 1, 2016

Aug. 1, 2016

Hi, in Debian we're currently moving to enable the maintainer mode to e.g. rebuild Wine's TrueType fonts. AJ already warned us that this is risky: On 04/01/2016 04:54 AM, wine-bugs(a)winehq.org wrote: > https://bugs.winehq.org/show_bug.cgi?id=40391 > > --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- > There is definitely a risk too, particularly for fonts. They are supposed to be > built with our forked version of fontforge > (https://source.winehq.org/git/fontforge.git) that contains a couple of fixes > compared to the upstream version. I really appreciate that warning, thanks again! See a "short" explanation at the end of the mail, why we want to do this anyway. I'd like to figure out how to improve the resulting situation by getting the Wine changes to fontforge applied upstream (and/or in Debian). With "upstream" I mean github.com/fontforge. I will contact them in a later step. Wine and Debian are both using the quite old fontforge version 20120731-b, the patches apply cleanly in Debian. But upstream is actively developing and in Debian someone is working on packaging a recent version (not sure with what outcome, e.g. afaik there is at least one upstream regression blocking an update). Are there any plans in Wine to update to a newer version? Wine's fontforge has 4 changes. I recreated them based on AJ's merge for 20120731-b and by myself for 20160404 to get a *rough* picture of their current state (not tested and I'm absolutely no expert in this): 1. Various hacks to avoid putting timestamps in generated files (AJ). No relevant changes upstream, but there is some work going to allow one to specify the timestamp in order to get the build deterministic/reproducible. Would this make this patch obsolete? I don't know why upstream wants timestamps at all, nor what problems these cause for Wine. Is this Wine specific, or would it make sense to drop timestamping upstream, too? 2. - Avoid outputting trailing spaces in sfd files (AJ). About a third seems to be applied in 20160404. I assume the rest would still be relevant if Wine updated its fontforge version. Is this patch only relevant for creating fonts/glyphs, but not for building the TrueType fonts? Looks like a good candidate for forwarding to upstream. 3. Enable the width of individual bitmap strikes to be altered (Huw Davies). Since the import of upstream version 20120731-b this patch only has a third of its original size. Are the remaining Wine changes still necessary, or are they cruft? If still needed, I guess they should be pushed upstream. In 20160404 not much seems to have changed, but the containing file bitmapview.c was moved ("splitting ui code from fontforge/ to fontforgeexe/"). Same as above: is this only needed when creating fonts? Looks like a candidate for upstream. 4. Don't save the selected state. (Huw Davies) I found no relevant changes upstream. No idea about this. Why are we doing this? ---------------------- The Debian Free Software Guidelines [DFSG] (which are the fundamental basis for the Debian project) mandate that binaries must be accompanied by their source (which is usually ensured by building from source), and that you must be able to modify and redistribute the package with only the software available in Debian. The reasons for these are e.g. philosophical (empowering the user), QA (rebuilding if there was an issue in the build tools), reproducibility (recreate byte-by-byte-identically, e.g. to rule out attacks at a build machine or do QA) or security (a build from correct source code may be manipulated by specific compilers). The TrueType fonts are pre-built with a forked fontforge, which isn't (and very unlikely will ever be) in Debian. To package the pre-built fonts imo we would have to remove Wine from official Debian (main), and move it to the non/semi-official contrib section. For the same reason (AFAIK, I'm not the author of these changes) we're also regenerating opengl files, request code and unicode. This problem was ignored/missed in the past for the Debian Wine packages, yet this is no argument against fixing them now. We definitely don't want Wine removed from Debian, instead keep it in and get it there as good as possible. btw, we're also adding a patch (based on wine staging) to append '(Debian)' to the version string now. btw2, can you recommend some alternative free fonts to install (either as partial replacement or as extension to the Wine fonts)? Greets, and thanks in advance jre [DFSG] https://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg, see also the following chapter "The main archive area".

2 3

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.
by Theodore Dubois July 12, 2016

July 12, 2016

This patch causes a segfault in the event that __wine_main_argv is not the argv that got passed to main. This happened in a program I wrote that acts as a custom wine loader. It creates an argv by using malloc, then passes that to wine_init. Why wouldn’t setprogname(argv[1]) be adequate? ~Theodore > On Feb 19, 2016, at 2:33 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> > --- > Try 2: > * Clean up the #ifdefs a bit. (I'm not happy about the duplicated code, though.) > * Don't copy the progname into a static array. There's no need; the argument vector lasts as long as the process itself. (I suppose I was being overly defensive with that.) > > configure.ac | 1 + > dlls/kernel32/process.c | 17 ++++++++++++++--- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/configure.ac b/configure.ac > index c9445e7..2ebbb10 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2026,6 +2026,7 @@ AC_CHECK_FUNCS(\ > sched_yield \ > select \ > setproctitle \ > + setprogname \ > setrlimit \ > settimeofday \ > sigaltstack \ > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index 86333be..4771108 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -1118,9 +1118,20 @@ static void set_process_name( int argc, char *argv[] ) > { > #ifdef HAVE_SETPROCTITLE > setproctitle("-%s", argv[1]); > -#endif > + /* remove argv[0] */ > + memmove( argv, argv + 1, argc * sizeof(argv[0]) ); > +#elif defined(HAVE_SETPROGNAME) > + int i, offset; > + char *end = argv[argc-1] + strlen(argv[argc-1]) + 1; > > -#ifdef HAVE_PRCTL > + offset = argv[1] - argv[0]; > + memmove( argv[1] - offset, argv[1], end - argv[1] ); > + memset( end - offset, 0, offset ); > + for (i = 1; i < argc; i++) argv[i-1] = argv[i] - offset; > + argv[i-1] = NULL; > + > + setprogname( argv[0] ); > +#elif defined(HAVE_PRCTL) > int i, offset; > char *p, *prctl_name = argv[1]; > char *end = argv[argc-1] + strlen(argv[argc-1]) + 1; > @@ -1141,11 +1152,11 @@ static void set_process_name( int argc, char *argv[] ) > argv[i-1] = NULL; > } > else > -#endif /* HAVE_PRCTL */ > { > /* remove argv[0] */ > memmove( argv, argv + 1, argc * sizeof(argv[0]) ); > } > +#endif /* HAVE_PRCTL */ > } > > > -- > 2.7.1 > > >

4 12

Re: [PATCH signed-off] secur32 : add and fix some algids
by Jacek Caban July 3, 2016

July 3, 2016

Hi Max, On 27.06.2016 05:29, Max Qian wrote: > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/secur32/schannel_gnutls.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index bcadd47..9d6af60 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -316,10 +316,11 @@ static ALG_ID schannel_get_mac_algid(gnutls_mac_algorithm_t mac) > case GNUTLS_MAC_UNKNOWN: > case GNUTLS_MAC_NULL: return 0; > case GNUTLS_MAC_MD5: return CALG_MD5; > - case GNUTLS_MAC_SHA1: > - case GNUTLS_MAC_SHA256: > - case GNUTLS_MAC_SHA384: > - case GNUTLS_MAC_SHA512: return CALG_SHA; > + case GNUTLS_MAC_SHA1: return CALG_SHA1; > + case GNUTLS_MAC_MD2: return CALG_MD2; > + case GNUTLS_MAC_SHA256: return CALG_SHA_256; > + case GNUTLS_MAC_SHA384: return CALG_SHA_384; > + case GNUTLS_MAC_SHA512: return CALG_SHA_512; > default: > FIXME("unknown algorithm %d\n", mac); > return 0; > @@ -331,8 +332,12 @@ static ALG_ID schannel_get_kx_algid(gnutls_kx_algorithm_t kx) > switch (kx) > { > case GNUTLS_KX_RSA: return CALG_RSA_KEYX; > + case GNUTLS_KX_DHE_PSK: > case GNUTLS_KX_DHE_DSS: > case GNUTLS_KX_DHE_RSA: return CALG_DH_EPHEM; > + case GNUTLS_KX_ECDHE_RSA: > + case GNUTLS_KX_ECDHE_PSK: return CALG_ECDH; MSDN mentions CALG_ECDH_EPHEM, which would fit better, but it seems to be missing in headers. Returning CALG_ECDH is fine with me, but please add a comment about CALG_ECDH_EPHEM. > + case GNUTLS_KX_ECDHE_ECDSA: return CALG_ECDSA; You're mixing tabs and spaces. Please avoid using tabs. Thanks, Jacek

3 2

Re: [PATCH] xaudio2: Always set current OpenAL context before making AL calls
by Chris Robinson June 30, 2016

June 30, 2016

On 06/30/2016 12:07 PM, Andrew Eikum wrote: > if(!alcIsExtensionPresent(NULL, "ALC_SOFT_loopback") || > !(palcLoopbackOpenDeviceSOFT = alcGetProcAddress(NULL, "alcLoopbackOpenDeviceSOFT")) || > - !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT"))){ > + !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT")) || > + !(palcSetThreadContext = alcGetProcAddress(NULL, "alcSetThreadContext"))){ > ERR("XAudio2 requires the ALC_SOFT_loopback extension (OpenAL-Soft >= 1.14)\n"); > return FALSE; > } alcSetThreadContext isn't part of the ALC_SOFT_loopback extension, you should check for ALC_EXT_thread_local_context instead. > +static void context_lock(ALCcontext *ctx) > +{ > + EnterCriticalSection(&al_lock); > + alcMakeContextCurrent(ctx); > +} > + > +static void context_unlock(void) > +{ > + LeaveCriticalSection(&al_lock); > +} Since you're relying on ALC_EXT_thread_local_context anyway, it would probably be better to use alcSetThreadContext in context_lock, which would allow you to get rid of the global lock for normal calls (another thread can't change the current thread context on you, and unlike OpenGL, the same context can be current on multiple threads at the same time).

2 1

Re: [PATCH] wined3d/resource: Performance improvement
by Chris Robinson June 30, 2016

June 30, 2016

On 06/30/2016 10:20 AM, Patrick Rudolph wrote: > Tests on Windows showed that mapping a buffer with flags WINED3D_MAP_DISCARD > and WINED3D_MAP_NOOVERWRITE is valid combination. Writing reliable tests > is difficult as the driver is free to choose when using discard. > > Unigine Heavon maps a lot of buffers with both flags, but run on about > 85% GPU-load, as WINE removes both hints and the game has to wait for > the buffer to be mapped. It makes logical sense to me that mapping a buffer with both DISCARD and NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at least some engines will map a part of a buffer with NOOVERWRITE and draw with that part, map the next part of the buffer with NOOVERWRITE and draw with that part, etc, then after the last part of the buffer it maps with DISCARD to get new memory and keep going while the previous buffer memory is handled asynchronously by the driver or card. I notice that wined3d has some parts where it ignores/removes DISCARD, so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. In such a case, the driver will get NOOVERWRITE for a part of the buffer that's still in use. It would probably be better to remove NOOVERWRITE when both DISCARD and NOOVERWRITE are set.

1 0

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
by Aaryaman Vasishta June 30, 2016

June 30, 2016

On Tue, Jun 28, 2016 at 3:24 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > + if (viewport->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + IDirect3DRM_AddRef(viewport->d3drm); > + > FWIW, I didn't put the intentional d3drm, camera leaks here because it seems that the device controls the leaked references via some sort of destroy callback on the device. (See the todo_wine tests in this patch). > + todo_wine ok(ref4 > frame_ref2, "Expected ref4 > frame_ref2, got > frame_ref2 = %u, ref4 = %u.\n", frame_ref2, ref4); > + > + IDirect3DRMDevice3_Release(device3); > + IDirect3DRMDevice_Release(device1); > I tried to release d3drm explicitly myself, like how I did with the texture tests. But the tests would then crash here, at IDirect3DRMDevice_Release, where the device gets destroyed. Which probably indicates that the device stores a list of leaked references and releases them on getting destroyed. For now I've decided to avoid the leak, thus avoiding the use of a destroy callback, and implementing this as a separate later on if an application demands it, unless it's safer to get this done on priority. Cheers, Aaryaman

1 0

Re: [PATCH 5/7] d3drm: Fix device not assigning width and height after creation.
by Henri Verbeet June 30, 2016

June 30, 2016

On 24 June 2016 at 23:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > HRESULT d3drm_device_set_ddraw_device_d3d(struct d3drm_device *device, IDirect3DRM *d3drm, IDirect3D *d3d, IDirect3DDevice *d3d_device) > { > + IDirectDrawSurface *surface; > + IDirect3DDevice2 *d3d_device2; > + DDSURFACEDESC desc; > + HRESULT hr; > + > device->d3drm = d3drm; > IDirect3DRM_AddRef(d3drm); > device->device = d3d_device; > IDirect3DDevice_AddRef(d3d_device); > > + /* Fetch render target and get width/height from there */ > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirectDrawSurface, (void **)&surface))) > + { > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirect3DDevice2, (void **)&d3d_device2))) > + return hr; > + hr = IDirect3DDevice2_GetRenderTarget(d3d_device2, &surface); > + IDirect3DDevice2_Release(d3d_device2); > + if (FAILED(hr)) > + return hr; > + } > + > + desc.dwSize = sizeof(desc); > + if (FAILED(hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc))) > + { > + IDirectDrawSurface_Release(surface); > + return hr; > + } > + > + device->width = desc.dwWidth; > + device->height = desc.dwHeight; > + IDirectDrawSurface_Release(surface); > + > return IDirect3D_QueryInterface(d3d, &IID_IDirectDraw, (void **)&device->ddraw); > } > This leaks some references (IDirect3DRM, IDirect3DDevice) on error paths, are those on purpose?

2 5

Re: [PATCH 4/5] inetcomm: Support LPSTR to LPWSTR conversion in GetProp
by Nikolay Sivov June 30, 2016

June 30, 2016

Is it possible to use PropVariantChangeType() for such conversion?

1 0

Re: [PATCH 1/5] inetcomm: Implement IMimeBody DeleteProp
by Nikolay Sivov June 30, 2016

June 30, 2016

On 06/30/2016 11:58 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/inetcomm/mimeole.c | 23 +++++++++++++++++-- > dlls/inetcomm/tests/mimeole.c | 53 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 74 insertions(+), 2 deletions(-) > > diff --git a/dlls/inetcomm/mimeole.c b/dlls/inetcomm/mimeole.c > index 766503d..cff95a1 100644 > --- a/dlls/inetcomm/mimeole.c > +++ b/dlls/inetcomm/mimeole.c > @@ -898,8 +898,27 @@ static HRESULT WINAPI MimeBody_DeleteProp( > LPCSTR pszName) > { > MimeBody *This = impl_from_IMimeBody(iface); > - FIXME("(%p)->(%s) stub\n", This, debugstr_a(pszName)); > - return E_NOTIMPL; > + header_t *cursor, *cursor2; > + BOOL found = FALSE; You don't need to initialize 'found'. > + > + TRACE("(%p)->(%s) stub\n", This, debugstr_a(pszName)); 'stub' should be removed, unless it's still too stubby. > + > + LIST_FOR_EACH_ENTRY_SAFE(cursor, cursor2, &This->headers, header_t, entry) > + { > + if(ISPIDSTR(pszName)) > + found = STRTOPID(pszName) == cursor->prop->id; > + else > + found = !lstrcmpiA(pszName, cursor->prop->name); > + > + if(found) > + { > + list_remove(&cursor->entry); > + HeapFree(GetProcessHeap(), 0, cursor); > + return S_OK; > + } > + } > + > + return MIME_E_NOT_FOUND; > } The way you use it, there's no need for _SAFE() list iteration. > static HRESULT WINAPI MimeBody_CopyProps( > diff --git a/dlls/inetcomm/tests/mimeole.c b/dlls/inetcomm/tests/mimeole.c > index 8063b86..46fd1d5 100644 > --- a/dlls/inetcomm/tests/mimeole.c > +++ b/dlls/inetcomm/tests/mimeole.c > @@ -604,6 +604,58 @@ static void test_BindToObject(void) > IMimeMessage_Release(msg); > } > > +static void test_BodyDeleteProp(void) > +{ > + static const char topic[] = "wine topic"; > + HRESULT hr; > + IMimeMessage *msg; > + IMimeBody *body; > + PROPVARIANT prop; > + > + hr = MimeOleCreateMessage(NULL, &msg); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + PropVariantInit(&prop); > + > + hr = IMimeMessage_BindToObject(msg, HBODY_ROOT, &IID_IMimeBody, (void**)&body); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, "Subject", 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, "Subject", 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + IMimeBody_Release(body); > + IMimeMessage_Release(msg); > +} > + > static void test_MimeOleGetPropertySchema(void) > { > HRESULT hr; > @@ -627,6 +679,7 @@ START_TEST(mimeole) > test_MessageGetPropInfo(); > test_MessageOptions(); > test_BindToObject(); > + test_BodyDeleteProp(); > test_MimeOleGetPropertySchema(); > OleUninitialize(); > }

1 0

Re: [v2 1/3] dinput: Print location ID in debugstr_device on the Mac
by Dmitry Timoshkov June 30, 2016

June 30, 2016

David Lawrie <david.dljunk(a)gmail.com> wrote: > +static Boolean get_device_property_long(IOHIDDeviceRef in_device, CFStringRef in_key, long * out_value) > +{ > + Boolean result = FALSE; > + CFTypeRef type; > + > + if (in_device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(in_device)); > + > + type = IOHIDDeviceGetProperty(in_device, in_key); > + > + if (type) > + { > + if (CFNumberGetTypeID() == CFGetTypeID(type)) > + result = CFNumberGetValue((CFNumberRef)type, kCFNumberLongType, out_value); > + } > + } > + return result; > +} > + > +long get_device_location_ID(IOHIDDeviceRef device) > +{ > + long result = 0; > + get_device_property_long(device, CFSTR(kIOHIDLocationIDKey), &result); > + return result; > +} The helper should be 'static'. Also, probably you should return value from the helper directly since you don't check for the boolean result anyway. Same comment applies for a similar winejoystick.drv patch. -- Dmitry.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP (v2).
by Marvin June 29, 2016

June 29, 2016

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=23888 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH] d3dx9: Avoid overflowing debug channel buffer when tracing ASCII effect errors.
by Alistair Leslie-Hughes June 29, 2016

June 29, 2016

Hi Matteo, On 29/06/16 03:06, Matteo Bruni wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > Inspired by a patch by Alistair Leslie-Hughes. > > dlls/d3dx9_36/effect.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(53,7): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(55,9): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "StaticMesh.fx(484,39): warning X3206: implicit truncation of vector type" Hers is the output from your patch. The first too lines are warnings are split across trace statement. Should we use a larger number to attempt to have each error/warning on one line. Best Regards Alistair Leslie-Hughes

2 1

Re: [v1 2/2] dinput/joystick_osx.c: sorts devices by location ID
by Ken Thomases June 29, 2016

June 29, 2016

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for dinput joysticks > > Note: if multiple virtual joysticks have the same location ID, they will > still be unordered > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) Similar comments as for the corresponding winejoystick.drv patch, of which this is a subset. -Ken

2 1

Re: [v1 2/2] winejoystick.drv/joystick_osx.c: sorts devices by location ID
by Ken Thomases June 29, 2016

June 29, 2016

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for winmm joysticks This should probably be a note and go below the "---" line, below. Also, please adjust the subjects of these patches. Take a look at how Alexandre changed the subjects of your previous commits. Try to save him the effort. The prefix should generally be just the DLL name without the name of the specific file (although changes to tests can have "/tests"). The first word after the colon should be capitalized. The verb should be in the imperative mood ("Sort" vs. "Sorts"). If you want to include the information that this patch is for the Mac which is lost by removing the file name, add that to the subject (e.g. "Sort devices by location ID on the Mac"). > @@ -321,6 +321,34 @@ static CFIndex find_top_level(IOHIDDeviceRef hid_device, CFMutableArrayRef main_ > /************************************************************************** > * find_osx_devices > */ You've separated the function header comment above from the function it goes with. > + > +/* > + * Helper to sort array by location ID since they are consistent across boots & launches > + */ Use the function header comment format used elsewhere in the file. > +static CFComparisonResult CFDeviceArrayComparatorFunction(const void *val1, const void *val2, void *context) As with the previous patches, don't start your function names with "CF" which is for Core Foundation functions. There's no reason to include "Function" in the name of a function. Use lowercase-and-underscores. Also, it should mention what it's comparing by or for. For example, "device_location_comparator" similar to button_usage_comparator() elsewhere in this file. > +{ > +#pragma unused(context) Don't bother with that. > + CFComparisonResult result = kCFCompareEqualTo; > + > + long loc1 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val1); > + long loc2 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val2); There's no need to cast void pointers to other pointer types. > + if (loc1 < loc2) { > + result = kCFCompareLessThan; > + } else if (loc1 > loc2) { > + result = kCFCompareGreaterThan; > + } If you're going to use braces around these blocks (which isn't necessary), put the braces on separate lines. > +/* > + * Helper to copy the CFSet to a CFArray > + */ > +static void CFSetApplierFunctionCopyToCFArray(const void *value, void *context) I know this name was copied from dinput, but it's still terrible. ;) > +{ > + CFArrayAppendValue((CFMutableArrayRef)context, value); Unneeded cast. > @@ -363,20 +391,16 @@ static int find_osx_devices(void) > if (devset) > { > CFIndex num_devices, num_main_elements; > - const void** refs; > - CFArrayRef devices; > + CFMutableArrayRef devices; > > num_devices = CFSetGetCount(devset); > - refs = HeapAlloc(GetProcessHeap(), 0, num_devices * sizeof(*refs)); > - if (!refs) > - { > - CFRelease(devset); > - goto fail; > - } > > - CFSetGetValues(devset, refs); > - devices = CFArrayCreate(NULL, refs, num_devices, &kCFTypeArrayCallBacks); > - HeapFree(GetProcessHeap(), 0, refs); > + devices = CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); As a minor optimization, you can specify a capacity to the above call. > + /* copy devices from (unordered) set to array */ > + CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, (void *)devices); Unneeded cast. > + /* now sort the array by location ID's */ Again, these comments don't add much and better names for the functions would make the code more self-explanatory. It might be worthwhile to put a comment here or in the function header about _why_ you're sorting by location ID (i.e. to provide a stable order across runs). That's a good general rule: comments shouldn't narrate what the code is doing, they should explain why it's doing it, or why it's doing it in a particular way, if that's non-obvious. > + CFArraySortValues(devices, CFRangeMake(0, num_devices), CFDeviceArrayComparatorFunction, NULL); > + -Ken

1 0

Re: [v1 1/2] winejoystick.drv/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases June 29, 2016

June 29, 2016

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) Same issues as the corresponding dinput patch. -Ken

1 0

Re: [v1 1/2] dinput/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases June 29, 2016

June 29, 2016

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static Boolean IOHIDDevice_GetLongProperty(IOHIDDeviceRef inIOHIDDeviceRef, CFStringRef inKey, long * outValue) Don't name your functions as though they were Apple's. Apple "owns" the namespace of identifiers starting with "IOHIDDevice". In general, just use simple lowercase-and-underscores names unless there's a strong reason not to. Something like "get_device_property_long". Same goes for the parameters: "key" and "out_value" or the like. > +{ > + Boolean result = FALSE; > + CFTypeRef tCFTypeRef; Don't use this naming convention either (is that Hungarian notation?). Why is the type repeated in the variable name? What does the "t" prefix signify. Just call this "value" or something. > + > + if (inIOHIDDeviceRef) { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(inIOHIDDeviceRef)); > + > + tCFTypeRef = IOHIDDeviceGetProperty(inIOHIDDeviceRef, inKey); > + > + if ( tCFTypeRef ) { > + /* if this is a number */ > + if (CFNumberGetTypeID() == CFGetTypeID(tCFTypeRef)) { > + /* get it's value */ What do these comments add? > + result = CFNumberGetValue((CFNumberRef)tCFTypeRef, kCFNumberSInt32Type, outValue); "long" and "SInt32" don't match reliably. Why not kCFNumberLongType? > +long IOHIDDevice_GetLocationID(IOHIDDeviceRef inIOHIDDeviceRef) Naming conventions here, too. > +{ > + long result = 0; > + (void)IOHIDDevice_GetLongProperty(inIOHIDDeviceRef, CFSTR(kIOHIDLocationIDKey), &result); I don't think we generally use the cast-to-void thing for unused return values in Wine. -Ken

1 0

Re: shell32/tests: Avoid casts from a COM object to an iface.
by Marvin June 29, 2016

June 29, 2016

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=23879 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

2 1

Re: [PATCH] winex11: fix destroying of top-level windows
by Alexandre Julliard June 28, 2016

June 28, 2016

Miklós Máté <mtmkls(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=40767 > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/winex11.drv/opengl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index d89a193..27ddd79 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -1314,6 +1314,9 @@ static void free_gl_drawable( struct gl_drawable *gl ) > { > switch (gl->type) > { > + case DC_GL_WINDOW: > + pglXDestroyWindow( gdi_display, gl->drawable ); > + break; Actually this one has some issues too: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2250: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:6312: Tests skipped: This GPU supports SM3, skipping unsupported shader test. device.c:6724: Tests skipped: D3DFMT_A32B32G32R32F supports filtering, skipping tests. device.c:7747: Tests skipped: Failed to create cube texture for format R8G8B8 (hr 0x8876086c), skipping tests. device.c:8450: Tests skipped: Dynamic D3DFMT_YUY2 textures not supported, skipping mipmap test. device.c:8450: Tests skipped: Dynamic D3DFMT_UYVY textures not supported, skipping mipmap test. X Error of failed request: GLXBadWindow Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 32 (X_GLXDestroyWindow) Serial number of failed request: 8900 Current serial number in output stream: 8901 Makefile:208: recipe for target 'device.ok' failed -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: d3dx10: Implement D3DX10CompileFromMemory.
by Matteo Bruni June 28, 2016

June 28, 2016

2016-06-27 21:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > + TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > + "sflags %#x, eflage %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", "eflage" typo. > diff --git a/dlls/d3dx10_43/d3dx10_43_main.c b/dlls/d3dx10_43/d3dx10_43_main.c > index 0c1ff80..fe56ee0 100644 > --- a/dlls/d3dx10_43/d3dx10_43_main.c > +++ b/dlls/d3dx10_43/d3dx10_43_main.c > @@ -37,6 +37,8 @@ > #include "d3dx10core.h" > #include "d3dx10tex.h" > > +#include "wine/debug.h" That is already included a few lines above. Looks good otherwise.

1 0

Re: [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection
by Matteo Bruni June 28, 2016

June 28, 2016

2016-06-23 1:45 GMT+02:00 Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection > > This add missing fields to the d3dcompiler_shader_reflection based on > http://timjones.tw/blog/archive/2015/09/02/parsing-direct3d-shader-bytecode > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476590(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb694550(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb172432(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476209(v=vs.85).… Thank you for the links, that saved me some time to have to look them up. > + UINT sample_frequency_shader; As far as I understand, that would be better served by a BOOL. > UINT dcl_count; > + UINT def_count; Nitpick but def_count is right before dcl_count in both D3D11_SHADER_DESC and in the shader bytecode, it would be nice to have the same order everywhere. We have tests for this in d3dcompiler_43/tests/reflection.c. Can you please add some tests for those new fields too? Notice that you don't necessarily need n separate new tests for each of the n new features. The patch subject should be something like "d3dcompiler: Add d3d11 fields to struct d3dcompiler_shader_reflection." i.e. no square brackets for the dll prefix and put a colon after it. Also, while not strictly required, it's encouraged to use git send-email, it will inline the patch without wrapping and generally take care of most of the formatting details, assuming git is configured correctly.

1 0