wine-devel December 2010

wine-devel@winehq.org

83 participants
219 discussions

Re: [PATCH 1/5] server: Handle more inotify mask values
by Alexandre Julliard 16 Dec '10

16 Dec '10

Piotr Caban <piotr(a)codeweavers.com> writes: > -static int inode_check_dir( struct inode *parent, const char *name ) > -{ > - char *path; > - unsigned int filter; > - struct inode *inode; > - struct stat st; > - int wd = -1, r = -1; > - > - path = inode_get_path( parent, strlen(name) ); > - if (!path) > - return r; > - > - strcat( path, name ); > - > - r = stat( path, &st ); > - if (r < 0) goto end; > - > - if (!S_ISDIR(st.st_mode)) > - { > - r = 0; > - goto end; > - } > - > - r = 1; > - > - filter = filter_from_inode( parent, 1 ); > - if (!filter) > - goto end; > - > - inode = inode_add( parent, st.st_dev, st.st_ino, name ); > - if (!inode || inode->wd != -1) > - goto end; > - > - wd = inotify_add_dir( path, filter ); > - if (wd != -1) > - inode_set_wd( inode, wd ); > - else > - free_inode( inode ); > - > -end: > - free( path ); > - return r; > -} You can't remove all this, you still need to add a watch for newly created directories. -- Alexandre Julliard julliard(a)winehq.org

1 0

Testbot: User not logged in Problem with WVISTAADM
by André Hentschel 15 Dec '10

15 Dec '10

Hi Greg, there is a noisy problem with the WVISTAADM, which causes much tests to be shown as "Failed" in the patchtracker. should we blacklist the Message returned by WVISTAADM or can you fix the underlying problem? -- Best Regards, André Hentschel

3 4

Thread-safety in winmm?
by Joerg-Cyril.Hoehle＠t-systems.com 15 Dec '10

15 Dec '10

Hi, I'm thankful for any kind of information regarding thread-safety and re-entrancy involving WINMM. I found little on the net. Basically, I'm wondering what kind of guarantees must code in winmm (which includes the MCI) provide w.r.t. multiple application threads using the winmm API. Use cases for the MCI: A) Thread 1: MCI_PLAY, thread 2: MCI_STOP B) Thread 1: MCI_PLAY, 2: MCI_PAUSE, 3: MCI_STOP C) Thread 1: MCI_PLAY, 2: MCI_STOP, 3: WINMM shutdown via ^C D) Any 2 MCI commands from 2 threads, excl. MCI_CLOSE E) Including MCI_CLOSE For instance, the following construct that is used in some Wine MCI drivers is not fully thread safe: WINE_MCI* wmw = (WINE_MCI*)mciGetDriverData(wDevID); /* oops */ if (wmw) { /* oops */ EnterCriticalSection(wmw->cs); The thread may be preempted at oops time, another one may close the device meanwhile; crash follows. Note that the MCI is easier to deal with than the rest of WINMM, because it has no CALLBACK_FUNCTION. Function callbacks create an additional burden via re-entrant code. Often enough, they are invoked within a critical section (e.g. lookup xyzNotifiyClient() in wine*.drv/). However, a CS is not a MUTEX, and callback code will happily enter any critical section already hold within the same thread! One could say that critical sections give a wrong feeling of security. Presumably CS are used over mutexes all over the place because a) they are said to be more efficient b) using mutexes to protect against re-entrant code is no solution either, as dead-locks would occur. The above example shows that it would be tough to make a driver thread-safe without the help of the central WINMM component. So I'm left wondering what are adequate levels of protection that I should design into code while I'm rewriting some of the MCI. - Should I care about robustness against driver shutdown as a consequence of ^C? (a particular case of close while playing) - One may argue that re-entrancy is not an issue for WINMM. Bug #3930, comment #37 explains that function callbacks should be invoked from another thread... - What is the worst that I should expect? (We already know that apps call winmm functions from within callbacks even though MSDN says it may deadlock...) - What should WINMM guarantee? - Will DRV_CLOSE ever be called once only? - Should a closing driver kill player threads or patiently wait? I've been thinking about supporting a graduated scenario similar to: E: robustness against any sequence of commands from a single thread; Bug #22978 shows mciseq does not satisfy that condition. D: asynchronous player + thread-safe stop/reset command; C: ... A: fully thread- and re-entrancy-safe One thing I've learned already is that innocent looking code such as PostThreadMessage() may cause the currently running thread to be preempted, even though it did not yet set all state variables correctly. E.g., the app may process a notification earlier that you'd believe it does! Thanks for any pointers, Jörg Höhle

