September 2017 - Wine-devel

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

Re: [3/3] ole32: Use a shortcut in DataCache_Save only if fSameAsLoad set to TRUE.
by Huw Davies 19 Oct '17

19 Oct '17

On Wed, Sep 20, 2017 at 02:54:21PM +0300, Dmitry Timoshkov wrote: > This looks like a typo, and this patch makes saving data in a pretty complex > application work. > > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/ole32/datacache.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ole32/datacache.c b/dlls/ole32/datacache.c > index 4e684b4189..c3383176f8 100644 > --- a/dlls/ole32/datacache.c > +++ b/dlls/ole32/datacache.c > @@ -1663,7 +1663,7 @@ static HRESULT WINAPI DataCache_Save( > } > > /* this is a shortcut if nothing changed */ > - if (!dirty && !fSameAsLoad && This->presentationStorage) > + if (!dirty && fSameAsLoad && This->presentationStorage) > { > return IStorage_CopyTo(This->presentationStorage, 0, NULL, NULL, pStg); > } No, this isn't a typo. The idea is to copy the loaded storage to a fresh storage that is passed when fSameAsLoad is FALSE. I'm aware that there are issues related to the storage handling in both the cache and the default handler. That's on my list of things to look into, but feel free to investigate further. Huw.

2 7

Re: [PATCH] server_ioctl_file() - Prefix printed hex values with '0x'
by Alexandre Julliard 12 Oct '17

12 Oct '17

Chris Morgan <chmorgan(a)gmail.com> writes: > Avoids the ambiguity with non-alphanumeric hex values. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > dlls/ntdll/file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index fd7f3dd..4d081b7 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -1567,7 +1567,7 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, > SERVER_END_REQ; > > if (status == STATUS_NOT_SUPPORTED) > - FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + FIXME("Unsupported ioctl 0x%x (device=0x%x access=0x%x func=0x%x method=0x%x)\n", That's mostly a matter of taste, so I don't think it's necessary to change it. -- Alexandre Julliard julliard(a)winehq.org

3 2

Please change WINE logo
by Farhad Mohammadi Majd 11 Oct '17

11 Oct '17

Hello, the current WINE logo is really ugly in highest level! and has no concept, please change it with better one, I have a good sample: https://commons.wikimedia.org/wiki/File:Wine_bw.png It is really beautiful and Window$ logo shows its relationship with M$ Windows, I hope this logo is legal. .

7 17

Wine Swag Sticker Poll
by Aric Stewart 10 Oct '17

10 Oct '17

Hello! So all the way back at wineconf I volunteered to be swag master for winehq. The idea is to have something that can be given away at trade shows, presentations, LUG visits and the like. Just something to help promote the visibility of the project. Jana here, CodeWeavers marketing director, has put together a sampling of designs to do as our first sticker and so now we are looking for some feedback on what people prefer. https://docs.google.com/forms/d/e/1FAIpQLSd5X_fXe9KSFAppRHz8kUo3XKeODyH5KeX… Rosanne? Could you direct me as to where this should be put up for the users as well? I am unfamiliar with how to communicate to our user base. The poll will run for as long as it feels like it needs to get some sort of winner. Comments and suggestions are always welcome! -aric

7 10

Re: [PATCH] midimap: Add warning for user in case midi won't work
by Matteo Bruni 29 Sep '17

29 Sep '17

2017-09-23 22:52 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > When no midi port or only the midi-through port > is found, we can inform the user that midi > won't work as expected. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/midimap/midimap.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/midimap/midimap.c b/dlls/midimap/midimap.c > index 64b4dc8546..c80834515b 100644 > --- a/dlls/midimap/midimap.c > +++ b/dlls/midimap/midimap.c > @@ -553,6 +553,7 @@ static LRESULT MIDIMAP_drvOpen(void) > { > MIDIOUTCAPSW moc; > unsigned dev, i; > + WCHAR throughportW[] = {'M','i','d','i',' ','T','h','r','o','u','g','h',0}; > > if (midiOutPorts) > return 0; > @@ -578,6 +579,13 @@ static LRESULT MIDIMAP_drvOpen(void) > } > } > > + if(numMidiOutPorts == 0) > + MESSAGE("Midi sound output won't work - No midi port found.\n"); > + else if(numMidiOutPorts == 1 && midiOutPorts[0].loaded == -1) > + MESSAGE("Midi sound output won't work - No working midi port found.\n"); > + else if(numMidiOutPorts == 1 && strncmpW(midiOutPorts[0].name, throughportW, strlenW(throughportW)) == 0) > + MESSAGE("Midi sound output probably won't work - Only 'midi through' port found. Make sure your setup is correct.\n"); > + > return 1; > } Since you have to resend anyway... The string comparison doesn't look correct to me, I think that breaks if the midi port name has a prefix matching the throughportW string. I guess it's not going to be a problem in practice but it seems better to do it right anyway. There should be a space between 'if' and the '(', like elsewhere in the function and source file.

2 3