November 2007 - Wine-Devel - list.winehq.org

Re: Valgrind results for Nov 12 & 13

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Oh, he'd undoubtedly prefer ignoring to memsetting. > But he would like it even better if we can > avoid sending unneeded bytes. Are the extra > bytes at the end (they ought to be)? If so, > whatever decides how many bytes to send could > be just a bit smarter. Actually memset is OK for server requests, not because of Valgrind but because of backwards compatibility concerns. It makes it possible to extend a request knowing that old clients will send 0 for the new fields. -- Alexandre Julliard julliard(a)winehq.org

Nov. 15, 2007

Re: Question: How to link kernel32.dll.so to get loaded at a fixed

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Good question. It's probably pretty involved; you may have to wait > for an expert to try it and see what it breaks. Alexandre suggested > it might not work recently (see > http://bugs.winehq.org/show_bug.cgi?id=10273#c17 ), but > perhaps he's being overly pessimistic. > > BTW if that idea works for Solaris, it might work for Linux, too. It works on Linux already, we are using prelink to set the kernel32 load address. That doesn't mean you can avoid -fPIC since the address is not guaranteed to be available. -- Alexandre Julliard julliard(a)winehq.org

Nov. 15, 2007

Re: dlls/msi/string.c -- fix use of signed versus unsigned (RESEND)

by James Hawkins

On 11/14/07, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Last one for today, promised. ;-) > > Gerald > > ---------- Forwarded message ---------- > From: Gerald Pfeifer <gerald(a)pfeifer.com> > To: <wine-patches(a)winehq.org> > Date: Sat, 3 Nov 2007 20:02:18 +0100 (CET) > Subject: dlls/msi/string.c -- fix use of signed versus unsigned > > This was a bit more tricky, but I hope I got it right. Basically the > problem here was that we used a parameter/variable n of type UINT both > as a true unsigned (the return of the hash function) and as a true signed > variable (comparing against -1). > > This removes the following three compiler diagnostics that I've been > seeing. In other words, this is also addressing very real issues! > > string.c: In function 'msi_addstring': > string.c:208: warning: comparison of unsigned expression < 0 is always false > string.c: In function 'msi_addstringW': > string.c:260: warning: comparison of unsigned expression < 0 is always false > string.c: In function 'msi_string2idW': > string.c:400: warning: comparison between signed and unsigned > > Gerald > > ChangeLog: > Fix use of signed versus unsigned variables. > This change is unnecessarily complicated. Also, the only actual bug of this type that was in string.c (comparison..always false) has been fixed: commit 1c1cf26997cdf491642b2086ad817a79ced99a2e Author: James Hawkins <truiken(a)gmail.com> Date: Mon Nov 5 04:49:07 2007 -0500 msi: Explicitly check the returned value against -1 as the variable is unsigned. All these patches to silence extraneous warnings makes me wonder whether you really understand the code or if you're just trying to get rid of warnings... -- James Hawkins

Nov. 15, 2007

re: Question: How to link kernel32.dll.so to get loaded at a fixed

by Dan Kegel

