wine-devel January 2014

wine-devel@winehq.org

56 participants
177 discussions

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

IMM / IME work
by Aric Stewart 16 Jun '16

16 Jun '16

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger 05 Jul '15

05 Jul '15

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard 23 Apr '15

23 Apr '15

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: configure: Add -linotify when present, for non-Linux platforms.
by Alexandre Julliard 23 Aug '14

23 Aug '14

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

2 1

What happened to the Fedora packages?
by Neal Gompa 02 Aug '14

02 Aug '14

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

Fixing conflicts between WineD3D and WGL
by Ken Thomases 28 Apr '14

28 Apr '14

Hi, This email brings together several threads of conversation that have been spread across different bug reports. Sorry for the length. The problem: WineD3D is based on WGL (a.k.a. opengl32). As a consequence, it conflicts with application use of WGL in a number of ways. It's also limited by WGL, which doesn't allow for all of the behaviors of DirectDraw and Direct3D. https://bugs.winehq.org/show_bug.cgi?id=28869 WineD3D needs to make its own GL context current temporarily and then restore the previous GL context, but WGL requires a DC to restore it and the DC may no longer be valid. https://bugs.winehq.org/show_bug.cgi?id=29301 WineD3D changes the window style of the device window when it should not. It needs to do that in order to render to the full screen where WGL only allows full-featured rendering to a window. https://bugs.winehq.org/show_bug.cgi?id=2082 Again, WineD3D is rendering to a window when it wants to render full-screen. In this case, the affected apps create an owned window that sits in front of the device window, obscuring it. http://bugs.winehq.org/show_bug.cgi?id=29934 WineD3D sets a pixel format on the application window. This conflicts with a later attempt by the app to set a different pixel format on the window via WGL. I think the solution to these problems is for WineD3D to have an alternative path to set up its GL context. Henri and I have been discussing using Wine-specific extensions to WGL to do this. There's already the extension WGL_WINE_pixel_format_passthrough which provides the wglSetPixelFormatWINE() function which is just like GDI's SetPixelFormat() and WGL's wglSetPixelFormat() except it allows for changing the pixel format after it's been set once. WineD3D needs to change it even though WGL doesn't allow that. In some of the bug reports listed above, I've suggested adding new extensions or modifying WGL_WINE_pixel_format_passthrough. We probably need a more comprehensive approach. WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. I'm not sure that's achievable but we should at least minimize such visible state changes to the extent we can. WGL state: * The DC pixel format. For window DCs (which I believe are the only ones of real interest), this is actually a property of the window, not the DC. Changed by SetPixelFormat(), wglSetPixelFormat(); exposed by GetPixelFormat(), wglGetPixelFormat(). * The current GL context for the thread. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentContext(). * The DC for the current GL context. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentDC(), wglGetCurrentReadDCARB(). The most important things to achieve are a) to not "consume" the only opportunity the app has to set the window's pixel format, and b) to restore the app's current GL context (and implicitly its DC) when returning control to it. I don't think it's necessary to avoid WineD3D ever changing WGL's notion of the current context. Certainly, while a WineD3D GL context is current, GL functions like glClear() will operate on WineD3D's context. If the app thinks its context is current and calls GL functions, its context better really be current. So, WineD3D really needs to restore the app's context before returning control (and it generally does, I think). If it's going to do that, then wglGetCurrentContext() will take care of itself. Same for wglGetCurrentDC(). Here's my proposal: Extension WGL_WINE_surface: HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); // if hdc is GetDC(<some normal window>), a window surface is created // if hdc is GetDC(0), GetDC(GetDesktopWindow()), or CreateDC("display", …), a full-screen surface is created. // once the surface is created, it no longer refers to hdc void wglDestroySurfaceWINE(HANDLE surface); HDC wglGetSurfaceDCWINE(HANDLE surface); // Returns a DC created for the surface. This is not the DC passed in to wglCreateSurfaceWINE(). void wglReleaseSurfaceDCWINE(HANDLE surface, HDC hdc); This is somewhat modeled on WGL_ARB_pbuffer. <http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt> A surface represents a "place" where GL can render, a potential target for a context. It can correspond to a Win32 window or it can be a full-screen surface. A full-screen surface will likely be a platform window (X11 or Mac) managed by the graphics driver but won't be a Win32 window. It should not interfere with mouse events or focus. A surface has a pixel format, similar to a window. Even if the surface was created from a window DC, its pixel format is independent of the window's. Since a surface is created with a pixel format, it shouldn't be necessary to set one with SetPixelFormat() on a surface DC. If it helps keep WineD3D's code simpler, we could allow it. I'm not sure if it will be necessary to support changing the pixel format after it's been set, using wglSetPixelFormatWINE(), or if the surface should just be destroyed and recreated as necessary. Doing the latter may eventually allow the removal of wglSetPixelFormatWINE(). The lifetime of a surface controls whatever resources the graphics driver has to manage for it. For a normal window, this may include a drawable. For a full-screen surface, this would include any full-screen platform window it might have created. WineD3D would obtain a DC from a surface using wglGetSurfaceDCWINE() just as it now obtains one for a window using GetDC(). There can be multiple DCs for a given surface. In particular, a DC can only be used on a single thread, so multiple threads would each have to get their own DC. The different lifetimes of surfaces vs. surface DCs is why this proposal differs from my approach in bug 2082, where I proposed an extension which just added full-screen DCs without a corresponding full-screen surface object. Destroying a surface while it still has extant surface DCs results in undefined behavior. Once WineD3D has a surface DC, it should be able to work with it as it currently does with window DCs. wglMakeCurrent() with a surface DC will associate the context with the surface drawable. For a surface created from a window, this would work as it does now in the graphics drivers with the exception of how the drawable is looked up from the DC. For a full-screen surface, this would target whatever full-screen drawable the graphics driver provides (possibly a platform window). There's a wrinkle having to do with the pixel format. User32 and the wineserver use the fact that a window has a pixel format to compute the "surface region" for the top-level window. This is a different "surface" than the concept central to this proposal. This "surface" is used for client-side GDI rendering using the DIB engine. Maintaining a surface region is necessary to prevent the contents of the window surface buffer from being blitted on top of any 3D rendering done to the window. To keep that functioning, the graphics drivers will still have to inform user32 that 3D rendering is being done to the window. It can do that using the existing mechanism, but that's not currently reversible because it's tied to the pixel format and that's a permanent property of a window. We'd like it to be reversible, since WineD3D can stop targeting a window. I'm thinking of using a count in user32. Extension WGL_WINE_make_current: BOOL wglMakeContextCurrentWINE(HGLRC hglrc); The standard WGL function wglMakeCurrent() combines two operations. It sets the a GL context's drawable to the provided DC and it makes the GL context current for the thread. This new function, wglMakeContextCurrentWINE(), would only do the latter. It would make a GL context current for the thread without changing which DC it's associated with. Both the X11 and Mac drivers already maintain the necessary state to do that. They don't need to have the DC passed in again. (If a GL context is associated with separate draw and read DCs using wglMakeContextCurrentARB(), then this function will leave it associated with both DCs.) This allows WineD3D to faithfully restore the app's previously-current WGL context. This addresses bug 28869. I considered some other designs but I don't think they work well. I looked for a way to do without special DCs. We could directly specify a pixel format when creating a context rather than getting it from the window or surface via the DC. We could make a context current directly on a surface rather than a surface DC. Unfortunately, too much of WGL depends on having a DC. For example, ChoosePixelFormat() and wglSwapBuffers(). What do folks think? Any feedback would be appreciated. -Ken

