October 2004 - Wine-Devel - list.winehq.org

dlls/x11drv/winpos.c::SWP_DoOwnedPopups
by Peter Riocreux Oct. 19, 2004

Oct. 19, 2004

I have a lot of WARNs from this function so I thought I would have a shufty at it to see if it was easy to fix. The FIXME above it is written so as to suggest that it is a matter of mere keystrokes to fix it up, or weeks of work, depending on your frame of mind when you read it. Still being a beginner (first patch now committed be Aj - yay!) and not knowing about Windows programming, I don't know where to look to decide which is the case. The comment above it says: /*********************************************************************** * SWP_DoOwnedPopups * * fix Z order taking into account owned popups - * basically we need to maintain them above the window that owns them * * FIXME: hide/show owned popups when owner visibility changes. */ It looks like, depending on some property of 'owner' it should or shouldn't use the property SWP_HIDEWINDOW in the call to SetWindowPos <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu…> If this is the case I could fix it, if I knew how to determine when 'owner' is visible. Do I also need a callback of some kind so that the popup is rendered invisible when the parent is, even if SWP_DoOwnedPopups is not called (or is that not (supposed to be) possible?)? Is the WARN there only because of the FIXME and if I fix the FIXME I should remove the WARN? Peter

1 1

Re: wine/dlls/ntdll time.c
by Dimitrie O. Paun Oct. 19, 2004

Oct. 19, 2004

On Mon, Oct 18, 2004 at 04:19:29PM -0500, Alexandre Julliard wrote: > Log message: > Rein Klazes <rklazes(a)xs4all.nl> > In RtlQueryTimezoneInformation use information from the registry if it > is available. > > Patch: http://cvs.winehq.org/patch.py?id=14188 Hmm, shouldn't we synch up with the Unix env instead? I assume this info is available in the Unix env... This would be preferable even in the case of a shared Windows install, me thinks. -- Dimi.

2 1

CreateFile GENERIC_WRITE on a directory
by ScratchMonkey Oct. 19, 2004

Oct. 19, 2004

Not sure if this should be in -users, but I'm trying to get the Tribes: Vengeance dedicated server going (1st person shooter) and it stops with a messagebox that it can't write to its own directory. Tracing the program with +relay reveals this: 000b:Call kernel32.CreateFileW(10415fc0 L"Z:\\home\\vengeance\\Server \\Program\\Bin\\",40000000,00000007,00000000,00000003,02000000,00000000) ret=1015b46d 000b:Call ntdll.RtlIsDosDeviceName_U(10415fc0 L"Z:\\home\\vengeance\\Server \\Program\\Bin\\") ret=554b4506 000b:Ret ntdll.RtlIsDosDeviceName_U() retval=00000000 ret=554b4506 000b:Call ntdll.RtlDosPathNameToNtPathName_U(10415fc0 L"Z:\\home\\vengeance \\Server\\Program\\Bin\\",559bebb0,00000000,00000000) ret=554b42c7 000b:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 ret=554b42c7 000b:Call ntdll.NtCreateFile (559beba4,40000000,559bebb8,559beba8,00000000,00000000,00000007,00000001,00 004010,00000000,00000000) ret=554b438f 000b:Ret ntdll.NtCreateFile() retval=c00000ba ret=554b438f 000b:Call ntdll.RtlNtStatusToDosError(c00000ba) ret=554b43bd 000b:Ret ntdll.RtlNtStatusToDosError() retval=00000005 ret=554b43bd 000b:Call ntdll.RtlFreeUnicodeString(559bebb0) ret=554b43cc 000b:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=554b43cc 000b:Ret kernel32.CreateFileW() retval=ffffffff ret=1015b46d Decoding the parameters to CreateFile show it trying to open the directory for GENERIC_WRITE. I'm about to dig into the wine sources but am hoping someone can spot the problem more quickly than me. I'm using the 20040914 source RPM from NewRPMs.

2 3

Re: Turn off Antialiasing for Rendering with Palette
by Alexandre Julliard Oct. 18, 2004

Oct. 18, 2004

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Description: > * When we are working with a palette, we need to disable antialiasing. > Antialiasing results in a lot of extra colour values which are not > mapped in the palette, causing bad display artifacts. > > Changelog: > * Disable antialiasing when working with the palette You shouldn't change the global antialias flag, this is ugly and it will most likely break the font caching. You have to add checks for a palette directly at the places that handle the anti-aliasing (and your palette check is wrong too, you shouldn't peek into the internals of the DC bitmap). -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Server: Create and Use New mem_free Function
by Alexandre Julliard Oct. 18, 2004

Oct. 18, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > We have our own mem_alloc memory allocator, so this patch adds the a > new free function, mem_free, and replaces instances of free with > mem_free. At the moment, the implementation completely defers to the > libc free function, but it makes sense to have this new function so > that we can easily change memory allocators. The patch also changes a > few instances of malloc to mem_alloc. You cannot do that, mem_alloc sets the error code but malloc doesn't, they are not the same thing. The purpose of mem_alloc is to simplify handling of allocation failures in common cases, it's not a general replacement for malloc. If you really want to change the memory allocator you can redefine malloc and free, but I'm not sure why you'd want to do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

