[PATCH 05/10] combase: Add stub dll.

[Sebastian Lackner]

Hi Martin,

a few things where I am not sure about:


[PATCH 05/10]

[...]
> +@ stub COMBASE_63
> +@ stub COMBASE_64
> +@ stub COMBASE_65
> +@ stub COMBASE_66
> +@ stub COMBASE_67
> +@ stub COMBASE_68
[...]

Are these really named exports, or exports by ordinal? If they are by ordinal and have no name assigned they are probably internal, and its not worth exporting them in Wine.
I also noticed that combase.dll exports a lot of functions (Co*), which in Wine are implemented in ole32. It probably makes sense to sync that, but that can also be added in a later patch in my opinion. I don't think make_specfiles already supports such a situation.


[PATCH 06/10 and also following patches]

> +/***********************************************************************
> + *      RoInitialize (api-ms-win-core-winrt-l1-1-0.@)
> + */

Those comments should probably be changed.


[PATCH 07/10]

Does creating an empty string really return a HSTRING or just NULL (which seems to behave identical)? It probably makes sense to add a test for that.

Does WindowsCreateString or WindowsCreateStringReference strip terminating NULL chars? (Embedded NULL chars are allowed obviously, but it might be possible that trailing NULL chars are handled differently).

nsivov on #winehackers also suggested that it might be worth trying to find out what the structure is on Windows, but not sure if its worth the effort. If we're not trying at all to be compatible, we could get rid of one of the two memory allocations by allocating (sizeof(hstring_private) + length) as a single chunk, and setting ->buffer according.


[PATCH 09/10]

I would also suggest adding tests for the content of the buffer. You can use for example memcmp(...) to verify that the content is correct.


[PATCH 10/10]

Is the buffer initialized? Are terminating NULLs stripped from the buffer?



Regards,
Sebastian