7 21

Cross-regressions between wine and mesa: how to handle them?
by Ruslan Kabatsayev 17 Mar '14

17 Mar '14

Hi all, I've come across a problem, which may be simplest to see in the following workability diagram, tested on GTAVC on a i915 machine: _____________________________________________ Mesa_\_Wine_|__1.3.21__|__1.5.17__|__1.5.24+_| ____9.0_____|____OK____|____OK____|___slow___| ___~9.1-____|____OK____|___slow___|___slow___| ___~9.1+____|____OK____|_GL_error_|_GL_error_| Here ~9.1- and ~9.1+ are bisected commits between 9.0 and 9.1, with "-" earlier commit and "+" later one. "slow" means slide show instead of normal animation. "GL error" is a set of errors like "err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ device.c / 677". Wine version 1.5.24+ means any wine newer than 1.5.24 up to 1.7.11. All these things are related to wine trying to use GLSL as much as possible, and Mesa trying to make it seem that it supports OpenGL 2+, even on chips like i915, which don't support it. For end user this looks like failing software, and moreover, it's not easy to understand which software does have bug. Wine perspective: On the one hand, wine seems to use what Mesa exposes. On the other, why use shaders for games which don't need them? Mesa perspective: On the one hand, it wants to advertise more support for latest OpenGL standards. On the other, why do it for very old HW which doesn't support it? So, I'm not sure where I should report these regressions - to bugs.winehq.org or to bugs.freedesktop.org? I remember some similar bugs reported to wine being closed as UPSTREAM (e.g. bug 33964), and fixed (or worked around?) in Mesa. But on the other hand, wine 1.3 worked perfectly for all Mesa versions - is it really Mesa fault that newer versions of wine don't work? Could someone please explain how to handle such situations? Regards, Ruslan

