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

Re: d3dx9 [patch 1/2, resend]: Floatify fabs into fabs
by Matteo Bruni 08 Apr '13

08 Apr '13

2013/4/7 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: > Both patches are fine for me (note that the email subject is missing an "f" but the actual patch has the correct title).

1 0

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

08 Apr '13

Main changes from the previous one: 1) O_DENYMAND is removed, sharelock mount option is introduced. 2) Patch fcntl.h and VFS patches are united into one. 3) flock/LOCK_MAND is disabled for sharelock mounts. 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 us 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 (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), The patchset avoid data races problem 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. Also, it turns flock/LOCK_MAND capability off for mounts with 'sharelock' option. This let us not mix one share reservation approach with another. The #1 patch adds flags to fcntl and 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_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 -EBUSY 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 -EBUSY untill this open is closed. Now this flag is processed by CIFS filesystems only. 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 ----- Pavel Shilovsky (7): fcntl: Introduce new O_DENY* open flags CIFS: Add share_access parm to open request CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS locks: Disable LOCK_MAND support for MS_SHARELOCK mounts fs/cifs/cifsacl.c | 8 +-- fs/cifs/cifsglob.h | 18 ++++++- fs/cifs/cifsproto.h | 8 +-- fs/cifs/cifssmb.c | 50 +++++++++--------- fs/cifs/dir.c | 16 +++--- fs/cifs/file.c | 20 +++++--- fs/cifs/inode.c | 16 +++--- fs/cifs/link.c | 25 +++------ fs/cifs/readdir.c | 5 +- fs/cifs/smb1ops.c | 16 +++--- fs/cifs/smb2file.c | 10 ++-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +-- fs/cifs/smb2proto.h | 14 ++--- fs/fcntl.c | 5 +- fs/locks.c | 108 ++++++++++++++++++++++++++++++++++++--- fs/namei.c | 45 ++++++++++++++-- fs/nfs/internal.h | 3 +- fs/nfs/nfs4proc.c | 2 + fs/nfs/nfs4xdr.c | 21 ++++++-- fs/nfs/super.c | 3 +- fs/nfsd/nfs4state.c | 46 ++++++++++++++++- fs/proc_namespace.c | 1 + include/linux/fs.h | 7 +++ include/uapi/asm-generic/fcntl.h | 11 ++++ include/uapi/linux/fs.h | 1 + 27 files changed, 355 insertions(+), 124 deletions(-) -- 1.8.1.5

2 10

Re: [3/3] comdlg32: Add an interactive PrintDlgEx test.
by Marvin 08 Apr '13

08 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=24985 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

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

08 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. > ... Is this patch or explanation not clear enough? (Still marked as "New") -- Sergey

1 0

Re: wbemprox: Implement some properties of Win32_ComputerSystem and Win32_DiskPartition.
by Hans Leidekker 08 Apr '13

08 Apr '13

On Mon, 2013-04-08 at 01:56 +0900, Kim Jung Eon (김중언) wrote: > @@ -241,18 +243,21 @@ static const struct column col_compsys[] = > { prop_modelW, CIM_STRING }, > { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 }, > { prop_numprocessorsW, CIM_UINT32, VT_I4 }, > - { prop_totalphysicalmemoryW, CIM_UINT64 } > + { prop_totalphysicalmemoryW, CIM_UINT64 }, > + { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC } Please keep properties sorted.

1 0

Re: d3dx9 [patch 1/3]: Avoid two useless computations
by Rico Schüller 07 Apr '13

07 Apr '13

On 05.04.2013 09:13, Nozomi Kodama wrote: > s = 0.75f; > - if ( order > 2 ) > - s += 5.0f / 16.0f; > - if ( order > 4 ) > - s -= 3.0f / 32.0f; > + if (order > 2) > + s = 1.0625f; > + if (order > 4) > + s = 0.96875f; > s /= D3DX_PI; Doesn't the compiler do that already? If not something like this would probably better: s = 0.23873...f; /* 0.75f / D3DX_PI */ if (order > 2) s = 1.0625f / D3DX_PI; if (order > 4) s = 0.96875f / D3DX_PI; Cheers Rico

2 1

Re: wbemprox: Implement some properties of Win32_ComputerSystem and Win32_DiskPartition.
by Nikolay Sivov 07 Apr '13

07 Apr '13

Please use your real name. On Sun, Apr 7, 2013 at 7:46 PM, mog422 <admin(a)mog422.net> wrote: > > > > >

1 0

64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
by jordan 07 Apr '13

07 Apr '13

