Windows 11 context menu integration improvement

[vtbassmatt]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

(This will apply only for 64-bit; as I understand it, there's no 32-bit Windows 11 planned)

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

(This will be Windows 11, but I don't have a test instance to validate what cmd.exe /c ver says)

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

(Applies to ext\shellhere and ext\guihere)

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

n/a

Details

The upcoming Windows 11 release changes how context menus are registered. While the regkey-based system currently in use will continue to function, such commands will be demoted behind a "Show more options" menu. To be clear, shell integration won't be broken on Win11, but it will be less convenient.

The new model uses what's called an IExplorerCommand and requires an "app identity" to attribute the integration. Identity is established for so-called "unpackaged" Win32 (like Git for Windows) using a concept called Sparse Manifests.

I believe the work required will be:

• Create a Sparse Manifest
  • Looks like this may require some visual assets, which would need to be chosen and rendered
  • There also appears to be an additional signing step (this blog post, see Signing a Sparse package)
• Detect Windows 11 in the installer
• if (windows.version == 11 && ext\shellhere == true) { register using IExplorerCommand }
• Same as ☝️ but for ext\guihere
• Think through the upgrade story -- if someone has GfW installed on a Win10 box and then upgrades to Win11, the context menu items won't be registered. Ideally the next time they update GfW, the right thing happens and they get the new context menu items.

The Windows team shared sample code. Their PM also offered to help out, should someone in the community wish to pick this work up and run into any trouble. microsoft/vscode#127365 includes a screenshot demonstrating where IExplorerCommands appear.

[rimrul]

While the regkey-based system currently in use will continue to function, such commands will be demoted behind a "Show more options" menu.

Why, Microsoft, why? We where glad we left git-cheetah behind and now we'll have to build COM-Interop shell extension DLLs again. Great.
I especially love their sample on how to specify an icon for these new context menu entries. You just don't.

Thank you for warning us about this.

Think through the upgrade story -- if someone has GfW installed on a Win10 box and then upgrades to Win11, the context menu items won't be registered. Ideally the next time they update GfW, the right thing happens and they get the new context menu items.

Well, at least for this microsoft has already (almost) provided a solution:

In our sample app, we register the Sparse package during first run. When our application is launched, we check if it’s running with Identity (identity or the lack thereof is a signal of whether the Sparse package has been registered/installed) if the app is not running with identity we then register the Sparse Package and restart the app. This is expected to take place only once at first run.

Include the sparse package and the COM-Interop shell extension DLL on Windows 10 installs as well and wrap that registration code so it only fires on Windows 11 (The required APIs to register a sparse package probably won't be available on Windows 10 systems anyways).

[rimrul]

The required APIs to register a sparse package probably won't be available on Windows 10 systems anyways.

Turns out they are available on Windows 10 since build 2004.

I especially love their sample on how to specify an icon for these new context menu entries. You just don't.

Ok, some more digging reveals the string format they expect.

[rimrul]

I should really stop looking into this. The more I look, the worse things get. This is drifting into the same area of barely (if at all) documented APIs that Wintoast is built around.

[rimrul]

I had an email about a comment that's apparently been deleted:

Why do you necessarily need a sparse package? 🤔 It turns out IExplorerCommand has been available since Windows Vista [...]
Wouldn't it be enough to just correctly register the COM component during installation? That would work on all supported Windows versions.

Those are some good questions. The only source I can find for the Windows 11 Context Menu requiring identity is the claim in that vscode issue. So maybe we can get away with just the COM component.

[Alovchin91]

@rimrul Yes, sorry, that was me 😬 I googled for IExplorerCommand and found a few documentation articles about it and a Windows 7-era sample, so I thought it might be that "old" mechanism. But then I read through the mentioned issue in VS Code repo, and also found out that the mentioned PhotoStore sample was recently updated specifically for this. So I decided I was inattentive and deleted the comment 😅

[rimrul]

No need to apologize. I stumbled across the same Windows 7 sample before and thought "Maybe they're reusing the old interface in a new context", but there seems to be absolutely no official documentation that the context menu requires identity now, so we might get away without a sparse package.

[Alovchin91]

there seems to be absolutely no official documentation

Just like always 😝

It's probably worth trying without a sparse package, because then that COM component could be used on all supported Windows versions.

But it seems that a sparse package could be useful at least because it's simpler than all this COM registration code 🤯 Also it's kind of future-proof, so it could be used on Windows 11+ only, falling back to the registry method on previous versions.

Windows Terminal also has a COM component, but I'm not sure if they have a sparse package (they use MSIX deployment AFAIK): microsoft/terminal#6100

[rimrul]

It's probably worth trying without a sparse package, because then that COM component could be used on all supported Windows versions.

Yes, that would be nice.

But it seems that a sparse package could be useful at least because it's simpler than all this COM registration code

It's looks a lot simpler because they only show the C# version and assume you only need to support Windows 10 2004 and newer...

Windows Terminal also has a COM component, but I'm not sure if they have a sparse package (they use MSIX deployment AFAIK): microsoft/terminal#6100

They refer to the Windows 7 sample as

A Win7 Explorer Command Sample which hasn't aged well

I don't think that's good.

[rimrul]

There is an official announcement of this now: https://blogs.windows.com/blog/2021/07/19/extending-the-context-menu-and-share-dialog-in-windows-11/

[fcharlie]

I spent some time writing a simple helper program that does the Windows 11 menu showing Git Bash Here:

Source Code: https://github.com/baulk/winmenu

How to experience:

1. Download GitForWindowsExtension-x64.appx from: https://github.com/baulk/winmenu/releases/tag/v1.0.0
2. Right-click on the properties of GitForWindowsExtension-x64.appx and choose to trust the temporary certificate of the file (or you can download the source code and compile and sign it yourself)
3. Run Add-AppxPackage .\GitForWindowsExtension-x64.appx

I think a better solution to this problem is to add the Windows 11 sparse package project in the Git for Windows organization. Then choose whether to install it in the Inno Setup script. If you need to install it, run a custom command to call the powershell script to install it. You can also uninstall appx when uninstalling Git for Windows.