Here's a patch I'm trying to make to implement the WM_GETICON message, which programs like GeoShell (a Win32 taskbar replacement) would use to get a taskbar icon for the running processes. I'm not quite sure if it's proper or not, though. Originally GeoShell would show no icon on the taskbar and print a lot of fixme messages about it being unsupported. With this patch it now (always) shows the Wine glass icon for programs, with no such fixme messages. Since I'm unable to try it on a real Windows machine, I don't know if it's the right behavior for it to always show the generic icon like that.
Feedback and help would be appreciated.
I updated the patch a little more to handle WM_QUERYDRAGICON as well (something else that was complained about with GeoShell), since it's dealt with similarly to WM_GETICON (lparam is unused and an HICON is returned in the result). An odd effect now is that apps are showing one of GeoShell's arrows for program icons in the taskbar, whereas before it was the Wine glass. I didn't change anything directly relating to WM_GETICON, so I have no idea what could have caused it to change like that.
On Sat, 10 Jun 2006 16:35:45 -0700, Chris wrote:
Originally GeoShell would show no icon on the taskbar and print a lot of fixme messages about it being unsupported. With this patch it now (always) shows the Wine glass icon for programs, with no such fixme messages.
Well I guess this is a slight improvement but obviously WM_GETICON requires inter-process bitmaps to be supported in some fashion, which is a fair bit of work. Maybe for efficiency reasons even requiring the dreaded remote thread creation/service thread :)
thanks -mike
On Sunday 11 June 2006 13:42, Mike Hearn wrote:
Well I guess this is a slight improvement but obviously WM_GETICON requires inter-process bitmaps to be supported in some fashion, which is a fair bit of work.
Aren't icons already created on the global heap? They're created with GlobalAlloc16, and (optionally) added to a link list of shared icons. Since HICONs are really just void pointers, would something need to be done to transform the pointer for the receiving thread to see the same memory (assuming different processes need different pointers to see the same memory area)? I'm not too read up on how shared memory actually works.
On Sun, 11 Jun 2006 20:26:11 -0700, Chris wrote:
Aren't icons already created on the global heap? They're created with GlobalAlloc16, and (optionally) added to a link list of shared icons.
No, this is a confusing Win32ism. The "global heap" is not actually global, it's process-local. There *is* a shared heap in Windows 9x but not in NT.
GDI objects are stored in the kernel in Windows, and so are "shared" via that mechanism. We do the same thing by moving things into the wineserver and transporting them via RPC.
Actually images are stored as pixmaps in the X server, so it'd be awfully convenient if we could leverage that but I suspect the need to support non-X display systems means we have to do it the hard way, by shovelling image bits across the socket.
thanks -mike
On Monday 12 June 2006 06:42, Mike Hearn wrote:
Actually images are stored as pixmaps in the X server, so it'd be awfully convenient if we could leverage that but I suspect the need to support non-X display systems means we have to do it the hard way, by shovelling image bits across the socket.
Actaully you couldn't anyway, according to dlls/user/cursoricon.c:
* This layout is very sub-optimal, as the bitmap bits are stored in * the X client instead of in the server like other bitmaps; however, * some programs (notably Paint Brush) expect to be able to manipulate * the bits directly :-(
How would you allocate memory that could be shared between processes (either implicitly, or with a way to "transform" a pointer for one process to another)? Would that be an acceptable work around until something better is made?
-
Chris -
Mike Hearn