Closed BikerScott closed 10 years ago
Thanks for the bug report!
This has to do with where I store the settings. On newer versions of Windows you can't write to the programs directory without administrator privileges, so mDesktop is unable to save the settings. To get around this you can right click mDesktop and run as administrator.
I'll fix this in the next version by storing the settings in %A_appdata%\mDesktop. This will return a directory safe to write to on all versions of Windows.
can we install a junction/mklink for a particular file from the mDesktop programs directory to a same-named file in a directory that has the proper permissions as a temporary work-around?
Alright I believe I've fixed this issue!
Can y'all install AutoHotkey then try running mDesktop from source?
I've installed AutoHotkey, NSIS from Nullsoft (with multiple plugins needed to get past various compile errors), but am still encountering issues. Opening the nsi file with VIM gives an error saying the last line is incomplete. It is indeed, missing a "]" and a <CR>.
I'll re-download and re-extract the source package. If that doesn't work, I'll manually close out the opencandy call (section below the end of Function .onGUIEnd)
I also don't have an OCSetupHlp, but as all the spamware lines all seem commented out anyway that probably doesn't matter.
Re-downloaded source, same problem with the end-of-file still exists. Deleted or commented out all opencandy stuff. Running install script still fails, saying essentially that mDesktop.exe doesn't exist. Commenting out the line in the script that specifies the exe results in the exe not being created by the install script.
ahh, okay. right click on the ahk file and clicking "compile" creates the exe that the installer was referring to.
You don't need the installer! Just run mDesktop.ahk
Or run the created exe. I just want to know if my latest commit fixes this issue for you.
Yes. Sorry for the lack of response. There are still other issues with running without elevating as an admin (some windows appear on all desktops, even - in rare cases - if the app was launched as the same non-admin user).
But this setting fix appears to work to fix this bug (#14).
No worries thanks for checking it out!
I'm not sure what we can do about controlling windows created by apps running as administrator. Except for running mDesktop as administrator. Does Windows still do that UAC popup thing? I set up a Windows 8 VM the other day and I don't remember it doing it.
Yes, and my network at work is very intent on me not changing windows security policies, even with an admin login. I don't want to start a war with IT, so I won't firewall them out and then drop my UAC level.
Vista's UAC was very intrusive. Windows 7 was much better from my perspective. 8.1 is a bit more intrusive than 7.
Is it possible to have mDesktop have a system service running which the main application tells what it wants done? I'm not sure this is any better from a security model or end user perspective though as it still requires an aspect of mDesktop to run as an admin/system user.
I've never worked with services so I'm not sure what that would take or accomplish. But I can use something like this to request administrator privileges:
DllCall("shell32\ShellExecuteA", uint, 0, str, "RunAs", str, A_ScriptFullPath, str, """" . PARAM1 . """", str, A_WorkingDir, int, 1)
I'll start a new ticket for further discussion since the original issue is solved.
What steps will reproduce the problem?
What is the expected output? What do you see instead? Expected it to launch with my previously saved settings
What version of the product are you using? On what operating system? Latest version (1.6 I think), Windows 8.1
Each restart I have to right click on the tray icon, open, and "save settings" before the application will start working again. It works flawlessly after that.