wine-devel December 2014

wine-devel@winehq.org

51 participants
126 discussions

Start a nNew thread

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile (try 2).
by Marvin 19 Dec '14

19 Dec '14

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by cdavis5x＠gmail.com 18 Dec '14

18 Dec '14

> On Dec 18, 2014, at 10:16 AM, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > This patch implements storing DOS attributes in the Samba format > "user.DOSATTRIB" extended attribute using fsetxattr and fremovexattr. > FILE_ATTRIBUTE_NORMAL is masked out since that attribute is > unnecessary, and leaving it out avoids having to store an attribute > for every file on the system. Only NORMAL? There are quite a few DOS attributes. Here’s a list from <winnt.h>: #define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_DEVICE 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 #define FILE_ATTRIBUTE_ENCRYPTED 0x00004000 (Yes, all of those are in Microsoft’s public headers. I checked.) Of those, these are the ones that Samba lets clients set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_OFFLINE and these are the ones that Samba returns: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_DIRECTORY FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_SPARSE_FILE (Weird. They let people set OFFLINE, but never return it…) These are the ones that MSDN says Windows lets programs set with SetFileAttributes() (but I can’t vouch for MSDN’s accuracy, so this really needs to be demonstrated with a test): FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and these are the ones that CreateFile() is supposed to let programs set: FILE_ATTRIBUTE_READONLY FILE_ATTRIBUTE_HIDDEN FILE_ATTRIBUTE_SYSTEM FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE FILE_ATTRIBUTE_TEMPORARY FILE_ATTRIBUTE_OFFLINE FILE_ATTRIBUTE_ENCRYPTED I definitely think we shouldn’t be letting people set the DEVICE attribute (this is, I suspect, the attribute you get from a device handle), or the REPARSE_POINT attribute (this is what Windows returns for e.g. symlinks and junctions); MSDN says that the SET_REPARSE_POINT FSCTL is supposed to be able to set this attribute, though. Samba also forcibly sets the DIRECTORY attribute according to whether the file is or is not actually a directory; we should do this, too. MSDN also says the COMPRESSED attribute is supposed to be set by the SET_COMPRESSION FSCTL, the ENCRYPTED attribute is supposed to be set by advapi32.EncryptFile() (which I suspect just makes a SET_ENCRYPTION FSCTL) or when the file is created, and the SPARSE_FILE attribute is supposed to be set by the SET_SPARSE FSCTL, so we should mask all those out too. (Or error out, depending on what native does; as always, the tests are your friends here.) Also, NORMAL is only supposed to be valid by itself, so if any attributes are set along with NORMAL, we may need to error out. We REALLY need tests for all this. ;) (We have some tests for setting file attributes, but not enough IMO.) Chip

2 1

Re: [PATCH 4/4] ntdll: Implement storing DOS attributes in NtCreateFile.
by Marvin 18 Dec '14

18 Dec '14

1 0

Re: [PATCH 3/4] ntdll: Implement storing DOS attributes in NtSetInformationFile.
by Marvin 18 Dec '14

18 Dec '14

1 0

Re: winex11.drv: don't drop raw input events after mouse warp
by Patrick Rudolph 18 Dec '14

18 Dec '14

Am 2014-12-17 20:56, schrieb Alexandre Julliard: > Patrick Rudolph <siro(a)das-labor.org> writes: > >> This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 >> After each mouse move the cursor is warped back to the center of the >> screen. This is OK for XInput, but not for XInput2 as XInput2 reports >> raw events that doesn't care about absolute screen coordinates and >> doesn't need to be dropped. There're frequent cursor warps resulting >> in lot's of dropped raw motion events (up to all). These dropped >> motion events cause mouse jitter, which is notable in FPS games, but >> not while using any GUI that only needs pixel coordinates. > > The problem is that warping the mouse also generates events, and you > have to ignore those. I've attached a log file, here: https://bugs.winehq.org/attachment.cgi?id=50258 As you can see XWarpCursor inserts MotionNotify events, that are correctly ignored using the serial, but there're no inserted RawMotion events. So there's no need to drop them, correct me if I'm wrong. Sadly I couldn't find any documentation for XWarpCursor and RawMotion events. Kind Regards, Patrick

2 1

Re: winex11.drv: don't drop raw input events after mouse warp
by Alexandre Julliard 17 Dec '14

17 Dec '14

Patrick Rudolph <siro(a)das-labor.org> writes: > This patch fixes bug https://bugs.winehq.org/show_bug.cgi?id=32913 > After each mouse move the cursor is warped back to the center of the > screen. This is OK for XInput, but not for XInput2 as XInput2 reports > raw events that doesn't care about absolute screen coordinates and > doesn't need to be dropped. There're frequent cursor warps resulting > in lot's of dropped raw motion events (up to all). These dropped > motion events cause mouse jitter, which is notable in FPS games, but > not while using any GUI that only needs pixel coordinates. The problem is that warping the mouse also generates events, and you have to ignore those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mmdevapi: More accurately track device position
by Marvin 17 Dec '14

17 Dec '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://testbot.winehq.org/JobDetails.pl?Key=10797 Your paranoid android. === w7u (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.501088 render.c:2005: Test failed: Got wrong volume: 0.501088 === w8 (32 bit render) === render.c:1976: Test failed: Got wrong volume: 0.671337 render.c:2005: Test failed: Got wrong volume: 0.671337

1 0

RE: [PATCH] libs/wine/string.c: Always return (int)written
by Hugh McMaster 17 Dec '14

17 Dec '14

On Wednesday, Dec 17 05:54:42 CST 2014, Jonathan Vollebregt wrote: >No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle >> vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. >> >> If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. I disagree. vsnprintfW is not a Windows function. We should be following the Linux form here, which returns the number of chars that would be written.

2 1

Re: [PATCH] libs/wine/string.c: Always return (int)written
by Jonathan Vollebregt 17 Dec '14

17 Dec '14

No: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx#returnValueToggle > vsnprintf ,_vsnprintf, and _vsnwprintf return the number of characters written if the number of characters to write is less than or equal to count; if the number of characters to write is greater than count, these functions return -1 indicating that output has been truncated. The return value does not include the terminating null, if one is written. > > If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. On 12/17/2014 12:47 PM, Hugh McMaster wrote: > Both GCC and Windows versions of vsnprintf return the number of chars that would be written to a given buffer when vsnprintf(NULL, 0, fmt, va_args) is called. > > Wine currently returns -1, which is incorrect. > > Also, if there is a short buffer, that is, buffer <= len, not only is any output truncated, but the return value is the number of chars that would be written if the buffer had sufficient space. > > Here, Wine returns -1, which is, again, incorrect. > > In all cases, the return value should be the number of chars written or the number of chars that would be written if the buffer has sufficient space.

1 0

RE: (resend) regedit: Improve error message when recasing a key.
by Hugh McMaster 17 Dec '14

17 Dec '14

On Wednesday, 17 Dec 2014 01:31:53 +0300, Dmitry Kozliuk wrote: >+ IDS_ERROR_RENAMING_VALUE "Error Renaming Value" >+ IDS_KEY_ALREADY_EXISTS "The Registry Editor cannot rename %s. > The specified key name already exists. Type another name and try again." You cannot use those strings. The first is a verbatim copy from native regedit.exe. The second is almost verbatim, with the exception of "key name". Native regedit.exe uses "value name". Please craft different text with the same meaning.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

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