On 29/06/06, Thomas Kho tkho@ucla.edu wrote:
+@REQ(get_menu_item_info)
- user_handle_t handle;
- unsigned int pos;
+@REPLY
- unsigned int required_size;
- unsigned int type;
- unsigned int state;
- unsigned int id;
- user_handle_t submenu;
- user_handle_t checkbit;
- user_handle_t uncheckbit;
- void* text;
- unsigned long itemdata;
- void* typedata;
- user_handle_t bmpitem;
- rectangle_t rect;
- unsigned int xTab;
- dimension_t bmpsize;
- VARARG(text,unicode_str);
+@END
HBITMAPs aren't technically user handles, and afaik you can't pass GDI handles between processes like that. At least, not on Windows.
H. Verbeet wrote:
On 29/06/06, Thomas Kho tkho@ucla.edu wrote:
+@REQ(get_menu_item_info)
- user_handle_t handle;
- unsigned int pos;
+@REPLY
- unsigned int required_size;
- unsigned int type;
- unsigned int state;
- unsigned int id;
- user_handle_t submenu;
- user_handle_t checkbit;
- user_handle_t uncheckbit;
- void* text;
- unsigned long itemdata;
- void* typedata;
- user_handle_t bmpitem;
- rectangle_t rect;
- unsigned int xTab;
- dimension_t bmpsize;
- VARARG(text,unicode_str);
+@END
HBITMAPs aren't technically user handles, and afaik you can't pass GDI handles between processes like that. At least, not on Windows.
You can pass HBITMAPs between processes on Windows, although you are correct in saying that they aren't user handles. Of course, passing bitmap handles between processes on Wine won't work yet.
Thomas, can you regenerate this patch using "void *" for bmpitem (or perhaps add a new gdi_handle_t type)?
On 30/06/06, Robert Shearman rob@codeweavers.com wrote:
You can pass HBITMAPs between processes on Windows,
Is there anything special you need to do to it for that to work? It doesn't seem to work very well for me, and any documentation I can find basically says that while GDI handles are unique between processes, only the process that created them can access them.
"Robert Shearman" rob@codeweavers.com wrote:
You can pass HBITMAPs between processes on Windows, although you are correct in saying that they aren't user handles. Of course, passing bitmap handles between processes on Wine won't work yet.
Feng Yuan's book claims that while GDI handles are kernel objects Windows kernel doesn't allow them to work across process boundaries. My tests confirm that.
On 6/30/06, Robert Shearman rob@codeweavers.com wrote:
Thomas, can you regenerate this patch using "void *" for bmpitem (or perhaps add a new gdi_handle_t type)?
I'll add the gdi_handle_t type and resubmit two patches (I caught another use in the menu struct).
Tommy
Thomas Kho wrote:
On 6/30/06, Robert Shearman rob@codeweavers.com wrote:
Thomas, can you regenerate this patch using "void *" for bmpitem (or perhaps add a new gdi_handle_t type)?
I'll add the gdi_handle_t type and resubmit two patches (I caught another use in the menu struct).
As others have said, GDI objects are not shared between processes. GDI objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I assumed that they were shared, because icons are shared, but they are a user32 object.
You'll have to write a test to see whether Windows allows you to retrieve and use the bitmap for a menu from another process.
On 6/30/06, Robert Shearman rob@codeweavers.com wrote:
Thomas Kho wrote:
On 6/30/06, Robert Shearman rob@codeweavers.com wrote:
Thomas, can you regenerate this patch using "void *" for bmpitem (or perhaps add a new gdi_handle_t type)?
I'll add the gdi_handle_t type and resubmit two patches (I caught another use in the menu struct).
As others have said, GDI objects are not shared between processes. GDI objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I assumed that they were shared, because icons are shared, but they are a user32 object.
You'll have to write a test to see whether Windows allows you to retrieve and use the bitmap for a menu from another process.
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?
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.
Tommy
On 30/06/06, Thomas Kho tkho@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?
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.
On 6/30/06, H. Verbeet hverbeet@gmail.com wrote:
On 30/06/06, Thomas Kho tkho@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
On 06/07/06, Thomas Kho tkho@ucla.edu wrote:
On 6/30/06, H. Verbeet hverbeet@gmail.com wrote:
On 30/06/06, Thomas Kho tkho@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 guess that means Windows does store the handle rather than its contents.
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?
I only looked over the patches briefly, but the bitmap handles kinda jumped out.
-
Dmitry Timoshkov -
H. Verbeet -
Robert Shearman -
Thomas Kho