[PATCH v2] server: Release related atoms when destroying a window class

[Ralf Habacker]

Am 27.11.18 um 08:32 schrieb Dmitry Timoshkov:
> Ralf Habacker <ralf.habacker at freenet.de> wrote:
> 
>>>> +    ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
>>>> +        "UnregisterClass() failed - unable to unregister atom\n");
>>>
>>> Using a clipboard api in the class test looks strange, why not call
>>> GlobalGetAtomName() directly instead?
>>>
>> On native Windows Atoms registered by RegisterClass are not in the
>> global atom table and therefore could not be checked by inspecting the
>> global atom table.
>>
>> from
>> https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables
>> "Also, registered classes are stored in an internal atom table used by
>> the system. An application adds atoms to this atom table using the
>> RegisterClass or RegisterClassEx function."
> 
> How does this justify the usage of GetClipboardFormatName?
> 
Some details about internal atom tables on Window are documentated at

https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables

"The system uses atom tables that are not directly accessible to
applications. However, the application uses these atoms when calling a
variety of functions. For example, registered clipboard formats are
stored in an internal atom table used by the system. An application adds
atoms to this atom table using the RegisterClipboardFormat function.
Also, registered classes are stored in an internal atom table used by
the system. An application adds atoms to this atom table using the
RegisterClass or RegisterClassEx function."

On native Windows atoms from RegisterClass are in the same atom table as
atoms registered by clipboard formats and the api function
GetClipboardFormatName() is the official way to get them. You may check
this with the test app from bug
https://bugs.winehq.org/show_bug.cgi?id=46180