1 0

Re: ntdll: use off_t instead of long
by Alexandre Julliard 15 Dec '10

15 Dec '10

André Hentschel <nerv(a)dawncrow.de> writes: > This is more correct and prevents a crash on sparc (at least what > Austin and me acutally reached) It's not more correct, it's just moving the problem around... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] cmd: Add CHOICE builtin with DOS6 to XP commandline parameter
by Alexandre Julliard 15 Dec '10

15 Dec '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + while (!errorlevel) { > + count = 0; > + while (!count){ > + /* FIXME: Add support for option /T */ > + WCMD_ReadFile(GetStdHandle(STD_INPUT_HANDLE), answer, 1, &count, NULL); > + if (!count) { > + WINE_TRACE("no more data from stdin\n"); > + if (have_console) > + SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), oldmode); > + > + HeapFree(GetProcessHeap(), 0, my_command); > + return; > + } > + } > + if (!opt_s) > + answer[0] = toupperW(answer[0]); > + > + ptr = strchrW(opt_c, answer[0]); > + if (ptr) { > + WCMD_output_asis(answer); > + WCMD_output(newline); > + if (have_console) > + SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), oldmode); > + > + errorlevel = (ptr - opt_c) + 1; > + WINE_TRACE("answer: %d\n", errorlevel); > + HeapFree(GetProcessHeap(), 0, my_command); > + return; > + } > + else > + { > + /* key not allowed: play a bell */ > + WINE_TRACE("key not allowed: %s\n", wine_dbgstr_w(answer)); > + WCMD_output_asis(bellW); > + } > + } > + /* This location is never reached */ It doesn't make sense to have a loop condition that never happens. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Dutch translation for notepad and winecfg changed
by James Mckenzie 15 Dec '10

15 Dec '10