oleaut32: SafeArrayDestroyData
by Walt Ogburn Oct. 18, 2004

Oct. 18, 2004

Hi, I am working on getting a scientific / engineering application called SRIM (www.srim.org) specifically the batch-mode component SRModule of SRIM 2003. This is a Visual Basic program, so there's lots of reliance on oleaut32.dll. In addition to freeing the data memory of the SafeArray, Wine's implementation of SafeArrayDestroyData sets the pointer pvData to NULL. The native Windows version apparently does not do this, and SRIM depends on pvData still pointing to the same place afterwards. Wine's code also uses this nulling to keep track of the memory, so that it won't get freed again. I can't say why a program would still want pvData after a call to SafeArrayDestroyData, but there it is. Could the flag FADF_DATADELETED be used to keep track of this instead? That seems to be the case only for vector SafeArrays now. The following patch seems to make SRIM work: =================================================================== Index: dlls/oleaut32/safearray.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/safearray.c,v retrieving revision 1.40 diff -u -r1.40 safearray.c --- dlls/oleaut32/safearray.c 20 Sep 2004 19:11:48 -0000 1.40 +++ dlls/oleaut32/safearray.c 18 Oct 2004 17:03:51 -0000 @@ -1254,7 +1254,7 @@ if (psa->cLocks) return DISP_E_ARRAYISLOCKED; /* Can't delete a locked array */ - if (psa->pvData) + if (psa->pvData && !(psa->fFeatures & FADF_DATADELETED)) { /* Delete the actual item data */ if (FAILED(SAFEARRAY_DestroyData(psa, 0))) @@ -1265,7 +1265,8 @@ { if (!SAFEARRAY_Free(psa->pvData)) return E_UNEXPECTED; - psa->pvData = NULL; + /* psa->pvData = NULL; */ + psa->fFeatures |= FADF_DATADELETED; } else psa->fFeatures |= FADF_DATADELETED; /* Mark the data deleted */ =================================================================== Also, is there a way to make the tests in oleaut32/tests/ run on the native dlls? If so, I could more clearly show that the Windows version doesn't null pvData. Thanks, Walter

2 2

Re: x11drv: Add stretching support to AlphaBlend
by Huw D M Davies Oct. 18, 2004

Oct. 18, 2004

On Sun, Oct 17, 2004 at 10:34:28PM -0400, Kevin Koltzau wrote: > Changelog: > Add stretching support to AlphaBlend XRenderSetPictureTransform is a relatively new addition to libxrender, arriving just before XFree 4.3. I don't think we want the whole xrender stuff to fail if this specific function isn't available in the library. Could you make the presence of this function optional and simply skip the stretched AlphaBlend if it's not there? Huw.

1 0

-fPIC on link line in winegcc for HPUX
by Warren_Baird/CSI＠cimmetry.com Oct. 18, 2004

Oct. 18, 2004

Hi all, Another change I had to make for HPUX that I'm not 100% sure about: The HPUX linker gets quite unhappy unless the gcc link line inside of winegcc is fed -fPIC. The problem is that the collect2 phase builds it's own temporary object file that gets included in the final link, and if that temp .o file isn't compiled with -fPIC, the HP linker complains. In order to get this to work, I had to add -fPIC to the list of link flags that winegcc recognizes: diff -ur patched/wine-20040914/tools/winegcc/winegcc.c wine-20040914/tools/winegcc/winegcc.c --- patched/wine-20040914/tools/winegcc/winegcc.c 2004-10-12 10:28:37.000000000 -0400 +++ wine-20040914/tools/winegcc/winegcc.c 2004-10-12 10:10:07.000000000 -0400 @@ -616,7 +616,7 @@ { "-nostartfiles", "-nodefaultlibs", "-nostdlib", "-s", "-static", "-static-libgcc", "-shared", "-shared-libgcc", "-symbolic", - "-framework" + "-framework", "-fPIC" }; int j; The question: is this going to be harmful on other platforms? I'm not sure whether I should protect it with ifdefs, or just leave it as is. Any suggestions? Thanks, Warren

3 6

Re: Resend: Honor --disable-debug or --disable-trace completely
by Alexandre Julliard Oct. 18, 2004

Oct. 18, 2004

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > wine/debug.h has some tests based on NO_{DEBUG,TRACE}_MSGS, which is set > (or not) in config.h. Quite a few files didn't #include config.h before > wine/debug.h, so some debugmsgs were always compiled in, even with > ./configure --disable-debug. > > Now maybe we want to install config.h as well, as debug.h is already > installed. I'll leave that one to Alexandre. No, the right fix is to put these defines in the Makefile and get rid of them in config.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MinGW portability fix
by Hans Leidekker Oct. 18, 2004

Oct. 18, 2004

On Sunday 17 October 2004 16:16, Hans Leidekker wrote: > Changelog: > Add configure check for getpagesize() declaration, needed by MinGW. Hmm, I just found that the AC_CHECK_DECL macro doesn't work as expected. You can skip this patch. -Hans

1 0