https://helgeklein.com/blog/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer/

How the App Paths Registry Key Makes Windows Both Faster and Safer

Why can you start Mozilla Firefox by typing "firefox" in the Run dialog and
press enter? Firefox.exe is not located in any directory in the path.

The same with Outlook (type "outlook"), PowerShell ("powershell"), VMware
Workstation ("vmware") or Adobe Reader ("acrord32").

This "magic application starting thingy" works because of a little-known
Windows feature based on the "App Paths" registry key.

App Paths - Dissection
In your forays through the Windows registry you may have noticed a peculiar
key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths, that has subkeys named like executables.

Here is what it looks like on my machine:
https://helgeklein.com/wp-content/uploads/2010/08/app-paths-registry-key.png

Notice that the HKLM App Paths key and its counterpart in HKCU are
basically mapping tables between executable names and their full paths.

The direct subkeys of App Paths store the executable names, while each
subkey's default value stores the full path to that executable.

Notice also, that the key "firefox.exe" has a named value "Path" that
stores the path to the program's installation directory.

So what is this all about?

App Paths - Explanation
The App Paths key provides a mechanism that allows programmers to make
their application startable by name only without having to modify the
system-wide path.

Why would they do that?
Vanity and overestimation of the importance of one's own application.

But, hey, it sometimes does come in handy to be able to start programs
without having to type the full path, just hit Win+R instead and type the
executable name.

Getting more technical, modifying the system path is not exactly best
practice since it may slow down the system, break other applications and
even create security holes.

To provide an alternative, Microsoft added the App Paths functionality in
XP.

Whenever a new process is to be started with the API functions ShellExecute
or ShellExecuteEx, and only a file name without a path is specified,
Windows looks in the following places for the executable:

The current working directory.
The Windows directory.
The Windows\System32 directory.
The directories listed in the PATH environment variable.

If there is a App Paths subkey with the name of the executable, the key's
default value is used as the program's full path. If the subkey also has a
value named Path, the string stored in Path is added to the PATH
environment variable, but only for the process to be started.

As mentioned, the App Paths key has a second use, namely proving
per-process PATH configurations, reducing the need of application
developers to modify the global system PATH.

For further information and a list of other possible values please see the
MSDN article Application Registration [App PathsProcessRegistry].
http://msdn.microsoft.com/en-us/library/ee872121%28VS.85%29.aspx

On 3/19/23 13:51, this is what Freethinker wrote:
> https://helgeklein.com/blog/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer/
>
> How the App Paths Registry Key Makes Windows Both Faster and Safer
>
> Why can you start Mozilla Firefox by typing "firefox" in the Run dialog and
> press enter? Firefox.exe is not located in any directory in the path.
> The same with Outlook (type "outlook"), PowerShell ("powershell"), VMware
> Workstation ("vmware") or Adobe Reader ("acrord32").
> This "magic application starting thingy" works because of a little-known
> Windows feature based on the "App Paths" registry key.
>
> App Paths - Dissection
> In your forays through the Windows registry you may have noticed a peculiar
> key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
> Paths, that has subkeys named like executables.
> Here is what it looks like on my machine:
> https://helgeklein.com/wp-content/uploads/2010/08/app-paths-registry-key.png
>
> Notice that the HKLM App Paths key and its counterpart in HKCU are
> basically mapping tables between executable names and their full paths.
> The direct subkeys of App Paths store the executable names, while each
> subkey's default value stores the full path to that executable.
>
> Notice also, that the key "firefox.exe" has a named value "Path" that
> stores the path to the program's installation directory.
>
> So what is this all about?
>
> App Paths - Explanation
> The App Paths key provides a mechanism that allows programmers to make
> their application startable by name only without having to modify the
> system-wide path.
>
> Why would they do that? Vanity and overestimation of the importance of one's own application.
> But, hey, it sometimes does come in handy to be able to start programs
> without having to type the full path, just hit Win+R instead and type the
> executable name.
>
> Getting more technical, modifying the system path is not exactly best
> practice since it may slow down the system, break other applications and
> even create security holes.
> To provide an alternative, Microsoft added the App Paths functionality in
> XP.
> Whenever a new process is to be started with the API functions ShellExecute
> or ShellExecuteEx, and only a file name without a path is specified,
> Windows looks in the following places for the executable:
>
> The current working directory.
> The Windows directory.
> The Windows\System32 directory.
> The directories listed in the PATH environment variable.
>
> If there is a App Paths subkey with the name of the executable, the key's
> default value is used as the program's full path. If the subkey also has a
> value named Path, the string stored in Path is added to the PATH
> environment variable, but only for the process to be started.
>
> As mentioned, the App Paths key has a second use, namely proving
> per-process PATH configurations, reducing the need of application
> developers to modify the global system PATH.
>
> For further information and a list of other possible values please see the
> MSDN article Application Registration [App PathsProcessRegistry].
> http://msdn.microsoft.com/en-us/library/ee872121%28VS.85%29.aspx
>
>
Not a bad idea, but don't change from 32bit to 64bit apps. Path of /program files and /program files(x86) would/will
screw this up unless there is some logic during install to correct the reg key.