Chris McKillroy asked: > I tried to use a DLL injection ... > (http://www.madshi.net/madCodeHookDescription.htm) > Under Solaris10 (wine version 0.9.49) the child process regularly > crashed... [because] kernel32.dll.so > always gets loaded to a varying address by the runtime linker Yep. Known problem with Wine. > After a posting to the Solaris Linker mailing list we got an answer > (http://mail.opensolaris.org/pipermail/tools-linking/2007-November/000945.ht…) > ... > My question now is: > How would I have to change things (makefile or whatsever) to get > kernel32.dll.so linked in a way to achive that it will be loaded to > address 0x7bf0000 each time under Solaris. Good question. It's probably pretty involved; you may have to wait for an expert to try it and see what it breaks. Alexandre suggested it might not work recently (see http://bugs.winehq.org/show_bug.cgi?id=10273#c17 ), but perhaps he's being overly pessimistic. BTW if that idea works for Solaris, it might work for Linux, too. - Dan

Nov. 15, 2007

Re: Valgrind results for Nov 12 & 13

by Dan Kegel

On Nov 15, 2007 2:33 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Since wineserver sequests are sent without an attempt to reduce the size of > written data (and memset(0) is a part of SERVER_START_REQ macro) I'd assume > that it's ok to do the same for server APC requests. Otherwise server calls > need to be optimized as well. I did optimize one recently for just this reason: http://www.winehq.org/pipermail/wine-cvs/2007-October/037608.html I haven't looked to see if the same technique can be used in the NTDLL_queue_process_apc case.

Nov. 15, 2007

Re: Start: Convert start to Unicode. [try4]

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > Changelog: > Convert start.exe to Unicode. Please carefully check buffer sizes passed to Win32 APIs. -- Dmitry.

Nov. 15, 2007

Re: [2/6] msvcrt: Implement strcat_s

by Dmitry Timoshkov

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote: > +@ cdecl strcat_s(str str) MSVCRT_strcat_s ... > +int CDECL MSVCRT_strcat_s( char* dst, size_t elem, const char* src ) > +{ > + unsigned int i, j; ... > +static int (*pstrcat_s)(char *dst, unsigned int len, const char *src); This one has the same objections as 2 previous patches. -- Dmitry.

Nov. 15, 2007

Re: [3/6] msvcrt: implement _mbsnbcpy_s

by Dmitry Timoshkov

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote: > +int CDECL _mbsnbcpy_s(unsigned char* dst, MSVCRT_size_t size, const unsigned char* src, MSVCRT_size_t n) > +{ > + unsigned int pos = 0; Same problem as with strcpy_s patch, and in addition MSVCRT_size_t is used. Perhaps strcpy_s implementation should use MSVCRT_size_t as well. > +@ cdecl _mbsnbcpy_s(ptr str long) The spec entry has wrong number of parameters. -- Dmitry.

Nov. 15, 2007

Re: [1/6] msvcrt: Implement strcpy_s

by Dmitry Timoshkov

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote: > +int CDECL MSVCRT_strcpy_s( char* dst, size_t elem, const char* src ) > +{ > + unsigned int i; ... > + for(i = 0; i < elem; i++) Since 'i' is used to enumerate [0 < elem] and elem has type size_t, 'i' should have type size_t as well. > +static int (*pstrcpy_s)(char *dst, unsigned int len, const char *src); But here 'len' has type 'unsigned int' for some reason. -- Dmitry.

Nov. 15, 2007

Re: taskmgr/perfpage.c simplification (RESEND)

by Gerald Pfeifer

On Thu, 15 Nov 2007, Alexandre Julliard wrote: >> CpuUsage and CpuKernelUsage are of type ULONG, so it does not make >> sense checking whether they are less than 0. > The checks should most likely done in PerfDataGetProcessorUsage before > converting to ULONG. Fair enough. I wasn't sure we want to incur that overhead, but it also shouldn't be that much. Updated patch below. Gerald ChangeLog: Move out-of-domain checking into PerfDataGetProcessorUsage() and PerfDataGetProcessorSystemUsage(). Index: programs/taskmgr/perfdata.c =================================================================== RCS file: /home/wine/wine/programs/taskmgr/perfdata.c,v retrieving revision 1.6 diff -u -3 -p -r1.6 perfdata.c --- programs/taskmgr/perfdata.c 22 Oct 2007 14:57:58 -0000 1.6 +++ programs/taskmgr/perfdata.c 15 Nov 2007 13:01:27 -0000 @@ -332,11 +332,19 @@ ULONG PerfDataGetProcessCount(void) ULONG PerfDataGetProcessorUsage(void) { + if( dbIdleTime < 0.0 ) + return 0; + if( dbIdleTime > 100.0 ) + return 100; return (ULONG)dbIdleTime; } ULONG PerfDataGetProcessorSystemUsage(void) { + if( dbKernelTime < 0.0 ) + return 0; + if( dbKernelTime > 100.0 ) + return 100; return (ULONG)dbKernelTime; } Index: programs/taskmgr/perfpage.c =================================================================== RCS file: /home/wine/wine/programs/taskmgr/perfpage.c,v retrieving revision 1.8 diff -u -3 -p -r1.8 perfpage.c --- programs/taskmgr/perfpage.c 23 May 2006 12:49:22 -0000 1.8 +++ programs/taskmgr/perfpage.c 15 Nov 2007 13:01:27 -0000 @@ -234,10 +234,6 @@ static DWORD WINAPI PerformancePageRefre */ CpuUsage = PerfDataGetProcessorUsage(); CpuKernelUsage = PerfDataGetProcessorSystemUsage(); - if (CpuUsage < 0 ) CpuUsage = 0; - if (CpuUsage > 100) CpuUsage = 100; - if (CpuKernelUsage < 0) CpuKernelUsage = 0; - if (CpuKernelUsage > 100) CpuKernelUsage = 100; /* * Get the memory usage

Nov. 15, 2007