After `SHARED_READ_{BEGIN,END}` retirement as well as introduction of uninitialized memory marking, I think this field no longer belongs to `desktop_shm_t`.
1. Callers of `get_shared_desktop` have no business accessing the `seq` and `id`—they are mere internals. Such internals should be private to winstation machinery in order to avoid "leaky abstraction." 2. It's not possible to access the body part of the object directly, which leads to somewhat ugly pointer arith for `mark_block_uninitialized()` call in `alloc_shared_object`, etc. Specifically, we're doing some `CONTAINING_RECORD`-like pointer hack based on the assumption of a specific data layout that will break silently (i.e. no compile-time errors) when we decide we want to change `session_obj_t`. 3. Finally, an incorrect `object_shm_t obj;` header for a new object type isn't reliably caught by the compiler, making it easier to introduce a mistake.
Instead, I'd propose something like this (see the MR-form suggestion):
```c typedef volatile struct { LONG64 seq; /* sequence number - server updating if (seq & 1) != 0 */ object_id_t id; /* object unique id, object data is valid if != 0 */ union { // this can be a separate union definition instead desktop_shm_t desktop; /* ... */ } body; } object_shm_t; ```
Also, we'll need a helper for `DECL_HANDLER(get_thread_desktop)` to retrieve object id and index. This gives us a clean-up opportunity: we can just move `struct object_info` into protocol.def, and move it around via server requests (which eliminates the need for separate `id` and `index` assignment.