[PATCH] winemac.drv: Use the public UTF-16 type for Unicode text.

Charles Davis cdavis5x at gmail.com
Wed Aug 21 11:31:12 CDT 2013


On Aug 21, 2013, at 10:11 AM, Ken Thomases wrote:

> On Aug 21, 2013, at 10:12 AM, Ken Thomases wrote:
> 
>> On Aug 20, 2013, at 10:49 PM, Charles Davis wrote:
>> 
>>> In the Windows world, "Unicode" almost universally means "UTF-16". So,
>>> use the well-known UTF-16 type instead of making up our own.
>>> 
>>> I have to wonder if there was a good reason Ken didn't use this
>>> initially.
>> 
>> Please hold this patch while I review it.
>> 
>> I think there is a good reason why I didn't use it, but I have to figure it out again. :-/
>> 
>> It has to do with a promised pasteboard type (what Microsoft calls delayed rendering) and the conversions to the other text types. I think we need to use a custom type to distinguish between being asked for promised data vs. being asked for a conversion.
> 
> Well, that wasn't the reason.  However, I've found a simpler reason not to commit this.  The data supplied for CF_UNICODETEXT is null-terminated, but public.utf16-plain-text shouldn't be.  (Neither CFString nor NSString treat a 0x0000 code unit specially.  It just ends up part of the string.)
Wow, I didn't know that. I guess that makes sense, because NSCFStrings are counted.
> 
> Was there a specific compatibility problem you were trying to solve?  Or just reviewing the code and found this strange and wanted to improve it?
I was looking over the patches as you sent them, found this strange, and thought this would improve it.
> 
> If you like, it may make sense to add conversions to public.utf16-plain-text like those done for public.utf8-plain-text, but the import/export functions will have to add/remove the terminating null.
Sounds good. But it might take me a little while to rework this. I have a bunch of other things going on at the moment. I'll probably miss today's commit wave, but not tomorrow's.

Chip




More information about the wine-devel mailing list