February 2013 - Wine-Devel - list.winehq.org

Re: [1/4] windowscodecs: Implement IWICColorContext::InitializeFromFilename.

by Hans Leidekker

On Wed, 2013-02-06 at 18:10 +0100, Ludger Sprenker wrote: > On Wed, 06 Feb 2013 13:51:32 +0100, Hans Leidekker wrote: > > > + handle = CreateFileW(filename, GENERIC_READ, 0, NULL, > > > OPEN_EXISTING, 0, NULL); > > > + if (handle == INVALID_HANDLE_VALUE) return > > > HRESULT_FROM_WIN32(GetLastError()); > > I think, you are hiding a fixme for the default color profiles shipped with windows. > > (like "c:\windows\system32\spool\drivers\color\sRGB Color Space Profile.icm") I don't think this is the right place for such a fixme, it could just as well be loading a profile that comes bundled with the app. Also note that any attempt to use the color context will cause a fixme to be printed.

Feb. 6, 2013

Re: [4/4] windowscodecs: Implement IWICComponentFactory::CreateDecoderFromFileHandle.

by Hans Leidekker

On Wed, 2013-02-06 at 10:25 -0600, Vincent Povirk wrote: > > + hr = map_file(file, &map, &mem, &size); > > + if (FAILED(hr)) return hr; > > + > ... > > + > > + hr = IWICStreamImpl_InitializeFromMemory(stream, mem, size.u.LowPart); > > + if (FAILED(hr)) goto error; > > This makes me sad. > > Is this really simpler than implementing Write and Seek for a file handle? I'd say it's a comparable amount of code. I don't have a strong preference for either option.

Feb. 6, 2013

kernel32: Use the monotonic counter in GetTickCount64.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I believe we should use this opportunity and review the usage of timers in Wine. E.g. I have a patch to have CreateTimerqueue use the monotonic timer too that I'll submit after some more testing. Mmdevapi's audio currently depends on the TimerQueue which IMHO erroneously depends on gettimeofday() instead of clocks not affected by DST and NTP. As a result, strange things should happen to Wine audio each time the clock is adjusted... What do you think? BTW, MSDN is wonderfully inconsistent - witness "system time": "System time is the current date and time of day. [...] The system bases system time on coordinated universal time (UTC)." http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%… "The system time is the time, in milliseconds, since the Microsoft Windows operating system was started." http://msdn.microsoft.com/en-us/library/windows/desktop/dd743637%28v=vs.85%… The latter is within the context of windows multimedia. I believe different teams at MS wrote documents without cross-checking their use of vocabulary. As a result, expressions don't mean the same things. Regards, Jörg Höhle

Feb. 6, 2013

Re: [1/4] windowscodecs: Implement IWICColorContext::InitializeFromFilename.

by Ludger Sprenker

On Wed, 06 Feb 2013 13:51:32 +0100, Hans Leidekker wrote: > + handle = CreateFileW(filename, GENERIC_READ, 0, NULL, > OPEN_EXISTING, 0, NULL); > + if (handle == INVALID_HANDLE_VALUE) return > HRESULT_FROM_WIN32(GetLastError()); Hello Hans, I think, you are hiding a fixme for the default color profiles shipped with windows. (like "c:\windows\system32\spool\drivers\color\sRGB Color Space Profile.icm") I don't know the correct way to support these files. Maybe wine could search in "/usr/share/color/icc" for compatible profiles on runtime or take these files from other open source projects and include them in the wine installation. Regards, Ludger

Feb. 6, 2013

Re: [4/4] windowscodecs: Implement IWICComponentFactory::CreateDecoderFromFileHandle.

by Vincent Povirk

> + hr = map_file(file, &map, &mem, &size); > + if (FAILED(hr)) return hr; > + ... > + > + hr = IWICStreamImpl_InitializeFromMemory(stream, mem, size.u.LowPart); > + if (FAILED(hr)) goto error; This makes me sad. Is this really simpler than implementing Write and Seek for a file handle?

Feb. 6, 2013

Re: kernel32/tests : added tests for copyfileex try7

