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

Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
by Jacek Caban 18 Jul '12

18 Jul '12

Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote: > I noticed we return in this case, without initializing this variable. > Visual inspection indicates we do not seem to access the variable in > this error case, but a) better safe than sorry, and b) GCC 4.8 currently > warns about it. > > Not sure URLPOLICY_DISALLOW is the best return value, open for better > alternatives. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek

2 4

winebuild port to ARM?
by Roger Cruz 07 Jul '12

07 Jul '12

Has anyone worked or is currently working on porting the x86 specific code in Winebuild to ARM? Specifically the relay.c file? Thanks Roger R. Cruz

2 9

[PATCH 0/6] Extended file stat system call
by David Howells 10 May '12

10 May '12

Implement a pair of new system calls to provide extended and further extensible stat functions. The second of the associated patches is the main patch that provides these new system calls: ssize_t ret = xstat(int dfd, const char *filename, unsigned atflag, unsigned mask, struct xstat *buffer); ssize_t ret = fxstat(int fd, unsigned atflag, unsigned mask, struct xstat *buffer); which are more fully documented in the first patch's description. These new stat functions provide a number of useful features, in summary: (1) More information: creation time, inode generation number, data version number, flags/attributes. A subset of these is available through a number of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). (2) Lightweight stat: Ask for just those details of interest, and allow a netfs (such as NFS) to approximate anything not of interest, possibly without going to the server. (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its cached attributes are up to date. (4) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available. (5) Make the fields a consistent size on all arches, and make them large. (6) Can be extended by using more request flags and appending further data after the end of the standard return data. Note that no lstat() equivalent is required as that can be implemented through xstat() with atflag == 0. ======= PATCHES ======= Patch 1 defines the xstat() and fxstat() system calls. Patches 2-6 implement extended stat facilities for Ext4, AFS, NFS and CIFS, and make eCryptFS go to the lower filesystem for such details. ============== CONSIDERATIONS ============== Should fxstat() be implemented as xstat() with a NULL filename, using dfd as fd? Should the default for a network fs be to do an unconditional (heavyweight) stat with a flag to suppress going to the server to update the locally held attributes and flushing pending writebacks? Should things like the Windows Archive, Hidden and System bits be handled through IOC flags, perhaps expanded to 64-bits? Are these things useful to userspace other than Samba and userspace NFS servers? Is it useful to pass the volume ID out? Or is statfs() sufficient for this? Should I add a sixth argument to xstat(), mark it reserved and require that must be supplied as 0 to hedge against future use? Is there anything else I can usefully add at the moment? ========== TO BE DONE ========== Autofs, ntfs, btrfs, ... I should perhaps use u8/u32/u64 rather than uint8/32/64_t. Handle remote filesystems being offline and indicate this with XSTAT_INFO_OFFLINE. ======= TESTING ======= There's a test program attached to the description for the main patch. It can be run as follows: [root(a)andromeda tmp]# ./xstat -R /mnt/foo xstat(/mnt/foo) = 0 0000: 000081a40000ffef 0000000000000001 0000020000000000 0000100000080000 0020: 0000000000000000 0000000600000008 000000004f88499a 0000000136fd9208 0040: 000000004f88499a 0000000136fd9208 000000004f8849b9 0000000106daf187 0060: 000000004f8849b9 0000000106daf187 000000000000000c 000000000000000f 0080: 0000000000000008 00000000484ebbef 0000000000000025 5949ebd4711efd82 00a0: d3250b5c15d5e380 0000000000000000 0000000000000000 0000000000000000 00c0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00e0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 results=ffef Size: 15 Blocks: 8 IO Block: 4096 regular file Device: 08:06 Inode: 12 Links: 1 Access: (0644/-rw-r--r--) Uid: 0 Gid: 0 Access: 2012-04-13 16:43:22.922587656+0100 Modify: 2012-04-13 16:43:53.115011975+0100 Change: 2012-04-13 16:43:53.115011975+0100 Create: 2012-04-13 16:43:22.922587656+0100 Inode version: 484ebbefh Data version: 25h Inode flags: 00080000 (-------- ----e--- -------- --------) Information: 00000200 (-------- -------- ------a- --------) Volume ID: 82fd1e71d4eb4959-80e3d5155c0b25d3 David --- David Howells (6): xstat: eCryptFS: Return extended attributes xstat: CIFS: Return extended attributes xstat: NFS: Return extended attributes xstat: AFS: Return extended attributes xstat: Ext4: Return extended attributes xstat: Add a pair of system calls to make extended file stats available arch/x86/syscalls/syscall_32.tbl | 2 arch/x86/syscalls/syscall_64.tbl | 2 fs/afs/inode.c | 29 ++- fs/afs/super.c | 7 + fs/cifs/cifsfs.h | 4 fs/cifs/cifsglob.h | 16 +- fs/cifs/dir.c | 2 fs/cifs/inode.c | 120 +++++++++++-- fs/ecryptfs/inode.c | 14 +- fs/ext4/ext4.h | 2 fs/ext4/file.c | 2 fs/ext4/inode.c | 32 +++ fs/ext4/namei.c | 2 fs/ext4/super.c | 1 fs/ext4/symlink.c | 2 fs/nfs/inode.c | 49 ++++- fs/nfs/super.c | 1 fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- include/linux/fcntl.h | 1 include/linux/fs.h | 4 include/linux/stat.h | 126 +++++++++++++- include/linux/syscalls.h | 7 + 22 files changed, 694 insertions(+), 81 deletions(-)