4 13

[PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky 04 Feb '14

04 Feb '14

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why extra mount option 'sharelock' is added for switching on/off O_DENY* flags processing. It allows to avoid use of these flags on critical places (like /, /lib) and turn them on if we really want it proccessed that way. So, we have 3 new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations The patchset avoids data races problem on newely created files: open with O_CREAT can return the -ESHAREDENIED error for a successfully created file if this files was locked with a sharelock by another task. Also, it turns flock/LOCK_MAND capability off for mounts with 'sharelock' option. This lets not mix one share reservation approach with another. Patches #1, #2 and #3 add O_DENY* flags to fcntl and implement VFS part. A patch #4 is related to CIFS client changes, #5 -- NFSD, #6 and #7 describe NFSv4 client parts. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- O_DENYREAD, O_DENYWRIYE, O_DENYDELETE - used to inforce a mandatory share reservation scheme of the file access. If these flag is passed, the open fails with -ESHAREDENIED in following cases: 1) if O_DENYREAD flag is specified and there is another open with READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ESHAREDENIED untill this open is closed. Now this flag is processed by VFS and CIFS filesystem. NFS returns -EINVAL for opens with this flag. This mechanism is done through flocks. If O_DENY* flags are specified, flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) !O_DENYREAD -> LOCK_READ | LOCK_MAND 2) !O_DENYWRITE -> LOCK_WRITE | LOCK_MAND 3) !O_DENYDELETE -> LOCK_DELETE | LOCK_MAND ----- Pavel Shilovsky (7): VFS: Introduce new O_DENY* open flags VFS: Add O_DENYDELETE support for VFS locks: Disable LOCK_MAND support for MS_SHARELOCK mounts CIFS: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS NFSv4: Add deny state handling for nfs4_state struct NFSv4: Add O_DENY* open flags support arch/alpha/include/uapi/asm/errno.h | 2 + arch/alpha/include/uapi/asm/fcntl.h | 3 + arch/mips/include/uapi/asm/errno.h | 2 + arch/parisc/include/uapi/asm/errno.h | 2 + arch/parisc/include/uapi/asm/fcntl.h | 3 + arch/sparc/include/uapi/asm/errno.h | 2 + arch/sparc/include/uapi/asm/fcntl.h | 3 + fs/cifs/cifsacl.c | 2 + fs/cifs/cifsfs.c | 2 +- fs/cifs/cifsglob.h | 17 +- fs/cifs/cifssmb.c | 2 +- fs/cifs/dir.c | 6 + fs/cifs/file.c | 20 ++- fs/cifs/inode.c | 12 +- fs/cifs/link.c | 2 + fs/cifs/netmisc.c | 2 +- fs/cifs/smb1ops.c | 3 + fs/cifs/smb2inode.c | 1 + fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 6 + fs/cifs/smb2pdu.c | 2 +- fs/fcntl.c | 5 +- fs/locks.c | 161 ++++++++++++++++-- fs/namei.c | 56 +++++- fs/nfs/dir.c | 39 ++++- fs/nfs/inode.c | 8 +- fs/nfs/internal.h | 3 +- fs/nfs/nfs4_fs.h | 83 ++++++++- fs/nfs/nfs4file.c | 8 +- fs/nfs/nfs4proc.c | 310 +++++++++++++++++++++++----------- fs/nfs/nfs4state.c | 65 ++++--- fs/nfs/nfs4super.c | 9 +- fs/nfs/nfs4xdr.c | 21 ++- fs/nfs/super.c | 7 +- fs/nfsd/nfs4state.c | 46 ++++- fs/nfsd/nfsproc.c | 1 + fs/proc_namespace.c | 1 + include/linux/fs.h | 15 ++ include/linux/nfs_fs.h | 5 +- include/linux/nfs_xdr.h | 1 + include/uapi/asm-generic/errno.h | 2 + include/uapi/asm-generic/fcntl.h | 12 ++ include/uapi/linux/fs.h | 1 + 43 files changed, 789 insertions(+), 166 deletions(-) -- 1.7.10.4

4 18

dpnet patches
by Stefan Dösinger 01 Feb '14

01 Feb '14

Hi Alistair, A while ago I promised to have a closer look at your dpnet patches. It’s a bit delayed, but here are some comments. How serious are you about dplay? Do you intend to do more work towards implementing it, or is that just wishful thinking on my part? http://source.winehq.org/patches/data/101857: The entire patch doesn’t do all that much, I think it’s best to hold of on that change until the function is meaningfully implemented - unless having a proper return value helps you in some way I’m missing. > + void *buffer = malloc(256); Please use HeapAlloc / HeapFree. http://source.winehq.org/patches/data/101856: > +DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); Isn’t that defined somewhere already? Do you need GUID_NULL to signal an uninitialized GUID? Is there a reason why setting the pointer to NULL doesn’t work? > -IMPORTS = dpnet ole32 > +IMPORTS = ole32 I’m not sure about this one, but winetest can automatically skip tests if the tested DLL doesn’t exist. It might use the imported libraries for that, or maybe just the name of the test. In the former case I think you want to keep the dpnet import. http://source.winehq.org/patches/data/101855: http://source.winehq.org/patches/data/101854: Did you think about sharing code between IDirectPlay8Peer and IDirectPlay8Server? The interfaces themselves have no relationship, but their methods are similar. http://source.winehq.org/patches/data/101853: > +typedef struct IDirectPlay8ClientImpl > +{ > + IDirectPlay8Client IDirectPlay8Client_iface; > + LONG ref; > +} IDirectPlay8ClientImpl; Are you sure you want to move the definition out of the library-wide header? If that works out ok it’s great, but you may need something other than the public interface in some other files in this library. I recommend to work without the typedef, but that should be changed in a separate patch. > - ULONG refCount = InterlockedIncrement(&This->ref); > + ULONG ref = InterlockedIncrement(&This->ref); > - TRACE("(%p)->(ref before=%u)\n", This, refCount - 1); > + TRACE("(%p) ref=%d\n", This, ref); ULONG is unsigned, you have to use %u. http://source.winehq.org/patches/data/101852 > + 'DPNSPModemModem' > + { > + val 'Friendly Name' = s 'Modem Connection For DirectPlay' > + val 'GUID' = s '{6D4A3650-628D-11D2-AE0F-006097B01411}' > + } > + > + 'DPNSPModemSerial' > + { > + val 'Friendly Name' = s 'Serial Connection For DirectPlay' > + val 'GUID' = s '{743B5D60-628D-11D2-AE0F-006097B01411}' > + } I know that those always exist on Windows, but wouldn’t it be better to not advertise them until we have an actual implementation? I think advertising DPNSPWinsockTCP alone should be ok for the start.

2 1

spam filtering errors
by Jonas Maebe 31 Jan '14

31 Jan '14

Hi, Since the latest update of the mailing list server, a lot of mails sent to this list are wrongly classified as spam by CodeWeavers' mail server. I've already sent a mail about this to postmaster(a)codeweavers.com several months ago, but got no reply and nothing appears to have changed. It seems that the main culprit is the "SINGLE_HEADER_3K" spamassassin check, in combination with a very low spam score threshold (1.0). Below is an example from Stefan Dösinger's last mail (titled "dpnet patches"). Jonas X-Spam-Flag: YES X-Spam-Report: Spam detection software, running on the system "wine.codeweavers.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Alistair, A while ago I promised to have a closer look at your dpnet patches. ItXs a bit delayed, but here are some comments. How serious are you about dplay? Do you intend to do more work towards implementing it, or is that just wishful thinking on my part? [...] Content analysis details: (1.1 points, 1.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefandoesinger[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

3 2

Re: user32/tests: Don't compare boolean expressions with TRUE or FALSE
by Marvin 31 Jan '14

31 Jan '14

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://newtestbot.winehq.org/JobDetails.pl?Key=4560 Your paranoid android. === wxppro (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0005013E fg 00030052 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === wvista (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000602B4 fg 00020222 in hook HCBT_ACTIVATE === w2008s64 (32 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 000600F0 fg 0001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 00000000 win.c:2952: Test failed: GetFocus() = 00000000 win.c:2975: Test failed: GetActiveWindow() = 00000000 win.c:2975: Test failed: GetFocus() = 00000000 win.c:3036: Test failed: GetActiveWindow() = 00000000 win.c:3036: Test failed: GetFocus() = 00000000 === w2008s64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 00000000000600F0 fg 000000000001004E in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000 === w7pro64 (64 bit win) === win.c:892: Test failed: wrong dwWindowStatus: 0001 != 0000 active 0000000000060106 fg 0000000000010064 in hook HCBT_ACTIVATE win.c:2952: Test failed: GetActiveWindow() = 0000000000000000 win.c:2952: Test failed: GetFocus() = 0000000000000000 win.c:2975: Test failed: GetActiveWindow() = 0000000000000000 win.c:2975: Test failed: GetFocus() = 0000000000000000 win.c:3036: Test failed: GetActiveWindow() = 0000000000000000 win.c:3036: Test failed: GetFocus() = 0000000000000000

1 0

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior (try2)
by Marvin 30 Jan '14

30 Jan '14

1 0

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior
by Alexandre Julliard 30 Jan '14

30 Jan '14

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > --- > dlls/oleaut32/recinfo.c | 75 +++++++++++++++++++++- > dlls/oleaut32/tests/test_tlb.idl | 6 +- > dlls/oleaut32/tests/vartype.c | 130 +++++++++++++++++++++++++++++++++++++++ > dlls/oleaut32/usrmarshal.c | 3 +- > dlls/oleaut32/variant.h | 2 +- > 5 files changed, 210 insertions(+), 6 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M oleaut32.dll -p oleaut32_test.exe.so typelib && touch typelib.ok typelib.c:3977: Test failed: typeattr->cbSizeInstance expected 4 got 16 make: *** [typelib.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] wmp: Added tests.
by Marvin 30 Jan '14

30 Jan '14

1 0

Re: [3/4] msxml3: Add separate QueryInterface implementation for IEnumVARIANT interface exported by IXMLElementCollection. Resend.
by Henri Verbeet 30 Jan '14

30 Jan '14

On 30 January 2014 06:07, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > + FIXME("interface %s not implemented\n", debugstr_guid(riid)); > + return E_NOINTERFACE; I don't know about xmlelem_collection_IEnumVARIANT_QueryInterface() specifically, but in general QueryInterface() should set *ppvObj to NULL on failure.

1 0

Re: wininet: InternetGetConnectedStateExW must return TRUE for success (try 2)
by Henri Verbeet 30 Jan '14

30 Jan '14

On 29 January 2014 23:01, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Citavi relies on == TRUE comparison so return TRUE instead of != FALSE > I think that in general this kind of change benefits from a comment indicating that the extra compare is on purpose, mostly to avoid someone from removing it again in the future.

2 1

Re: [2/2] kernel32: Don't leak extrabuf when HeapReAlloc fails
by Henri Verbeet 30 Jan '14

30 Jan '14

On 29 January 2014 23:41, André Hentschel <nerv(a)dawncrow.de> wrote: > - extrabuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize ) ; > + if (newbuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize )) > + extrabuf = newbuf; > + else > + break; This will introduce a warning: computername.c: In function ‘dns_gethostbyname’: computername.c:90:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses] I happen to think + if (!(newbuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize ))) + break; + extrabuf = newbuf; would be slightly nicer anyway.

