October 2017 - 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

COM tracing ...
by Michael Meeks Aug. 21, 2018

Aug. 21, 2018

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

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: [PATCH] arm64: Use __builtin_ms_va_list and __attribute__((ms_abi)) on arm64
by André Hentschel Feb. 13, 2018

Feb. 13, 2018

Am 14.08.2017 um 12:35 schrieb Martin Storsjo: > Windows uses a different ABI for va_list on arm64 just like on x86_64. > > On x86_64, the calling convention for windows functions is completely > different from the one on other platforms. On arm64, they're mostly the > same, with the only exception being variadic functions (where all float > arguments are passed in integer registers, since the va_list is a single > pointer). > > Any functions using __builtin_ms_va_start need to be decorated with > __attribute__((ms_abi)). > > Add a check in configure for the support of __builtin_ms_va_list > (both features appared in clang at the same time, in the 5.0 release). > > This fixes running binaries that use e.g. printf style functions > (e.g. midl.exe from the windows 10 sdk), fixing > https://bugs.winehq.org/show_bug.cgi?id=38886. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > clang 5.0, which this requires, isn't yet released, but is in RC2 and > will probably be released pretty soon. > --- > configure.ac | 7 +++++++ > include/msvcrt/crtdefs.h | 6 +++++- > include/windef.h | 6 +++++- > include/wine/test.h | 4 ++-- > 4 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 7d52b24..c33221f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -179,6 +179,13 @@ case $host in > CFLAGS="$CFLAGS -marm" > AC_SUBST(TARGETFLAGS,"-marm") > ;; > + aarch64*) > + AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list]) > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])], > + [AC_MSG_RESULT([yes])], > + [AC_MSG_RESULT([no]) > + AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])]) Hi, The upstreamed variadic function handling is terrific, thanks for that! I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC... At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64. It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK... On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5 OK... We need this improvement, I'll sign it off :) Now, we only need to convince distributions to avoid x18

3 4

Upcoming TestBot patches
by Francois Gouget Dec. 19, 2017

Dec. 19, 2017

For those that are interested I'm trying to regularly push my set of 'might be ready to send' patches on GitHub: https://github.com/fgouget/wine-tools/tree/future So feel free to have a look and / or test it. -- Francois Gouget <fgouget(a)codeweavers.com>

2 4

Wine tests
by Jeremy White Nov. 15, 2017

Nov. 15, 2017

Hey all, I thought I would start my annual harangue a little bit early this year. I thought I'd summarize the lens I see things with and then see if there is anything constructive we can do now, and then again when we meet in person. Then we'll also have drink to turn to if we end with nothing but despair. The ideal is that this page: http://test.winehq.org/data/ be covered entirely in green. That would indicate that our unit tests ran successfully on all tested systems. A further ideal is that it would have 'Mac' and 'Android' columns that were also green. The holy dream we all crave is that a 'make test' would work in a rational fashion. And the ultimate fantasy is that every patch sent would be tested not only on Windows if the tests change, but on Linux, Mac, and Android as well. (Alexandre does that by hand now, but it'd be nice to automate that test). A more reasonable ideal is that all of our tests would run successfully on a well curated list of 'rigorous' test machines. I don't believe that we have an official page for that; I maintain an unofficial one here: https://www.winehq.org/~jwhite/latest.html That is all of the 'newtb' Windows VMs excluding Windows 2000, Windows 8, and Windows 10. That list of failures has fluctuated; starting at about 40, and once getting down to as few as a dozen. It now stands at about 20, where it's been for a while. Nicely (?), we're down to only intermittent failures :-/. I think the instinct has been to fix all of the Windows tests; that once those are consistently green, then it would make sense to go after a well defined Linux rig and push it to green. CodeWeavers has a rack of hardware and we're happy to put any flavor of system in there (and have done so, with standard rigs for testing AMD and NVidia Linux boxes). A quick scan suggests that those rigs stand at about the same number of failures; low to mid teens. I think we are lacking several things: 1. Some help for Francois. He's basically doing all of this on his own. We could use some people willing to fight through Perl to help extend our capabilities. 2. The ability (will?) to drive the Windows tests to green. Is it time to articulate a kind of test that is expected to periodically fail? In other words, do we have tests that 'reasonably' fail, and so we should redefine that failure? Many years in the past, we had constructive sessions where I forcibly prevented people from going to the pub until we flipped a whole lot more bits to green. I can remember times when that worked quite nicely. But we haven't been as productive with that lately. Is it worth dedicating another block of time to it at the Wine conference? Would it work better if we prepared ahead of time? For example, let me suggest this: that developers start right now running winetest on machines they plan to bring to Wineconf. Then we can have that body of information available to us at the conference, and we can choose to attack issues that show commonality. Does that make sense? Any other prep work we should do? (Jacek and Piotr assure me that there will be plenty of beer for drowning sorrows, so that seems to be covered). Cheers, Jeremy

5 7

Setting a source directory in winedbg
by Mihai Todor Nov. 3, 2017

Nov. 3, 2017

Hi Everyone, I noticed that I can set the source directory via the `dir` command in winedbg, but, for some reason, it rejects absolute paths, like Z:\bla\blah, claiming that ":" is a syntax error. I tried to enclose the path in quotes / double quotes, but then the quote / double quote is rejected as a syntax error. I don't have sufficient knowledge of bison to grok the code in programs/winedbg/dbg.y, so is there a way to escape the colon symbol? As a workaround, I mapped my build directory under Wine, but that is really annoying. Thank you, Mihai Todor

1 1

Re: [v3] oleaut32: Add ARM support to DispCallFunc().
by Alexandre Julliard Nov. 2, 2017

Nov. 2, 2017

