Hi Martin,
On 08.12.2014 09:14, Martin Storsjö wrote:
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.
Ah, indeed, they are probably just exports by ordinal (the numbers match the ordinals).
There's a bunch of other functions with numbers, like ObjectStublessClient3 (3-32), NdrProxyForwardingFunction3 (3-32) as well - should I skip those as well, or is there any point in keeping them?
Those are really exports by name, but on Windows they are also exported by ole32 and missing in the current Wine specfile. Since this is most likely also an internal implementation detail (which is hopefully never directly used) it should be okay to skip them, in my opinion.
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.
Ok, I can try to sync those as well.
If you find a way to do that it would be nice, but not sure if its possible with the existing make_specfiles script.
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.
Ok, will do.
I guess you already noticed it, but it should be (sizeof(hstring_private) + length + 1) of course. ;)
I haven't tried to figure out the internal structure on windows, since the API (at least so far, and at least as long as there's no more of Windows Runtime involved) seems to suggest it's only an internal detail.
Well, I guess this idea is mainly inspired by msvcrt internal structures. Although its not officially documented a lot of applications mess around with the internal datastructures. Nevertheless, since we are not aware of any application doing that, its probably not worth the effort. I guess our current implementation is already very close to what MS does, so it could be easily fixed if it turns out to be necessary later.
Regards, Sebastian