September 2009 - Wine-devel

Re: CPPCheck Sept 8 GIT
by Marcus Meissner 09 Sep '09

09 Sep '09

On Tue, Sep 08, 2009 at 07:21:03PM -0700, chris ahrendt wrote: > [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) > Deallocating a deallocated pointer: stream2 > [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource > leak: stream3 > [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource > leak: stream4 > [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) > Memory leak: mem > [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource > leak: old_cwd > [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd > [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource > leak: fd_cwd > [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible > error) Array index out of bounds > [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource > leak: mixer > [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource > leak: mixer These were committed yesterday ... Did you run before the large commit or afterwards? Ciao, marcus

1 0

Re: [ntdll, cmd] Implement file attributes with xattr on mac and linux (fixes bug 15679)
by Kai Blin 08 Sep '09

08 Sep '09

On Tuesday 08 September 2009 16:11:06 Dan Kegel wrote: > This patch uses filesystem extended attributes in > a way compatible with Samba 3 to store the win32 attribute bits. > It builds and runs on mac and linux, passes tests on linux and vista, > and should be easy-ish to port to solaris (though who knows > what xattr solaris' native cifs server uses, hopefully it's the > same as what samba 3 does). As JRA already replied with more Samba3-specific things, just a word about the Samba4 handling. In the last months, we've been working on getting more and more features of Samba3 and Samba4 use the same codebase or at least behave the same way. There's a good chance that both implementations will converge to one sort of behavior, so if we get that implemented we should be fine. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Question regarding SIO_GET_EXTENSION_FUNCTION_POINTER
by Nicholas LaRoche 08 Sep '09

08 Sep '09

I ran into a bug last week regarding the lack of SIO_GET_EXTENSION_FUNCTION_POINTER support in WSAIoctl. Are there any outstanding issues preventing it's implementation? Perhaps if anyone has worked in this area, are there any things I should look out for when trying to implement it? At first glance it looks like returning an arbitrary pointer may prove tricky since wine likes to relocate DLLs to unpredictable addresses at runtime. (i.e. kernel32.dll is not predictably mapped to a single address as with Windows XP; turning off ASR for the current shell has no effect) -Nick

2 5

Re: [3/3]msctf/tests: test ITfThreadMgr::AssociateFocus
by Paul Vriens 08 Sep '09

08 Sep '09

On 09/01/2009 02:08 PM, Aric Stewart wrote: > --- > dlls/msctf/tests/inputprocessor.c | 141 > ++++++++++++++++++++++++++++++++++++- > 1 files changed, 139 insertions(+), 2 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Aric, This one introduced some test failures on Vista and higher. Could you have a look? -- Cheers, Paul.

2 1

Re: [wined3d][1/3] Allow infinity count of backbuffers in IWineD3DDeviceImpl_CreateSwapChain()
by Henri Verbeet 08 Sep '09

08 Sep '09

- Please don't use TCHAR etc. in Wine. - You still didn't prove you need to copy the data for each backbuffer. - You still have whitespace errors.

1 0

[RFC] Implement file attributes with xattr on mac and linux (fixes bug 15679)
by Dan Kegel 08 Sep '09

08 Sep '09

Builds and runs on mac and linux, passes tests on linux and vista. Fixes http://bugs.winehq.org/show_bug.cgi?id=15679 It's worth discussing a bit before posting to wine-patches. This patch uses filesystem extended attributes to store the win32 attribute bits. These are available fairly widely finally - I think current Linux, Mac, and Solaris all support some form of extended attributes. Because the extended attribute API varies somewhat wildly between operating systems, I went whole-hog and used autoconf to detect the differences between the api on linux and macosx. Somebody else should be able to add solaris support without much difficulty if this is approved. The convention chosen is that the win32 file attributes are stored as a four digit hex number in the extended attribute named user.wine.attr. (The 'user' prefix is suggested by http://www.freedesktop.org/wiki/CommonExtendedAttributes .) For backwards compatibility, if a native file lacks extended attributes; it is reported as having ARCHIVE attribute. Likewise, if a file just has the ARCHIVE attribute set, there is no native extended attribute. Here's an example: touch foo.dat wine cmd /c attrib -a foo.dat xattr -l foo.dat This outputs user.wine.attr: 0000 i.e. because the file has anything but the default attribute, we store the entire win32 attribute bitmask in the extended attribute. Another example: touch bar.dat wine cmd /c attrib +s bar.dat xattr -l bar.dat This outputs user.wine.attr: 0024 or ARCHIVE | SYSTEM. This convention should be thought over carefully before we go with it. I also considered using individual xattrs for each attribute bit, but discarded that idea as adding overhead and complexity without any obvious payoff. Finally, the implementation of attrib in cmd is lame -- it only handles two arguments. It's enough for the moment, but the real attrib can handle multiple attribute flags, and we should support that sometime. So, what do folks think? - Dan

2 1

Re: wined3d: Fix vendor detection when using an Intel X4500HD
by Austin English 08 Sep '09

08 Sep '09

On Mon, Sep 7, 2009 at 11:52 PM, Jaime Rave<jaimerave(a)gmail.com> wrote: > This patch fix the fixme: > > fixme:d3d_caps:wined3d_guess_vendor Received unrecognized GL_VENDOR > "Tungsten Graphics, Inc". Returning VENDOR_WINE. > > > > Forgot the patch. -- -Austin

1 0

Re: msvcrt: dont overwrite the standard streams (with test, try 5)
by Eric Pouech 07 Sep '09

07 Sep '09

André Hentschel a écrit : > Some Apps e.g. mingw-apps use lpReserved2 to pass some data to the child-process, this data starts with 4 Byte of Zeros(unsinged 0) to tell msvcrt not to read that as an inherit-block. > Hi André a couple of comments to your patch > See also Bug 18479 > --- > dlls/msvcrt/file.c | 2 +- > dlls/msvcrt/tests/Makefile.in | 2 +- > dlls/msvcrt/tests/file.c | 50 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 52 insertions(+), 2 deletions(-) > > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 6671f2f..8f63e8d 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -349,7 +349,7 @@ void msvcrt_init_io(void) > InitializeCriticalSection(&MSVCRT_file_cs); > MSVCRT_file_cs.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": MSVCRT_file_cs"); > GetStartupInfoA(&si); > - if (si.cbReserved2 != 0 && si.lpReserved2 != NULL) > + if (si.cbReserved2 != 0 && si.lpReserved2 != NULL && *(unsigned*)si.lpReserved2) > IMO, we should also test that cbReserved2 is >= sizeof(unsigned) otherwise we'd be in trouble > { > char* wxflag_ptr; > HANDLE* handle_ptr; > diff --git a/dlls/msvcrt/tests/Makefile.in b/dlls/msvcrt/tests/Makefile.in > index 74199e1..8c71971 100644 > --- a/dlls/msvcrt/tests/Makefile.in > +++ b/dlls/msvcrt/tests/Makefile.in > @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msvcrt.dll > APPMODE = -mno-cygwin > -IMPORTS = kernel32 > +IMPORTS = kernel32 user32 > you should do it without user32. instead of doing this > + while (MsgWaitForMultipleObjects( 1, &proc.hProcess, FALSE, INFINITE, QS_ALLINPUT ) != 0) > + { > + while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessageA(&msg); > + } > you could simply wait for the child process to terminate A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 3

Re: [5/5] WineD3D: Use GL_ATI_meminfo if available
by Henri Verbeet 07 Sep '09

07 Sep '09

2009/9/5 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* All GL_ATI_meminfo enums return 4 ints, even the (undocumented) > + * GL_TOTAL_PHYSICAL_MEMORY_ATI one, which returns {mem, 0, 0, 0} */ > + GLint mem[4]; > + /* Returns the vidmem in KB */ > + glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, mem); > + checkGLcall("glGetIntegerv(GL_TOTAL_PHYSICAL_MEMORY_ATI, mem)"); > + > + /* The first driver version that supports ATI_meminfo doesn't implement > + * GL_TOTAL_PHYSICAL_MEMORY_ATI - catch this situation as adviced by AMD > + */ > + if(mem[0] < 65536) If the implementation doesn't recognise "GL_TOTAL_PHYSICAL_MEMORY_ATI" you're testing uninitialized memory here. I hope AMD didn't actually advice you to code it like that.

3 4

Finding IDB_VIEW_SMALL_COLOR
by Joel Holdsworth 07 Sep '09

07 Sep '09

Hi All, Does anyone know what DLL the image 32-bit version the standard image list IDB_VIEW_SMALL_COLOR is stored in in Windows? You can see some of it in this screenshot: http://www.airwebreathe.org.uk/IDB_VIEW_SMALL_COLOR.png. I might expect it to be in comctl32.dll with the other common image lists... but it's not - only the old 4-bit version of the image. Does anyone know where the 32-bit one is? Thanks Joel

3 3