1 0

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior
by Marvin 30 Jan '14

30 Jan '14

2 1

Re: mshtml/tests: Use common wine_dbgstr_guid implementation from test.h (resend)
by Marvin 30 Jan '14

30 Jan '14

1 0

Re: [PATCH] shell32: Older shell32 doesn't support CSIDL_PROGRAM_FILES
by Alexandre Julliard 29 Jan '14

29 Jan '14

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > This should fix the failing NT4 tests. > > These tests are _really_ old, like 2005. I'm surprised they haven't > been fixed by now. Is there something I'm missing? They should probably have been fixed back then, but at this point NT4 isn't worth the trouble anymore, we should simply get rid of it in the test results. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] winhttp/tests: Only advance to the next notification test if the function is ok.
by Marvin 29 Jan '14

29 Jan '14

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://newtestbot.winehq.org/JobDetails.pl?Key=4521 Your paranoid android. === wvista (32 bit notification) === notification.c:363: Test failed: failed to receive response 12029 notification.c:368: Test failed: request failed unexpectedly 0 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 441: expected status 0x00000008 got 0x00200000 notification.c:99: Test failed: 447: expected status 0x00000008 got 0x00200000 notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 2293700 notification.c:460: Test failed: failed to query data available 12019 Timeout === w7pro64 (32 bit notification) === notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 2686916 notification.c:460: Test failed: failed to query data available 12019 Timeout === w2008s64 (64 bit notification) === notification.c:359: Test failed: failed to send request 12029 notification.c:363: Test failed: failed to receive response 12017 notification.c:367: Test failed: failed unexpectedly 12019 notification.c:368: Test failed: request failed unexpectedly 4 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 === w7pro64 (64 bit notification) === notification.c:359: Test failed: failed to send request 12002 notification.c:363: Test failed: failed to receive response 12019 notification.c:368: Test failed: request failed unexpectedly 4 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:100: Test failed: 370: expected function 3 got 8