Donna Whisnant <dewhisna(a)dewtronics.com> writes: > Adds ARM ABI support to DispCallFunc() to allow IDispatch invoke calls > to succeed on ARM platforms. This change specifically targets only > 32-bit little-endian (ARMEL) platform CPUs. It's believed to likely be > compatible with big-endian (ARMEB) platforms, but testing for that > platform should be completed before enabling. > > Tested on Raspbian Stretch 2017-09-07 RPi image using a Qemu systemd > container to compile and run it on an x86-64 Host.. When running on > Raspberry Pi hardware, a 3G/1G split kernel needs to be used for Wine > to function. It breaks the Android build: arm-linux-androideabi-gcc -c -o typelib.o ../../../wine/dlls/oleaut32/typelib.c -I. -I../../../wine/dlls/oleaut32 \ -I../../include -I../../../wine/include -D__WINESRC__ -D_OLEAUT32_ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret -D__ANDROID_API__=26 -marm {standard input}: Assembler messages: {standard input}:32: Error: selected processor does not support ARM mode `vldm r3!,{s0-s15}' Makefile:516: recipe for target 'typelib.o' failed make: *** [typelib.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface
by Henri Verbeet Nov. 1, 2017

Nov. 1, 2017

Perhaps this is sufficiently far removed from core Direct3D that nobody cares, but for what it's worth: On 31 October 2017 at 03:01, Fabian Maurer <dark.shadow4(a)web.de> wrote: > +typedef struct > +{ > + ID3DX8 ID3DX8_iface; > + LONG ref; > +} d3dx8; Please don't typedef structures just to save keystrokes. > +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, void **ppv) > +{ > + d3dx8 *This = impl_from_ID3DX8(iface); Please use lowercase variable names. > + > + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + if (IsEqualGUID(riid, &IID_IUnknown)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_ID3DX8)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_IPersistPropertyBag)) > + FIXME("No interface for IID_IPersistPropertyBag\n"); > + else if(IsEqualGUID(riid, &IID_IPersistStreamInit)) > + FIXME("No interface for IID_IPersistStreamInit\n"); > + else > + FIXME("No interface for %s\n", debugstr_guid(riid)); Not implementing an arbitrary interface is a WARN at best. > + > + if (*ppv) > + { > + IUnknown_AddRef((IUnknown *)(*ppv)); > + return S_OK; > + } > + > + return E_NOINTERFACE; > +} I think Nikolay already hinted at this, but this is fairly different from the canonical QueryInterface() implementation, especially for an object that only implements a single interface. > +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8 *device, > + LONG hFont, D3DXFont **retFont) Please use lowercase parameter names, and avoid the stray 'h'. > +static HRESULT WINAPI d3dx8_AssembleShaderFromFile(ID3DX8 *iface, BSTR file, LONG flags, BSTR *log, > + D3DXBuffer **constants, D3DXBuffer **ppVertexShader) > +{ > + FIXME("(%s, %i, %p, %p, %p): stub!\n", debugstr_w(file), flags, log, constants, ppVertexShader); I certainly have my preferences when it comes to trace formatting, but I think "%i" is questionable for flags regardless of preference. > +static const ID3DX8Vtbl ID3DX8_Vtbl = "d3dx8_vtbl" > +HRESULT d3dx8_create(IUnknown *outer_unk, void **ppv) > +{ > + d3dx8 *object; > + > + TRACE("(%p,%p)\n", outer_unk, ppv); > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(d3dx8)); "sizeof(*object)"

4 6

Re: [PATCH] wmvcore/tests: Access IWMDRMReader(|2|3) interfaces on Windows.
by Nikolay Sivov Oct. 31, 2017

Oct. 31, 2017

On 24.10.2017 8:36, Jefferson Carpenter wrote: > +#if defined(__MINGW32__) || defined(__MINGW64__) > +#ifdef _WIN64 > + flagPtrAddr = (unsigned long long)(reader) - 24; > + flagMem[556] = 1; > +#elif _WIN32 > + flagPtrAddr = (unsigned int)(reader) - 12; > + flagMem[288] = 1; > +#endif > + *(unsigned char **)flagPtrAddr = flagMem; > +#endif Why would you need something like that to match potential Wine's implementation? How do applications access this thing?

3 10

Re: [PATCH 4/4] dx8vb: Implement Direct3D8 methods
by Stefan Dösinger Oct. 31, 2017

Oct. 31, 2017

Hi Fabian, Why do you need a proxy IDirect3D8 implementation in dx8vb? Is there any difference between dx8vb and d3d8? Stefan > Am 31.10.2017 um 00:31 schrieb Fabian Maurer <dark.shadow4(a)web.de>: > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/dx8vb/Makefile.in | 2 +- > dlls/dx8vb/directx8.c | 112 ++++++++++++++++++++++++++++++++++++++----------- > 2 files changed, 89 insertions(+), 25 deletions(-) > > diff --git a/dlls/dx8vb/Makefile.in b/dlls/dx8vb/Makefile.in > index 8438d022f4..33fe651503 100644 > --- a/dlls/dx8vb/Makefile.in > +++ b/dlls/dx8vb/Makefile.in > @@ -1,5 +1,5 @@ > MODULE = dx8vb.dll > -IMPORTS = uuid ole32 > +IMPORTS = uuid ole32 d3d8 > > C_SRCS = \ > d3dx8.c \ > diff --git a/dlls/dx8vb/directx8.c b/dlls/dx8vb/directx8.c > index 338862a4ff..dd50c86008 100644 > --- a/dlls/dx8vb/directx8.c > +++ b/dlls/dx8vb/directx8.c > @@ -21,6 +21,9 @@ > #include "config.h" > > #include "dx8vb_private.h" > +#define __WINE_D3D8TYPES_H > +#define __WINE_D3D8CAPS_H > +#include "d3d8.h" > #include "ocidl.h" > > #include "wine/debug.h" > @@ -36,6 +39,7 @@ typedef struct > typedef struct > { > Direct3D8 Direct3D8_iface; > + IDirect3D8 *direct3d8; > LONG ref; > } direct3d8; > > @@ -95,7 +99,10 @@ static ULONG WINAPI direct3d8_Release(Direct3D8 *iface) > TRACE("(%p/%p)->(): new ref %d\n", iface, This, ref); > > if (!ref) > + { > + IDirect3D8_Release(This->direct3d8); > HeapFree(GetProcessHeap(), 0, This); > + } > > return ref; > } > @@ -104,91 +111,145 @@ static ULONG WINAPI direct3d8_Release(Direct3D8 *iface) > > static HRESULT WINAPI direct3d8_RegisterSoftwareDevice(Direct3D8 *iface, void *initializeFunction) > { > - FIXME("(%p): stub!\n", initializeFunction); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_RegisterSoftwareDevice(This->direct3d8, initializeFunction); > + > + FIXME("(%p) -> (%x)\n", initializeFunction, ret); > + > + return ret; > } > > static int WINAPI direct3d8_GetAdapterCount(Direct3D8 *iface) > { > - FIXME("(): stub!\n"); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + int ret = IDirect3D8_GetAdapterCount(This->direct3d8); > + > + FIXME("() -> (%i)\n", ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_GetAdapterIdentifier(Direct3D8 *iface, int adapter, > LONG flags, D3DADAPTER_IDENTIFIER8 *identifier) > { > - FIXME("(%i, %i, %p): stub!\n", adapter, flags, identifier); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_GetAdapterIdentifier(This->direct3d8, adapter, flags, identifier); > + > + FIXME("(%i, %i, %p) -> (%x)\n", adapter, flags, identifier, ret); > + > + return ret; > } > > static int WINAPI direct3d8_GetAdapterModeCount(Direct3D8 *iface, int adapter) > { > - FIXME("(%i): stub!\n", adapter); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + int ret = IDirect3D8_GetAdapterModeCount(This->direct3d8, adapter); > + > + FIXME("(%i) -> (%i)\n", adapter, ret); > + > + return ret; > } > > static HRESULT WINAPI direct3d8_EnumAdapterModes(Direct3D8 *iface, int adapter, int mode, D3DDISPLAYMODE *displayMode) > { > - FIXME("(%i, %i, %p): stub!\n", adapter, mode, displayMode); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_EnumAdapterModes(This->direct3d8, adapter, mode, displayMode); > + > + FIXME("(%i, %i, %p) -> (%x)\n", adapter, mode, displayMode, ret); > + > + return ret; > } > > static HRESULT WINAPI direct3d8_GetAdapterDisplayMode(Direct3D8 *iface, int adapter, D3DDISPLAYMODE *displayMode) > { > - FIXME("(%i, %p): stub!\n", adapter, displayMode); > + direct3d8 *This = impl_from_Direct3D8(iface); > + HRESULT ret; > > - return E_NOTIMPL; > + ret = IDirect3D8_GetAdapterDisplayMode(This->direct3d8, adapter, displayMode); > + > + TRACE("(%i, %p) -> (%x)\n", adapter, displayMode, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceType(Direct3D8 *iface, int adapter, D3DDEVTYPE checkType, > D3DFORMAT displayFormat, D3DFORMAT backBufferFormat, LONG bWindowed) > { > - FIXME("(%i, %u, %u, %u, %i): stub!\n", adapter, checkType, displayFormat, backBufferFormat, bWindowed); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + LONG ret = IDirect3D8_CheckDeviceType(This->direct3d8, adapter, checkType, > + displayFormat, backBufferFormat, bWindowed); > + > + FIXME("(%i, %u, %u, %u, %i) -> (%i)\n", adapter, checkType, displayFormat, backBufferFormat, bWindowed, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceFormat(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT adapterFormat, LONG usage, D3DRESOURCETYPE rType, D3DFORMAT checkFormat) > { > - FIXME("(%i, %u, %u, %i, %u, %u): stub!\n", adapter, deviceType, adapterFormat, usage, rType, checkFormat); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + LONG ret = IDirect3D8_CheckDeviceFormat(This->direct3d8, adapter, deviceType, > + adapterFormat, usage, rType, checkFormat); > + > + FIXME("(%i, %u, %u, %i, %u, %u) -> (%i)\n", adapter, deviceType, adapterFormat, usage, rType, checkFormat, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceMultiSampleType(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT renderTargetFormat, LONG windowed, D3DMULTISAMPLE_TYPE multiSampleType) > { > - FIXME("(%i, %u, %u, %i, %u): stub!\n", adapter, deviceType, renderTargetFormat, windowed, multiSampleType); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = IDirect3D8_CheckDeviceMultiSampleType(This->direct3d8, adapter, deviceType, > + renderTargetFormat, windowed, multiSampleType); > + > + FIXME("(%i, %u, %u, %i, %u) -> (%i)\n", adapter, deviceType, renderTargetFormat, windowed, multiSampleType, ret); > > - return 0; > + return ret; > } > > static LONG WINAPI direct3d8_CheckDepthStencilMatch(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT adapterFormat, D3DFORMAT renderTargetFormat, D3DFORMAT depthStencilFormat) > { > - FIXME("(%i, %u, %u, %u, %u): stub!\n", adapter, deviceType, adapterFormat, renderTargetFormat, depthStencilFormat); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = IDirect3D8_CheckDepthStencilMatch(This->direct3d8, adapter, deviceType, adapterFormat, > + renderTargetFormat, depthStencilFormat); > + > + TRACE("(%i, %u, %u, %u, %u) ->(%i)\n", adapter, deviceType, adapterFormat, > + renderTargetFormat, depthStencilFormat, ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_GetDeviceCaps(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, D3DCAPS8 *caps) > { > - FIXME("(%i, %u, %p): stub!\n", adapter, deviceType, caps); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_GetDeviceCaps(This->direct3d8, adapter, deviceType, caps); > + > + TRACE("(%i, %u, %p) -> (%x)\n", adapter, deviceType, caps, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_GetAdapterMonitor(Direct3D8 *iface, int adapter) > { > - FIXME("(%i): stub!\n", adapter); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = (LONG)IDirect3D8_GetAdapterMonitor(This->direct3d8, adapter); > + > + TRACE("(%i) -> (%i)!\n", adapter, ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_CreateDevice(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, HWND hFocusWindow, > @@ -235,6 +296,9 @@ HRESULT direct3d8_create(Direct3D8 **ppv) > > object->Direct3D8_iface.lpVtbl = &Direct3D8_Vtbl; > object->ref = 1; > + object->direct3d8 = Direct3DCreate8(D3D_SDK_VERSION); > + if(!object->direct3d8) > + ERR("Can't create D3D8 object\n"); > > *ppv = &object->Direct3D8_iface; > > -- > 2.15.0 > > >

2 3

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface
by Nikolay Sivov Oct. 31, 2017

Oct. 31, 2017

On Tue, Oct 31, 2017 at 2:31 AM, Fabian Maurer <dark.shadow4(a)web.de> wrote: > > main.c > > IDL_SRCS = dx8vb.idl > diff --git a/dlls/dx8vb/d3dx8.c b/dlls/dx8vb/d3dx8.c > new file mode 100644 > index 0000000000..2959849547 > --- /dev/null > +++ b/dlls/dx8vb/d3dx8.c > @@ -0,0 +1,861 @@ > + /* > + * Copyright 2017 Fabian Maurer > + * > + * 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 COBJMACROS > + > +#include "config.h" > + > +#include "dx8vb_private.h" > +#include "ocidl.h" > + > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(dx8vb); > + > +typedef struct > +{ > + ID3DX8 ID3DX8_iface; > + LONG ref; > +} d3dx8; > + > +static inline d3dx8 *impl_from_ID3DX8(ID3DX8 *iface) > +{ > + return CONTAINING_RECORD(iface, d3dx8, ID3DX8_iface); > +} > + > +/*** d3dx8 - IUnknown methods ***/ > + > Comment seems a bit useless, you're not going to use this file for anything else. > +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, > void **ppv) > +{ > + d3dx8 *This = impl_from_ID3DX8(iface); > + > + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + if (IsEqualGUID(riid, &IID_IUnknown)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_ID3DX8)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_IPersistPropertyBag)) > + FIXME("No interface for IID_IPersistPropertyBag\n"); > + else if(IsEqualGUID(riid, &IID_IPersistStreamInit)) > + FIXME("No interface for IID_IPersistStreamInit\n"); > + else > Where does this come from?

2 1

Re: [PATCH 3/4] dx8vb: Add Direct3D8 interface with stubs
by Nikolay Sivov Oct. 31, 2017

Oct. 31, 2017

> > > static HRESULT WINAPI directx8_QueryInterface(IDirectX8 *iface, REFIID > riid, void **ppv) > @@ -237,9 +440,11 @@ static HRESULT WINAPI directx8_ > DirectPlayAddressCreate(IDirectX8 *iface, DirectP > > static HRESULT WINAPI directx8_Direct3DCreate(IDirectX8 *iface, > Direct3D8 **ret) > { > - FIXME("(%p): stub!\n", ret); > + HRESULT res = direct3d8_create(ret); > > - return E_NOTIMPL; > + TRACE("(%p) -> (%x)\n", ret, res); > + > + return res; > } > That's an unusual way to arrange things. Why don't you return as "return direct3d8_create();" ?

2 1

Wineconference keynote 2017
by Marcus Meissner Oct. 30, 2017

Oct. 30, 2017

Hi folks, I have uploaded Alexandres Wineconference 2017 Keynote to youtube: https://www.youtube.com/watch?v=AokFgDSLMWU&t=772s Ciao, Marcus

2 1

WineConf agenda
by Jacek Caban Oct. 29, 2017

Oct. 29, 2017

Hi all, It's getting close to WineConf and I think it's time to think about agenda. Does anyone have anything he'd like to talk about? Any ideas about conversations we should have? Feel free to add them to https://wiki.winehq.org/WineConf2017 Cheers, Jacek

4 4

Re: [v2] oleaut32: Add ARM support to DispCallFunc().
by Donna Whisnant Oct. 28, 2017

Oct. 28, 2017

V3 has been posted. Other comments are inlined below... > > Hi, > > thanks, but it seems I missed minor things last time: > > > + args = heap_alloc(sizeof(VARIANT) * cActuals + sizeof(DWORD) * 4 ); > > Try to be consistent with the spaces for each function call. > Sorry. That one came from a cut-and-paste of the i386 code and I missed fixing it. > > + case VT_R4: /* these must be 4-byte aligned, and put in 's' regs or stack, as they are single-floats */ > > + if (scount < 16) > > + regs.sd.s[scount++] = V_R4(arg); > > + else > > + args[argspos++] = V_UI4(arg); > > + break; > ... > > + case VT_VARIANT: > > + /* 8-byte align 'r' and/or stack: */ > > + if (rcount < 3) > > + { > > + rcount += (rcount % 2); > > + } > > + else > > + { > > + rcount = 4; > > + argspos += (argspos % 2); > > + } > ... > > + case VT_BOOL: /* VT_BOOL is 16-bit but BOOL is 32-bit, needs to be extended */ > > + if (rcount < 4) > > + regs.r[rcount++] = V_BOOL(arg); > > + else > > + args[argspos++] = V_BOOL(arg); > > + break; > > + default: > > + if (rcount < 4) > > + regs.r[rcount++] = V_UI4(arg); > > + else > > + args[argspos++] = V_UI4(arg); > > + break; > > + } > > Maybe one of those is not really conistent wrt curly brackets > That was actually intentional, as I made the 'if' in the VT_VARIANT case consistent with itself. All of the others cited needed no curly braces on either half of the 'if'. However, that one had to have curly braces on the 'else', so I made it consistent on the other side too and used curly braces throughout the 'if'. My usage of curly braces with respect to 'if' statements was to use them on both halves or neither half... But since you want them removed, I have removed the extra curly braces on that one in the v3 post. > > + case VT_CY: > > + V_UI8(pvargResult) = call_method(func, argspos, args, (DWORD*)&regs ); > > + break; > > + default: > > + V_UI4(pvargResult) = call_method( func, argspos, args, (DWORD*)&regs ); > > + break; > > space issue again, maybe somewhere else too? > Oops, I missed that one space. Fixed. I didn't spot any others. The rest appear correct or are at least consistent throughout.

1 0

Re: [v2] oleaut32: Add ARM support to DispCallFunc().
by André Hentschel Oct. 28, 2017

Oct. 28, 2017

Am 26.10.2017 um 06:39 schrieb Donna Whisnant: > Adds ARM ABI support to DispCallFunc() to allow IDispatch invoke calls > to succeed on ARM platforms. This change specifically targets only > 32-bit little-endian (ARMEL) platform CPUs. It's believed to likely be > compatible with big-endian (ARMEB) platforms, but testing for that > platform should be completed before enabling. > > Tested on Raspbian Stretch 2017-09-07 RPi image using a Qemu systemd > container to compile and run it on an x86-64 Host.. When running on > Raspberry Pi hardware, a 3G/1G split kernel needs to be used for Wine > to function. Hi, thanks, but it seems I missed minor things last time: > + args = heap_alloc(sizeof(VARIANT) * cActuals + sizeof(DWORD) * 4 ); Try to be consistent with the spaces for each function call. > + case VT_R4: /* these must be 4-byte aligned, and put in 's' regs or stack, as they are single-floats */ > + if (scount < 16) > + regs.sd.s[scount++] = V_R4(arg); > + else > + args[argspos++] = V_UI4(arg); > + break; ... > + case VT_VARIANT: > + /* 8-byte align 'r' and/or stack: */ > + if (rcount < 3) > + { > + rcount += (rcount % 2); > + } > + else > + { > + rcount = 4; > + argspos += (argspos % 2); > + } ... > + case VT_BOOL: /* VT_BOOL is 16-bit but BOOL is 32-bit, needs to be extended */ > + if (rcount < 4) > + regs.r[rcount++] = V_BOOL(arg); > + else > + args[argspos++] = V_BOOL(arg); > + break; > + default: > + if (rcount < 4) > + regs.r[rcount++] = V_UI4(arg); > + else > + args[argspos++] = V_UI4(arg); > + break; > + } Maybe one of those is not really conistent wrt curly brackets > + case VT_CY: > + V_UI8(pvargResult) = call_method(func, argspos, args, (DWORD*)&regs ); > + break; > + default: > + V_UI4(pvargResult) = call_method( func, argspos, args, (DWORD*)&regs ); > + break; space issue again, maybe somewhere else too? Otherwise I'm quite tempted to sign it off

1 0

Re: Fwd: Re: oleaut32: Add ARM support to DispCallFunc().
by Donna Whisnant Oct. 26, 2017

Oct. 26, 2017

Thanks. I did miss it, as I had subscribed to the patches list, but forgot to subscribe the devel list. And thanks for your feedback. One additional comment regarding the tests, as I didn't see mention of that in this thread. My code passes the tests for this DispCallFunc() function (I did verify that) except for the specialized case that tests for win64 functionality in DispCallFunc(). That test was designed to verify stdcall vs. cdecl on 32-bit x86 platforms. However, like the 64-bit x86, ARM (both 32 and 64) doesn't use stdcall in the traditional sense of stack cleaning. Thus, that test needs to be #ifdef'd out on ARM as it isn't valid. But I didn't like how that looked and it wasn't consistent with the existing 64-bit version. I thought a better solution would be to change it to only be there for "__i386__" instead, as I think that's the only mode that will ever need it. So if you are wondering why my patch set didn't touch the test code and why that particular test technically fails, that's why. I figured you guys can decide which way you want to tweak that... My other replies are inlined below... On Tue, Oct 24, 2017, at 13:37, André Hentschel wrote: > hi, just in case you missed it > > > -------- Weitergeleitete Nachricht -------- > Betreff: Re: oleaut32: Add ARM support to DispCallFunc(). > Datum: Mon, 23 Oct 2017 23:07:43 +0200 > Von: André Hentschel <nerv(a)dawncrow.de> > An: wine-devel(a)winehq.org > > Hi Donna and Welcome to the Wine Project! > > Whats your motivation for this patch? > You did a very good job for a firsttimer! > Thanks! While new to this project, I've been programming for over 37 years. My motivation on this patch was porting some ActiveX components over to ARM to run on a Raspberry Pi Zero W for a data logging device I'm designing for the CAN bus. Those components use IDispatch for invocation rather than the vtable, as they were designed to be extensible without requiring users to recompile their code, and this was the last piece of the puzzle to make them fully work on ARM. > Some more notes below: > > Am 22.10.2017 um 03:04 schrieb Donna Whisnant: > > Adds ARM ABI support to DispCallFunc() to allow IDispatch invoke calls > > to succeed on ARM platforms. This change specifically targets only > > 32-bit little-endian (ARMEL) platform CPUs. It's believed to likely be > > compatible with 64-bit and/or big-endian (ARMEB) platforms, but testing > > for those other platforms should be completed before enabling. > > > > Tested on Raspbian Stretch 2017-09-07 RPi image using a Qemu systemd > > container to compile and run it on an x86-64 Host.. When running on > > Raspberry Pi hardware, a 3G/1G split kernel needs to be used for Wine > > to function. > > > > Signed-off-by: Donna Whisnant <dewhisna(a)dewtronics.com> > > --- > > dlls/oleaut32/typelib.c | 221 +++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 219 insertions(+), 2 deletions(-) > > > > diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c > > index ebf6d85..d7ef212 100644 > > --- a/dlls/oleaut32/typelib.c > > +++ b/dlls/oleaut32/typelib.c > > @@ -6302,8 +6302,48 @@ static HRESULT WINAPI ITypeInfo_fnGetIDsOfNames( ITypeInfo2 *iface, > > return DISP_E_UNKNOWNNAME; > > } > > > > +#if defined(__arm__) && defined(__ARM_32BIT_STATE) && !defined(__ARMEB__) > > +/* Note: this may work OK on 64-bit and/or ARMEB, but has currently only been tested for 32-bit ARMEL */ > > While i doubt there is something risky here regarding endianess you can > keep the ARMEB check, but get rid of the 32bit check, it might be about > Thunk(16bit) vs. ARM(32bit) but I'm not sure. > Anyway, this won't work on 64bit, because the instruction set is totally > different, but it inspires me to do the 64bit version as soon this lands > upstream ;) > Interesting. Between the ARMEB/ARMEL modes and the 32/64 bit check, I would have left the 32-bit check and tossed the !ARMEB check, which is the opposite of your instructions. I'm fairly certain there isn't anything endian-specific. But as you pointed out, the instruction set on the 64-bit is different. So I'm confused why you say to get rid of the 32-bit check. Are you talking about removing the 'define' check for 32-bit or just the comment? Can you please clarify? > > > > -#ifdef __i386__ > > +extern LONGLONG call_method( void *func, int nb_stk_args, const DWORD *stk_args, const DWORD *reg_args ); > > +__ASM_GLOBAL_FUNC( call_method, > > + /* r0 = *func > > + * r1 = nb_stk_args > > + * r2 = *stk_args (pointer to 'nb_stk_args' DWORD values to push on stack) > > + * r3 = *reg_args (pointer to 8, 64-bit d0-d7 (double) values OR as 16, 32-bit s0-s15 (float) values, followed by 4, 32-bit (DWORD) r0-r3 values) > > + */ > > + > > + "push {fp, lr}\n\t" /* Save frame pointer and return address (stack still aligned to 8 bytes) */ > > + __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") > > + __ASM_CFI(".cfi_rel_offset %fp,0\n\t") > > + "add fp, sp, #4\n\t" /* Setup frame pointer */ > > Is this adjusted FP used somewhere? (I forgot a lot of things regarding > arm32...) > In my first version of the code, I was using r4 and r5 (which had to be saved/restored) and originally had slightly different arguments coming into the function (more than was fitting in the registers) and so I was setting up the frame for easier debugging. But then I remembered I have the 'ip' register to my disposal, and that was sufficient and allowed me to toss the saving of those other registers. And, my original function signature was passing both the floating point registers and the core registers in separate structures using separate pointers to them, but then I realized that could be a single structure with both, so I tossed the extra argument and everything would then fit into the registers alone for the call, meaning the stack frame itself isn't really needed anymore. However, it's still necessary to set 'fp', though, as it's needed for cleaning the stack on the return from the callee, but I could toss the +4 adjustment of it or use "#0" for the adjustment like the compiler probably would (as I think it maps to the same instruction binary). If I do that, the ASM_CFI macro usage could be dropped too as there would be nothing for them to report. > > + __ASM_CFI(".cfi_def_cfa_register %fp\n\t") > > + > > + "lsls r1, r1, #2\n\t" /* r1 = nb_stk_args * sizeof(DWORD) */ > > + "beq 1f\n\t" /* Skip allocation if no stack args */ > > + "add r2, r2, r1\n" /* Calculate ending address of incoming stack data */ > > + "2:\tldr ip, [r2, #-4]!\n\t" /* Get next value */ > > + "str ip, [sp, #-4]!\n\t" /* Push it on the stack */ > > + "subs r1, r1, #4\n\t" /* Decrement count */ > > + "bgt 2b\n\t" /* Loop till done */ > > + > > + "1:\tvldm r3!, {s0-s15}\n\t" /* Load the s0-s15/d0-d7 arguments */ > > + "mov ip, r0\n\t" /* Save the function call address to ip before we nuke r0 with arguments to pass */ > > + "ldm r3, {r0-r3}\n\t" /* Load the r0-r3 arguments */ > > + > > + "blx ip\n\t" /* Call the target function */ > > + > > + "sub sp, fp, #4\n\t" /* Clean the stack using 'fp' to allow for either stdcall or cdecl calls */ > > + __ASM_CFI(".cfi_def_cfa %sp,4\n\t") > > + "pop {fp, pc}\n\t" /* Restore FP and return */ > > + __ASM_CFI(".cfi_same_value %fp\n\t") /* Here for completeness and symmetry with other cpus, but won't be reached */ > > + ) > > + > > +/* same function but returning single/double floating point */ > > +static float (* const call_float_method)(void *, int, const DWORD *, const DWORD *) = (void *)call_method; > > +static double (* const call_double_method)(void *, int, const DWORD *, const DWORD *) = (void *)call_method; > > + > > +#elif defined(__i386__) > > > > extern LONGLONG call_method( void *func, int nb_args, const DWORD *args, int *stack_offset ); > > __ASM_GLOBAL_FUNC( call_method, > > @@ -6637,7 +6677,184 @@ DispCallFunc( > > void* pvInstance, ULONG_PTR oVft, CALLCONV cc, VARTYPE vtReturn, UINT cActuals, > > VARTYPE* prgvt, VARIANTARG** prgpvarg, VARIANT* pvargResult) > > { > > -#ifdef __i386__ > > +#if defined(__arm__) && defined(__ARM_32BIT_STATE) && !defined(__ARMEB__) > > +/* Note: this may work OK on 64-bit and/or ARMEB, but has currently only been tested for 32-bit ARMEL */ > > Same as above > > > + int argspos; > > + void *func; > > + UINT i; > > + DWORD *args; > > + struct { > > + union { > > + float s[16]; > > + double d[8]; > > + } sd; > > + DWORD r[4]; > > + } regs; > > + int rcount; /* 32-bit register index count */ > > + int scount; /* single-precision float register index count (will be incremented twice for doubles, plus alignment) */ > > + > > + TRACE("(%p, %ld, %d, %d, %d, %p, %p, %p (vt=%d))\n", > > + pvInstance, oVft, cc, vtReturn, cActuals, prgvt, prgpvarg, > > + pvargResult, V_VT(pvargResult)); > > You can go up to 100 chars per line, so be free to rearrange this > I could, but the trace line was a cut-and-paste from the i386 path that was already there and I figured consistency in the code was good. > > + > > + if (cc != CC_STDCALL && cc != CC_CDECL) > > + { > > + FIXME("unsupported calling convention %d\n",cc); > > + return E_INVALIDARG; > > + } > > + > > + argspos = 0; > > + rcount = 0; > > + scount = 0; > > + > > + /* Determine if we need to pass a pointer for the return value as arg 0. If so, do that */ > > + /* first as it will need to be in the 'r' registers: */ > > + switch (vtReturn) > > + { > > + case VT_DECIMAL: > > + case VT_VARIANT: > > + regs.r[rcount++] = (DWORD)pvargResult; /* arg 0 is a pointer to the result */ > > + break; > > + case VT_HRESULT: > > + WARN("invalid return type %u\n", vtReturn); > > + return E_INVALIDARG; > > + default: /* And all others are in 'r', 's', or 'd' registers or have no return value */ > > + break; > > + } > > + > > + if (pvInstance) > > + { > > + const FARPROC *vtable = *(FARPROC **)pvInstance; > > + func = vtable[oVft/sizeof(void *)]; > > + regs.r[rcount++] = (DWORD)pvInstance; /* the This pointer is always the first parameter */ > > + } > > + else func = (void *)oVft; > > + > > + /* maximum size for an argument is sizeof(VARIANT). Also allow for return pointer and stack alignment. */ > > + args = heap_alloc(sizeof(VARIANT) * cActuals + sizeof(DWORD) * 4 ); > > + > > + for (i = 0; i < cActuals; i++) > > + { > > + VARIANT *arg = prgpvarg[i]; > > + DWORD *pdwarg = (DWORD *)(arg); /* a reinterpret_cast of the variant, used for copying structures when they are split between registers and stack */ > > + int ntemp; /* Used for counting words split between registers and stack */ > > + > > + switch (prgvt[i]) > > + { > > + case VT_EMPTY: > > + break; > > + case VT_R4: /* these must be 4-byte aligned, and put in 's' regs or stack, as they are single-floats */ > > + if (scount < 16) > > + { > > + regs.sd.s[scount++] = V_R4(arg); > > + } else { > > + args[argspos++] = V_UI4(arg); > > + } > > I think no curly brackets are necessary here at all, but we usually don't > open them in the same line as the if/else statement for new code > Oh sorry. I thought I was being consistent with the rest of the code-base. I have the curly brace on the next line after the 'if', but didn't think about the 'else'. I will fix that and resubmit it. I personally like the curly braces even for single-line statements, though, as it keeps from either misreading it or accidentally adding something for the conditional and forgetting to add them. But I will fix the formatting. > > + break; > > + case VT_R8: /* these must be 8-byte aligned, and put in 'd' regs or stack, as they are double-floats */ > > + case VT_DATE: > > + if (scount < 15) > > + { > > + scount += (scount % 2); /* align scount to next whole double */ > > + regs.sd.d[scount/2] = V_R8(arg); > > + scount += 2; > > + } else { > > + scount = 16; /* Make sure we flag that all 's' regs are full */ > > + argspos += (argspos % 2); /* align argspos to 8-bytes */ > > + memcpy( &args[argspos], &V_R8(arg), sizeof(V_R8(arg)) ); > > + argspos += sizeof(V_R8(arg)) / sizeof(DWORD); > > + } > > + break; > > + case VT_I8: /* these must be 8-byte aligned, and put in 'r' regs or stack, as they are long-longs */ > > + case VT_UI8: > > + case VT_CY: > > + if (rcount < 3) > > + { > > + rcount += (rcount % 2); /* align rcount to 8-byte register pair */ > > + memcpy( &regs.r[rcount], &V_UI8(arg), sizeof(V_UI8(arg)) ); > > + rcount += sizeof(V_UI8(arg)) / sizeof(DWORD); > > + } else { > > + rcount = 4; /* Make sure we flag that all 'r' regs are full */ > > + argspos += (argspos % 2); /* align argspos to 8-bytes */ > > + memcpy( &args[argspos], &V_UI8(arg), sizeof(V_UI8(arg)) ); > > + argspos += sizeof(V_UI8(arg)) / sizeof(DWORD); > > + } > > + break; > > + case VT_DECIMAL: /* these structures are 8-byte aligned, and put in 'r' regs or stack, can be split between the two */ > > + case VT_VARIANT: > > + /* 8-byte align 'r' and/or stack: */ > > + if (rcount < 3) > > + { > > + rcount += (rcount % 2); > > + } else { > > + rcount = 4; > > + argspos += (argspos % 2); > > + } > > + ntemp = sizeof(*arg) / sizeof(DWORD); > > + while (ntemp > 0) > > + { > > + if (rcount < 4) > > + { > > + regs.r[rcount++] = *pdwarg++; > > + } else { > > + args[argspos++] = *pdwarg++; > > + } > > + --ntemp; > > + } > > + break; > > + case VT_BOOL: /* VT_BOOL is 16-bit but BOOL is 32-bit, needs to be extended */ > > + if (rcount < 4) > > + { > > + regs.r[rcount++] = V_BOOL(arg); > > + } else { > > + args[argspos++] = V_BOOL(arg); > > + } > > + break; > > + default: > > + if (rcount < 4) > > + { > > + regs.r[rcount++] = V_UI4(arg); > > + } else { > > + args[argspos++] = V_UI4(arg); > > + } > > + break; > > + } > > + TRACE("arg %u: type %s %s\n", i, debugstr_vt(prgvt[i]), debugstr_variant(arg)); > > + } > > + > > + argspos += (argspos % 2); /* Make sure stack function alignment is 8-byte */ > > + > > + TRACE("rcount: %d, scount: %d, argspos: %d\n", rcount, scount, argspos); > > + > > + switch (vtReturn) > > + { > > + case VT_EMPTY: /* EMPTY = no return value */ > > + case VT_DECIMAL: /* DECIMAL and VARIANT already have a pointer argument passed (see above) */ > > + case VT_VARIANT: > > + call_method( func, argspos, args, (DWORD*)&regs ); > > + break; > > + case VT_R4: > > + V_R4(pvargResult) = call_float_method( func, argspos, args, (DWORD*)&regs ); > > + break; > > + case VT_R8: > > + case VT_DATE: > > + V_R8(pvargResult) = call_double_method( func, argspos, args, (DWORD*)&regs ); > > + break; > > + case VT_I8: > > + case VT_UI8: > > + case VT_CY: > > + V_UI8(pvargResult) = call_method(func, argspos, args, (DWORD*)&regs ); > > + break; > > + default: > > + V_UI4(pvargResult) = call_method( func, argspos, args, (DWORD*)&regs ); > > + break; > > + } > > + heap_free( args ); > > + if (vtReturn != VT_VARIANT) V_VT(pvargResult) = vtReturn; > > + TRACE("retval: %s\n", debugstr_variant(pvargResult)); > > + return S_OK; > > + > > +#elif defined(__i386__) > > int argspos, stack_offset; > > void *func; > > UINT i; > > > > >

2 2

Re: [PATCH 4/4] d3d9/tests: Windows 10 15.07 doesn't detect external mode changes.
by Henri Verbeet Oct. 25, 2017

Oct. 25, 2017

On 19 October 2017 at 10:09, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This fixes this test failure: > http://test.winehq.org/data/9787af34b1c23deb67902fc7dbf2c8421b987048/win10_… > > What I have tried to debug or try to work around this issue: > *) Checked that the resolution is actually changed. It is changed from > 640x480 to 800x600. > *) IDirect3DSwapchain9Ex::GetDisplayModeEx sees the new mode. Calling > this method does not make Present see it though. > *) Replace Present with PresentEx. > *) Call flush_events before calling Present. > > I'm happy to try more ideas, but I think this is just broken in this > Windows build. It is working OK in my 17.03 VM, and I believe it was > working on 16.07 too, but I don't have 16.07 around anymore because it > auto updated to 17.03... Should we update the Windows 10 VMs at some point? Do we want to keep the old versions around?

3 2

Re: [PATCH 3/4] mshtml/tests: Skip postMessage test on IE7.
by Marvin Oct. 24, 2017

Oct. 24, 2017

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=33746 Your paranoid android. === w7pro64 (32 bit htmldoc) === htmldoc.c:3118: Test failed: Incorrect error code: -2146697211 htmldoc.c:3123: Test failed: Page address: L"http://test.winehq.org/tests/winehq_snapshot/" htmldoc.c:5895: Test failed: expected OnChanged_1012 htmldoc.c:5896: Test failed: expected Exec_HTTPEQUIV htmldoc.c:5898: Test failed: expected Exec_SETTITLE htmldoc.c:5939: Test failed: expected FireNavigateComplete2

1 0

Re: [PATCH 2/3] gdiplus: Add internal string format properties used by EMF+ records
by Vincent Povirk Oct. 24, 2017

Oct. 24, 2017

I think the margins in default_drawstring_format should be 1/6. It's not currently used in GdipDrawString or GdipMeasureString, but that's something we may change in the future. Also, they're copied over to generic_default_format which would've had 1/6 margins previously.

1 0

Re: [01/10] secur32: Implement AcquireCredentialsHandle for Kerberos.
by Alexandre Julliard Oct. 24, 2017

Oct. 24, 2017

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > configure.ac | 18 +++ > dlls/secur32/Makefile.in | 2 +- > dlls/secur32/kerberos.c | 276 +++++++++++++++++++++++++++++++++++++++++--- > dlls/secur32/secur32.c | 1 + > dlls/secur32/secur32_priv.h | 1 + > 5 files changed, 282 insertions(+), 16 deletions(-) I liked the idea of putting this in kerberos.dll. Have you given up on this? -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: [PATCH] cmd: Implement builtin mklink command
by Alexandre Julliard Oct. 24, 2017

Oct. 24, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if(hard && !CreateHardLinkW(file1, file2, NULL)) > + WCMD_output_stderr(WCMD_LoadMessage(WCMD_READFAIL), file1); > + else if(!junction && !CreateSymbolicLinkW(file1, file2, isdir)) > + WCMD_output_stderr(WCMD_LoadMessage(WCMD_READFAIL), file1); > + else if(junction) > + WINE_TRACE("Juction links currently not supported.\n"); Surely the options have to be exclusive. It makes no sense to try to create multiple links for the same file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] msxml/tests: Add test for \u escape sequences in regular expressions.
by Nikolay Sivov Oct. 24, 2017