Hey List, A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86). the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to… moving on. So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails. -> Successful on Intel: xj(a)xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close So intel computers tested (2 that i know of) work just fine. -> Failure on AMD: http://pastebin.com/x64pig3s and a little snippet: ./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0xffffffff at address 0xffffffff (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module <snip> fixme:dbghelp:elf_search_auxv can't find symbol in module Unhandled exception: page fault on read access to 0xffffffff in 64-bit code (0x00000000ffffffff). fixme:dbghelp:elf_search_auxv can't find symbol in module Register dump: rip:00000000ffffffff rsp:000000000023fa78 rbp:000000000023fbd0 eflags:00010246 ( R- -- I Z- -P- ) rax:00000000003d8de0 rbx:0000000000000000 rcx:0000000000000000 rdx:0000000000000001 rsi:00000000ffffffff rdi:00007f1205f559d0 r8:0000000000000000 r9:0000000000000000 r10:0000000000000001 r11:0000000000000000 r12:0000000000000000 r13:00007f1205f50040 r14:000000007b86f920 r15:00007fffffbe8000 Stack dump: 0x000000000023fa78: 0000000180007756 00000000003d8de0 0x000000000023fa88: 00007f1206ff14d3 0000000000010ac1 0x000000000023fa98: 000000000000000d 0000000000000000 0x000000000023faa8: 00007f1200000000 fffffffffffffffe 0x000000000023fab8: 000000000023fbd0 00007f1205f559d0 0x000000000023fac8: 00007f1205f55b09 2020202020202020 0x000000000023fad8: 0000000000010ac1 00007f1207324323 0x000000000023fae8: 0000000000002000 ffff00ffffffffff 0x000000000023faf8: ffff00ffffffffff 0000000000202020 0x000000000023fb08: 00000001800077d0 0000000180000000 0x000000000023fb18: 0000000000010ac1 5b5b5b5b5b5b5b5b 0x000000000023fb28: 5b5b5b5b5b5b5b5b 2020202020202020 It's odd that it is working on Intel H/W, but not my AMD system. ~ what could be a possible reason for this? We've made s simple test app that doesn't require jackd, or FSThost functions, to simplify things. The source code can be found here: https://sourceforge.net/p/fsthost/code/171/tree/ SVN code required: svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the test app source code is called 'test64-most-simple.c' The test app can be compiled with; $ make -f Makefile64-most-simple then $ ./test64.exe /path/to/64bitVST a tester can be found here: http://www.ddmf.eu/freeware.php grab 'ColourEQ' (contains both 32bit and 64bit versions... and obviously use the 64bit version to try/test.) anyway, i am not sure what the problem is, maybe someone here has an idea or two? ... i've been wondering if there is some sort of misalignment/compiler issue, that is causing the problem...but i want to rule out Wine64 being an issue, first - if possible. any help is appreciated. Thanks Jordan

5 12

Build and override a simple winelib DLL
by Maxime Sednaoui 06 Apr '13

06 Apr '13

Hi, First, I already asked for the same thing at the forum where I've been told to post here for my question Link here : http://forum.winehq.org/viewtopic.php?f=8&t=18675 I have a Windows executable that load a really simple DLL (it is a test) and I want to create a Winelib DLL that will override the Windows DLL. Basically, I created mylib_main.c and mylib.spec to build the Winelib DLL with the command: winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROOT}/include -shared mylib.spec winebuild -w --def -o libmylib.def --export mylib.spec Now I have mylib.dll.so and I want to override mylib.dll What should I do ? I removed the Windows library but then I got a Page Fault when the function is called. I also tried to configure the override with winecfg or set environment variables like WINEDLLPATH or add a DllMain in my library. I don't understand how to proceed. Is this because of the way I build my library ? Or maybe I forget a step to link it properly ? In attachment, a tar with the sources and binaries myapp.exe : the Windows executable mylib.dll : the Windows library mylib_main.c , mylib.spec : the sources to build the Winelib library

3 3

Portability - Port Wine to Wayland
by André Hentschel 05 Apr '13

05 Apr '13

Hi Dan, i just removed your gsoc idea and i want to let you know why. There was a quite short discussion on IRC: Andre_H_laptop: austin_laptop: Dan added a quite controversal gsoc idea... afaik ken needed 1 year for the mac driver and dan further suggests to have a look at xwayland first to see if a new driver is needed. So the time needed for that job is some days to 1 year. what do you think? julliard: Andre_H_laptop: writing a graphics driver is definitely not suitable for gsoc

2 1