December 2005 - Wine-Devel - list.winehq.org

Re: Fix dsiplay of fonts with Symbol codepages (codepage 42) as well
by Dmitry Timoshkov Dec. 15, 2005

Dec. 15, 2005

"David Moore" <davidm(a)sjsoft.com> wrote: > The patch below first checks to see if the codepage is one of the > exceptions, and if it is, passes in NULLs for the last two arguments. I wonder how did you build the list of exceptions: why CP_UTF7 is there but CP_UTF8 is not? Why 50xxx,52xxx,57xxx code pages are there? I'd suggest as a start to have only CP_UTF7, CP_UTF8 and CP_SYMBOL in the exception list. -- Dmitry.

2 2

Regression in Wine on FreeBSD (DVD Shrink)
by Travis Poppe Dec. 15, 2005

Dec. 15, 2005

Hello All, Lately I've been trying to track down a problem that prevents DVD Shrink 3.2 from starting on FreeBSD in any version of Wine built on/after 04-20-2005 (including the recent beta releases). Any version built prior to this works fine. I've tracked the problem down to the changes made to x11drv/dib.c (and associated) on 04-20-2005. I'm not fluent in C; I merely found the problem through trial and error. If I copy the x11drv/dib.c (and ntdll/, so the old dib.c will work) from 04-18-2005 in place of the one introduced on the 20th, the problem disappears and DVD Shrink fires right up. Changing dib.c (and dib.c only) back to the 20th snapshot re-introduces the problem, and DVD Shrink hangs again. As I don't understand the code, I don't know how to detect where the problem really lies, as the dib.c changes may only be indirectly responsible. I am very willing to test for or aid anyone who wouldn't mind helping with this problem, however. I have already contacted the author of the changes (dib.c and associated) and he suggested I try this list. If anyone would like to glance at the differences between the two files I've mentioned above, I have posted a diff here: http://lickwid.net/~tlp/dib.c.diff --- are the old and working changes +++ are the new and broken changes Any help would be greatly appreciated. Thanks, -- Travis Poppe IRC: tlp @ irc.freenode.net

2 1

Re: There is no need to offset the source rectangle in the reverse direction before scrolling
by Rein Klazes Dec. 15, 2005

Dec. 15, 2005

On Tue, 13 Dec 2005 23:53:07 +0800, you wrote: >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > There is no need to offset the source rectangle in the reverse > direction before scrolling. > >--- cvs/hq/wine/dlls/x11drv/scroll.c 2005-11-22 12:41:07.000000000 +0800 >+++ wine/dlls/x11drv/scroll.c 2005-12-13 23:42:15.000000000 +0800 > /* Then clip again to get the source rectangle that will remain in the > * clipping rect */ > rcSrc = rcClip; >- OffsetRect( &rcSrc, -dx, -dy); > IntersectRect( &rcSrc, &rcSrc, &rcClip); In the first place: with this change the IntersectRect call is a no-op I doubt you understand the reason for "to offset the source rectangle in the reverse direction": Scrolling should only occur in the clipping rectangle. When you talk about the *destination* pixels, a clipping with the cliprect is needed. Here we are talking about the *source* pixels, from destination to source is indeed reverse. *that* is what is happening here. If you are not convinced: the change is wrong and clipping fails. I have added a test to confirm that. The test also gives a nice visual idea what goes wrong, just add a Sleep() or two to get the picture. Changelog: dlls/x11drv : scroll.c dlls/user/tests : win.c Restore the previous change to X11DRV_ScrollDC. With a regression test to confirm it was wrong. Rein.

3 3

Re: [mscms/tests/profile.c] Add another possible error
by Saulius Krasuckas Dec. 15, 2005

Dec. 15, 2005

* On Wed, 14 Dec 2005, Paul Vriens wrote: > > GetStandardColorSpaceProfileW with a non-NULL machinename will return > ERROR_NOT_SUPPORTED on 2000/WinXP/2003 (and maybe more). > > --- a/dlls/mscms/tests/profile.c > +++ b/dlls/mscms/tests/profile.c > @@ -515,7 +515,7 @@ static void test_GetStandardColorSpacePr > /* Parameter checks */ > > todo_wine > - fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER)); > + fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER || GLE == ERROR_NOT_SUPPORTED)); Hm, while I believe you, Paul, I don't like testing of several invalid parameters in one check. If different versions of mscms.dll are coded in different ways, we'll be getting one GLE on one platforms and another GLE on anothers. IMHO this way we can test algorithmic (conditional) branching of GetStandardColorSpaceProfile(), which won't be the same on all platforms. So I offer to skip it and test only single parameter in one check. I'll try to send a patch.

