August 2012 - Wine-Devel - list.winehq.org

Re: kernel32: Add UTF-7 support. (try 4)

by Alex Henrie

Correction: I meant to write that try 4 exits the loop slightly faster when ending a base64 sequence, it has nothing to do with escaped plus signs which are handled a few lines earlier. -Alex

Aug. 20, 2012

Re: [6/7] gdiplus: Add a test for extra space added by GdipMeasureString. Resend.

by Marvin

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=21046 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 20, 2012

Re: msctf: Call interface methods properly

by Marvin

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=21043 Your paranoid android. === TEST64_W7SP1 (32 bit inputprocessor) === inputprocessor.c:259: Test failed: Unexpected TextStoreACP_GetStatus sink inputprocessor.c:259: Test failed: Unexpected TextStoreACP_GetStatus sink

Aug. 20, 2012

Re: How to convert msvcp names to legible names?

by Owen Rudge

On 19/08/2012 01:04, Bruno Jesus wrote: > Which is the roseta stone used to read all msvcp function names like > "msvcp80.dll.??0?$basic_stringstream(a)GU?$char_traits(a)G@std@@V?$allocator(a)G@2@@std@@QAE(a)H@Z, > aborting" as the real function name in source code? http://slush.warosu.org/c++filtjs/ is handy if you want to quickly decode a mangled name. -- Owen Rudge http://www.owenrudge.net/

Aug. 19, 2012

Re: How to convert msvcp names to legible names?

by Charles Davis

On Aug 18, 2012, at 6:04 PM, Bruno Jesus wrote: > Which is the roseta stone used to read all msvcp function names like > "msvcp80.dll.??0?$basic_stringstream(a)GU?$char_traits(a)G@std@@V?$allocator(a)G@2@@std@@QAE(a)H@Z, > aborting" as the real function name in source code? The __unDName() function in msvcrt (and its younger sibling, __unDNameEx()). The undname tool included with Visual Studio will call this function for you on a name you give on the command line. Chip

Aug. 19, 2012

How to convert msvcp names to legible names?

by Bruno Jesus

Which is the roseta stone used to read all msvcp function names like "msvcp80.dll.??0?$basic_stringstream(a)GU?$char_traits(a)G@std@@V?$allocator(a)G@2@@std@@QAE(a)H@Z, aborting" as the real function name in source code? Thanks in advance, Bruno

Aug. 19, 2012

Microsecond unit

by Francois Gouget

The microsecond unit is 'µs' and yet, in dlls/sane.ds/sane.rc, we define it as 'us' and then rely on the British and American English PO files to convert it to 'µs'. Why not put the right unit directly in the RC file? It's UTF-8 anyway... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Aug. 18, 2012

Re: winedbg: Use standard fixed pitch UI font for the crash dialog.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > For me every tab is replaced by a black square, so it doesn't look all > that good... Actually that's a bug in edit control (or rather a bug in new fancy edit implementation using uniscribe): running notepad, then changing font to Courier and pressing tab draws same black square. -- Dmitry.

Aug. 17, 2012

Re: [10/10] gdiplus: Filter tabs out until they are properly supported using stringformat.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > This should probably be handled somehow by gdip_format_string. > DrawDriverString doesn't have access to the StringFormat, and there's > a good change that the native implementation really does draw tabs as > squares. Also, MeasureCharacterRanges and MeasureString will have to > account for tabstops. > > gdip_format_string already has logic to ignore certain characters, but > it needs more thought as to how we can do that and keep the offsets > passed to the callback accurate, and how to eventually pass > information about tabs to the callback. > > If this does turn out to be a correct change for DrawDriverString (I > predict that it is not), then MeasureDriverString should be updated as > well. A quick test shows that DrawDriverString does draw tabs as squares, so MeasureDriverString is not affected by this change. Since this patch is clearly a workaround for missing handling of tabs, and I doubt that somebody is really using DrawDriverString to draw tabs as squares, I don't see anything wrong with accepting this patch until somebody adds support for tabstops in stringformat. -- Dmitry.

