re: WM_GETICON patch
Mike Hearn wrote: ... 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 :) Adding support for remote thread creation is on Tommy Kho's to-do list. (Probably just for linux and nptl initially.) - Dan
Re: WM_GETICON patch
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?
Re: WM_GETICON patch
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
Re: WM_GETICON patch
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.
Re: WM_GETICON patch
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
Re: WM_GETICON patch
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. Index: dlls/user/message.c === RCS file: /home/wine/wine/dlls/user/message.c,v retrieving revision 1.111 diff -u -r1.111 message.c --- dlls/user/message.c 23 May 2006 12:48:46 - 1.111 +++ dlls/user/message.c 11 Jun 2006 05:46:23 - @@ -625,6 +625,11 @@ FIXME( "WM_NCPAINT hdc packing not supported yet\n" ); data->count = -1; return 0; +case WM_GETICON: +case WM_QUERYDRAGICON: +/* WM_GETICON and WM_QUERYDRAGICON doesn't give or return any data. The + result of the reply is the value we care about */ +return 0; case WM_PAINT: if (!wparam) return 0; /* fall through */ @@ -648,9 +653,7 @@ case WM_PAINTCLIPBOARD: case WM_SIZECLIPBOARD: /* these contain HICON */ -case WM_GETICON: case WM_SETICON: -case WM_QUERYDRAGICON: case WM_QUERYPARKICON: /* these contain pointers */ case WM_DROPOBJECT: @@ -911,9 +914,7 @@ case WM_PAINTCLIPBOARD: case WM_SIZECLIPBOARD: /* these contain HICON */ -case WM_GETICON: case WM_SETICON: -case WM_QUERYDRAGICON: case WM_QUERYPARKICON: /* these contain pointers */ case WM_DROPOBJECT:
WM_GETICON patch
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. Index: dlls/user/message.c === RCS file: /home/wine/wine/dlls/user/message.c,v retrieving revision 1.111 diff -u -r1.111 message.c --- dlls/user/message.c 23 May 2006 12:48:46 - 1.111 +++ dlls/user/message.c 10 Jun 2006 23:19:01 - @@ -625,6 +625,10 @@ FIXME( "WM_NCPAINT hdc packing not supported yet\n" ); data->count = -1; return 0; +case WM_GETICON: +/* WM_GETICON doesn't give or return any data. The result of the reply + is the value we care about */ +return 0; case WM_PAINT: if (!wparam) return 0; /* fall through */ @@ -648,7 +652,6 @@ case WM_PAINTCLIPBOARD: case WM_SIZECLIPBOARD: /* these contain HICON */ -case WM_GETICON: case WM_SETICON: case WM_QUERYDRAGICON: case WM_QUERYPARKICON: @@ -911,7 +914,6 @@ case WM_PAINTCLIPBOARD: case WM_SIZECLIPBOARD: /* these contain HICON */ -case WM_GETICON: case WM_SETICON: case WM_QUERYDRAGICON: case WM_QUERYPARKICON:
