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

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
by Stefan Dösinger 15 Nov '07

15 Nov '07

Am Donnerstag, 20. September 2007 03:49:40 schrieb Carroll Vance: > I have tested this with a driver I made and it seemed to > work fine. I don't know much about ntoskrnl.exe, but if you have a test driver, you may want to include it in the patch. Other libraries have a set of regression tests in dlls/<lib>/tests . ntoskrnl.exe doesn't have any yet, but I don't know if that is a policy or just because no one started it yet.

2 1

Re: dlls/msi/string.c -- fix use of signed versus unsigned (RESEND)
by James Hawkins 15 Nov '07

15 Nov '07

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

2 3

Question: How to link kernel32.dll.so to get loaded at a fixed address (0x7bf0000) each time in a Solaris environment
by Chris McKillroy 15 Nov '07

15 Nov '07

Hello everybody, I recently run into the following problem: I tried to use a DLL injection into a process started by a controller Process using an external code hooking dll (http://www.madshi.net/madCodeHookDescription.htm) to achieve some sort of datalink. In a windows environment the solution works stable and perfectly. (Controller Process NWNX4 as provided by nwnx4.org, child process nwn2server.exe, as provided by Obsidian - all legal and intended use). Under Solaris10 (wine version 0.9.49) the child process regularly crashed upon creation, respectivley when the dll was injected. After a lengthy debugging session it appeared that kernel32.dll.so always gets loaded to a varying address by the runtime linker, which seems to crash the whole procedure. I succeeded making a kernel32.dll.so which gets loaded to a constant address in Solaris by using the tool "crle" on Solarice, but I couldn't control the address - it appeared to be somewhat arbitrary which base address was chosen. The crash problem remained. I would like to try if the procedure would work if I could get a kernel32.dll.so which always gets loaded to the same address 0x7bf0000, as in standard windows. After a posting to the Solaris Linker mailing list we got an answer (http://mail.opensolaris.org/pipermail/tools-linking/2007-November/000945.ht…) which was designed to work with the SUN toolchain. 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 0x7bf0000each time under Solaris. Thanks Chris

2 1

re: Question: How to link kernel32.dll.so to get loaded at a fixed
by Dan Kegel 15 Nov '07

15 Nov '07

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

2 1

Re: Start: Convert start to Unicode. [try4]
by Dmitry Timoshkov 15 Nov '07

15 Nov '07

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

1 0

Re: [2/6] msvcrt: Implement strcat_s
by Dmitry Timoshkov 15 Nov '07

15 Nov '07

"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.

1 0

Re: [3/6] msvcrt: implement _mbsnbcpy_s
by Dmitry Timoshkov 15 Nov '07

15 Nov '07

"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.

1 0

Re: [1/6] msvcrt: Implement strcpy_s
by Dmitry Timoshkov 15 Nov '07

15 Nov '07

"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.

1 0

Re: taskmgr/perfpage.c simplification (RESEND)
by Alexandre Julliard 15 Nov '07

15 Nov '07

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Another simplifcation I'd like to ping if you don't mind. > > ---------- Forwarded message ---------- > From: Gerald Pfeifer <gerald(a)pfeifer.com> > To: <wine-patches(a)winehq.org> > Date: Thu, 1 Nov 2007 16:14:28 +0100 (CET) > Subject: taskmgr/perfpage.c simplification > > 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. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Patch to make Wine prettier
by Alexander Nicolaysen Sørnes 15 Nov '07

15 Nov '07

On Sunday 11 November 2007 14:56:21 Fred . wrote: > Applications that run under Wine looks so legacy like Windows 95. > > This patch makes the software applications look a bit more modern and > prettier by changing the colors from the Windows 95-look to the > "Windows Classic"-look, the one in Windows ME/2000/2003. > > I have not yet tested the patch. Because I was unable to compile Wine > on my computer. > > The file should goto; > /wine/dlls/user32/resources/display.rc Great idea, but the patch does not change anything. Alexander N. Sørnes

1 0