wine-devel May 2013

wine-devel@winehq.org

77 participants
183 discussions

Re: [PATCH] dlls/gdi32/freetype.c: A better divide by zero fix, report bad fonts.
by Sam Edwards 07 May '13

07 May '13

On 05/06/2013 03:05 PM, Max TenEyck Woodbury wrote: > Just to make this clear, the most recent version of this patch is such > a graceful handling, right? I haven't worked on gdi32/freetype.c much, so I wouldn't be the one to say for sure (you should probably talk to Alexandre Julliard, Dmitry Timoshkov, or Huw Davies), but I'll give you my thoughts anyway: On 05/05/2013 12:48 PM, max(a)mtew.isa-geek.net wrote: > > + /* HACKHACK: If a font has tmHeight=0, let us know. */ > + if (!font->potm->otmTextMetrics.tmHeight) { > + ERR("Font named '%s' has tmHeight=0, aveWidth=%d!\n", font->ft_face->family_name, font->aveWidth); > + } > + Since we've learned that tmHeight=0 is not actually an error, it doesn't make sense to log it using ERR(...). I would suggest a TRACE(...) or (preferably) nothing at all. Also, when I wrote the ERR message patch for you, it was intended only to help you locate the problematic font and wasn't meant to be included in upstream Wine. (Which is why I marked it with HACKHACK and didn't bother to use debugstr_a.) As for the actual check, it makes sense to consider what the math is trying to do: If aveWidth is extremely large (relative to tmHeight), then assume aveWidth is wrong and set it to 0. If tmHeight is 0, then it seems reasonable to assume that aveWidth isn't valid either. I'm not sure why the sanity check cares to do this: (aveWidth+tmHeight-1) / tmHeight > 100 When it can just do this: (aveWidth+tmHeight-1) / tmHeight > 100 = (aveWidth-1)/tmHeight + 1 > 100 = (aveWidth-1)/tmHeight > 99 = (aveWidth-1) > tmHeight*99 = aveWidth > tmHeight*99 + 1 ≈ aveWidth > tmHeight*100 This allows us to write out tmHeight just once, and is also much easier to understand at a glance. So, I would just simplify the whole sanity check to something like: /* Make sure that the font has sane width/height ratio */ if (font->aveWidth > font->potm->otmTextMetrics.tmHeight * 100) { WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth); font->aveWidth = 0; } But even then, the sanity check itself sounds like a workaround for a much deeper bug. Maybe add a "FIXME: Investigate why this is necessary" comment while you're at it? Best, Sam

2 1

[PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
by Max Kellermann 07 May '13

07 May '13

The first memcpy() call in puts_clbk_str_w() confuses character count and byte count. It uses the number of characters (out->len) as number of bytes. This leaves half of the buffer undefined. Interestingly, the second memcpy() call in the same function is correct. This bug potentially makes applications expose internal (secret) data. Usually, the destination buffer is on the stack, and the stack often contains secrets. Therefore, one could argue that this bug constitutes a security vulnerability. --- dlls/msvcrt/printf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h index cfba4b7..8b749bc 100644 --- a/dlls/msvcrt/printf.h +++ b/dlls/msvcrt/printf.h @@ -48,7 +48,7 @@ static int FUNC_NAME(puts_clbk_str)(void *ctx, int len, const APICHAR *str) return len; if(out->len < len) { - memcpy(out->buf, str, out->len); + memcpy(out->buf, str, out->len*sizeof(APICHAR)); out->buf += out->len; out->len = 0; return -1;

3 4

Re: user32: Implement IMR_QUERYCHARPOSITION handling in the edit control
by Dmitry Timoshkov 07 May '13

07 May '13

Aric Stewart <aric(a)codeweavers.com> wrote: > dlls/user32/edit.c | 21 +++++++++++++++++++++ > include/imm.h | 9 +++++++++ > 2 files changed, 30 insertions(+) Using usual 4 spaces indentation would slightly improve the readability. -- Dmitry.

2 2

Re: [PATCH 6/8] ieframe: Added more InternetExplorer object tests.
by Marvin 07 May '13

07 May '13

1 0

Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
by Dmitry Timoshkov 06 May '13

06 May '13

max(a)mtew.isa-geek.net wrote: > + if ( font->aveWidth && font->potm->otmTextMetrics.tmHeight ) { > + if (((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) / > + font->potm->otmTextMetrics.tmHeight) > 100) { > WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth); > font->aveWidth = 0; > } In which case font->potm->otmTextMetrics.tmHeight is going to be 0? -- Dmitry.

6 19

Re: d3dx9 [patch 2 / 3]: Avoid useless computations in D3DXMatrixAffineTransformation
by Rico Schüller 06 May '13

06 May '13

On 05.05.2013 23:01, Nozomi Kodama wrote: > > + FLOAT xw, xx, xy, xz, yw, yy, yz, zw, zz; > I'm not very happy with the additional amount of variables... Please have a look at the attached patches. I think something like the first one (d3dx9: Apply rotationcenter only when a rotation is done.) should be done but has no influence on your patch (it is only attached, because the second patch influences the same part). 1. The amount of variables needed could be reduced to 3 by reordering the calculations (see patch 2, lines 36 - 58). This could also be done in your patch. Though I'm not sure that's a good idea ... comments and other opinions are welcome. Below this the points are not directly related to your patch: 2. In the next step we could also avoid a couple of multiplications by multiplying the scaling and adjusting the constants (see patch 2, lines 70 - 79). 3. We could also avoid the temps by reordering the calculation (Doing rotationcenter before the scaling). This way the tempxx could be avoided by using the out matrix directly. Cheers Rico

1 0

Re: d3dx9 [patch 1 / 3]: Avoid useless computations in D3DXMatrixAffineTransformation2D
by Rico Schüller 06 May '13

06 May '13

On 05.05.2013 23:00, Nozomi Kodama wrote: > + FLOAT tmp1, tmp2; > > + tmp1 = cosf(rotation); > + tmp2 = sinf(rotation); > As of it is really clear what's in those variables, we may name them with a better name instead of tmp1/tmp2 ... but I'm fine with either version. Cheers Rico

1 0

Re: [1/3] server: Add a process flag indicating whether the process is terminating, use it to block thread creation in a bei
by Marvin 06 May '13

06 May '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25445 Your paranoid android. === W7PROX64 (64 bit loader) === loader.c:1638: Test failed: expected WAIT_OBJECT_0, got 0x102 loader.c:1648: Test failed: expected thread exit code 196, got 259 loader.c:1210: Test failed: expected thread exit code 196, got 259 loader.c:1220: Test failed: expected WAIT_ABANDONED, got 0x102 loader.c:1236: Test failed: expected WAIT_OBJECT_0, got 0x102

2 1

GSoC 2013 - Registry Merging Project
by orzhvs 04 May '13

04 May '13

Hi, everyone. Thank you for your viewing and comments on the proposal. Sorry that the rough plan is kind of mess and now I've rewritten this part a little more like a Time Schedule. I appreciate it if you have a glance at it. >From now to 27th, May. Work on some basic knowledge such as the usage of WineTestBot, getting familiar to debugging in wine or so, with help of the community, and do some favor if possible. 28th, May to 16th, June. Have interviews with the mentor at any time if convenient. Put forward my initial frame design and make puzzles clear, then adjust the plan under the guide of the mentor. So that the testing and development plan will be settled down after this part. 17th, June to 24, June. Carry out pre-work tests on variety versions of Windows. Write test reports which definite some questions and guesses. I wish to report some bugs during this part once I found one. Some invoking tests vie different layer of dlls both some additional test code (maybe for difference between versions of windows) to the existing one in the advapi32.dll should be written. 25th, June to 24th, July. Prophase of the official development. I'll implement almost all of the registry merging feature, especially code in the server part, so that I can submit my patch and looking forward to feedbacks as early as possible. 25th, July to 31st, July. The Mid-term evaluations will be finished and submitted. 1st, Auguest to 31st, August. Second stage of the development. Implement the rest part of our scheme. In this part, changes will be real-time reported in the mailing-list and apply improvement timely to make it closer to a final product. 1st, September to 27th, September. Only clean-ups and small fix of code should be left here. I'll write and verify the final evaluations and final test results, together with other documents produced in the project. Then with some modification from the mentor it's submitted to Google. The schedule will be carried out up to speed so that I may finish ahead of the end date in each part, in which case I'd like make prepare for the next part and contritube my spare time to the commutiry, rather that only such narrowed in one project. Considering that it may be a little fuzzy in boundarys of different phases, I came up with some Possible Milestones : 1.Pre-development test works are finished. 2.Complete the mostly full test codes. 3.Merging of classes in HKCU and HKLM is implemented in server part. 4.Merging is implemented in all aviable layer. 5.Compatibility of different Windows versions are fullfilled. 6.All the work including documents are done on time. That's most of the schedule I can think of now, and I'll be very happy to improve it before submitting it to the mentor If you have futher advise, to save time and make the communication smoother. Best Regards, Guo Jian

1 0

Re: winex11.drv: Fixed XInput2 errors with mislabeled mice axis. (try 2)
by Alexandre Julliard 04 May '13

04 May '13

Christopher Cope <ccope3(a)utk.edu> writes: > @@ -286,8 +286,10 @@ static void enable_xinput2(void) > class->number, class->min, class->max, class->resolution, class->mode, > XGetAtomName( data->display, class->label )); > if (class->label == x11drv_atom( Rel_X ) || class->label == x11drv_atom( Rel_Y )) count++; > - /* workaround for drivers that don't provide labels */ > - if (!class->label && class->number <= 1 && class->mode == XIModeRelative) count++; > + /* workaround for drivers that don't provide correct labels */ > + if (((!class->label && class->number <= 1) || class->label == x11drv_atom( Abs_X ) || > + class->label == x11drv_atom( Abs_Y )) > + && class->mode == XIModeRelative) count++; The whole point of testing labels was because some platforms don't set the relative mode correctly, so this is going to break them again. -- Alexandre Julliard julliard(a)winehq.org

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2013