--
Al

On 19.03.23 19:35, Big Al wrote:
> Not a bad idea, but don't change from 32bit to 64bit apps.
> Path of /program files and /program files(x86) would/will
> screw this up unless there is some logic during install to
> correct the reg key.

The "App Path" is different from the "$PATH" in how it works.
https://micksmix.wordpress.com/2011/08/19/the-windows-app-paths-registry-key/

I've been using the App Paths sub key since Windows XP but I don't use it
to run programs that already registered themselves into the App Paths key.
https://tweaks.com/windows/36684/creating-app-paths-in-windows-xp/

I use it to call scripts that I have written over the years.
And I use it to open up files that I've written over the years.
And because it remembers what you called with a simple but usable history.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\{mykey}.exe
@Default c:\path\whatever-I-want-to-happen-when-I-type-mykey

An example is you have a document, which can be anything, but let's say
it's a todo list (for arguments sake) and you want access to it easily.

You can make a shortcut to it, but then when you have another need for a
document, let's say it's a scratch file (for arguments sake), you need
ANOTHER shortcut.

Then let's say you want to call up a manopage script (for arguments sake).
You need _another_ easy-to-find shortcut to make running it instantaneous.

While you could solve this instantaneous access a bunch of ways, the
article was saying that a lot of people don't know about this way.

(Click taskbar icon for Win+R) & then type todo (& press the Enter key).
(Click taskbar icon for Win+R) & then type scratch (& press the Enter key).
(Click taskbar icon for Win+R) & then type manpage (& press the Enter key).

Even better, Windows creates a pulldown of those for you to choose from.
(Click taskbar icon for Win+R) & select todo,scratch,manpage from the menu.

Some people get complicated with all the options but I just keep it simple.
https://old.sandon.it/node/24

On 20.03.23 16:34, Stan Brown wrote:
>> The "App Path" is different from the "$PATH" in how it works.
>> https://micksmix.wordpress.com/2011/08/19/the-windows-app-paths-registry-key/
>>
>
> That's an interesting description of AppPath; thank you.
> But what is this $PATH you mentioned in passing? Are you referring to
> something in UNIX? In Windows it would be %PATH, right? (I'm not
> busting your chops here; I really want to know.)

