Instead of some packages going to WinGet\Links and others to PATH, pick one

[github-account1111]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

I find it burdensome that WinGet just scatters packages throughout the system. The user then has to scour through directories trying to find the installed package or recall what they even have installed in the past. There is:

• The usual C:\ProgramData\Microsoft\Windows\Start Menu\Programs that points to C:\Program Files
• C:\Program Files\WinGet\Links that points to C:\Program Files\WinGet\Packages
• PATH that seems to also point to C:\Program Files\WinGet\Packages
• More?

Here's an example of what I'm talking about. WinGet creates a link under WinGet\Links for this package:

[CLI ] Extracting archive to: C:\Users\usr\AppData\Local\Temp\WinGet\CGSecurity.TestDisk.7.3\extracted
[CLI ] Successfully extracted archive
[CORE] Created target install directory: C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe
[REPO] Creating new Portable Index with version [Latest] at 'C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe.db'
[CORE] Renaming directory to: C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe\testdisk-7.3-WIP
[CORE] Symlink created at: C:\Program Files\WinGet\Links\fidentify_win.exe with target path: C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe\testdisk-7.3-WIP/fidentify_win.exe
...
[CORE] Symlink created at: C:\Program Files\WinGet\Links\testdisk_win.exe with target path: C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe\testdisk-7.3-WIP/testdisk_win.exe
[CLI ] Portable target directory already exists in PATH registry: C:\Program Files\WinGet\Links

but modifies PATH for this package:

[CLI ] Extracting archive to: C:\Users\usr\AppData\Local\Temp\WinGet\DMDE.DataRecovery.GUI.4.4.4\extracted
[CLI ] Successfully extracted archive
[CORE] Created target install directory: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe
[REPO] Creating new Portable Index with version [Latest] at 'C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe.db'
[CORE] Moving portable exe to: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe\changelog.txt
...
[CORE] Moving portable exe to: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe\template.txt
[CORE] Appending portable target directory to PATH registry: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe
[CORE] Install directory added to PATH: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe

Proposed technical implementation details

Decide on a location and stick to it. I think the first location makes the most sense because that's where Windows programs have always gone. The second one is also decent but I don't see the point in it when the first one exists? The third one is plain stupid. That's not what PATH is even for, and, according to WinGet's own portable program specs, that shouldn't even happen.

[denelon]

There are a few considerations when an explicit path is added for a package and when a symbolic link is added to the default directory.

Was the package previously installed on the path or in the symbolic link directory.

If the user is elevated or developer mode is enabled, symbolic links are used.
If the user is not elevated and the developer mode is disabled, direct path entries are used.
If the portable application needs access to libraries in the same directory (explicit in the manifest) direct path entries are used.

Running winget list <package> --details shows the installed location of a package.

[github-account1111]

I've never installed either package.

I ran both install commands elevated and don't have developer mode enabled.

Running winget list --details shows the installed location of a package.

Any way to list where the corresponding link is (C:\Program Files\WinGet\Links, PATH, etc.)?

> winget list CGSecurity.TestDisk --details
TestDisk [CGSecurity.TestDisk]
Version: 7.3
Publisher: CGSecurity
Local Identifier: ARP\Machine\X64\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe
Product Code: cgsecurity.testdisk_microsoft.winget.source_8wekyb3d8bbwe
Installer Category: portable
Installed Scope: Machine
Installed Architecture: X64
Installed Location: C:\Program Files\WinGet\Packages\CGSecurity.TestDisk_Microsoft.Winget.Source_8wekyb3d8bbwe
Origin Source: winget

> winget list DMDE.DataRecovery.GUI --details
DMDE Data Recovery Software [DMDE.DataRecovery.GUI]
Version: 4.4.4
Publisher: DMDE Software
Local Identifier: ARP\Machine\X64\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe
Product Code: dmde.datarecovery.gui_microsoft.winget.source_8wekyb3d8bbwe
Installer Category: portable
Installed Scope: Machine
Installed Architecture: X64
Installed Location: C:\Program Files\WinGet\Packages\DMDE.DataRecovery.GUI_Microsoft.Winget.Source_8wekyb3d8bbwe
Origin Source: winget

I guess it's not obvious to me why the link for one was placed in WinGet\Links, and the link for other went to PATH.

[Trenly]

I guess it's not obvious to me why the link for one was placed in WinGet\Links, and the link for other went to PATH.

It's because for DMDE.DataRecovery.GUI, it has dependencies on files in the same directory. Because applications launched via symlink don't have direct access to libraries in the same directory, it gets added to PATH. As denelon mentioned,

If the portable application needs access to libraries in the same directory (explicit in the manifest) direct path entries are used.

This is specified in the manifest - https://github.com/microsoft/winget-pkgs/blob/2ca046c19ac66682d0b7b506c732acb2380a85f4/manifests/d/DMDE/DataRecovery/GUI/4.4.4/DMDE.DataRecovery.GUI.installer.yaml#L10

---

However, CGSecurity.TestDisk does not have that type of dependency and so it can be run from a symlink IF your machine allows the creation of symlinks (either developer mode enabled or running WinGet as admin)

[github-account1111]

Why not link all packages through PATH then? That'll at least narrow things down from 3+ locations to 2 (1 once #2299 is implemented). It'll also eliminate the need for manifest authors to figure out if library access is necessary for every new package and package update.

[denelon]

We don't want to overrun the path environment variable. There are performance considerations as wells as a length barrier.

[whindsaks]

Because applications launched via symlink don't have direct access to libraries in the same directory, it gets added to PATH.

Why not use a small shim application instead? This is what Scoop does.

[denelon]

That didn't meet all of our security requirements.

[whindsaks]

That didn't meet all of our security requirements.

What was the issue? It just needs to read the path to the app from itself, then GetCommandLine+ShellExecuteEx+WaitForSingleObject and you are done...

[github-account1111]

I struggle to understand the performance argument (C:\Program Files\WinGet\Links is also in PATH, so wouldn't putting more entries there have the same performance impact?), but the PATH length barrier does sound like it could become an issue.

IDK if I should close this since the other person had questions but please feel free to close this yourself.

[stephengillie]

I add these locations as favorites in my approval VMs, to track down applications more quickly:
Logs file: C:\Users\user\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
Programs: C:\Users\user\AppData\Local\Programs
Download: C:\Users\user\AppData\Local\Temp\WinGet
Portable: C:\Users\user\AppData\Local\Microsoft\WinGet\Packages
Symlinks: C:\Users\user\AppData\Local\Microsoft\WinGet\Links\

[denelon]

I struggle to understand the performance argument (C:\Program Files\WinGet\Links is also in PATH, so wouldn't putting more entries there have the same performance impact?), but the PATH length barrier does sound like it could become an issue.

IDK if I should close this since the other person had questions but please feel free to close this yourself.

Each entry in the path environment variable becomes another directory to scan for an executable. The ordering does matter, but there is a performance hit if there are a large number of directories to scan and a large number of files in those directories. The later the target executable is in terms of paths to be traversed, the longer it takes to locate and execute the target executable.