Albert Pool <albertpool(a)solcon.nl> wrote: One patch per message, please. Please see the Submitting Patches page on the Wiki. > >--- > programs/notepad/Nl.rc | 5 +++-- > programs/winecfg/Nl.rc | 15 ++++++++------- > 2 files changed, 11 insertions(+), 9 deletions(-) > >diff --git a/programs/notepad/Nl.rc b/programs/notepad/Nl.rc >index f5eeaab..31178a6 100644 >--- a/programs/notepad/Nl.rc >+++ b/programs/notepad/Nl.rc >@@ -1,7 +1,8 @@ > /* > * Notepad (Dutch resources) > * >- * Copyright 2003 Hans Leidekker >+ * Copyright 2003 Hans Leidekker Please follow the existing spacing in the file, this type of change is not needed. >+ * Copyright 2010 Albert Pool James McKenzie

1 0

Re: [PATCH 4/5] mshtml: Forward PluginHost's QueryService calls to window object
by Marvin 15 Dec '10

15 Dec '10

1 0

re: winetricks IE6 installer not downloading
by Dan Kegel 14 Dec '10

14 Dec '10

This is fixed in svn, try http://winezeug.googlecode.com/svn-history/r2031/trunk/winetricks

1 0

Re: shlwapi/tests: Standardize the COM usage in ordinal.c.
by Marvin 14 Dec '10

14 Dec '10

2 1

Re: ole32/tests: Standardize the COM usage in clipboard.c.
by Marvin 14 Dec '10

14 Dec '10

2 1

Re: shell32: Fix shelllink test to not crash on NT4
by Marvin 14 Dec '10

14 Dec '10

1 0

winetricks IE6 installer not downloading
by Jevgeni Burtin 14 Dec '10

14 Dec '10

Hi, When I try to install IE6 using winetricks it pops up installer wizard and when I press I accept installer tells me following error: "Setup was unable to download required components". (Internet connection is working well) Screenshot of error: http://ubuntuone.com/p/Tbs/ Thanks.

1 0

Re: oleaut32/tests: Use an iface instead of an vtbl pointer in IRecordInfoImpl
by Marvin 14 Dec '10

14 Dec '10

1 0

RFC: Pass ReadFile and WriteFile requests on sockets to ws2_32.dll
by Erich Hoover 14 Dec '10

14 Dec '10

Attached is a patch to take kernel32/ntdll ReadFile and WriteFile requests on sockets and pass them to WSARecv and WSASend. This patch is part of a series I'm working on for the infamous C&C networking bug (Bug #7929). The functionality added by this patch was requested by a previous RFC response so that ReadFile and WriteFile requests will have all the same filtering as WSARecv and WSASend. Any and all feedback is greatly appreciated. Erich Hoover ehoover(a)mines.edu

2 1

Re: msctf/tests: Standardize the COM usage in inputprocessor.c.msctf/tests.
by Marvin 14 Dec '10

14 Dec '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=7584 Your paranoid android. === W7PRO (32 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:757: Test failed: Deactivation came unexpectedly === W7PROX64 (32 bit inputprocessor) === inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus === W7PROX64 (64 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:757: Test failed: Deactivation came unexpectedly

2 1

Re: winealsa.drv: use ERR() for fatal errors instead of WARN()
by Alexandre Julliard 14 Dec '10

14 Dec '10

Austin English <austinenglish(a)gmail.com> writes: > See http://bugs.winehq.org/show_bug.cgi?id=22034 If the errors are properly handled, there's no reason to have an ERR. If they aren't, that should be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 6 resend)
by Alexandre Julliard 14 Dec '10

14 Dec '10

Charles Davis <cdavis(a)mymail.mines.edu> writes: > +#if defined(HAVE_GETATTRLIST) && defined(ATTR_VOL_CAPABILITIES) && \ > + defined(VOL_CAPABILITIES_FORMAT) && defined(VOL_CAP_FMT_CASE_SENSITIVE) > + char *mntpoint = NULL; > + struct attrlist attr; > + struct vol_caps caps; > + struct get_fsid get_fsid; > + struct fs_cache *entry; > + > + /* First get the FS ID of the volume */ > + attr.bitmapcount = ATTR_BIT_MAP_COUNT; > + attr.reserved = 0; > + attr.commonattr = ATTR_CMN_DEVID|ATTR_CMN_FSID; > + attr.volattr = attr.dirattr = attr.fileattr = attr.forkattr = 0; > + get_fsid.size = 0; > + if (getattrlist( dir, &attr, &get_fsid, sizeof(get_fsid), 0 ) != 0 || > + get_fsid.size != sizeof(get_fsid)) > + return TRUE; > + /* Try to look it up in the cache */ > + entry = look_up_fs_cache( get_fsid.dev ); > + if (entry && !memcmp( &entry->fsid, &get_fsid.fsid, sizeof(fsid_t) )) > + /* Cache lookup succeeded */ > + return entry->case_sensitive; > + /* Cache is stale at this point, we have to update it */ > + > + mntpoint = get_device_mount_point( get_fsid.dev ); > + /* Now look up the case-sensitivity */ > + attr.commonattr = 0; > + attr.volattr = ATTR_VOL_INFO|ATTR_VOL_CAPABILITIES; > + if (getattrlist( mntpoint, &attr, &caps, sizeof(caps), 0 ) == 0) > + { If that can fail then you need to structure this differently, otherwise you'll end up looking up the mount point on every call. Also please put that chunk in a separate function, it's totally different from the statfs code path. > +#elif defined(__linux__) > + /* Only assume CIOPFS is case insensitive. */ > + /* Normally, we'd have to parse the mtab to find out exactly what > + * kind of FUSE FS this is. But, someone on wine-devel suggested > + * a shortcut. We'll stat a special file in the directory. If it's > + * there, we'll assume it's a CIOPFS, else not. > + * This will break if somebody puts a file named ".ciopfs" in a non- > + * CIOPFS directory. > + */ > + cifile = RtlAllocateHeap( GetProcessHeap(), 0, strlen( dir )+sizeof("/.ciopfs") ); > + if (!cifile) return TRUE; > + strcpy( cifile, dir ); > + strcat( cifile, "/.ciopfs" ); > + if (stat( cifile, &st ) == 0) > + { > + RtlFreeHeap( GetProcessHeap(), 0, cifile ); > + return FALSE; > + } You lost the statfs here. > @@ -1872,7 +2097,7 @@ static NTSTATUS find_file_in_dir( char *unix_name, int pos, const WCHAR *name, i > { > ret = ntdll_umbstowcs( 0, de[1].d_name, strlen(de[1].d_name), > buffer, MAX_DIR_ENTRY_LEN ); > - if (ret == length && !memicmpW( buffer, name, length)) > + if (ret == length && !memicmpW( buffer, name, length )) Please avoid gratuitous whitespace changes. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] amstream: Be more verbose when whe can't test
by Marvin 13 Dec '10

13 Dec '10

1 0

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list
by Alexandre Julliard 13 Dec '10

13 Dec '10

Andrew Eikum <aeikum(a)codeweavers.com> writes: > - /* search element n in list */ > - for(i=0; i < index; i++) > + i = 0; > + LIST_FOR_EACH_ENTRY (pTypeInfo, &This->typeinfo_list, ITypeInfoImpl, entry) > + { > + if(i >= index) > + break; > + ++i; > + } It looks like an array would be more appropriate than a list. -- Alexandre Julliard julliard(a)winehq.org

2 4

Removal of wineaudioio.drv
by Michael Stefaniuc 13 Dec '10

13 Dec '10

Hello guys, I have just submitted a patch to remove wineaudioio.drv from Wine. It was used by Solaris but the Solaris versions 9 and 10 that are "supported" by Wine do not have it any more. Solaris is using ESD at the moment and newer version will move to OSS4. If anybody has a reason why wineaudioio.drv should stay in please speak up *now*. This is your chance. Of course if you do speak up you volunteer to maintain wineaudioio.drv ;) bye michael

