feature request: playing nice with Vista UAC

[stax76]

The plugin dir reg key should be at HKCU and the default location should be the local app data dir of the current user.

Applications that load and install plugins dynamically like Firefox, Thunderbird, StaxRip, MeGUI etc. require this since unlike XP under Vista applications normally run with limited privilegs.

edit: wrong forum, sorry

[stax76]

Has nobody a opinion on this? The registry pointer to the plugin directory as well as the default location are in protected system locations. Application can't change the plugin directory or install or delete plugins under Vista unless started explicitly with elevated privilegs. If Firefox would do it like AviSynth it would be a major hassle to install or uninstall plugins.

Autoloading helps to improve usability as well as reducing bloat by sharing plugins between applications instead of every application using their own set of plugins. According to a poll I once created (http://forum.doom9.org/showthread.php?t=106481), auto loading is the commonly preferred method of using plugins.

[squid_80]

I disagree, because then x64 and x86 versions would point to the same directory and that would be bad. (HKCU is the same for x86/x64 apps while HKLM is segregated.)
OTOH the x64 version could use a different registry key, but I think that would still be at odds with your end purpose.

[stax76]

Another reason why the default location, the programs directory is not a good choice is that plugins have settings characteristics, it's something people want to backup so the user directory would be a natural choice.

[unskinnyboy]

Another reason why the default location, the programs directory is not a good choice is that plugins have settings characteristics, it's something people want to backup so the user directory would be a natural choice.What do you mean by this? Plug-ins (e.g. myplugin.dll) are read-only and cannot be written into or modified in any other way. So what is there to back up, except the plug-ins themselves?

[stax76]

I mean the entire plugin directory to backup and I don't think the programs directory should contain anything to backup, only installers should write there.

[Sharktooth]

even if i hate vista i agree with stax.
however 2 separate folders for 32 and 64 bits plugins are needed (maybe plugins32 and plugins64)
the problems start when an app should identify if the 32 or 64 bit version is installed.
however it could be easy if avisynth itself would set the registry keys with a different suffix accordingly to the installed version. the software may look for them and estabilish what version is installed and where the plugins folder is located.

[Doom9]

I support this change request as well. While installing Avisynth as such is an act that requires high system permissions, installing an avisynth plugin should be something a regular user can do without administrative privileges. In addition, storing plugins in a user specific directory would permit different users on the same machine to use their own plugins.

[IanB]

As I more or less discussed in a PM with stax, put forward approximately where and what source code change are required and what directories and registry keys can safely be used by plebe visturd processes and I'll consider how best to add the feature. You don't need to hard spec the code changes, just describing how it needs to work is adequate.

I.E. Do the research needed to make this work successfully and keep working transparently for the current user base.

Also as a fair amount of this request effects the installer, some research on how to detect Vista and develop good default install values for the Nullsoft Install System we use.

Hints: See src\core\avisynth.cpp, line 1101, routine ScriptEnvironment::PrescanPlugins() and HKCU\Software\Avisynth\PluginDir2_5 might be a good key to start with.

And as this is the Developer Forum I expect to see discussion of real code ideas, bits, bytes, API calls and potential problems.

[stax76]

I've looked at the source code, a smooth migration path makes things difficult, in particular when you are not very comfortable with C++, NSIS assembly like script (braindead IMHO) and setting up the build environment. I thought then maybe I can improve StaxRip to deal better with the situation, I found a good way:

StaxRip uses 7-Zip to pack/unpack applications, if unpacking fails, it will try a second time and this time there will be a manifest file telling windows that 7-Zip requires highest privilegs, UAC dialog pops up, problem solved.

[IanB]

... don't need to hard spec the code changes, just describing how it needs to work ...I don't expect you to write any C++ or NSIS, or build an Avisynth.dll.

I do expect some evidence of having read the code, thought about how it currently works, and come up with a plan on how to make this feature work. Doing a bit of Google-foo to find out about NSIS and Visturd, and a bit of live testing on a Visturd box to find out which directories and registry keys are workable, I think is not unreasonable.

Further hint:- Leave existing autoload plugin reg keys and directories as they are. Add new per user key. If absent then old behaviour else scan that directory for extra autoload plugins.

[stax76]

Backward compatibility is often a challange, after all backward compatibility is one of the main reasons why Visturd as you call it is so slow and bloated. Unfortunately it's necessary because otherwise people would start asking questions why stuff don't work as it used to be or they couldn't get things to work at all. Maybe you can outline what the installer and AviSynth currently does so people can post their ideas about what changes should be done.

The NSIS variable for the local app data dir of the current user is $LOCALAPPDATA I think, the Win32 API should be SHGetFolderPath with CSIDL_LOCAL_APPDATA flag.

[IanB]

@stax,

Yes $LOCALAPPDATA and SHGetFolderPath(CSIDL_LOCAL_APPDATA) is the kind of info needed. Doing the research and testing with seeming trivial stuff like this can be a real ball breaker when you don't have any test platform, so here I am having to rely on others to do it.

[foxyshadis]

Ian, I'll give you full remote desktop access to a Vista box tomorrow if that's what you need. I just need to call someone during business hours to turn it back on.