10 65

Re: Ubuntu 12.04 (version#2, drop previous mail)
by Eric Pouech 09 May '12

09 May '12

> This is because you _cannot_ install the 32-bit -dev packages onto > 12.04. It's not just symlinks that are missing, many of the header > files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least > Just do the chroot. You will save yourself so much grief and it will > actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ -- -- Eric Pouech

3 4

Request for help/advice in investigation of one interesting "huge FPS regression" bug
by Alexey Loukianov 03 May '12

03 May '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good day to all. Henri, Stefan, I address this message to you at the first place as to a main developers of wined3d/opengl stuff. Nevertheless, hints and help are welcome from anyone, cause ATM I'm totally confused and don't know what else to try to investigate a case. What I've got here is an app (localized version of "Perfect World" MMORPG game client from "Mail.Ru Games Corp") that seems to suffer huge FPS regression which I believe to be a bug in nVIDIA drivers rather than a regression in Wine. Details are following. When I configure an app to run in a windowed mode I've got around 40 FPS on game login screen with nVIDIA drivers 275.09.07, but switching into using more recent versions causes FPS to drop to around ~10. Configuring the game to use fullscreen more fixes the issue - I've got ~30-40 FPS at game login screen no matter the driver version I use. I've been suspecting that this issue might be related to vsync control (and a recent change in nVIDIA linux drivers for vsync to be on by default) that causes the issue, so I had exported __GL_SYNC_TO_VBLANK="0" into the environment and used nvidia-settings to set vsync to be off by default. Using a small native opengl demo program I had specifically written to test for vsync state I can prove that vsync defaults to be off on my system. Also I had modified Wine's winex11.drv opengl.c in a way that a call to wglSwapIntervalEXT always sets swap_interval to be zero, no matter what was originally requested. Nevertheless, I still got this strange FPS drop when I run the game in a windowed more with a recent nVIDIA drivers. What could be a cause for it? What I want is to track down the problem to it's roots and check if it's really a bug in nVIDIA drivers. In the end I would like to implement a small opengl demo that would trigger the bug so nVIDIA wouldn't be able to reject my bug report on a matter that "it's a Wine bug, prove us that it's not". - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPij76AAoJEPB9BOdTkBULjz4H/1B/Nw6qOQUlEmDb64SmabvQ LQmzIHcnH38Ftz3KyWQxlYZ5EtLDYAIOQeP4pAHfzxKhGUJ1mCumv4ByaSs4YDhI juWJ/u/88vKwZYXJ9nZLQVqJY+dkr9MbxP3q0eGNaAFLNRDIqodzJJWB5EPucMrX Yid/zMjl5uGd9QDCO3Db4gwJKYpvHCbAfzADddqBwPoak9jXdlq53H9a2mImTbCB JR1MXQq6gFakOgtxXPxzFSU2Ge0n8RBGGN7UeZEubsLiktnmvTbKAJmmgWgPG80Y mlud7LrM4wLRPtpwTwS+M1n8TuVtUZzzCTagRyj3XSRL8Pqf2d5S3H+MpxBT1JQ= =TkMD -----END PGP SIGNATURE-----

5 8

GSOC 2012 has started
by Austin English 03 May '12

03 May '12

Howdy, Google Summer of Code 2012 has started, and we have 5 students this year: Józef Kucia - Implement missing functions in D3DX9, mentored by Stefan Dösinger - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/jos/58002 Lucas Fialho Zawacki, mentored by Joystick configuration and testing applet Marcus Meissner - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/lfzawacki/3… Magdalena Nowak - Control Panel, mentored by Owen Rudge - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/magdalena/1… Marek K Chmiel - Encryption – digital signature security, mentored by Juan Lang - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/mkchmiel/16… Qian Hong - GSoC project: Improve CJK font support, mentored by Aric Stewart - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/fracting/11… Good luck everyone! -- -Austin

3 3

Fwd: Ubuntu 12.04 (version#2, drop previous mail)
by Eric Pouech 01 May '12

01 May '12

for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation, just hints if you want to take that road (version #3) (I'm using a multiarch x86_64/i386) now wine compiles and runs in 32bit while compiled on 64bit machine here's the summary of the pain getting it right after upgrade in response to https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321 I was able to compile 32bit-wine on 64bit as I always, and without a chroot or anything similar Problem #1 ---------- an old (11.10 according to the dates) directory was left over after migration, whereas it should have been removed /usr/include/i386-linux-gnu Problem #2 ---------- a ton of symlinks are missing in /usr/lib/i386-linux-gnu for example [root:/usr/lib/i386-linux-gnu]# ls -l /usr/lib/i386-linux-gnu/libfree* lrwxrwxrwx 1 root root 20 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.8.0 -rw-r--r-- 1 root root 624084 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.0 and it misses lrwxrwxrwx 1 root root 16 avril 28 21:30 /usr/lib/i386-linux-gnu/libfreetype.so -> libfreetype.so.6 the same applies for a lot libraries libXcursor.so libXi.so libXxf86vm.so libxrandr.so libxinerama.so libxcomposite.so libGLU.so libdbus-1.so (libdbus-1.so lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libgnutls.so libsane.so libv4l1.so libgphoto2.so libgphoto2_port.so libgstreamer-0.10.so (***) libcapi20.so libcups.so libfontconfig.so libtiff.so libmpg123.so libopenal.so libxrender.so libGL.so (libGL.so is in mesa subdir!!!) libxml2.so libxslt.so libssl.so libcrypto.so libjpeg.so (***) libpng.so.0 (libpng12.so.0 lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libXext.so the ones marked (***) means that the symlink is missing but it doesn't solve fully the issue from a wine perspective (see below) Problem #3 (jpeg) ----------------- Fails to open<jconfig.h>. which only lies in /usr/include/x86_64-linux-gnu/jconfig.h, and couldn't be accessed from 32bit build Creating the /usr/include/i386-linux-gnu/ directory and creating a symlink for jconfig.h to /usr/include/x86_64-linux-gnu/jconfig.h just works (I checked the contents of jconfig.h and it looks reasonable to do so) Problem #4 (gstreamer) ---------------------- it doesn't work as only /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h is installed (/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h doesn't exist, dpkg -S doesn't find it) and /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h defines gint64 as long, which is correct on 64bit targets one wrong on 32 bit ones... one should craft a decent /usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h, or grab one out of pure i386 install (I haven't had time to look further into those, my main interest was to have a 32bit setup up& running) List of potentially installed i386 packages ------------------------------------------- fixed by installing i386 packages (not exhaustive, unfortunately, as I didn't note all the :i386 packages I've manually installed) libldap2.so alternatively, if I do a [eric:~]$ dpkg -l | grep i386 | grep -- -dev ii libc6-dev-i386 2.15-0ubuntu10 Embedded GNU C Library: 32-bit development libraries for AMD64 ii libldap2-dev:i386 2.4.28-1.1ubuntu4 OpenLDAP development libraries ii libpthread-stubs0-dev:i386 0.3-3 pthread stubs not provided by native libc, development files ii libx11-dev:i386 2.1.4.99.1-0ubuntu2 X11 client-side library (development headers) ii libxau-dev:i386 1:1.0.6-4 X11 authorisation library (development headers) ii libxcb1-dev:i386 1.8.1-1 X C Binding, development files ii libxdmcp-dev:i386 1:1.1.0-4 X11 authorisation library (development headers) tends to ask for libc6-dev:i386, libldap2-dev:i386, libx11-dev:i386, libxau-dev:i386, libxcb1-dev:i386, libxdmcp-dev:i386 as dedicated installations of dev:i386 packages but strangely enough, when looking at details, libx11-dev (for example) cannot be installed with libx11-dev:i386 according to manifest, but I have both installed (and both install the same files in /usr/include for example) this looks very strange indeed List of stuff that won't work ----------------------------- won't be supported (just to note them, as those are the left overs from the configure failing list) compiled without multiarch support: libhal, libgsm Warning at compilation ---------------------- when compiling, some warnings still have to be worked upon /home/eric/work/wine/dlls/winex11.drv/keyboard.c:1109:5: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] this one can be forgotten for now (it's just being marked deprecated in precise, so warning doesn't come from misconfiguration) debugging (32bit and 64bit) is broken ------------------------------------- the debugging is broken it turns out that ptrace and prctl (which had to be added in 11.10) work fine when tracing, only the first started process get correct pid out of wineserver in socket SCM_CREDENTIALS info. the later get 0 I tried to force the pid without requiring the recvmsg stuff and it works just fine I've not found yet the change that broke this more to come if get any futher on the remaining topics A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

5 7

Patches 85862 & 85862
by Christian Costa 01 May '12

01 May '12

What's wrong with these patches : - http://source.winehq.org/patches/data/85862 - http://source.winehq.org/patches/data/85862 There are marked as pending but can't see anything wrong. Maybe I'm missing something. Christian

1 0

Re: [1/3] d3dx9: Define DDS structures. (try 3)
by Stefan Dösinger 01 May '12

01 May '12

The patches look good to me. Am Sonntag, 29. April 2012, 21:43:08 schrieb Józef Kucia: > This patch series implements the DDS support for D3DXGetImageInfo functions. > > Try 2: Define pitch as LONG. > Try 3: Revert it back to DWORD. > --- > dlls/d3dx9_36/surface.c | 66 > ++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 65 > insertions(+), 1 deletions(-) > > diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c > index 567282c..3319927 100644 > --- a/dlls/d3dx9_36/surface.c > +++ b/dlls/d3dx9_36/surface.c > @@ -28,9 +28,73 @@ WINE_DEFAULT_DEBUG_CHANNEL(d3dx); > > > /* Wine-specific WIC GUIDs */ > - > DEFINE_GUID(GUID_WineContainerFormatTga, > 0x0c44fda1,0xa5c5,0x4298,0x96,0x85,0x47,0x3f,0xc1,0x7c,0xd3,0x22); > > +/* dds_header.flags */ > +#define DDS_CAPS 0x1 > +#define DDS_HEIGHT 0x2 > +#define DDS_WIDTH 0x2 > +#define DDS_PITCH 0x8 > +#define DDS_PIXELFORMAT 0x1000 > +#define DDS_MIPMAPCOUNT 0x20000 > +#define DDS_LINEARSIZE 0x80000 > +#define DDS_DEPTH 0x800000 > + > +/* dds_header.caps */ > +#define DDS_CAPS_COMPLEX 0x8 > +#define DDS_CAPS_TEXTURE 0x1000 > +#define DDS_CAPS_MIPMAP 0x400000 > + > +/* dds_header.caps2 */ > +#define DDS_CAPS2_CUBEMAP 0x200 > +#define DDS_CAPS2_CUBEMAP_POSITIVEX 0x400 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEX 0x800 > +#define DDS_CAPS2_CUBEMAP_POSITIVEY 0x1000 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEY 0x2000 > +#define DDS_CAPS2_CUBEMAP_POSITIVEZ 0x4000 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEZ 0x8000 > +#define DDS_CAPS2_VOLUME 0x200000 > + > +/* dds_pixel_format.flags */ > +#define DDS_PF_ALPHA 0x1 > +#define DDS_PF_ALPHA_ONLY 0x2 > +#define DDS_PF_FOURCC 0x4 > +#define DDS_PF_RGB 0x40 > +#define DDS_PF_YUV 0x200 > +#define DDS_PF_LUMINANCE 0x20000 > + > +struct dds_pixel_format > +{ > + DWORD size; > + DWORD flags; > + DWORD fourcc; > + DWORD bpp; > + DWORD rmask; > + DWORD gmask; > + DWORD bmask; > + DWORD amask; > +}; > + > +struct dds_header > +{ > + DWORD signature; > + DWORD size; > + DWORD flags; > + DWORD height; > + DWORD width; > + DWORD pitch_or_linear_size; > + DWORD depth; > + DWORD miplevels; > + DWORD reserved[11]; > + struct dds_pixel_format pixel_format; > + DWORD caps; > + DWORD caps2; > + DWORD caps3; > + DWORD caps4; > + DWORD reserved2; > +}; > + > + > /************************************************************ > * D3DXGetImageInfoFromFileInMemory > *

1 0

Re: wined3d: Fix build with MSVC (try 2).
by Stefan Dösinger 30 Apr '12

30 Apr '12

Am Samstag, 28. April 2012, 10:16:13 schrieb Thomas Faber: > Apparently NAN and INFINITE are C99 as well (I should really get a > version of the old standard instead of mostly reading C99 :|). > > How about a simple const variable that will trick MSVC, while not > changing semantics. How about a function in libs/port or a macro in one of its headers? I believe the NAN/INFINITE issue is not specific to wined3d. With the const variable, msvc compiles the code, but still produces a warning.

2 2