Good question. Please do ask as I want to promote this wonderful feature.
(I don't have Windows 11 so I don't know if it's in that too - is it?)

My mistake. I was using the $PATH term from my Linux days where it's my
fault I didn't even test that it's "echo %path%" on my Windows 10 PC.

But funny you mentioned that because I have a similar % sub keys:
HKLM\Microsoft\Windows\CurrentVersion\App Paths\%.exe
@Default=C:\path\keywords.ppt
Which lists all the %keyword% Windows keywords for me, lest I forget.
%PATH% �V C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
%PATHEXT% �V .com;.exe;.bat;.cmd;.vbs;.vbe;.js;.jse;.wsf;.wsh;.msc
%HOMEPATH% -C:\Users\<username>
%LOCALAPPDATA% �V C:\Users\<username>\AppData\Local
%PSMODULEPATH% �V %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\

The App Path is useful if you want to open something up without having to
create a shortcut (although the App Path can run a shortcut also).

It's probably important to note (because it's not intuitive) that the name
of the subkey can be anything but it must end with "exe" for some reason.

To take a common example likely everyone has, this common app path sub key:
HKLM\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
@Default=C:\path\firefox.exe
Doesn't actually have to be "firefox.exe" but even "f.exe" would work.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f.exe
@Default=C:\path\firefox.exe

That is, the only meaningful part of the sub key name is the "exe" and the
fact that it has to be a unique sub key within the App Paths registry key.

