Mike Hearn mike@theoretic.com writes:
I'm going to keep sending this flipping patch until it gets in, or I find out what the next problem is you know. There's no escape! :)
Well, at least the critical section handling is broken, but the real problem is that all this stuff doesn't belong in shell32. We should really redesign it to get rid of the internal WS_EX_TRAYWINDOW flag and have a separate process to manage the tray window (plus other background tasks like the progman DDE interface, and maybe the desktop window too).
On Mon, 2003-09-15 at 19:20, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
I'm going to keep sending this flipping patch until it gets in, or I find out what the next problem is you know. There's no escape! :)
Well, at least the critical section handling is broken
How? I took another look and couldn't see any way for it to escape, but I could well have missed one. Or do you mean more generally?
But the real problem is that all this stuff doesn't belong in shell32. We should really redesign it to get rid of the internal WS_EX_TRAYWINDOW flag and have a separate process to manage the tray window (plus other background tasks like the progman DDE interface, and maybe the desktop window too).
Well yes, I know. Long term we need to remove the KDE stuff too so when an XEMBED tray is not detected, we can fall back to a "wine system tray". But, this is quite a large project, and currently many users have broken system tray support so it'd be nice for this to go in for now. Maybe I can get around to moving it into a separate process (wineshell?) some day, but not in the next few months, that's for sure.
thanks -mike
Mike Hearn mike@theoretic.com writes:
How? I took another look and couldn't see any way for it to escape, but I could well have missed one. Or do you mean more generally?
You are trying to protect the global list of items with a per-item critical section. This cannot possibly work.
On Mon, 2003-09-15 at 20:45, Alexandre Julliard wrote:
You are trying to protect the global list of items with a per-item critical section. This cannot possibly work.
I am? As far as I can see, the linked list probably should have a critical section too, but the per item one is to protect access to the NOTIFYICONDATAA structure, as both the calling thread and the dedicated trayitem thread could be accessing it, so you need protection on the item level too.
Better way to do it then?
Mike Hearn mike@theoretic.com writes:
I am? As far as I can see, the linked list probably should have a critical section too, but the per item one is to protect access to the NOTIFYICONDATAA structure, as both the calling thread and the dedicated trayitem thread could be accessing it, so you need protection on the item level too.
But you can't use that one to protect the global list.
Better way to do it then?
Using SendMessage to do the changes in the proper context; but we need a separate process to manage the window, we don't want to go around creating threads behind the application's back.
On Mon, 2003-09-15 at 23:36, Alexandre Julliard wrote:
But you can't use that one to protect the global list.
Nope. As I said, I guess we need a separate section for that.
Better way to do it then?
Using SendMessage to do the changes in the proper context; but we need a separate process to manage the window, we don't want to go around creating threads behind the application's back.
Is that a condition for the patch going in then? Also, is there a reason not to create threads behind the apps back? What I mean is, does that break some apps that don't expect it, or is it just a cleanliness thing.
IIRC Microsoft not only create threads but entire windows implicitly as part of the OLE APIs.
thanks -mike
Mike Hearn mike@theoretic.com writes:
Is that a condition for the patch going in then? Also, is there a reason not to create threads behind the apps back? What I mean is, does that break some apps that don't expect it, or is it just a cleanliness thing.
A bit of both, but it can definitely break apps. Mostly because the only way to be really compatible is to do things the way Windows does them as much as possible.
IIRC Microsoft not only create threads but entire windows implicitly as part of the OLE APIs.
Well, where Windows creates threads or windows then we should do it, and where it doesn't we shouldn't either.
If it can, it actually doesnt IMHO. Like I wrote to Mike, Im using Yahoo Messenger (and other apps) for months (year ?) with this patch applied and this for sure creates lesser problems than with our current system tray support.
A bit of both, but it can definitely break apps. Mostly because the only way to be really compatible is to do things the way Windows does them as much as possible.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Alexandre Julliard -
Mike Hearn -
Sylvain Petreolle