April 2013 - Wine-devel - list.winehq.org

Re: [PATCH 2/2] winspool.drv: Check the value of pDeviceName.(try 3)
by Marvin 05 Apr '13

05 Apr '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24967 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Trying Battle for Wesnoth in Wine.
by Tae Wong 05 Apr '13

05 Apr '13

You haven’t tried Battle for Wesnoth latest version in Wine on Ubuntu so you have uploaded the about.cfg file to MediaFire which contains over 1000 lines and some un-terminated quoted strings in many names. Check it here (http://www.mediafire.com/?mbw9y2i834z2k7r) Swear at error message (Quoted string not terminated) whilst you fix the un-terminated quoted strings.

2 1

Trying Battle for Wesnoth in Wine.
by Tae Wong 05 Apr '13

05 Apr '13

You haven’t tried Battle for Wesnoth latest version in Wine on Ubuntu so you have uploaded the about.cfg file which contains over 1000 lines and some un-terminated quoted strings in many names.

1 0

[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky 04 Apr '13

04 Apr '13

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 one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four 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 (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD 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_DENYMAND - used to inforce a mandatory share reservation scheme of the file access. If this flag is passed, the open fails with -ETXTBSY in following cases: 1) if O_DENYREAD flag is specified and there is another open with O_DENYMAND flag and READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with O_DENYMAND flag and WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYMAND and O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYMAND and O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ETXTBSY untill this open is closed. Now this flag is processed by CIFS filesystems only. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND -> LOCK_MAND 2) !O_DENYREAD -> LOCK_READ 3) !O_DENYWRITE -> LOCK_WRITE ----- Pavel Shilovsky (7): fcntl: Introduce new O_DENY* open flags vfs: Add O_DENYREAD/WRITE flags support for open syscall CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2 NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS fs/cifs/cifsacl.c | 6 +- fs/cifs/cifsglob.h | 12 +++- fs/cifs/cifsproto.h | 9 +-- fs/cifs/cifssmb.c | 47 ++++++++-------- fs/cifs/dir.c | 14 +++-- fs/cifs/file.c | 18 ++++-- fs/cifs/inode.c | 11 ++-- fs/cifs/link.c | 10 ++-- fs/cifs/readdir.c | 2 +- fs/cifs/smb1ops.c | 15 ++--- fs/cifs/smb2file.c | 10 ++-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +++-- fs/fcntl.c | 5 +- fs/locks.c | 117 +++++++++++++++++++++++++++++++++++---- fs/namei.c | 44 ++++++++++++++- fs/nfs/nfs4xdr.c | 24 ++++++-- fs/nfsd/nfs4state.c | 46 ++++++++++++++- include/linux/fs.h | 6 ++ include/uapi/asm-generic/fcntl.h | 14 +++++ 23 files changed, 345 insertions(+), 101 deletions(-) -- 1.8.1.2

8 36

Re: wined3d: Properly handle backbuffer_width/_height=0 in wined3d_device_reset.
by Henri Verbeet 04 Apr '13

04 Apr '13

Is this really the correct behaviour when windowed is FALSE and the backbuffer width / height is 0? That may just not be allowed at all, but it seems weird to use the window's dimensions in that case, instead of e.g. the current display mode. > if (!swapchain_desc->backbuffer_width || !swapchain_desc->backbuffer_height > || swapchain_desc->backbuffer_width != swapchain->desc.backbuffer_width > || swapchain_desc->backbuffer_height != swapchain->desc.backbuffer_height) Double indent for line continuations, please. > window = swapchain_desc->device_window ? > swapchain_desc->device_window : device->create_parms.focus_window; This is really just the same as "window = swapchain->device_window;". > if(swapchain_desc->backbuffer_width) Space between control statements and '('.

1 0

Re: extrac32: Preprocess command line before passing to CommandLineToArgvW().
by Sergey Guralnik 04 Apr '13

04 Apr '13

On 2013-04-04 15:19, Sergey Guralnik wrote: > Playing with one application, that uses extrac32.exe, > I've found that Wine's extrac32 can't process some > command lines, that cause no problem with native one. > ... > There are two ways to solve this promlem: > - write own parser for extrac32, > - perform some translation for command line before > passing to CommandLineToArgvW(). P.S. Replacing wWinMain() with wmain() doesn't solve this problem. -- Sergey

1 0

Wine Gecko 2.20-beta1
by Jacek Caban 04 Apr '13

04 Apr '13

Hi all, I've uploaded a new Gecko builds to SourceForge [1]. This one is based on Firefox 20 beta and, other than usual update of Gecko, it should fix some crashes like bug b*ug 32753* <http://bugs.winehq.org/show_bug.cgi?id=32753>. To test them, you need recent Wine Git version with the attached patch. As usually, grab the build from SourceForge, put it in the right place [2] and run patched Wine. All help with testing is appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/2.20-beta1/ [2] http://wiki.winehq.org/Gecko

1 1

Re: cmd: Remove a pointless linefeed in an error message.
by Julian Rüger 04 Apr '13

04 Apr '13

Sorry for nagging ;) Wasn't the convention to assume an 80-character wide terminal? This line would wrap, then. So the linefeed is not totally pointless here. Please correct me, if I'm mistaken. Best regards, Julian Am Mittwoch, den 03.04.2013, 16:07 +0200 schrieb Francois Gouget: > --- > programs/cmd/cmd.rc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/cmd/cmd.rc b/programs/cmd/cmd.rc > index c3cdb52..d464cab 100644 > --- a/programs/cmd/cmd.rc > +++ b/programs/cmd/cmd.rc > @@ -360,5 +360,5 @@ Enter HELP <command> for further information on any of the above commands.\n" > WCMD_NOOPERAND, "Expected an operand.\n" > WCMD_NOOPERATOR, "Expected an operator.\n" > WCMD_BADPAREN, "Mismatch in parentheses.\n" > - WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12),\n hexadecimal (0x34) or octal (056).\n" > + WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12), hexadecimal (0x34) or octal (056).\n" > }

2 1

Re: msvcr110: forward __crtSetUnhandledExceptionFilter to kernel32.SetUnhandledExceptionFilter (try 2)
by Dmitry Timoshkov 04 Apr '13

04 Apr '13

Austin English <austinenglish(a)gmail.com> wrote: > Try 2: use cdecl calling convention > -@ stub __crtSetUnhandledExceptionFilter > +@ cdecl __crtSetUnhandledExceptionFilter(ptr) kernel32.SetUnhandledExceptionFilter It's not acceptable to mix calling conventions when forwarding an API with number of arguments != 0. -- Dmitry.

1 0

Re: [PATCH 2/2] winspool.drv: Check the value of pDeviceName.(try 2, resend)
by Marvin 03 Apr '13

03 Apr '13

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 http://testbot.winehq.org/JobDetails.pl?Key=24942 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0