Let's say (Windows 10, 64-bit) I have a standalone exe file, c:\example\example.exe -- not installed with an installer, doesn't have anything in the registry, just an exe file.
If I then go into the registry, and add a key "example.exe" to App Paths, and set its default value to the path (.reg file snippet):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\example.exe]
@="C:\\example\\example.exe"What is different on my system now? What exactly can I do now that I could not do before I added that?
22 Answers
Nothing is different. If the program does not need to be installed with an installer, then there is no real point in adding a registry entry.
I have a number of these small programs and I just run them from the location they are stored in. So path not needed.
If you need a path to it, use Windows Environment variables to add the path. Advanced Windows Settings, Advanced Tab and click on Environment Variables. This will be preferable to a registry entry.
It may be preferable not to have a path so you can run the program from a USB Key or a different (non-OS) Drive.
Looks like it was a case of RTFM; I got a link to the documentation from this comment (thanks), so I figured I'd post a brief rundown. Check the MS docs for complete details.
The main purpose of "App Paths", as this answer hints at, is as an alternate place for per-app PATH entries (as opposed to the global user or system PATH entries). Also it specifies a couple of details for how Windows (particularly ShellExecute) deals with the program.
For my specific example, the only thing it does is specify the full path of "example.exe". There are probably a couple of effects here but one noticeable one is:
- I can now type "example.exe", or even just "example", in Start → Run and it will run the application; I no longer have to specify the complete path (e.g. I don't have to type out "c:\example\example.exe").
However, there are a few other values that can appear under the subkey, that affect various things:
- Path specifies a list of paths that are added to the PATH environment variable when the application is run -- I guess this is the main purpose of App Paths (hence the name).
- DropTarget can be used to specify custom behavior when files are dragged onto the exe, as opposed to the default of just turning the filenames into command line parameters.
- SupportedProtocols specifies if the application handles specific URL schemes.
- UseUrl specifies if the application can deal with URLs instead of just local files, with the end effect being to allow for various optimizations such as Windows passing the URL of an internet resource to the application rather than downloading it locally first, etc.
- DontUseDesktopChangeRouter is some setting that has something to do with avoiding file selection dialog deadlocks for debugger applications. It's a very specific option.
That's about it: paths, custom drag & drop behavior, URL handling, and a seemingly arbitrary hyper-specific debugger-related setting that I guess they couldn't find a better place for (or it was an old high priority hot-fix and some poor MS dev was running on caffeine and fumes). It's an odd little collection; but I'm sure there are historical reasons for everything there.
