And it's existence is significant. Ordinary users cannot write to "HKLM\...\App Paths", but they can write to "HKCU\...\App Paths". TCC already looks in "HKLM\...\App Paths" when resolving EXE names. I suspect the next version will also look in "HKCU\...\App Paths", giving the user the advantage of being able to find more EXEs which are not in %PATH.
It means what it means. The path is searched by conforming applications. F.e. by explorer.exe.
The existence or absence is insignificant, the behavior matters.
Explorer also searches "App Paths". That's why I can enter "excel", "winword", "outlook", "textpad" (and others) in the Start\Run dialog when none of them are in my path. I'd call TCC's doing it a feature.
What you mean by "also"? I understand you less and less.
"App Paths" is no magic, it's a shell defined registry key, that is searched by shell functions and conforming applications. F.e. Far manager.
TCC typically uses CreateProcess() to start apps ... not shell functions. So if it's going to look in "App Paths" it must do it manually.
Does your example (3 posts ago) use CMD? Here, textpad.exe is only mentioned in "App Paths" and TCC finds it while CMD doesn't.
Code:
v:\> ver & which textpad
TCC 23.00.31 x64 Windows 10 [Version 10.0.17763.55]
textpad is an external : C:\apps\textpad\textpad.exe
v:\> cmd /c ver ^& textpad.exe
Microsoft Windows [Version 10.0.17763.55]
'textpad.exe' is not recognized as an internal or external command,
operable program or batch file.
No, it doesn't. Far manager uses internal app starter, unless you Shift+Enter.
In which case it uses ShellExecuteEx().
Internal starter does not use ShellExecuteEx() directly, but is compatible with it.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.