1 1

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 4)
by Chris Robinson 13 Dec '10

13 Dec '10

On Sunday, December 12, 2010 2:19:42 pm Louis Lenders wrote: > +#define USER_HZ_TO_TICKSPERSEC(x,y) (ULONGLONG)10000000 * x / y I'd recommend adding proper parenthesis, to avoid potential problems with order-of-operations. #define USER_HZ_TO_TICKSPERSEC(x,y) ((ULONGLONG)10000000 * (x) / (y)) That way it won't break if you do math in the argument for some reason, like with USER_HZ_TO_TICKSPERSEC(val+1, user_hz) or USER_HZ_TO_TICKSPERSEC(val, user_hz*2) > + static long user_hz; > + > + user_hz = sysconf(_SC_CLK_TCK); There's no real point to making it static if you're always going to (re)set the variable. It would be better to just make the call once: static long user_hz; i(user_hz == 0) user_hz = sysconf(_SC_CLK_TCK); You could also make it an inline function to avoid making user_hz a parameter: /* Convert system clock to 100ns tics */ static long user_hz; static inline ULONGLONG ClockToTics(ULONGLONG val) { i(user_hz == 0) user_hz = sysconf(_SC_CLK_TCK); return val * 10000000 / user_hz; } ... sppi->IdleTime.QuadPart = ClockToTics(idle); sppi->KernelTime.QuadPart = ClockToTics(sys); ...etc... Though I'll defer judgement to others as to what's better.

2 1

Re: msi: Fix testfailure on some 2k3 machines (try 2)
by Marvin 13 Dec '10

13 Dec '10

1 0

Re: msi: Fix testfailure on some 2k3 machines
by Hans Leidekker 13 Dec '10

13 Dec '10

On Sun, 2010-12-12 at 22:44 +0100, André Hentschel wrote: > r = MsiOpenProductA(prodcode, &hprod); > - ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || r == ERROR_SUCCESS, > - "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED or ERROR_SUCCESS, got %d\n", r); > + ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || ERROR_INSTALL_PACKAGE_REJECTED || r == ERROR_SUCCESS, > + "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED, ERROR_INSTALL_PACKAGE_REJECTED or ERROR_SUCCESS, got %d\n", r); ERROR_INSTALL_PACKAGE_REJECTED means the user has insufficient rights. Look at how action.c handles this error, for example.

2 1

Re: [PATCH] cmd: Allow GOTO to a label, which has a following whitespace, with test
by Marvin 12 Dec '10

12 Dec '10

1 0

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 4)
by Nikolay Sivov 12 Dec '10

12 Dec '10

On 12/13/2010 01:19, Louis Lenders wrote: > Change from try 3: improved macro as per Juan's suggestion, and made user_hz a static variable > > /proc/stat measures the times > in units of USER_HZ, whereas Windows uses 100ns ticks. > This should fix http://bugs.winehq.org/show_bug.cgi?id=23847 > @@ -1591,6 +1593,9 @@ NTSTATUS WINAPI NtQuerySystemInformation( > int count; > char name[10]; > char line[255]; > + static long user_hz; > + > + user_hz = sysconf(_SC_CLK_TCK); This change doesn't make any difference, I think the idea was to make it global.

1 0

← Newer
1
2
3
4
5
6
7
8
9
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 2010