Aug. 17, 2012

Re: [10/10] gdiplus: Filter tabs out until they are properly supported using stringformat.

by Vincent Povirk

This should probably be handled somehow by gdip_format_string. DrawDriverString doesn't have access to the StringFormat, and there's a good change that the native implementation really does draw tabs as squares. Also, MeasureCharacterRanges and MeasureString will have to account for tabstops. gdip_format_string already has logic to ignore certain characters, but it needs more thought as to how we can do that and keep the offsets passed to the callback accurate, and how to eventually pass information about tabs to the callback. If this does turn out to be a correct change for DrawDriverString (I predict that it is not), then MeasureDriverString should be updated as well.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Vincent Povirk

> Since I have no tests for GdipMeasureCharacterRanges I don't want to break > it inadvertently. If somebody proves that GdipMeasureCharacterRanges should > be affected by extra padding as well, merging the code to gdip_format_string > shouldn't be too hard. Well, I'm saying you'll break it if you only change the other two functions and leave this one alone. It's more important for DrawString, MeasureString, and MeasureCharacterRanges to be consistent with each other than with Windows. Applications won't typically rely on specific measurements, but they WILL rely on the measurements from MeasureCharacterRanges and MeasureString to match the actual result from DrawString. It should be obvious that changing the way DrawString lays out the text, or changing the measurements of some text, without a corresponding change in the other functions, will make the measurements WRONG, even if they happen to pass your tests and match the results on Windows. If you want to change the layout for only some of the string functions, you're going to need some very strong justification for that.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> >> Why can't this logic go in gdip_format_string? > >> > > >> > Because not all of its callers should be affected (GdipMeasureCharacterRanges > >> > is one of them). > >> > >> How not? If the padding is there when drawing the whole string, it > >> affects the positions of individual characters. > > > > Many sources on the net suggest using GdipMeasureCharacterRanges to avoid > > extra padding added by GdipMeasureString. > > My understanding is that MeasureCharacterRanges does not include the > padding in its measurements, because it measures individual > characters, but it still accounts for the padding. That means that if > you measure a character range with padding applied, the resulting > rectangle will be shifted by the amount of the padding, but the > padding will be outside the rectangle. > > This makes it possible to avoid the padding when drawing effects such > as a background highlight behind some text. Returning a measurement > that doesn't reflect reality as you suggest would not be a useful > behavior, as the measurement would simply lead to drawing something in > the wrong place. Since I have no tests for GdipMeasureCharacterRanges I don't want to break it inadvertently. If somebody proves that GdipMeasureCharacterRanges should be affected by extra padding as well, merging the code to gdip_format_string shouldn't be too hard. -- Dmitry.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Vincent Povirk

>> >> Why can't this logic go in gdip_format_string? >> > >> > Because not all of its callers should be affected (GdipMeasureCharacterRanges >> > is one of them). >> >> How not? If the padding is there when drawing the whole string, it >> affects the positions of individual characters. > > Many sources on the net suggest using GdipMeasureCharacterRanges to avoid > extra padding added by GdipMeasureString. My understanding is that MeasureCharacterRanges does not include the padding in its measurements, because it measures individual characters, but it still accounts for the padding. That means that if you measure a character range with padding applied, the resulting rectangle will be shifted by the amount of the padding, but the padding will be outside the rectangle. This makes it possible to avoid the padding when drawing effects such as a background highlight behind some text. Returning a measurement that doesn't reflect reality as you suggest would not be a useful behavior, as the measurement would simply lead to drawing something in the wrong place.

Aug. 17, 2012

Re: Re: DSSENH/tests: Added block cipher mode tests for the DSSENH cryptographic service provider (try2)

by Marvin

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=20983 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 17, 2012

