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

Re: [PATCH] bits: Implemented BITS_IBackgroundCopyManager_Release and Test (12/12)

by Detlef Riekenberg

On Do, 2007-11-15 at 08:24 -0800, Roy Shea wrote: > dlls/qmgr/qmgr.c | 19 ++++++++++++++- > dlls/qmgr/qmgr.spec | 4 +- > dlls/qmgr/tests/Makefile.in | 17 ++++++++++++++ > dlls/qmgr/tests/qmgr.c | 50 > +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 86 insertions(+), 4 deletions(-) The initial test can always be a seperate Patch. -- By by ... Detlef

Nov. 15, 2007

Re: [PATCH] bits: Added BITS IDL and standard header file (3/12)

by Detlef Riekenberg

On Do, 2007-11-15 at 08:21 -0800, Roy Shea wrote: > +++ b/include/bitsmsg.h > @@ -0,0 +1,83 @@ > +/* > + * Return values that may be generated by BITS as described at: > + * http://msdn2.microsoft.com/en-us/library/aa362823.aspx We want to remove all links to MSDN from wine (the URL changes to often) and include/bitsmsg.h fit perfect in a seperate Patch. -- By by ... Detlef

Nov. 15, 2007

Re: [PATCH] bits: Add implementation of BITS_IClassFactory_CreateInstance (9/12)

by Detlef Riekenberg

On Do, 2007-11-15 at 08:24 -0800, Roy Shea wrote: > Implementation of BITS_IClassFactory_CreateInstance ond the support > function > BackgroundCopyManagerConstructor. > --- > dlls/Makefile.in | 5 +++++ > + qmgrprxy \ > + qmgrprxy/libqmgrprxy.$(IMPLIBEXT) \ This changes are unrelated for the actual Patch You should never send any autogenerated code. (<wine>/tools/make_makefiles does the changes during commit) -- By by ... Detlef

Nov. 15, 2007

Re: [3/4] msxml: Implement removeAttribute

by Alistair Leslie-Hughes

Mikołaj Zalewski wrote: > 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 > > Thanks for pointing this out. Ill write some tests, and retry again shortly. Alistair Leslie-Hughes

Nov. 15, 2007

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread

by Saulius Krasuckas

* On Fri, 21 Sep 2007, Stefan [iso-8859-1] D�singer wrote: > * 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. Doesn't that need to be product' licence compatible? > 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. Cool idea, of course, but my old question is: Does MinGW have any support for compiling KMD/WDM binaries today?

Nov. 15, 2007

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

by Gerald Pfeifer

On Thu, 15 Nov 2007, James Hawkins wrote: > I don't see how silencing warnings catches any regression. With default options older versions of GCC currently issue two warnings for all of Wine, so any warning regression immediately jumps out for analysis to see whether it is a real regression. If instead of two the base is 2000, just another one is easy to miss. That's the experience we made with GCC, and some other projects I have worked on. > If you really want to keep sending in patches for these warnings, > please be more conservative. Unsigned comparisons for less than 0 > are actual bugs, so you can be sure about those I actually plan to focus on those. There are about fifty left. Just for patches I have sent already or on my disk it would be nice to see those considered because I did invest time on those. Gerald

Nov. 15, 2007

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

by James Hawkins

On 11/15/07, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > On Thu, 15 Nov 2007, James Hawkins wrote: > >> ChangeLog: > >> Fix use of signed versus unsigned variables. > > This change is unnecessarily complicated. > > How do you propose to address the following? > > string.c: In function 'msi_addstring': > string.c:208: warning: comparison between signed and unsigned > string.c: In function 'msi_addstringW': > string.c:260: warning: comparison between signed and unsigned > string.c: In function 'msi_string2idW': > string.c:400: warning: comparison between signed and unsigned > Turn off the warning. > > Also, the only actual bug of this type that was in string.c > > (comparison..always false) has been fixed: > > Happy to hear that! > > > 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... > > I'm mostly trying to get bugs fixed. In the last couple of weeks my > patches have addressed several realy bugs and/or triggered others to > look into bugs, both of which I'd claim is a good thing. ;-) > Ok, but this patch didn't fix any bug and it's makes an already complicated module that much more complicated. > Reducing the number of warnings is one way to catch regressions easier > and get bugs addressed (not all warnings really are due to real bugs, > of course, but that's hard to see up front). > I don't see how silencing warnings catches any regression. It's hard to see for you because you're changing code you don't understand. > And, no, I am not an expert of the entire Wine codebase, and certainly > not to the level you and others are for those pieces you maintain. And > the MSI code apparently is one of the more tricky ones... > We all appreciate your effort, but we could use your resources in more helpful ways. I suggest you look through bugzilla, pick out a bug, and try to fix that bug. You'll become more familiar with the code that way and you'll be fixing an actual reported bug. If you really want to keep sending in patches for these warnings, please be more conservative. Unsigned comparisons for less than 0 are actual bugs, so you can be sure about those, but the other warnings you need to spend a lot of time to see if there really is any bug. Warnings are just warnings, not errors, and there's a reason we don't turn all the warnings on. -- James Hawkins

Nov. 15, 2007

Re: Question: How to link kernel32.dll.so to get loaded at a fixed address (0x7bf0000) each time in a Solaris environment

by Marcus Meissner

On Thu, Nov 15, 2007 at 01:12:07PM +0100, Chris McKillroy wrote: > 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. For Linux we use the ELF tool "prelink". It should however be possible write a LD linker script to do the same. Not sure if this is applicable to Solaris. Ciao, Marcus

Nov. 15, 2007

Re: Valgrind results for Nov 12 & 13

by Jeremy White

> p.s. the mailing list archives seem to be not archiving new messages :-( Jer restarted mailman and it seems to be fixed now. Presumably a side effect of the db going nuts yesterday. cheers, Jeremy

Nov. 15, 2007

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

by Gerald Pfeifer

On Thu, 15 Nov 2007, James Hawkins wrote: >> ChangeLog: >> Fix use of signed versus unsigned variables. > This change is unnecessarily complicated. How do you propose to address the following? string.c: In function 'msi_addstring': string.c:208: warning: comparison between signed and unsigned string.c: In function 'msi_addstringW': string.c:260: warning: comparison between signed and unsigned string.c: In function 'msi_string2idW': string.c:400: warning: comparison between signed and unsigned > Also, the only actual bug of this type that was in string.c > (comparison..always false) has been fixed: Happy to hear that! > 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... I'm mostly trying to get bugs fixed. In the last couple of weeks my patches have addressed several realy bugs and/or triggered others to look into bugs, both of which I'd claim is a good thing. ;-) Reducing the number of warnings is one way to catch regressions easier and get bugs addressed (not all warnings really are due to real bugs, of course, but that's hard to see up front). And, no, I am not an expert of the entire Wine codebase, and certainly not to the level you and others are for those pieces you maintain. And the MSI code apparently is one of the more tricky ones... Gerald

Nov. 15, 2007