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

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: include: Avoid overflow (warning) in RGBA_MAKE.
by Dmitry Timoshkov 26 Feb '17

26 Feb '17

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/include/d3dtypes.h > +++ b/include/d3dtypes.h > @@ -53,7 +53,7 @@ typedef LONG D3DFIXED; > #define RGBA_GETRED(rgb) (((rgb) >> 16) & 0xff) > #define RGBA_GETGREEN(rgb) (((rgb) >> 8) & 0xff) > #define RGBA_GETBLUE(rgb) ((rgb) & 0xff) > -#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | ((g) << 8) | (b))) > +#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((unsigned)(a) << 24) | ((r) << 16) | ((g) << 8) | (b))) This is a public header, probably you need to fix the callers of this macro instead. -- Dmitry.

3 4

Re: kernel32: Avoid two potential buffer overflows of cStr in create_hardware_branch.
by Sebastian Lackner 12 Feb '17

12 Feb '17

On 08.10.2016 22:31, Gerald Pfeifer wrote: > + char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)], http://man7.org/linux/man-pages/man3/readdir.3.html says: """The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)""" This means your solution will not work on all systems.

3 4

TestBot news
by Francois Gouget 20 Jan '17

20 Jan '17

I have upgraded Debian on vm1 from 7 to 8.6 and the filesystem from ext3 to ext4. This gets it a non-antique version of the kernel and QEMU which includes Huw's fix for the ntdll:exception test. So there should be one less unfixable failure for VMs being run on vm1. That said I'm not really happy with the state of things on vm1: for some reason its reverts are much slower than they should be. For instance with the wvista VM doing 3 reverts in a row on otherwise idle machines gives me: vm1 56.361s 46.803s 46.569s vm2 10.206s 9.783s 9.912s vm3 9.583s 8.137s 8.004s One could think that vm2 has much better hardware but that's just not the case: PassMark Disk Disk Host CPU MT ST Type Speed vm1 Xeon E3-1230v2 8855 1940 HD 130 MB/s vm2 Opteron 6128 6959 n/a HD Raid0 144 MB/s vm3 Xeon E3-1226v3 7462 2127 SSD 354 MB/s All hosts have 16 GB of RAM. So vm2 has what looks like a somewhat slower processor and a marginally faster disk thanks to Raid0. That should not be sufficient for it to be 4 times faster, particularly given that vm3 has a disk that's over twice as fast is only marginally faster than vm2. Indeed during the revert vm1 shows no read traffic (lots of RAM to cache that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just uses CPU for the last ~4 seconds. vm3 also shows it's not an AMD vs Intel thing. There may be some missing CPU feature on vm1 but if that's the case I don't see what. So there is still a mystery there and if anyone has an insight into it it would be appreciated. Despite that I have put vm1 back to active duty. But I decided to keep the wvistau64 VM on the vm2 host. This means vm1 essentially only has one VM to take care of and since most of the time it's going to be idle already it should not slow jobs down. I also applied all Windows updates up to 2016/07/25 to the w7u VM. This caused some new failures that Hans started tackling / fixed. Any other new failure on the 3 VMs affected by the upgrade (wvista, wvistau64 and w7u) should be fixable. The configuration of the other two vms, wvista and wvistau64 should be essentially unchanged. Finally I also performed a minor upgrade on vm3: from Debian 8.2 to 8.6. The goal was to see if the minor QEMU upgrade would be sufficient to get Windows 10 to stop crashing when running WineTest. It looks like that's not the case. So the next step will be to grab QEMU 2.7 from the Debian BackPorts but there's a dumb command line incompatibility with libvirt 1.2.9 and there's no easily installable alternative :-( Fortunately I have a qemu wrapper script that should bridge the gap. -- Francois Gouget <fgouget(a)codeweavers.com>

4 9

Wine and Valgrind / handling SIGILL
by Austin English 20 Jan '17

20 Jan '17

Howdy all, Several months ago, a patch from Sebastian: commit 44fbc018eda12bdee5c2c1e2e40dbdc6a81b27fd Author: Sebastian Lackner <sebastian(a)fds-team.de> Date: Thu Feb 12 11:09:34 2015 +0100 winebuild: Do not access memory below ESP when restoring thread contexts. Based on a patch by John Reiser. for https://bugs.winehq.org/show_bug.cgi?id=14367 Caused problems for running Wine under Valgrind: https://bugs.kde.org/show_bug.cgi?id=344139 There are patches floating around for both Wine and Valgrind (see previous link), but from what I've seen so far, both projects aren't a fan of the current patches. Given that Wine developers like using Valgrind to check for problems, and I know Julian would like to use Wine with Valgrind, I feel like some solution to this problem can be found. Since my efforts at trying to run messages between the two projects hasn't solved it yet, I figured an email thread would work better ;). -- -Austin GPG: 14FB D7EA A041 937B

3 7

[v2 0/7] x86: enable User-Mode Instruction Prevention
by Ricardo Neri 03 Jan '17

03 Jan '17

This is v2 of my first submission done a while ago[1]. I apologize for the delay. User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[2]. For instance, these applications rely on sidt returning a non- accesible memory location[3]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The concensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[4] does not support applications that use these instructions. It relies on WineHQ for this[4]. Furthermore, the applications for which the concern was raised run in protected mode [3]. This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return a base address to a dummy location in kernel memory and a limit of 0. * STR, SLDT returns 0 as the segment selector. This seems OK since we are providing a dummy value as the base address of the global descriptor table. * SMSW returns 0. Lastly, I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate file that both MPX and UMIP can access and avoid code duplication. While here, I fixed two small bugs that I found in the MPX implementation. The code that I used to test the emulated instructions can be found in [6]. [1]. https://lwn.net/Articles/705877/ [2]. https://www.winehq.org/ [3]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [4]. http://www.dosemu.org/ [5]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [6]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… Thanks and BR, Ricardo Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Liang Z Li <liang.z.li(a)intel.com> Cc: x86(a)kernel.org Cc: linux-msdos(a)vger.kernel.org Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Ricardo Neri (7): x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Fail when implicit zero-displacement is used along with R/EBP x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention arch/x86/Kconfig | 10 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn.h | 6 + arch/x86/include/asm/umip.h | 16 +++ arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 ++- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 170 ++++++++++++++++++++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-utils.c | 148 ++++++++++++++++++++++++ arch/x86/mm/mpx.c | 119 +------------------ 13 files changed, 382 insertions(+), 121 deletions(-) create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-utils.c -- 2.9.3

5 30

Emitting aligned SSE movs in gcc with force_align_arg_pointer
by Daniel Santos 31 Dec '16

31 Dec '16

I'm working on a few improvements in GCC targeting 64-bit Wine. I've got a patch set that gives us back aligned SSE movs for 64-bit ms_abi functions that call System V functions. However, it looks like I'll have to wait until GCC 8's stage 1 comes around (https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01924.html) but I thought I should post this here to prevent any duplication of effort. (Come to think of it, I should probably open a gcc bug report for this.) Following this patch set I have the out-of-lining patch set for the msabi/sysv prologues & epilogues as well that I'm still refining and cleaning up a bit. Happy New Year all! Daniel

1 0

Re: [2/3] ntdll: Implement FileIdInformation class support in NtQueryInformationFile.
by Nikolay Sivov 31 Dec '16

31 Dec '16

On 31.12.2016 16:50, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > dlls/ntdll/file.c | 19 ++++++++++++++++++- > include/winternl.h | 9 +++++++++ > 2 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 6eddd19..fbadfbd 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2379,7 +2379,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileRenameInformationBypassAccessCheck */ > 0, /* FileLinkInformationBypassAccessCheck */ > 0, /* FileVolumeNameInformation */ > - 0, /* FileIdInformation */ > + sizeof(FILE_ID_INFORMATION), /* FileIdInformation */ > 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > 0, /* FileHardLinkFullIdInformation */ > @@ -2621,6 +2621,23 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > } > } > break; > + case FileIdInformation: > + { > + struct statfs volstats; > + FILE_ID_INFORMATION *info = ptr; > + if ((fstat(fd, &st) == -1) || (fstatfs(fd, &volstats) == -1)) > + { > + io->u.Status = FILE_GetNtStatus(); > + } > + else > + { > + memset(info, 0, sizeof(*info)); > + ((PLARGE_INTEGER)&info->VolumeSerialNumber)->LowPart = (ULONG)volstats.f_fsid.__val[0]; > + ((PLARGE_INTEGER)&info->VolumeSerialNumber)->HighPart = (ULONG)volstats.f_fsid.__val[1]; > + ((PLARGE_INTEGER)&info->FileId)->QuadPart = st.st_ino; > + } > + } > + break; > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > diff --git a/include/winternl.h b/include/winternl.h > index 891b6a7..2f2ea86 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -571,6 +571,15 @@ typedef struct _FILE_INTERNAL_INFORMATION { > LARGE_INTEGER IndexNumber; > } FILE_INTERNAL_INFORMATION, *PFILE_INTERNAL_INFORMATION; > > +typedef struct _FILE_ID_128 { > + UCHAR Identifier[16]; > +} FILE_ID_128, *PFILE_ID_128; Windows SDK has it in winnt.h, using BYTE instead of UCHAR. > + > +typedef struct _FILE_ID_INFORMATION { > + ULONGLONG VolumeSerialNumber; > + FILE_ID_128 FileId; > +} FILE_ID_INFORMATION, *PFILE_ID_INFORMATION; > + This one should go to winbase.h, as FILE_ID_INFO. > typedef struct _FILE_EA_INFORMATION { > ULONG EaSize; > } FILE_EA_INFORMATION, *PFILE_EA_INFORMATION;

2 1