Re: [02/10] gdiplus: If source and destination rectangles differ it's not a reason to fallback to software blitting.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > You also removed the test for rotation and skewing, which are > definitely NOT handled by gdi32. I guess that this patch could be dropped then, other patches in the series shouldn't be affected. -- Dmitry.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> Why can't this logic go in gdip_format_string? > > > > Because not all of its callers should be affected (GdipMeasureCharacterRanges > > is one of them). > > How not? If the padding is there when drawing the whole string, it > affects the positions of individual characters. Many sources on the net suggest using GdipMeasureCharacterRanges to avoid extra padding added by GdipMeasureString. -- Dmitry.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Vincent Povirk

>> Why can't this logic go in gdip_format_string? > > Because not all of its callers should be affected (GdipMeasureCharacterRanges > is one of them). How not? If the padding is there when drawing the whole string, it affects the positions of individual characters.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Why can't this logic go in gdip_format_string? Because not all of its callers should be affected (GdipMeasureCharacterRanges is one of them). -- Dmitry.

Aug. 17, 2012

Re: [02/10] gdiplus: If source and destination rectangles differ it's not a reason to fallback to software blitting.

by Vincent Povirk

>> > Both StretchBlt and GdiAlphaBlend handle that case just fine. >> >> Only if the graphics interpolation mode happens to be nearest >> neighbor, which isn't the default. > > Feel free to add a check for it, there is no need to penalize a common > case without a reason. You also removed the test for rotation and skewing, which are definitely NOT handled by gdi32.

Aug. 17, 2012

Re: [08/10] gdiplus: GdipMeasureString/GdipDrawString should add extra space around the text.

by Vincent Povirk

Why can't this logic go in gdip_format_string?

Aug. 17, 2012

Re: [02/10] gdiplus: If source and destination rectangles differ it's not a reason to fallback to software blitting.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Both StretchBlt and GdiAlphaBlend handle that case just fine. > > Only if the graphics interpolation mode happens to be nearest > neighbor, which isn't the default. Feel free to add a check for it, there is no need to penalize a common case without a reason. -- Dmitry.

Aug. 17, 2012

Re: [02/10] gdiplus: If source and destination rectangles differ it's not a reason to fallback to software blitting.

by Vincent Povirk

> Both StretchBlt and GdiAlphaBlend handle that case just fine. Only if the graphics interpolation mode happens to be nearest neighbor, which isn't the default.

Aug. 17, 2012

Re: DSSENH/tests: Added block cipher mode tests for the DSSENH cryptographic service provider

by Marvin

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=20977 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 17, 2012

Re: [PATCH 2/3] riched20: Added support for UTF8 BOM stream. (Try 2)

by Qian Hong

On Fri, Aug 17, 2012 at 1:37 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > There's no reason to move the data. Thanks for review! Will provide a better version soon. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Aug. 16, 2012

Re: [PATCH 2/3] riched20: Added support for UTF8 BOM stream. (Try 2)

by Alexandre Julliard

Qian Hong <fracting(a)gmail.com> writes: > @@ -304,8 +307,19 @@ static LRESULT ME_StreamInText(ME_TextEditor *editor, DWORD dwFormat, ME_InStrea > > if (!(dwFormat & SF_UNICODE)) > { > - /* FIXME? this is doomed to fail on true MBCS like UTF-8, luckily they're unlikely to be used as CP_ACP */ > - nWideChars = MultiByteToWideChar(CP_ACP, 0, stream->buffer, stream->dwSize, wszText, STREAMIN_BUFFER_SIZE); > + if (!is_read) > + { > + is_read = TRUE; > + if (stream->dwSize >= 3 && !memcmp(stream->buffer, bom_utf8, 3)) > + { > + cp = CP_UTF8; > + stream->dwSize -= 3; > + memmove(stream->buffer, stream->buffer + 3, stream->dwSize); There's no reason to move the data. -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2012