XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 19 Mar 2023 21:39:16 +0200, Freethinker 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.)

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/2023 12:34 PM, Stan Brown wrote:

On Sun, 19 Mar 2023 21:39:16 +0200, Freethinker 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.)

PS > cmd # Switch to Command Prompt Microsoft Windows [Version 10.0.22621.1413]
(c) Microsoft Corporation. All rights reserved.

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;
...

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

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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.

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;
...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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\

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <MPG.3e822af6a3c12ad899009e@news.individual.net>, Stan Brown wrote...

On Sun, 19 Mar 2023 21:39:16 +0200, Freethinker 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.)

Interesting thread. The easiest way to see the variables (all types) set in your session is to open a command windows and type at the prompt: SET

In PowerShell (which I still haven't learned!) the equivalent seems to be Get- Variable, but there doesn't seem to be an equivalent to %PATH.

--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <MPG.3e83b9178e40128f989a54@news.eternal-september.org>, Philip Herlihy wrote...

In article <MPG.3e822af6a3c12ad899009e@news.individual.net>, Stan Brown wrote...

On Sun, 19 Mar 2023 21:39:16 +0200, Freethinker 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.)

Interesting thread. The easiest way to see the variables (all types) set in your session is to open a command windows and type at the prompt: SET

In PowerShell (which I still haven't learned!) the equivalent seems to be Get-
Variable, but there doesn't seem to be an equivalent to %PATH.

Ah - it's more complicated than that in PowerShell:

https://learn.microsoft.com/en- us/powershell/module/microsoft.powershell.core/about/about_environment_variable s?view=powershell-7.3

Time was when I'd write whole applications in a day by ditching C++ in favour of Unix shell scripting!

--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 20 Mar 2023 19:33:34 +0200, Freethinker wrote:

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

I don't have any App Path in the HKLM hierarchy, and only four in the
HKCR hierarchy: OneDriveFileLauncher.exe, Skype.exe, WindowsPackageManagerServer.exe, winget.exe. I didn't create any of
them and don't use any of them. They must have been part of the
Windows install, though why they're in HKCR instead of HKLM I don't
know.

But you and I work very differently. I hardly ever use the "Run"
window in any form, other than for regedit. Much of what I do is on
the command line, where I have aliases defined so I don't need to
bloat up %PATH% _and_ don't have to type the paths myself. For the
rest I use standard keyboard shortcuts, like Windows+E to open File
Explorer. And I defined my own shortcuts for the programs I use
frequently: Ctrl+Alt+I for Irfanview, Ctrl+Alt+E for Excel, etc. I
use the mouse and Start Menu only to launch infrequently used
programs.

If App Path worked on the command line, I might use it, but as it
doesn't (I tried an experiment) I can say that it's interesting but
not directly relevant to me.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.03.23 20:53, Stan Brown wrote:

I don't have any App Path in the HKLM hierarchy, and only four in the
HKCR hierarchy: OneDriveFileLauncher.exe, Skype.exe, WindowsPackageManagerServer.exe, winget.exe.

I don't see how that's possible given what I've seen of the App Paths
(note the spelling is plural) since Windows XP days when it was highly advertised as a solution to the %path% problem.

If you copy and paste EXACTLY this path into your registry,
what does it find?

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

All of those should be equivalent when pasted into the registry address bar.

I didn't create any of
them and don't use any of them. They must have been part of the
Windows install, though why they're in HKCR instead of HKLM I don't
know.

I won't claim to understand Microsoft's grand design for the Windows registry.

But I pasted these into my Windows 10 registry and they were not found. Computer\HKEY_CLASSES_ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths HKEY_CLASSES_ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths HKCR\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

But you and I work very differently. I hardly ever use the "Run"
window in any form, other than for regedit.

There's no issue here as it's there to use only if you want to use it.
An example is it's an easy way to open up %UserProfile% or %localappdata%.

But having an App Paths (note the plural) subkey has no negative side
effects that I know of. It's additive functionality.

Much of what I do is on
the command line, where I have aliases defined so I don't need to
bloat up %PATH% _and_ don't have to type the paths myself.

That works too.

For the
rest I use standard keyboard shortcuts, like Windows+E to open File
Explorer. And I defined my own shortcuts for the programs I use
frequently: Ctrl+Alt+I for Irfanview, Ctrl+Alt+E for Excel, etc. I
use the mouse and Start Menu only to launch infrequently used
programs.

Irfanview added itself to my App Paths, by the way, so I am surprised
you didn't find it (but note that the App Paths subkey is plural).

Sometimes it all boils down to keystrokes where you can run excel
in few keystrokes, but what about popping up a document called
family.xls where you just type "family" and up that document comes
in excel?

The App Paths also runs any command you want it to run but I use it
more to open up things such as documents and folders the most.

And, I should note, I never search, so you might have to run searches
a lot more than the zero times I have to run them (mine are disabled).

If you have to search even once, then it's once more than I have had to, especially if the result of that search could have been something simple like opening up the folder to the youtube.dl executable (as just an example).

An example is I've seen a lot of people open up an admin cmd window using
a search, which is just about the dumbest way to do that, don't you think?

Another example is running any shortcut, no matter where it's location.
Or opening up a directory, no matter how long the path to that directory.

It's always a one-word command.

If App Path worked on the command line, I might use it, but as it
doesn't (I tried an experiment) I can say that it's interesting but
not directly relevant to me.

No issues with you that the App Paths (note the plural) does not work
on the command line, but nether does the command line work in the run
box (except for certain things).

They're additive.
But they're not for everyone I guess.

I'm just letting people know the App Paths key has existed since Windows
XP days when it was advertised to augment the %path% in many situations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 22 Mar 2023 06:30:17 +0200, Freethinker wrote:

On 21.03.23 20:53, Stan Brown wrote:

I don't have any App Path in the HKLM hierarchy, and only four in the
HKCR hierarchy: OneDriveFileLauncher.exe, Skype.exe, WindowsPackageManagerServer.exe, winget.exe.

I don't see how that's possible given what I've seen of the App Paths
(note the spelling is plural)

I did a direct jump to
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Path
without the "s" suffix, so that explains why I thought there was
nothing there. To compound my error, when looking under HKCR I
started at
HKCR\SOFTWARE\Microsoft\Windows\
and then clicked down the hierarchy to open things, again without
noticing the end "s" at the last stage. So that explains why I found
some App Pathses in HKCR.

When I retry with
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
there are a few dozen entries.

But still, since App Paths doesn't work on the command line, it's not
much use to me.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22.03.23 18:53, Stan Brown wrote:

I don't see how that's possible given what I've seen of the App Paths
(note the spelling is plural)

I did a direct jump to
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Path
without the "s" suffix, so that explains why I thought there was
nothing there.

Thanks for saying that because, ever since WinXP days when Microsoft
introduced the App Paths sub key to work around %path% issues, I've never
seen a system that did NOT have the "App Paths" sub key. (By the way, I'm
not sure the difference between a "key" and a "sub key", so it you see me
use the term both ways, it's because I don't really know the proper terms.)

To compound my error, when looking under HKCR I
started at
HKCR\SOFTWARE\Microsoft\Windows\
and then clicked down the hierarchy to open things, again without
noticing the end "s" at the last stage. So that explains why I found
some App Pathses in HKCR.

Well, I made an error also when I had responded to you so we're even.
Herbert showed me that the %path% is respected in the Win+R run command.

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

Then I clicked the Win+R icon which is always pinned to my taskbar.
And I typed "test" and then I hit the Enter key.
The App Paths test.exe won out over the %path%\test.bat file.
When I renamed the App Paths sub key to test1.exe, then the %path% won.

So Windows first checks the App Paths, and *then* it consults the %path%. That's useful in & of itself to override %path% on a case-by-case basis.

So now we're even that I also made a mistake in how this works.
It's good to work together toward the same goal of being more efficient.

When I retry with
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
there are a few dozen entries.

But still, since App Paths doesn't work on the command line, it's not
much use to me.

It looks like the %path% works on the command line and on the Run command. Meanwhile App Paths works only on the Run command - but - it runs first!

If it were a race, the App Paths wins ... (jk).
If it were the command line, the %path% wins.

Each has their own merits because both can call documents, shorcuts, batch files and executables at a single step which is to just type the name.
Win+R family (and that opens up family.xls)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.microsoft.windows

On 23.03.2023 17:09, Freethinker wrote:

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

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?

You still don't believe, that there is no difference. You make
a second entry in the registry and I make a second entry in
PATH-directory:

jak.bat with the content:
jakarta.bat

But a more elegant way (for a NTFS volume) would be:

mklink /h jak.bat jakarta.bat

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.microsoft.windows

On 23.03.23 16:47, Herbert Kleebauer wrote:

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?

You still don't believe, that there is no difference. You make
a second entry in the registry and I make a second entry in
PATH-directory:

jak.bat with the content:
jakarta.bat

But a more elegant way (for a NTFS volume) would be:

mklink /h jak.bat jakarta.bat

I'm finally acceding to your wise advice that they're essentially
equivalent in that whatever you to using a %path% method is the same number
of steps as what you do in the App Paths method. Same result in the end.

I went through the registry and I found some things that were odd though,
which I'm not sure if the %path% method handles but they were oddball.

I liked that VanguardLH said the App Paths can do a "temporary path"
extension which I'm sure the %path% method can do also, where I happened to notice when looking in my registry that 7Zip seems to have done that task:
HKLM\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\7zFM.exe
@Default=C:\path\7zip\7zFM.exe
@Path=C:\path\7zip\

I didn't know it could expand variables but this shows that it can.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\licensemanagershellext.exe
@Default=%SystemRoot%\System32\licensemanagershellext.exe
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\PowerShell.exe
@Default=%SystemRoot%\system32\WindowsPowerShell\v1.0\PowerShell.exe
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\SnippingTool.exe
@Default=%SystemRoot%\system32\SnippingTool.exe

But other stuff was odd, for example, is this double sub key.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\msedge.exe
(which had a sub entry below it)

Another example is resource hacker added the following to the App Paths:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\cmmgr32.exe
@Default= this was blank which seemed odd to me
@CmNative=DWORD 32-bit Hex value = 2
@CmstpExtensionDll=C:\Windows\System32\cmcfg32.dll
When I ran Win+R cmmgr32, nothing happened, which is the @Default key,
but when I typed Win+R cmcfg32.dll, Resource Hacker came up. http://www.angusj.com/

One by one I went down the registry entries and deleted the ones I didn't
make when I ran into another Resource Hacker odd entry that it had added.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\dfshim.dll
@Default= this was blank which seemed odd to me
@UseURL=DWORD 32-bit Hex value = 2
When I ran Win+R dfshim.dll, Resource Hacker came up again.

Mostly I use the App Paths on an ad hoc unplanned spur of the moment
situation, such as when there's a file I can't find easily so when I find
it, I then just make an App Paths subkey to that specific disparate file.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\serials.exe
@Default=c:\path\serial_numbers.doc

What got me started on the App Paths back in WinXP days was you could put
any given folder DIRECTLY into the App Paths, but that stopped in Win10.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\batch.exe
@Default=c:\path\batch_folder <=== this stopped working in Win10
Where you can point to any shortcut to open that folder:
@Default=c:\path\open_batch_folder.lnk
With the shortcut target being any of the normal methods:
Target=%comspec% /c %windir%\explorer.exe C:\path\batch_folder
Or pointing to a command to open the folder instead of to a link.
@Default=c:\path\open_batch_folder.bat
Where the open_batch_folder.bat file contained a single line such as
%comspec% /k cd C:\path\batch\
or
%comspec% /c %windir%\explorer.exe C:\path\batch
But, even simpler, apparently a plain old normal folder shortcut works
@Default=c:\path\open_batch_folder.lnk
Where the shortcut target is a normal folder link with nothing fancy.
@Default=c:\path\batch\

After having looked at the keys in the App Paths for the first time,
most weren't fancy but some were there, inexplicably, by Microsoft.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\msedge.exe\SupportedProtocols
@Default=blank
@http=blank
@https=blank

Who knows what Microsoft is up to on some of those, but in the end
analysis, I'm going to agree with you the %path% & App Paths are
two different ways to accomplish the same number of steps to run
programs and to open up files and folders and to run shortcuts
from the Win+R command box (which I have pinned to my taskbar).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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.

wordpad

fails

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)