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

Re: server: Add a call for retrieving the image file name of a process.
by Alexandre Julliard Nov. 16, 2007

Nov. 16, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > --- > dlls/ntdll/process.c | 20 +++++++++++++++++++- > dlls/ntdll/tests/info.c | 36 ++++++++++++++++++++++++++++++++++++ > server/process.c | 31 +++++++++++++++++++++++++++++++ > server/protocol.def | 9 +++++++++ > 4 files changed, 95 insertions(+), 1 deletions(-) You should use the existing get_dll_info request for that. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/6] try 2: msvcrt: Implement strcpy_s
by Detlef Riekenberg Nov. 16, 2007

Nov. 16, 2007

On Do, 2007-11-15 at 17:35 +0100, Stefan Dösinger wrote: > + memset(dest, 'X', sizeof(dest)); > + ret = pstrcpy_s(dest, sizeof(dest), small); > + ok(ret == 0, "Copying a string into a big enough destination > returned %d, expected 0\n", ret); > + ok(dest[0] == 's' && dest[1] == 'm' && dest[2] == 'a' && dest[3] > == 'l' && > + dest[4] == 'l' && dest[5] == '\0'&& dest[6] == 'X' && dest[7] > == 'X', Is it really needed to check the memory after the end of the string? Does an application depend on this? --- cut --- memset(dest, 'X', sizeof(dest)-1); /* never read past the buffer, when we check the result */ dest[sizeof(dest)-1] = '\0'; ret = pstrcpy_s(dest, sizeof(dest), small); ok( !ret && !lstrcmpA(dest, small), "got %d and '%s' (expected '0' and '%s')\n", ret, dest, small); -- cut -- For my tests with buffers, i found it useful to test with: - buffer present, but size is 0 - buffer one byte smaller as the string (no space left for the '\0') - buffer large enough for the string, but no space left for the '\0' - buffer exact as needed - buffer one byte larger as needed - empty source string - NULL source - NULL target This allow you to verify, how the terminating '\0' is handled. Did you test with invalid pointers (crash / handled graceful)? -- By by ... Detlef

2 2

re: dlls/msi/string.c -- fix use of signed versus unsigned (RESEND)
by Dan Kegel Nov. 16, 2007

Nov. 16, 2007

Gerald Pfeifer wrote: > How do you propose to address the following? > string.c: In function 'msi_addstring': > string.c:208: warning: comparison between signed and unsigned For starters: diff --git a/configure.ac b/configure.ac index 3d62f45..c97aa8e 100644 --- a/configure.ac +++ b/configure.ac @@ -1134,6 +1134,7 @@ then WINE_TRY_CFLAGS([-fno-strict-aliasing]) WINE_TRY_CFLAGS([-Wdeclaration-after-statement]) WINE_TRY_CFLAGS([-Wwrite-strings]) + WINE_TRY_CFLAGS([-Wno-sign-compare]) dnl Check for noisy string.h saved_CFLAGS="$CFLAGS" Then, after we've fixed all the real bugs, maybe consider going back and turning on the signed/unsigned comparison warning.

1 0

Re: [2/6] try 2: msvcrt: implement strcat_s
by Dmitry Timoshkov Nov. 16, 2007

Nov. 16, 2007

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote: > +@ cdecl strcat_s(str str) MSVCRT_strcat_s ... > +int CDECL MSVCRT_strcat_s( char* dst, MSVCRT_size_t elem, const char* src ) The spec file entry still has wrong number of parameters. -- Dmitry.

1 0

Re: [3/6] try 2: msvcrt: implement _mbsnbcpy_s
by Detlef Riekenberg Nov. 15, 2007

Nov. 15, 2007

On Do, 2007-11-15 at 17:37 +0100, Stefan Dösinger wrote: > + const unsigned char small[] = "small"; > + int ret; > + memset(dest, 'X', sizeof(dest)); > + ret = p_mbsnbcpy_s(dest, sizeof(dest), small, sizeof(small)); > + ok(ret == 0, "_mbsnbcpy_s: Copying a string into a big enough > destination returned %d, expected 0\n", ret); > + ok(dest[0] == 's' && dest[1] == 'm' && dest[2] == 'a' && dest[3] > == 'l' && > + dest[4] == 'l' && dest[5] == '\0'&& dest[6] == 'X' && dest[7] > == 'X you can use memcmp, when small is defined different: + const unsigned char small[] = "small\0XX"; I also suggest to make the buffer larger as you tell the api and always terminate the buffer unsigned char dest[10]; dest[sizeof(dest)-1] = '\0'; -- By by ... Detlef

1 0

Re: [PATCH] bits: Stub version of qmgr with svchost and proxy (5/12)
by Detlef Riekenberg Nov. 15, 2007

Nov. 15, 2007

On Do, 2007-11-15 at 08:22 -0800, Roy Shea wrote: > This adds svchost, proxying, and a stub version of the qmgr.dll > process. The > functional code in this patch is boilerplate required to run a DLL as > a > service via svchost. > --- > dlls/qmgr/Makefile.in | 6 ++- > dlls/qmgr/factory.c | 85 +++++++++++++++++++++++ > dlls/qmgr/qmgr.c | 8 ++- > dlls/qmgr/qmgr.inf | 32 +++++++++ > dlls/qmgr/qmgr.spec | 1 + > dlls/qmgr/qmgr_main.c | 98 +++++++++++++++++++++++++-- > dlls/qmgr/qmgr_private.h | 14 ++++- > dlls/qmgr/qmgr_service.c | 156 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/qmgr/rsrc.rc | 21 ++++++ > dlls/qmgrprxy/Makefile.in | 25 +++++++ > dlls/qmgrprxy/qmgrprxy.idl | 20 ++++++ > dlls/qmgrprxy/qmgrprxy.spec | 5 ++ > 12 files changed, 461 insertions(+), 10 deletions(-) It would be better, when you can reduce the Patchsize, but I have no knowledge about the code. (must everything from factory.c, qmgr_main.c and qmgr_service.c in the same Patch?) qmgrprxy looks really splitable from the rest as a seperate Patch. > -0,0 +1,5 @@ > +@ stdcall -private DllCanUnloadNow() > +@ stdcall -private DllGetClassObject(ptr ptr ptr) > +@ stdcall -private DllRegisterServer() > +@ stdcall -private DllUnregisterServer() > +@ stdcall GetProxyDllInfo(ptr ptr) I'm unable to find the code for this functions. Is everything build from qmgrprxy.idl ? -- By by ... Detlef

1 0

Re: [PATCH] bits: Implemented BITS_IBackgroundCopyManager_Release and Test (12/12)
by Detlef Riekenberg Nov. 15, 2007

Nov. 15, 2007

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

1 0

Re: [PATCH] bits: Added BITS IDL and standard header file (3/12)
by Detlef Riekenberg Nov. 15, 2007

Nov. 15, 2007

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

1 0

Re: [PATCH] bits: Add implementation of BITS_IClassFactory_CreateInstance (9/12)
by Detlef Riekenberg Nov. 15, 2007

Nov. 15, 2007

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

1 0

Re: [3/4] msxml: Implement removeAttribute
by Mikołaj Zalewski Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

"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 Nov. 15, 2007

Nov. 15, 2007

"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 Nov. 15, 2007

Nov. 15, 2007

"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 Nov. 15, 2007

Nov. 15, 2007

"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 Nov. 15, 2007

Nov. 15, 2007

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 Nov. 15, 2007

Nov. 15, 2007

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

server: avoid sending uninitialized bytes in break_thread()
by Dan Kegel Nov. 15, 2007

Nov. 15, 2007

In break_thread(), generate_debug_event() seems to send the entire ExceptionInformation array regardless of how many entries are used. The smart thing to do would be to send only the used elements, but I couldn't figure out how to do that. So here's a quick fix that just zeroes that array before calling generate_debug_event(). Is there a better way? Found by running the Word Viewer 97 under valgrind: 000d: wait_debug_event() = 0 { pid=000a, tid=000b, wait=(nil), event={exception,{code=80000003,flags=0,rec=(nil),addr=0x40007f0,params={},first=1} } Syscall param writev(vector[1]) points to uninitialised byte(s) at 0x40007F2: (within /lib/ld-2.5.so) by 0x806AF20: call_req_handler (request.c:249) by 0x8056075: main_loop (fd.c:523) Address 0x451AAB8 is 24 bytes inside a block of size 88 alloc'd by 0x806A167: set_reply_data_size (request.c:200) by 0x80510A6: req_wait_debug_event (request.h:96) by 0x806AFC7: call_req_handler (request.c:286) by 0x8056075: main_loop (fd.c:523) BTW, here's how I ran word viewer under valgrind: wordview.sh: WINEDIR=$HOME/wine-git; VALGRIND_CMD="/usr/local/valgrind-3.2.3-wine/bin/valgrind --trace-children=yes --gen-suppressions=all --suppressions=$WINEDIR/tools/valgrind-suppressions --leak-check=full --num-callers=20 " WINE=$WINEDIR/wine wget http://downloads.pcworld.com/pub/new/business/word_processing/wordview.exe cp wordview.exe ~/.wine/drive_c/wvinstall.exe mv ~/.wine/dosdevices/z: ~/.wine/dosdevices/oldz cd ~/.wine/drive_c $VALGRIND_CMD $WINE wvinstall.exe /q cd ../.. mv ~/.wine/dosdevices/oldz ~/.wine/dosdevices/z:

1 1

Re: server: Make timer id allocation algorithm conform to the Windows one
by Uwe Bonnes Nov. 15, 2007

Nov. 15, 2007

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: Dmitry> Hello, this patch should fix the problem reported in the bug Dmitry> 10343. My test which calls SetTimer in an infinite loop shows Dmitry> that XP starts to allocate timer ids at 0x7fff and goes Dmitry> backwards to 0x101, then restarts from 0x7fff. Isn't this worth a test suite case? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

AppDB down =(
by John Klehm Nov. 15, 2007

Nov. 15, 2007

Erm yeah the appdb is down... too many connections...sad times. John

3 2

Re: [4/4] msxml: Test for removeAttribute (try 2)
by Alistair Leslie-Hughes Nov. 14, 2007

Nov. 14, 2007

Hi, Changelog: msxml: Test for removeAttribute Best Regards Alistair Leslie-Hughes

2 1

Re: [4/8] WineD3D: Depth stencil fixes
by H. Verbeet Nov. 14, 2007

Nov. 14, 2007

On 13/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > static void depth_copy(IWineD3DDevice *iface) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - IWineD3DSurfaceImpl *depth_stencil = (IWineD3DSurfaceImpl *)This->depthStencilBuffer; > + IWineD3DSurfaceImpl *depth_stencil = (IWineD3DSurfaceImpl *)This->auto_depth_stencil_buffer; > > /* Only copy the depth buffer if there is one. */ I think this one should be changed to use stencilBufferTarget instead, although not in this patch.

2 2