That gives you an advantage if, for example, you want to make a few Firefox
App Paths sub keys (which I haven't tested) such as this off the cuff set.

HKLM\Microsoft\Windows\CurrentVersion\App Paths\f1.exe
@Default=C:\path\firefox.exe (with no options invoked)

HKLM\Microsoft\Windows\CurrentVersion\App Paths\f2.exe
@Default=C:\path\firefox.exe (with one set of options invoked)

HKLM\Microsoft\Windows\CurrentVersion\App Paths\f3.exe
@Default=C:\path\firefox.exe (with another set of options invoked)

Where those sets of options can be targets inside separate shortcuts,
but where those shortcuts don't have to clutter your GUI if you use
them a lot at all you need to remember is f1, f2 and f3 to run them.

In addition, you might have firefox in your path but maybe you want to run
a different firefox, which the App Paths sub key allows you to easily do.

HKLM\Microsoft\Windows\CurrentVersion\App Paths\f4.exe
@Default=C:\different-path\firefox.exe

To run each of these, you'd only need to pin the Win+R icon to the taskbar
and then tap that icon and a selection of previous choices can be made
from a list of the most recently used that Windows automatically maintains.

You can turn that remembering off, of course, and of course you can always
check your App Paths subkey if you forget the names you assigned to them.

To import into a second computer, of course you'd need to be well
organized that you put your scripts and folders in the same location.

Notice that it also opens documents, which I use for frequently used stuff.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\doc1.exe
@Default=C:\path\document.txt

HKLM\Microsoft\Windows\CurrentVersion\App Paths\doc2.exe
@Default=C:\path\document.xls

HKLM\Microsoft\Windows\CurrentVersion\App Paths\doc3.exe
@Default=C:\path\document.pdf

Once you decide to run shortcuts, you can do almost anything with them.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\whatismyipaddress.exe
C:\path\runcurl.lnk
Where the shortcut runcurl.lnk has the following target
%comspec% /k %windir%\system32\curl.exe icanhazip.com

HKLM\Microsoft\Windows\CurrentVersion\App Paths\archives.exe
C:\path\archives.lnk
Where the shortcut archives.lnk has the following target
%comspec% /c %windir%\explorer.exe c:\path\archives

HKLM\Microsoft\Windows\CurrentVersion\App Paths\admin.exe
C:\path\admim.bat
Where admin.bat sets an obvious color when it invokes an admin window.
@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
IF NOT "%~1"=="" goto :START
SET LogFile=%TEMP%\admin.vbs"
Echo Set UAC = CreateObject("Shell.Application") >"%LogFile%"
Echo UAC.ShellExecute "%~f0", "%cd%", "", "runas", 1 >>"%LogFile%"
Start "" /MIN "%LogFile%"
goto :EOF
:START
cmd /k "CD /D "%*" & Echo Administrator: & color 4F"
REM runas.exe /user:administrator /savecred "put your command here instead, to skip UAC"
:EOF

It's advised to maintain a summary document that explains them all.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\apppaths.exe
C:\path\my_app_paths.doc

Which, brings up, for example, something like this quick summary.
Win+R % (brings up all the Windows keywords)
Win+R firefox (runs the default firefox with no options
Win+R f1 (runs a different firefox with no options invoked
Win+R f2 (runs firefox with one set of options invoked
Win+R f3 (runs firefox with another set of options invoked
Win+R f4 (runs yet another firefox)
Win+R doc1 (opens a text document for edit)
Win+R doc2 (opens an excel document for edit)
Win+R doc3 (opens a pdf document for edit)
Win+R whatismyipaddress ---> (determines your current WAN/VPN IP address)
Win+R archives (opens the archives folder in Windows file explorer)
Win+R admin (opens an obvious red administrator command window)
Win+R apppaths (opens an obvious red administrator command window)

Be advised that invoking the app paths sub key does not create the
document but an empty document in its place will work for starters.

While I never change the %path%, there is nothing preventing anyone from
using both the Windows %path% and the App Paths sub key as intended.

If you find out that App Paths does even better stuff, let me know as
I'm always using this feature of Windows 10 every day many times a day.

On 20.03.23 19:43, Paul wrote:
>> That's an interesting description of AppPath; thank you.
>> But what is this $PATH you mentioned in passing? Are you referring to
>> something in UNIX? In Windows it would be %PATH, right? (I'm not
>> busting your chops here; I really want to know.)
>>
>
> PS > cmd # Switch to Command Prompt
> Microsoft Windows [Version 10.0.22621.1413]
> (c) Microsoft Corporation. All rights reserved.
>
> C:\>echo %path%
>
> ...
> C:\WINDOWS; # Lots of custom crap in there...
> C:\WINDOWS\System32\Wbem;
> C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
> C:\Program Files\gs\gs9.56.1\bin;
> ...
>
> C:\>echo %path # Doesn't work with just one percent
> %path
>
> The %path% seems to be the puppy.
>
> Just like %userprofile% in Command Prompt is your home dir.
>
> In Powershell, this seemed to work, after a fashion.
>
> echo $env:Path

Thank you for testing that as I was colloquially using the $path to refer
to the path but I should have been referring to the Windows %path% instead.

One related advantage of the App Paths sub key is you can create this.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\path.exe
@Default=C:\path\whatever-it-is-you-want-it-to-do

Notice the word "path" is just a keyword. It could by "foo" for all it
matters. The only thing that matters isn't that it's already registered.

With this App Paths sub key, you can define even common Windows keywords
you'd never think you could define as your very own commands, but you can.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\windows.exe
@Default=C:\path\whatever-it-is-you-want-it-to-do

HKLM\Microsoft\Windows\CurrentVersion\App Paths\run.exe
@Default=C:\path\whatever-it-is-you-want-it-to-do

HKLM\Microsoft\Windows\CurrentVersion\App Paths\path.exe
@Default=C:\path\whatever-it-is-you-want-it-to-do

But you'd want to make sure they're not already defined, such as
Win+R cmd
Win+R powershell
Win+R tasks

One interesting tidbit is while I was testing that, I noticed this was
not registered (so that it's therefore available for you to use at will)
Win+R font
But that this was already registered (so you shouldn't probably use it)
Win+R fonts

There is some magic there because I can't get the App Paths sub key to
open a folder directly. I have to call a shortcut whose target opens it.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\programs.exe
@Default=C:\path\open_program_files.lnk
Where the shortcut open_program_files.lnk has the following target
%comspec% /c %windir%\explorer.exe %programfiles%

One hint I had forgotten to mention is that if you use the App Paths sub
key frequently, like I do, it helps to make a "test" sub key for testing.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\test.exe
@Default=C:\path\whatever-it-is-you-want-it-to-do

Also, if folks don't know it, they can cut and paste this verbatim and
the registry will take you to the location that you just cut and pasted.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

That saves time but even better is to save THAT PATH into the favorites.
Windows Registry > Favorites > Add to Favorites

In practice, every time I mess with a registry key, I add it to the
Favorites, not so much as a way of easily getting back (although that
it does) but as a way of keeping an ad hoc log of what keys I messed with.

Of course, none of you others have ever messed with a registry key, and
then days or weeks later regretted doing so, but by then you forgot what
you did - that must be only me who has fallen for that mistake... :)

Let me know if you find other uses for the App Paths registry key as I
have used it every day many times a day ever since Windows XP days.

Freethinker <freethinker@mymail.com> wrote:
> One interesting tidbit is while I was testing that, I noticed this was
> not registered (so that it's therefore available for you to use at will)
> Win+R font
> But that this was already registered (so you shouldn't probably use it)
> Win+R fonts

Is there a listing of all pre-registered Windows 10/11 keywords anywhere?

On 20.03.23 18:33, Freethinker wrote:
> echo %path%
XP PRO (2004) path:

C:\01-sjouke\test>echo %path%
C:\Documents and Settings\All Users\Application
Data\Oracle\Java\javapath;C:\Pro
gram Files\Windows Resource
Kits\Tools\;C:\WATCOM\BINNT;C:\WATCOM\BINW;C:\gcc_eq
uation32\bin;C:\gcc_equation32\libexec\gcc\i386-pc-mingw32\4.4.3;C:\WINDOWS\syst
em32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\GTK\2.0\bin;C:\gimp\bin;C:\Program
F iles\VDMSound\;C:\Program Files\Support Tools\;C:\Program
Files\Microsoft SQL Se
rver\90\Tools\binn\;C:\Program Files\Brief\;C:\Program Files\Common
Files\Acroni
s\SnapAPI\;C:\Program Files\Calibre2\;C:\Program Files\QuickTime\QTSystem\

On 22.03.23 21:01, Freethinker wrote:
> I created test.bat and put it in my %path%, where it contained one line.
> %comspec% /k echo hello
> I also created an App Paths sub key test.exe containing this @Default.
> c:\path\family.xls

This is a better test which shows how Microsoft designed the order of
App Paths
%path%
%pathext%

To test which is run first by Microsoft design, run this simple test.

First, "echo %pathext%" in a command window, which, for me, outputs this.
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

Second, "echo %path% and put this one line test.bat into your path.
%comspec% /k echo hello

Third, add an App Paths subkey of the same core name to the registry.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\test.exe
@Default=osk

Then in the "Win+R" run box, type "test" and then hit the enter key.
Who wins?

Notice it's not what you'd intuitively think as documented by Microsoft.
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration

The fundamental reason is in how Microsoft looks for the file to run.

"When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file."

Where the next sentence tells us what Microsoft suggests apps use.

"We recommend registering your application in the App Paths
registry subkey. Doing so avoids the need for applications
to modify the system PATH environment variable."

This makes sense because otherwise our %path% could have as many entries as
the number of programs we've installed, each of which added to %path%.

What is harder to determine intuitively is which will win if you
change the filename extension, which still confuses me a little bit.

It would be nice if someone can write a better summary (or a better test).

On 20.03.23 20:21, Peter wrote:
> Is there a listing of all pre-registered Windows 10/11 keywords anywhere?

I googled to find this, most of which work inside the Win+R run box.
https://ss64.com/nt/syntax-variables.html

On the topic of what can be done with the App Paths subkey, I was
discussing this topic in the other thread with others when I realized that
even though Herbert showed me that I was wrong about the number of steps to
run a batch command via the App Paths versus via the %path% were the same,
and namely conspicuously, the number of steps is one (as it should be),
there is another (minor) advantage I just realized of App Paths over the
%path%.

Let's say I want to run a batch command called jakarta.bat (using
VanguardLH's example cleanup script).

Using the %path% I would just place the "jakarta.bat" file anywhere in the
%path% and then I'd type one word at the Win+R run box, namely "jakarta".

If I felt like using the App Paths command (which, incidentally, can
_extend_ the %path% temporarily, but I'm not using that feature of it),
I could do the same one-word command called "jakarta" using this subkey:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\jakarta.exe
@Default=c:\path\jakarta.bat

Accounting for the vagaries of how Microsoft travels the various places to
look for things, in both cases when I type one word "jakarta" the batch
file runs.

But with the App Paths subkey, I can also add another key (if desired)
called something else, and another, and another (not that I would want
multiple keys that do the same thing unless they're hard to remember).

So this subkey would run the same jakarta.bat file by typing "foo".
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe
@Default=c:\path\jakarta.bat

But perhaps more useful would be an abbreviation of the jakarta name.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\jak.exe
@Default=c:\path\jakarta.bat

That way, I could type jakarta or jak (or foo) and the batch file runs.
Can this easily be done using the %path% method?

On 23.03.23 04:03, Freethinker wrote:
> This is a better test which shows how Microsoft designed the order of
> App Paths
> %path%
> %pathext%

Herbert tested the path order and found out a likely source of my confusion
(the path order was different depending on how exactly you call a progname)

Here's what he said so that we can keep the solutions together in 1 place.

On 23.03.23 11:00, Herbert Kleebauer wrote:
> On 23.03.2023 01:50, Freethinker wrote:
>
> > It's only after I rename the App Paths "test.exe" to something other than
> > "test" that the %path% wins out over my App Paths in that specific test.
>
> I did only a quick testing (so I may be wrong) but as I see it:

I appreciate the testing as it's confusing what the sequence is
given the document said the App Paths was after the %path% but my specific
test showed under that circumstance, the %path% was after the App Paths.
> If you use "start progname" it use %PATH% first and then "App Path"
> If you use "<WIN>-r progname" it use "App Path" first and then %PATH%

Oh. Well. That might be it. I never use "start progname" as I always
use the Win+R shortcut pinned to my taskbar and then the progname.
> The first place in the above search order it finds an executable,
> it is executed (no matter whether it is a com exe or bat). Only
> if there are more executable in this directory, the order is
> .com , .exe, .bat

This is only slightly confusing because it applies only to the
"start progname" I think, as usually with App Paths you specify the
full filespec (where that filespec can be to a .com, .exe, .bat,
or even to any file such as a .txt .ppt or .lnk or whatever).

> If you open a CMD window and type
> wordpad
> you get a not found message (because it is not in the %PATH%).
> If you use
> start wordpad
> Wordpad is started (I suppose, because of the "App Path" entry)
> <WIN>-r wordpad also starts Wordpad.

I just tried all three and I agree with you on all three.
cmd> wordpad
fails
cmd> start wordpad
works
Win+R wordpad
works

This is what I found in the registry for App Paths.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE
@Default="%ProgramFiles%\Windows NT\Accessories\WORDPAD.EXE"

> Now create a wordpad.bat in a PATH-directory with the content "pause".
> "wordpad" and "start wordpad" now start the batch.
> Whereas "<WIN>-r wordpad" still starts Wordpad.

I'll take it from you that your summary is correct on the path order.
start progname ==> puts %path% in front of App Paths
Win+R progname ==> puts App Paths in front of %path%

Then, of course, there's the case of the ability to temporarily extend
the path which I found an example of put there by Microsoft I guess.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe
@Default=C:\Program Files\Office12\WINWORD.EXE
@Path=C:\Program Files\Office12\
@SaveURL= string value of 1
@useURL= string value of 1

In a way, that Microsoft Office entry exemplifies the best of both worlds
in that we can presume Winword.exe, once run from the App Paths, will run
through the %path% first for things it calls out, and then it will look in
its own folder which it temporarily added to the path in the App Paths.