wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

Re: [3/4] msxml: Implement removeAttribute
by Mikołaj Zalewski 15 Nov '07

15 Nov '07

A problem with this patch is that the user may have an IXMLDOMNode * reference to the attribute node being removed. The xmlFreeProp will free the xmlnode so accessing the IXMLDOMNode could result in memory corruption. Under MSXML it's possible to access such node and even reconnect it e.g. to a different documents (at least I seem to remember such a thing for element nodes). I don't think supporting it is possible with our current reference counting only for the whole document. I was thinking about also keeping reference counts for each connected component and each node. The connected component count could be used to determine if the node can be freed in such a situation and the node count could be used to update the connected component counts if the tree gets split. But so far I haven't written any code (Another possibility is to keep in each node the refcount of the whole subtree starting in this node. This is more elegant but it would take a linear time with respect to the tree height to update the refcount). Mikołaj Zalewski

2 1

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

← Newer
1
...
14
15
16
17
18
19
20
...
28
Older →

Jump to page:

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 November 2007