July 2010 - Wine-devel - list.winehq.org

Re: [PATCH 03/10] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.
by testbot＠testbot.winehq.org 16 Jul '10

16 Jul '10

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

1 0

Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
by Michael Stefaniuc 16 Jul '10

16 Jul '10

Hello Max, are you replacing all FIXME with FIXME_ONCE? While I do agree that we need the _ONCE variant changing all FIXME is not useful. bye michael On 07/14/2010 09:02 PM, Max TenEyck Woodbury wrote: > --- > dlls/ntdll/file.c | 40 ++++++++++++++++++---------------------- > 1 files changed, 18 insertions(+), 22 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 0a6ee55..0b59765 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -117,7 +117,7 @@ static NTSTATUS FILE_CreateFile( PHANDLE handle, ACCESS_MASK access, POBJECT_ATT > > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER; > > - if (alloc_size) FIXME( "alloc_size not supported\n" ); > + if (alloc_size) FIXME_ONCE( "alloc_size not supported\n" ); > > if (options& FILE_OPEN_BY_FILE_ID) > io->u.Status = file_id_to_unix_file_name( attr,&unix_name ); > @@ -1484,7 +1484,7 @@ NTSTATUS WINAPI NtFsControlFile(HANDLE handle, HANDLE event, PIO_APC_ROUTINE apc > break; > > case FSCTL_PIPE_IMPERSONATE: > - FIXME("FSCTL_PIPE_IMPERSONATE: impersonating self\n"); > + FIXME_ONCE("FSCTL_PIPE_IMPERSONATE: impersonating self\n"); > status = RtlImpersonateSelf( SecurityImpersonation ); > break; > > @@ -1531,7 +1531,7 @@ NTSTATUS WINAPI NtSetVolumeInformationFile( > ULONG Length, > FS_INFORMATION_CLASS FsInformationClass) > { > - FIXME("(%p,%p,%p,0x%08x,0x%08x) stub\n", > + FIXME_ONCE("(%p,%p,%p,0x%08x,0x%08x) stub\n", > FileHandle,IoStatusBlock,FsInformation,Length,FsInformationClass); > return 0; > } > @@ -2397,8 +2397,7 @@ static NTSTATUS get_device_info( int fd, FILE_FS_DEVICE_INFORMATION *info ) > } > } > #else > - static int warned; > - if (!warned++) FIXME( "device info not properly supported on this platform\n" ); > + FIXME_ONCE( "device info not properly supported on this platform\n" ); > info->DeviceType = FILE_DEVICE_DISK_FILE_SYSTEM; > #endif > info->Characteristics |= FILE_DEVICE_IS_MOUNTED; > @@ -2430,7 +2429,6 @@ NTSTATUS WINAPI NtQueryVolumeInformationFile( HANDLE handle, PIO_STATUS_BLOCK io > { > int fd, needs_close; > struct stat st; > - static int once; > > if ((io->u.Status = server_get_unix_fd( handle, 0,&fd,&needs_close, NULL, NULL )) != STATUS_SUCCESS) > return io->u.Status; > @@ -2441,10 +2439,10 @@ NTSTATUS WINAPI NtQueryVolumeInformationFile( HANDLE handle, PIO_STATUS_BLOCK io > switch( info_class ) > { > case FileFsVolumeInformation: > - if (!once++) FIXME( "%p: volume info not supported\n", handle ); > + FIXME_ONCE( "%p: volume info not supported\n", handle ); > break; > case FileFsLabelInformation: > - FIXME( "%p: label info not supported\n", handle ); > + FIXME_ONCE( "%p: label info not supported\n", handle ); > break; > case FileFsSizeInformation: > if (length< sizeof(FILE_FS_SIZE_INFORMATION)) > @@ -2513,19 +2511,19 @@ NTSTATUS WINAPI NtQueryVolumeInformationFile( HANDLE handle, PIO_STATUS_BLOCK io > } > break; > case FileFsAttributeInformation: > - FIXME( "%p: attribute info not supported\n", handle ); > + FIXME_ONCE( "%p: attribute info not supported\n", handle ); > break; > case FileFsControlInformation: > - FIXME( "%p: control info not supported\n", handle ); > + FIXME_ONCE( "%p: control info not supported\n", handle ); > break; > case FileFsFullSizeInformation: > - FIXME( "%p: full size info not supported\n", handle ); > + FIXME_ONCE( "%p: full size info not supported\n", handle ); > break; > case FileFsObjectIdInformation: > - FIXME( "%p: object id info not supported\n", handle ); > + FIXME_ONCE( "%p: object id info not supported\n", handle ); > break; > case FileFsMaximumInformation: > - FIXME( "%p: maximum info not supported\n", handle ); > + FIXME_ONCE( "%p: maximum info not supported\n", handle ); > break; > default: > io->u.Status = STATUS_INVALID_PARAMETER; > @@ -2560,7 +2558,7 @@ NTSTATUS WINAPI NtQueryEaFile( HANDLE hFile, PIO_STATUS_BLOCK iosb, PVOID buffer > BOOLEAN single_entry, PVOID ea_list, ULONG ea_list_len, > PULONG ea_index, BOOLEAN restart ) > { > - FIXME("(%p,%p,%p,%d,%d,%p,%d,%p,%d) stub\n", > + FIXME_ONCE("(%p,%p,%p,%d,%d,%p,%d,%p,%d) stub\n", > hFile, iosb, buffer, length, single_entry, ea_list, > ea_list_len, ea_index, restart); > return STATUS_ACCESS_DENIED; > @@ -2584,7 +2582,7 @@ NTSTATUS WINAPI NtQueryEaFile( HANDLE hFile, PIO_STATUS_BLOCK iosb, PVOID buffer > */ > NTSTATUS WINAPI NtSetEaFile( HANDLE hFile, PIO_STATUS_BLOCK iosb, PVOID buffer, ULONG length ) > { > - FIXME("(%p,%p,%p,%d) stub\n", hFile, iosb, buffer, length); > + FIXME_ONCE("(%p,%p,%p,%d) stub\n", hFile, iosb, buffer, length); > return STATUS_ACCESS_DENIED; > } > > @@ -2636,18 +2634,16 @@ NTSTATUS WINAPI NtLockFile( HANDLE hFile, HANDLE lock_granted_event, > NTSTATUS ret; > HANDLE handle; > BOOLEAN async; > - static BOOLEAN warn = TRUE; > > if (apc || io_status || key) > { > - FIXME("Unimplemented yet parameter\n"); > + FIXME_ONCE("Unimplemented yet parameter\n"); > return STATUS_NOT_IMPLEMENTED; > } > > - if (apc_user&& warn) > + if (apc_user ) > { > - FIXME("I/O completion on lock not implemented yet\n"); > - warn = FALSE; > + FIXME_ONCE("I/O completion on lock not implemented yet\n"); > } > > for (;;) > @@ -2672,7 +2668,7 @@ NTSTATUS WINAPI NtLockFile( HANDLE hFile, HANDLE lock_granted_event, > > if (async) > { > - FIXME( "Async I/O lock wait not implemented, might deadlock\n" ); > + FIXME_ONCE( "Async I/O lock wait not implemented, might deadlock\n" ); > if (handle) NtClose( handle ); > return STATUS_PENDING; > } > @@ -2710,7 +2706,7 @@ NTSTATUS WINAPI NtUnlockFile( HANDLE hFile, PIO_STATUS_BLOCK io_status, > > if (io_status || key) > { > - FIXME("Unimplemented yet parameter\n"); > + FIXME_ONCE("Unimplemented yet parameter\n"); > return STATUS_NOT_IMPLEMENTED; > } >

7 12

Administrative privileges and running tests under Windows
by Mariusz Pluciński 16 Jul '10

16 Jul '10

Hi wine-devel I have problems with tests I written last time. The problem is connected with privileges levels under Windows. The method I'm testing is IGameExplorer::AddGame, which registers given game in Windows Game Explorer. One of it's parameters (installScope) defines if game should be registered for all users or only currently logged one. The problem is that routine's behaviour depends on if application was started with administrative privileges or not. If I call method with GIS_ALL_USERS parameter, it succeeds only with administrative privileges (fails if I run it as normal user). If I call it with GIS_CURRENT_USER parameter, it succeeds under normal user level, and fails (sic!) under administrative. My question is, how I should write tests to support both of these cases. Both seems to be exclusive, and I prefer first to ask, rather than trying implement it in some odd (and probably wrong) way. I also want to make it available to run under Wine project's test machines, but I don't know how they're configured and will them allow me to test administrative case.

2 2

Re: [website] German translation of stable release news 1.2
by Paul Vriens 16 Jul '10

16 Jul '10

On 07/16/2010 05:50 PM, André Hentschel wrote: > +<p><p>Der Quellcode ist jetzt<a href="http://prdownloads.sourceforge.net/wine/wine-1.2-rc7.tar.bz2">verfügbar</a>. Hi André, You've listed the wrong download. -- Cheers, Paul.

1 0

re: Please remove / block user from bugzilla
by Dan Kegel 16 Jul '10

16 Jul '10

I only see one post from him ever, and he was *trying* to be helpful. Everybody should get a few chances. A warning should suffice. If you ask me, http://bugs.winehq.org/show_bug.cgi?id=6971#c371 is more objectionable, because it shows the Wine community to be ill-mannered and hostile to newbies. - Dan

7 19

RFC: Detecting the wine prefix
by Paul Chitescu 16 Jul '10

16 Jul '10

Hi! I would want to implement a change in where the wine prefix is assumed by default. The current behavior of only considering WINEPREFIX is cumbersome and risky. Slip a finger, forget a letter and you end running a potential disastrous command in the wrong prefix. I ruined my main prefix by accidenatlly running "winetricks ie6" in it... To fix that I use a wrapper script (unimaginatively named "win") that detects the proper prefix from the current directory and calls wine or other programs (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am satisfied by this wrapper but has several disadvantages: - You need to remember to run it instead of wine. - You may paste a command from somewhere and forget to add "win" in front. - Needs to be distributed. The proposed solution is to incorporate the prefix detection logic in wine itself so no wrapper is needed. The modified behavior would be like this: - If WINEPREFIX is set obey that, user knows better. This is also required to create a new prefix. - Starting from current working directory descend towards root looking for a directory that: 1. Has a dosdevices/ subdirectory and a system.reg file or 2. Has a .wine symlink pointing to a directory matching condition 1. or 3. Holds a .wine regular file whose content is the name of a directory matching condition 1. - If a valid prefix (matches condition 1. above) is found use it for wine - Else use the default ~/.wine The extra checks 2. and 3. are to be able to handle the case when the current directory is on a path that is symlinked from inside the prefix. In particular test 3. is used when the files are on a FAT (or other symlink incapable) partition. I have several wine prefixes whose "Program Files" is located on a much larger FAT32 partition shared with you know what. What do you think about this? Should I go on coding it? Paul Chitescu

4 6

Re: Please remove / block user from bugzilla
by James Mckenzie 16 Jul '10

16 Jul '10

Luke Benstead <kazade(a)gmail.com> wrote: >Sent: Jul 16, 2010 7:18 AM >To: Henri Verbeet <hverbeet(a)gmail.com> >Cc: wine-devel(a)winehq.org, Dan Kegel <dank(a)kegel.com> >Subject: Re: Please remove / block user from bugzilla > >> How do frequent wine committers, and especially Alexandre, feel about >> > these two issues? >> I'd say Alexandre's opinion is pretty clear, as always: >> http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html. >> >> >That's doesn't settle this at all, Alexandre is almost certainly referring >to the bug number in the patch itself there, rather than the subject line. Actually, during the first part of the Wine 1.2 rc set, it was suggested to put the bug number somewhere in either the changelog or in the subject line. What I seen in the message is that AJ wanted something more meaningful in the code than just "testing for bug XXXX". The comment could become part of the Wine code base and is not clear. James McKenzie

1 0

Cascading test failures
by Greg Geldorp 16 Jul '10

16 Jul '10

Ideally, tests should be independent on each other. That's not the case right now. A clear example is msi:package, which often fails (on XP) with 1574 errors, see http://test.winehq.org/data/tests/msi:package.html. For all the cases I've checked, when these 1574 errors occur the preceding msi:install test timed out (the reverse is not true, I see msi:install timeouts followed by a successful msi:package). My current theory is that the Windows Installer service gets confused when the msi:install test times out and is bluntly terminated by the winetest wrapper. A possible solution might be to introduce a cleanup mechanism invoked by winetest.exe when it detects a timeout or crash in one of the test executables. After terminating the test executable, winetest.exe would then call "testname_test.exe --cleanup failed_test_name". The --cleanup argument could be handled by the tests main(), just like --list is handled by main(). A test executable would be able to register a cleanup function by setting a global function pointer to its cleanup function. In the case of msi_test.exe, that cleanup function could try to stop and restart the Windows Installer service. Does this sound worthwhile to pursue? Any other/better ideas? Ge.

5 6

Re: kernel32: Update the Dutch translation
by Paul Vriens 16 Jul '10

16 Jul '10

On 07/16/2010 03:05 PM, Sven Baars wrote: > MessageId=1207 > SymbolicName=ERROR_NOT_CONTAINER > Language=NLD > -Not a container > +Geen > . You are missing something here I guess. -- Cheers, Paul.

2 1

Re: wineboot: fix Serbian Latin translation
by Paul Vriens 16 Jul '10

16 Jul '10

On 07/14/2010 09:40 AM, Damjan Jovanovic wrote: > Changelog: > * wineboot: fix Serbian Latin translation > > Damjan Jovanovic > Hi Damjan, Thanks for looking into this. I guess we need the pragma statement now as you are introducing UTF-8, not? I did talk to Nenad about the fact that his translations appeared to be all ASCII (and I did see some non-ASCII ones on wikipedia) but no response so I'd figured it was correct. -- Cheers, Paul.

3 4