user32.dll: Implementation for LockWorkStation() based on xdg-screensaver

[Michael Karcher]

Am Dienstag, den 09.09.2008, 18:25 +0300 schrieb Paul Chitescu:
> Known problems:
> 1. 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.

> 2. 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...

> 3. 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