http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #4 from Andrea Faulds <ajf@ajf.me> --- I wrote a test application that uses SHAppBarMessage() and tested it on Windows 2000. On that OS: - An appbar registered with SHAppBarMessage() does indeed get an area of the screen reserved to it, such that maximized windows won't cover it, and you can't move the window cursor over it when dragging or resizing a window. The registration also makes existing windows, maximized or otherwise, move out of the way, including by resizing if necessary. - If explorer.exe is not running, registering an appbar doesn't do anything, and so the area of the screen isn't reserved and you can maximize over it. - When explorer.exe is killed, the appbar and taskbar areas of the screen stay reserved (maximizing won't cover them), even if there is no longer be anything in them. - When explorer.exe is killed, the existing appbar registrations are apparently forgotten, because when explorer.exe is restarted, currently maximized windows get resized over the appbar (but not the taskbar of course). Based on these findings, I hypothesize that Windows's explorer.exe: 1) operates some kind of server to register appbars and respond to queries 2) in response to appbar registration, updates some kind of global state that lives outside the process which specifies what part of the screen applications can use (the SPI_GETWORKAREA rect?) 3) in response to appbar registration, triggers resizing and movement to ensure open windows remain within that part of the screen I see that WINE's explorer.exe already does (1) in appbar.c, but I see no sign that it tries to do (2) or (3). So I guess those are the missing pieces here. I suspect there is no public Win32 API for doing (2) in particular. But it seems doable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.