1 0

Re: [1/2] winhttp/tests: Ignore some missing notifications.
by Marvin 29 Jan '14

29 Jan '14

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://newtestbot.winehq.org/JobDetails.pl?Key=4520 Your paranoid android. === wvista (32 bit notification) === notification.c:363: Test failed: failed to receive response 12029 notification.c:368: Test failed: request failed unexpectedly 0 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 4 got 8 notification.c:99: Test failed: 441: expected status 0x00000008 got 0x00200000 notification.c:99: Test failed: 447: expected status 0x00000008 got 0x00200000 notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 2293700 notification.c:460: Test failed: failed to query data available 12019 Timeout === w2008s64 (64 bit notification) === notification.c:359: Test failed: failed to send request 12029 notification.c:363: Test failed: failed to receive response 12017 notification.c:367: Test failed: failed unexpectedly 12019 notification.c:368: Test failed: request failed unexpectedly 4 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 370: expected status 0x00000008 got 0x00000800 notification.c:100: Test failed: 370: expected function 3 got 8 notification.c:99: Test failed: 441: expected status 0x00000008 got 0x00200000 notification.c:99: Test failed: 447: expected status 0x00000008 got 0x00200000 notification.c:455: Test failed: failed unexpectedly 12019 notification.c:456: Test failed: request failed unexpectedly 0 notification.c:460: Test failed: failed to query data available 12019 Timeout === w7pro64 (64 bit notification) === notification.c:100: Test failed: 447: expected function 3 got 4

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2014