[PATCH 15/15] api-ms-win-core-winrt-string: Implement a few HSTRING functions.

[Michael Müller]

Hi Martin,

you are right that WindowsSubstring always creates a new backing buffer
(although it is not necessary), but there is also
WindowsDuplicateString. This function indeed uses the same backing
buffer as you can verify with this small sample code:
https://dl.dropboxusercontent.com/u/61413222/test-string.c

The MSDN also explicitly mentions that the refcount is incremented in
this case:
"If string was created by calling the WindowsCreateString function, the
reference count of the backing buffer is incremented. If string was
created by calling the WindowsCreateStringReference function, the
Windows Runtime copies its source string to a new buffer and starts a
reference count, which means that newString is not a fast-pass string."
Source: http://msdn.microsoft.com/en-us/library/br224634(v=vs.85).aspx

It is necessary to implement reference counting in order to be fully
compatible with the Windows implementation.

Regards,
Michael

Am 06.12.2014 um 16:28 schrieb Martin Storsjö:
> Hi Sebastian,
> 
> On Mon, 1 Dec 2014, Sebastian Lackner wrote:
> 
>>>> * http://msdn.microsoft.com/en-us/library/br224632(v=vs.85).aspx
>>>> mentions: """Calling WindowsDeleteString decrements the reference
>>>> count of the backing buffer, and if the reference count reaches 0,
>>>> the Windows Runtime de-allocates the buffer."""
>>>>
>>>> I don't see the concept of refcounted backing buffers anywhere in
>>>> your code, which is most likely wrong. Its difficult to fix that
>>>> later.
>>>
>>> I had a really hard time understanding the MSDN part here - I don't
>>> find any corresponding function for increasing a refcount, so I don't
>>> see how the HSTRING itself would be refcounted. So I think that only
>>> matters once you pass those string handles into the full Windows
>>> Runtime itself.
>>
>> I think the main purpose of that is to implement fast versions for
>> functions like SubString(...). If its not created with
>> WindowsCreateStringReference(...) both strings can use the same
>> backing buffer, which is faster than copying part of the string.
>>
>> Normally strings are immutable, but as it is also possible to get a
>> raw pointer to the buffer (
>> http://msdn.microsoft.com/en-us/library/br224636(v=vs.85).aspx ) an
>> application might depend on this specific implementation detail. Tests
>> would really help here to confirm my theory that changing the
>> substring also modifies the original one.
> 
> I did test this now, and no, a string created with WindowsSubstring
> doesn't share the same backing buffer as the original string it was
> based on (created with WindowsCreateString), so changes to either of
> them via the pointer from WindowsGetStringRawBuffer doesn't affect the
> other one.
> 
> So therefore I don't really see where reference counting would come into
> play with this API at all, unless the Windows Runtime hooks into HSTRING
> objects via some other (non-public) functions. Or is CloseHandle
> supposed to be able to handle HSTRINGs, and is there any corresponding
> function that would increase the reference count of any generic HANDLE?
> 
> // Martin