MScholtes/VirtualDesktop

Window moving fails with unhelpful error in non-admin console

R2RT opened this issue · 2 comments

R2RT commented

Hey again,

I've been checking out VirtualDesktop back in May and I don't recall such issue, so probably Microsoft has changed something.

It seems that some subset of commands requires elevated access.

E.g. in normal cmd.exe:

> VirtualDesktop gd:1 mv:notepad
Virtual desktop number 1 (desktop 'Desktop 2') selected
Error in parameter 'mv:notepad'

In elevated (Administrator) one:

> VirtualDesktop.exe gd:1 mw:notepad
Virtual desktop number 1 (desktop 'Desktop 2') selected
Window of process 'notepad' moved to desktop number 1 (desktop 'Desktop 2')

But in both consoles gdfw works:

> VirtualDesktop gdfw:notepad
Window of process 'notepad' is on desktop number 1 (desktop 'Desktop 2')

Tested on Windows 10 Pro, 22H2 (Build 19045.4651)

I suppose not much can be done on VirtualDesktop side: it could ask for elevated access, but it kills its purpose of being small utility.
It could also be run in some server mode, where admin access is given only once (potentially - on startup as service) - but it might be an overkill.

Anyway, as for this issue report, error log for missing elevated access could be more verbose. Currently it reads as if user made some error in command: "Error in parameter 'mv:notepad'", not that Windows refused to process properly written command.

Hello @R2RT,

the "user made some error in command":
There's a typo in your "normal command". Use parameter mw instead of mv.

Greetings

Markus

R2RT commented

Yay, what a shame, thanks for spotting that :( I somehow managed to always do same error in a few non-admin consoles. Gonna stick to full-named commands since now.