by Alexandre Julliard

Patrick Rudolph <siro(a)das-labor.org> writes: > + if( !GetTempPathA( MAX_PATH,tmppath ) ) > + { > + win_skip("GetTempPathA failed\n"); > + return; > + } > + > + /* create a dummy file for copy tests */ > + if( !GetTempFileNameA( tmppath,"IN",0,source_name ) ) > + { > + win_skip("GetTempFileNameA failed\n"); > + return; > + } > + > + /* create a dummy file for copy tests */ > + if( !GetTempFileNameA( tmppath,"OUT",0,dest_name ) ) > + { > + win_skip("GetTempFileNameA failed\n"); > + return; > + } > + > + source_handle = CreateFileA( source_name, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 ); > + if( !source_handle ) > + { > + win_skip("CreateFileA failed (%d)\n", GetLastError()); > + return; > + } > + > +#define COPYFILEEXFILESIZE 10000000 > + > + /* set filesize to COPYFILEEXFILESIZE */ > + TotalFileSize.QuadPart = COPYFILEEXFILESIZE; > + > + if( !pSetFilePointerEx(source_handle,TotalFileSize,NULL,FILE_BEGIN) ) > + { > + win_skip("SetFilePointerEx failed (%d)\n", GetLastError()); > + return; > + } > + > + if( !pSetEndOfFile(source_handle) ) > + { > + win_skip("SetEndOfFile failed (%d)\n", GetLastError()); > + return; > + } All these calls are not supposed to fail on Windows either. win_skip is not appropriate. -- Alexandre Julliard julliard(a)winehq.org

Feb. 6, 2013

Re: [PATCH] Support a protection scheme which reset the GS selector

by Alexandre Julliard

Alessandro Pignotti <a.pignotti(a)sssup.it> writes: > Hi everyone, > > I've found two different games: > > -) Of orcs and men > -) The testament of sherlock holmes > > which are using a protection scheme which reset the GS segment selector, > possibly to confuse virtual machines. Since on linux the GS selector is > used internally by glibc the game would crash as soon as a native glibc > method is called by wine. The proposed patch tries to workaround this > problem by restoring the GS to a known working value in wine's SEGFAULS > handler and try the instruction again. This should be done similarly to the other checks in raise_segv_exception. -- Alexandre Julliard julliard(a)winehq.org

Feb. 6, 2013

Re: [2/5] windowscodecs: Basic tests for tiff encoder options (try2)

by Vincent Povirk

> @Vincent: I thought about adding the properties one at a time but it seemed > a bit like overkill for the tiff encoder, which has only two options. But I > will defenitly do this for the jpeg encoder, which has much more options. Well, actually, on further consideration I can understand why you did it this way, since adding a property is very easy and doesn't really require implementing that property. Though it'd be nice to get some notification when a property is used that we don't support.

Feb. 5, 2013

Re: [2/5] windowscodecs: Basic tests for tiff encoder options

by Vincent Povirk

+ { wszTiffCompressionMethod, VT_UI1, VT_UI1, {.iVal=WICTiffCompressionDontCare} }, This .field=value initialization syntax is not acceptable for Wine (not in C89). I don't know another way to initialize unions. + if (clsid_encoder == &CLSID_WICTiffEncoder) + todo_wine test_specific_encoder_properties(options, testdata_tiff_props, all_props, cProperties2); It might be better to mark the individual properties with a todo, so they can be added one at a time.

Feb. 5, 2013

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

by J. Bruce Fields

On Tue, Feb 05, 2013 at 03:33:21PM +0400, Pavel Shilovsky wrote: > 2013/1/31 J. Bruce Fields <bfields(a)fieldses.org>: > > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote: > >> 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. > > > > Maybe that's good enough. A mount flag might be simpler and give > > consistent enforcement for all users. > > > >> > >> 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. > > > > It would be useful to have some really careful documentation of how > > these are meant to work. Maybe try updating the open man page? > > Yes, that's a good idea. Do you mean smth like this? > > 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; > > Also, 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. Do you need to document interactions with flock() as well? --b.

Feb. 5, 2013