Fwiw I claim that there's no const misuse here. The const keyword in C/C++ never means that a value, possibly through a pointer to it, is constant. It always only means that the reference or pointer cannot be used directly to mutate the value.
This is exactly how it has been used in the shared object infrastructure, and how it is being used here. The shared objects are not constant, neither on the wineserver nor on the client side, they are still mostly always kept as const pointers to avoid accidental modification and to convey information that additional steps need to be used to mutate the values:
a) From the client side, call a wineserver request. b) From wineserver side, use the SHARED_WRITE macros.
To the contrary to other shared objects which have specific and stronger data consistency mechanism and can use the SHARED_WRITE macros more freely to mutate the values, the shared handle table uses a different and less robust mechanism as has been specifically requested during review.
This other mechanism makes many more assumptions, and the client/server side only work with some very specific sequence of modification. This means that the shared handles can safely be mutated only during allocation / free of their corresponding handles, and nowhere else.
Therefore, I believe it is even more critical to keep the const qualifier, on the wineserver side, in this case that it would even be for other shared objects.