[PATCH 10/11] server: add calls to get/set menu item info

[Thomas Kho]

On 6/30/06, H. Verbeet <hverbeet at gmail.com> wrote:
> On 30/06/06, Thomas Kho <tkho at ucla.edu> wrote:
> > I'm not 100% clear what the problem is. My interpretation of your
> > first email was that there was a necessary distinction in type between
> > user/gdi handles as stored in the server, but now my understanding is
> > that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not
> > be mutable by external processes. Is that right?
> The basic problem is that if you create a HBITMAP in one process, then
> pass the handle to another process, you can't read the contents of the
> bitmap in that other process.
>
> So suppose you create a menu item in one process and set a custom
> bitmap on the menu item. Should the menu then display correctly in
> another process if you pass it the menu handle?

This is a case that isn't clearly defined by MSDN and seems to have
buggy behavior in practice. I tried just this and found that nested
popups were drawn intact except for missing bitmaps (as expected for
gdi objects). Windows even lets you set a top-level-menu in one app to
a menu item's popup menu in another app, which happens to mess up the
drawing of the original top-level-menu.

> > I did some probing and was able to change the values of the four gdi
> > objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in
> > MENUITEMINFO) from an external process. Specifically, I changed the
> > brush to one returned by GetStockObject(WHITE_BRUSH), changed the
> > bitmap to one of the predefined handles, and set (un-)check bitmaps to
> > an invalid value that was correctly returned upon a GetMenuItemInfo
> > query. So, I think regardless of the scope of gdi objects, it's the
> > right behavior for the menu code to blindly set and get the gdi
> > handles.
> Stock objects are somewhat special, since they're not created / owned
> by the current process.

Okay, so I tried the same with a solid brush and the gdi handle was
invalid in the remote process (again, as expected). However, as with
invalid bitmap handles, the menu functions complied in setting/getting
the value of the handle for the invalid brush.

Your original critique was that GDI objects aren't user handles, and
Rob suggested I create a gdi_handle_t in the server to correctly type
the gdi handles that need to be stored on the server but are
meaningless unless in the context of the process that created the gdi
object. I understand that much. Is there something else I'm missing
that needs to be addressed?

Thanks,

Thomas Kho