1 0

Re: sysparams : nonclient metric fixes
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

Rein Klazes <wijn(a)wanadoo.nl> writes: > Changelog: > dlls/user : sysparams.c > dlls/user/tests : sysparams.c > Implement saving and fix reading of nonclient metrics with conformance > tests. The test fails here: sysparams.c:195: Test failed: Wrong action got 42 expected 47 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: msvcrt.wctime
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

Marcus Meissner <marcus(a)jet.franken.de> writes: > Used by Google Earth. If anyone has a better > idea on the static buffer handling please speak up.. ;) It should go in the per-thread data structure (cf. msvcrt_get_thread_data). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: Added stubs for SetupGetInfInformation and SetupQueryInfFileInformation [RESEND]
by Alexandre Julliard Dec. 15, 2005

Dec. 15, 2005

James Hawkins <truiken(a)gmail.com> writes: > Is there anything wrong with this patch? Yes, the patch file is truncated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Create the compatible bitmap from the screen, not the bitmap we're copying
by Paul Vriens Dec. 15, 2005

Dec. 15, 2005

> Hi, > > This patch fixes bug 1715. > > Changelog > * Create the compatible bitmap from the screen, not the bitmap we're > copying. > > dlls/comctl32/toolbar.c | 12 ++++++++---- > 1 files changed, 8 insertions(+), 4 deletions(-) > > -- > James Hawkins > > Hi James, somehow you managed to attach an empty file. (I think). Paul.

2 1

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory
by David Nolden Dec. 14, 2005

Dec. 14, 2005

> There is no change in Wine that would have caused this. I seem to > remember that this or a similar error was caused by threading problems > in glibc in the past. Perhaps you upgraded glibc or the kernel on your > system? But when I checkout a cvs from the end of november, it runs.. when I checkout a current one it doesn't. I didn't upgrade glibc, nor the kernel. (I checked out and compiled a cvs from november just an hour ago, and it ran fine) greetings, David

2 1

Printf Integer Conversions update
by Jesse Allen Dec. 14, 2005

Dec. 14, 2005

Hi All, I've updated my patch and need comments on it. The patch is for a portible method for integer conversions in printf. Since it's primarily intended for I64 sizes that it is all it is used for to avoid breaking anything else, even though, it should be able to handle all integers. You can find it at http://www.chez.com/alors/ along with lots of tests. Since last time, I was wondering what to do about %I64e, and well, testing it out it seems to be just like %e on windows so I decided to not worry about our own float I64 conversion since it's the same. So only I64 integer types get fowarded to pf_integer_conv and floats just get put through libc's printf. I still wonder about %I64e versus %e just because libc's %lle and %e are different hmmmm. This time I use pf_output_format_A to handle the field output. I had to modify it to account for the extra sign and alternate formatting. I guess I need to modify pf_output_format_W the same way, but some one let me know if it is needed and whether just copying what I have over is ok. I added pf_is_integer_format to detect when I have an integer and I64 size case. I modified the others so each uppercase and lowercase type is explicit: static inline BOOL pf_is_valid_format( char fmt ) { - char float_fmts[] = "acdefginoux"; + char float_fmts[] = "acCdeEfgGinouxX"; if (!fmt) return FALSE; - fmt = tolower( fmt ); return strchr( float_fmts, fmt ) ? TRUE : FALSE; } Because D is not a valid conversion type, and especially 'I'. If we get passed %I0d for example, it should print I0d. If I didn't do this, then it tries to convert 'I' as an 'i' type, which would be a bug. I don't know if this will cause other things to regress, so I could back out the change. In my testing of I64 on windows 2k3 (x86), I hit an obscure bug? '%#+25.22I64u' for -1 prints ' 18446744073709551615' returning 21 but normally it should be ' 0018446744073709551615' returning 25. It only does it only for I64 types, and only in this exact combination -- precision and field doesn't matter what number, but #+ must be there and be unsigned. If I try '%+#25.22I64u' then I get correct output. You can see this in the tests and try it out. I tried about 20-30 other combinations and it only happens this way. I haven't built in support of the bug yet, but it is there. So I'm thinking, great, we have to support this obscure I64 with bugs too. Jesse

1 0