Am Dienstag, den 09.09.2008, 18:25 +0300 schrieb Paul Chitescu:
Known problems:
- Although trying to check with access() if /usr/bin/xdg-screensaver is
executable there is no error returned from spawnvp() if exec() eventually fails after fork() succeeds. Unlikely but possible.
I see that as a bug in spawnvp(). You can not do anything about that. But I dislike checking using access, because a) it is a well-known race condition (in this case, it does not seem to matter, as /usr/bin should be writable by root only). b) you sacrifice the possibility to find /usr/local/bin/xdg-screensaver if the utility has been locally added. (more important point). Would removing the access call and just trying to call xdg-screensaver have any negative implication except for not letting the windows application know that locking failed? If not, I would remove the call, as MSDN says that locking can also fail on Windows for various reasons even if LockWorkStation returned TRUE.
- No way to disable it - maybe users don't want their screen locked.
So what? If a windows process calls LockWorkStation when the user does not want the workstation to be locked, it's a bug in the windows process, except...
- Doesn't take into account virtual desktops, and I have no idea what it
should do in that case, just deny access?
... if running in virtual desktop mode. (I suppose you mean "explorer /desktop" and not virtual desktop provided by X Window managers or virtual desktops provided by the linux kernel) As the real right way to implement this call is to SendMessage to explorer.exe, and explorer knows whether it runs in virtual desktop mode, I would suggest that the patch be extended to handle the screensaver start in Wine's explorer process, and just do nothing in the virtual desktop case.
Regards, Michael Karcher
-
Michael Karcher