October 2017 - Wine-devel - list.winehq.org

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

22 Nov '20

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 28 Sep '18

28 Sep '18

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 21 Aug '18

21 Aug '18

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 14 Jun '18

14 Jun '18

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 13 Feb '18

13 Feb '18

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 19 Dec '17

19 Dec '17

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 15 Nov '17

15 Nov '17

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 03 Nov '17

03 Nov '17

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 02 Nov '17

02 Nov '17

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 01 Nov '17

01 Nov '17

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