Oct. 24, 2017

On 12.10.2017 22:37, Zebediah Figura wrote: > For bug #43581. > > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > --- > dlls/msxml3/tests/schema.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/dlls/msxml3/tests/schema.c b/dlls/msxml3/tests/schema.c > index ee84b92158..dc65811adb 100644 > --- a/dlls/msxml3/tests/schema.c > +++ b/dlls/msxml3/tests/schema.c > @@ -407,6 +407,15 @@ static const CHAR szOpenSeqXML2[] = "<test><x/><x/><y/><z/><z/><w/></test>"; > static const CHAR szOpenSeqXML3[] = "<test><w/><x/><x/><y/><z/><z/></test>"; > static const CHAR szOpenSeqXML4[] = "<test><x/><x/><y/><z/><z/><v/></test>"; > > +static const CHAR szUnicodeEscapeXDR[] = > +"<schema xmlns='http://www.w3.org/2001/XMLSchema'>" > +" <simpleType name='type1'>" > +" <restriction base='string'>" > +" <pattern value='\\u0020'/>" > +" </restriction>" > +" </simpleType>" > +"</schema>"; > + > #define check_ref_expr(expr, n) { \ > LONG ref = expr; \ > ok(ref == n, "expected %i refs, got %i\n", n, ref); \ > @@ -1154,6 +1163,23 @@ static void test_XDR_schemas(void) Is it XDR "feature" only, that they didn't add to XSDs? > IXMLDOMDocument2_Release(schema); > IXMLDOMSchemaCollection_Release(cache); > > + /* test for \u escapes */ > + schema = create_document_version(60, &IID_IXMLDOMDocument2); > + cache = create_cache_version(60, &IID_IXMLDOMSchemaCollection); > + if (!schema || !cache) > + { > + if (schema) IXMLDOMDocument2_Release(schema); > + if (cache) IXMLDOMSchemaCollection_Release(cache); > + return; > + } Is this really specific to msxml6? It's better to test on all of them to get a full picture, but probably all of them support this extension if 6th does. If you want to skip on unsupported class, just return after first failure, no need to check both pointers. > + > + ole_check(IXMLDOMDocument2_loadXML(schema, _bstr_(szUnicodeEscapeXDR), &b)); > + ok(b == VARIANT_TRUE, "failed to load XML string\n"); > + todo_wine ole_check(IXMLDOMSchemaCollection_add(cache, _bstr_(""), _variantdoc_(schema))); I think it's better to get rid of ole_check(), but it's up to you. > + > + IXMLDOMDocument2_Release(schema); > + IXMLDOMSchemaCollection_Release(cache); > + > free_bstrs(); > } > >

2 1