578 lines
27 KiB
Markdown
578 lines
27 KiB
Markdown
---
|
||
title: The Windows Context Menu – Is It a Lost Cause?
|
||
description: We dive in deep into the Windows context menu and how to customize it to your liking.
|
||
created: 2023-08-13T15:51:19Z
|
||
updated: 2024-02-18T21:32:12Z
|
||
draft: false
|
||
tags: ['windows', 'context-menu', 'customization', 'registry', 'shell', 'shell-extensions', 'context-menu-handlers']
|
||
thumbnail: '/images/blog/thumbnails/the-windows-context-menu.png'
|
||
---
|
||
|
||
# The Windows context menu is... poorly made.
|
||
Third-party software developers adding oil into this dumpster fire aren't helping with it.
|
||
**It's not their fault**, though,
|
||
as there is no common standard and almost no documentation for adding entries to the context menu.
|
||
|
||
It's safe to say that currently, there's no salvation for it.
|
||
At the very least, it's working and serving millions of users.
|
||
The new Windows 11 context menu shows Microsoft keeps pressing onward with their all-time classic:
|
||
writing new, less friendly, less extensible APIs from scratch,
|
||
simultaneously piling up layers upon layers of untested code atop the previous versions they can't entirely get rid of due to deep backwards compatibility problems that will inevitably arise.
|
||
|
||
I want to dedicate this article to _actually customizing_ the Windows 10
|
||
(incidentally, also 11 Legacy) context menu to your liking
|
||
instead of just complaining about its inner workings.
|
||
After reading this article completely, you should be able to bring your menu from this abomination...
|
||
|
||
|
||
|
||
**...to this!**
|
||
|
||
|
||
|
||
Be wary — there's _plenty_ of registry digging involved. And the terrible part is...
|
||
|
||
**Forget any logic when dealing with registry keys.**
|
||
Nowadays, registry structure is the least of all concerns.
|
||
The idea of using registry as a coherent setting list has long since been abandoned,
|
||
and nobody seems to care about it, as the end user doesn't.
|
||
If someone does — they know what they're doing, and they will likely not complain,
|
||
because they have abused registry the same way at least once. 😉
|
||
|
||
Whilst there are layers of abstraction applied to the most Windows settings,
|
||
the context menu is, unfortunately, left aside.
|
||
And much to our dismay, its backend is also janky, terrible and tangled up.
|
||
The only fair question to reader from me is **«Do you really think it's worth your time?»**.
|
||
And if your answer is an astounding **«Hell yeah»**,
|
||
and you are as much of a perfectionist as I am, buckle up and prepare for several hours of pure joy.
|
||
|
||
::card
|
||
---
|
||
icon: warning
|
||
title: Before we begin
|
||
---
|
||
Invoking `sfc /scannow` or `dism /restorehealth` will likely interfere with your context menu,
|
||
as Microsoft is peculiar — they had customization via direct registry manipulation in mind for more granular control,
|
||
but their tools **aren't adapted** to store so meticulously tweaked settings.
|
||
This isn't anything new — that hasn't changed ever since integrity checks were introduced in Windows XP.
|
||
_No need to worry, though!_ The aforementioned tools will keep working; however, some of your tweaks might be reset
|
||
upon execution.
|
||
::
|
||
|
||
## Context menu components
|
||
There are two main components the context menu is composed of:
|
||
|
||
* **Shell entries** — provided locally and managed by the registry;
|
||
* **Context menu handlers** — provided and managed by external software;
|
||
|
||
Neither of them is documented well, but
|
||
there is some developer documentation for handlers available [on Microsoft's website](https://go.enderman.ch/Fm4t3).
|
||
It explains how they work internally, but that doesn't really help our case.
|
||
As for the shell entries, I couldn't find anything.
|
||
|
||
Certainly a shame! Shell entries are so much more flexible and customizable.
|
||
In fact, **you don't get any customization** with context menu handlers whatsoever,
|
||
unless the developer was paid and bothered enough to read most of the documentation above.
|
||
|
||
To let you tweak context menu settings directly through their app,
|
||
they have to implement **both the handler and the endpoints** for handler settings,
|
||
which are commonly simple registry values.
|
||
Microsoft hasn't provided any convention for software developers to follow,
|
||
so you're at the mercy of them providing you with a friendly user interface to tweak the handler.
|
||
|
||
[7-Zip](https://go.enderman.ch/7-zip) serves as a neat example of great software design —
|
||
the developer here allows you to extensively tweak their handler.
|
||
|
||
|
||
|
||
[MobaXterm](https://go.enderman.ch/mobaxterm) also is an illustrative example of the case where you can customize
|
||
the shell integration from the application itself.
|
||
The developers of that software use shell entries instead of context menu handlers, which seems like an odd choice
|
||
for this case.
|
||
_It seems like someone was underpaid!_ 😊
|
||
|
||
|
||
|
||
In conclusion, there are three types of applications in terms of friendliness towards context menu customization:
|
||
|
||
* **Apps using context menu handlers with customizable settings** — the friendliest;
|
||
* **Apps using shell entries** — customizable through registry hacks;
|
||
* **Apps using context menu handlers without settings** — the entries are uneditable;
|
||
|
||
The first case is the simplest and isn't worth talking about —
|
||
consult the documentation for the software in question to find all the necessary tweaks.
|
||
**The rest of the cases are discussed in this article.**
|
||
|
||
### Shell entries
|
||
For starters, all the tweaking happens inside `HKEY_CLASSES_ROOT` — alias for `HKEY_LOCAL_MACHINE\Software\Classes`.
|
||
That registry key contains all the data about shell components and file extension handlers.
|
||
|
||
For example, data under the `exefile` key will exclusively apply to files with the `.exe` extension.
|
||
A trusty old method [«companion» viruses](https://go.enderman.ch/Kvo3u) utilized back in the day to «accompany» their victims —
|
||
the executable (`.exe`/`.com`) files was a simple pass-through setup:
|
||
the virus executable was specified as the handler for all other executable files.
|
||
A belarusian virus from 2005, [Neshta.A](https://go.enderman.ch/2WeQ0), worked exactly this way and caused heaps of damage.
|
||
|
||
Since all the settings inside the `HKCR` key are divided into types,
|
||
editing the context menu for each file type and shell extension manually is unavoidable.
|
||
|
||
_Yeah..._
|
||
|
||
This is **abysmal**, and, unfortunately, there is no better approach.
|
||
While you're likely already reconsidering your choices, let me try to pull you back in and explain the basics.
|
||
That way you can at least tweak the menu for the extensions you work with the most
|
||
and bring the most noticeable context menu areas up to par...
|
||
|
||
There _are_ some minor generalizations present in the key.
|
||
For instance, there are wildcard entries for **every** file system object,
|
||
**every** image, **every** media file and so on.
|
||
Nonetheless, Microsoft has taken a horrible approach with the context menu from the beginning.
|
||
Even though such a disarray always annoyed me, I know full well there's no way for them to fix it now.
|
||
_That's how sometimes life is._
|
||
We'll tackle the generalized keys a bit later, let's start simple.
|
||
|
||
#### General structure
|
||
The following figure is what seems to be the general structure of an extension registry key:
|
||
|
||
|
||
|
||
The structure may vary for some extensions, but you can almost be sure you're in the right place if the key contains the `Shell` subkey.
|
||
Children of the `Shell` subkey are the «shell entries» — locally provided customizable entries of the context menu.
|
||
|
||
::card
|
||
---
|
||
icon: info
|
||
title: Clearing up the confusion
|
||
---
|
||
The terminology may be a little confusing, since Microsoft hasn't ever offered a standard nomenclature for the
|
||
context menu. The article tosses plenty of loose terms around, so here's the nomenclature I have resorted to
|
||
for better understanding:
|
||
* **Shell** is the Windows Explorer;
|
||
* **Shell entry** is a singular entry within the context menu — the atomic component;
|
||
* **Shell integration** is the general footprint of software within the context menu and may consist of one or
|
||
more shell entries;
|
||
* **Shell extension** is a general term for a plugin for the Windows Explorer — the **context menu handler** is a
|
||
particular case of a shell extension;
|
||
* **Shell component** is a broad term for a component that helps the shell interact with the system — that includes
|
||
shell extensions, file extensions, protocols, etc.;
|
||
|
||
If this doesn't show how big of a predicament Microsoft is in with the context menu, I don't know what does.
|
||
I tried my best to keep the technical language as clear as possible. 😒
|
||
::
|
||
|
||
#### Editing entries
|
||
Locally provided entries always available for a quick and dirty edit are stored under the `Shell` subkey.
|
||
Entries provided by software — the context menu handlers — are stored under the `ShellEx` subkey.
|
||
|
||
|
||
|
||
Since registry key names are case-insensitive by design in Windows, capitalization plays no role.
|
||
**The value names, however, are** — keep that in mind, as in some cases it might bite you.
|
||
The context menu doesn't seem to care.
|
||
|
||
_Truly an amazing specification!_
|
||
|
||
|
||
#### Executing entries
|
||
A shell entry must contain the `command` subkey to execute commands.
|
||
The **default value** of the subkey controls execution on click of the shell entry and follows Batch syntax...
|
||
_to some extent_. You cannot have «extended» Batch logic in the entries,
|
||
which immeasurably disappointed me, so much so, that I wrote two neat utilities called
|
||
[quiet](https://go.enderman.ch/elevate) and [elevate](https://go.enderman.ch/elevate)<sup>sudo for Windows [anyone](https://go.enderman.ch/XuDXW)?</sup> for that specific purpose.
|
||
|
||
No matter how hard I tried, I could not find the exact specification of the incomplete Batch logic the default value uses.
|
||
|
||
|
||
|
||
|
||
|
||
My suggestion is to treat the default `command` value as **raw command line** (e.g. Run box),
|
||
with an exception to the following two macros:
|
||
* `%1` — the absolute file path without quotes
|
||
If you right-click `C:\Users\bleh\p.txt`, execute the shell entry,
|
||
the `%1` in the context of the command line will be equivalent to `C:\Users\bleh\p.txt`;
|
||
* `%V` — the absolute directory path without quotes;
|
||
|
||
::card
|
||
---
|
||
icon: error
|
||
title: Inconsistency
|
||
---
|
||
Keep in mind that the `%1` macro is the Batch version of `argv[1]` — the first item in the C argument vector.
|
||
When a context menu is invoked from within, say, a library, the argument vector stops making sense
|
||
because a library is a Windows Shell feature, meaning it's sophisticated. Opening a library internally
|
||
**requires a [different API](https://go.enderman.ch/KuKR4)** to opening a folder, or even executing a file.
|
||
In such cases, the `%1` macro **does not exist** in the context of the command line. This is also likely
|
||
the reason why libraries are in a separate category to folders in terms of shell entries.
|
||
The directory macro `%V` also sometimes falls flat depending on the shell entry it's being invoked from.
|
||
**Brilliant consistency!**
|
||
::
|
||
|
||
On rare occasions, the default value is left unset, with `DelegateExecute` alongside it containing a GUID.
|
||
When that's the case, the command handler is implemented through the `IExecuteCommand` COM interface,
|
||
and you cannot customize it.
|
||
|
||
**Why is that a thing?** Ask me a simpler question. It could be a compatibility layer for C, but your guess is as good as mine.
|
||
|
||
|
||
|
||
#### Adding entries
|
||
Making new entries isn't as bad as managing existing ones,
|
||
so I managed to scrabble it into a sort of algorithm, if that makes sense:
|
||
|
||
1. Locate the target extension.
|
||
2. **Careful!** Some extensions may be buried within other extensions.
|
||
As an example, the [Folder Background](#folder-background) extension is located under the [Folder](#folder) extension `Directory` key in the `Background` subkey.
|
||
3. Navigate to the `shell` key.
|
||
If there is none, and you're _confident_ there should be,
|
||
try creating one — **chances are high** it isn't going to break Windows.<sub>(no, seriously)</sub>
|
||
4. Create a new key, the name **must be alphanumeric**. The name is case-insensitive.
|
||
5. Create the `command` subkey.
|
||
6. Specify the command line you want to execute on click in the **default value**.
|
||
7. The entry should appear in the context menu. If it does not, restart Explorer.
|
||
If it still doesn't appear, you probably screwed up the procedure — return to step 1.
|
||
If you verified everything for sure, then the extension is simply **not registered** in the shell.
|
||
|
||
#### Nesting entries
|
||
You can nest entries too!
|
||
1. Repeat the first 4 steps from [Adding entries](#adding-entries).
|
||
Don't add the `command` key just yet.
|
||
2. Create another `shell` key.
|
||
3. Inside it, create a subkey **called anything else, but** `command`.
|
||
4. Working within the subkey, repeat steps 5–7.
|
||
5. Navigate back to the root shell entry
|
||
6. Create an empty `REG_SZ` value called `SubCommands`.
|
||
|
||
|
||
|
||
|
||
|
||
It's possible to have an entry include a single nested entry as well.
|
||
|
||
|
||
|
||
|
||
To control the parent context menu entry, use the outer `Shell` subkey.
|
||
|
||
|
||
|
||
To control its children, use the inner `Shell` subkeys.
|
||
|
||
|
||
|
||
#### Customizing entries further
|
||
There are a plethora of options when it comes to customizing the shell entries.
|
||
_Too bad they're all undocumented._
|
||
By default, the context menu items **borrow their names** from the respective shell entries they're owned by.
|
||
|
||
##### Name
|
||
To override the default name,
|
||
you can either use the default value or specify a `REG_SZ` value called `MUIVerb` inside the respective `shell` key
|
||
for the shell entry.
|
||
MUIVerb takes precedence over the default value.
|
||
|
||
When it comes to the name, the sky is the limit.
|
||
_Actually, Unicode is the limit._
|
||
Either way, put in anything you want; **it's going to work**.
|
||
|
||
##### Icon
|
||
To enable the icon for your shell entry,
|
||
you should use the `REG_SZ` value called `Icon` inside the respective `shell` key for the shell entry.
|
||
|
||
It uses that unmistakably distinct and clumsy **WinAPI resource syntax** to specify a direct link to the icon within
|
||
a file containing resources.
|
||
```csv
|
||
PATH_TO_FILE_WITH_ICON_RESOURCES,INDEX
|
||
```
|
||
|
||
If you want to select the first icon (in that case, the `INDEX` part is 0),
|
||
the `INDEX` part can be omitted completely:
|
||
```csv
|
||
PATH_TO_FILE_WITH_ICON_RESOURCES
|
||
```
|
||
|
||
The following expressions are completely valid and are going to work:
|
||
```csv
|
||
"C:\Windows\system32\cmd.exe"
|
||
C:\Windows\regedit.exe
|
||
"C:\Windows\explorer.exe",0
|
||
C:\Windows\system32\cmd.exe,0
|
||
cmd.exe
|
||
shell32.dll,3
|
||
SHELL32.DLL,10
|
||
"C:\Windows\system32\SHELL32.DLL",9
|
||
```
|
||
You can omit the quotes and absolute paths depending on the `%PATH%` variable that unholy concoction of an API uses.
|
||
**Spoiler:** they don't match against the system `%PATH%`.
|
||
Only God knows what paths it's able to parse by default.
|
||
`C:\Windows` and `C:\Windows\system32` always work for sure, though.
|
||
|
||
It's still highly recommended to supply the absolute path, the `%PATH%` variables of the shell icon picker and the
|
||
shell entry **do not seem to correspond**.
|
||
|
||
::card
|
||
---
|
||
icon: idea
|
||
title: Tip
|
||
---
|
||
You can use the Explorer folder icon picker to acquire the icon DLL and visually calculate the offset
|
||
of the desired icon.
|
||
For instance, the one I selected on the screenshot has an index of `5`.
|
||
The indexing begins with 0 and **ascends in columns**.
|
||
::
|
||
|
||
|
||
|
||
It's also possible to pull resource strings from files containing string tables.
|
||
|
||
|
||
|
||
##### Separators
|
||
Another integral part of the context menu, which is hardly documented by anyone.
|
||
Managing them is also rather quirky and takes getting used to.
|
||
Separators in shell entries are relative to the item they're being enabled for and **can overlap** without any issue.
|
||
|
||
Use `SeparatorBefore` and `SeparatorAfter` empty `REG_SZ` values
|
||
to add a separator before or after the shell entry being edited, respectively.
|
||
|
||
|
||
|
||
##### Appear in the Shift+Click context menu only
|
||
It's possible to «hide» the shell entry from an ordinary context menu right-click.
|
||
Such a shell entry is called «extended».
|
||
|
||
Enable that functionality by creating an empty `REG_SZ` value called `Extended` inside the `shell` key for the
|
||
respective shell entry.
|
||
|
||
##### Hide in safe mode
|
||
To disable the shell entry in safe mode,
|
||
create an empty `REG_SZ` value called `HideInSafeMode` inside the `shell` key for the respective shell entry.
|
||
|
||
##### Never default
|
||
The bold context menu item shown at the top is considered to be the default action for the file type.
|
||
An example of a default shell entry would be «Open» for folders.
|
||
|
||
|
||
|
||
There can be no default entry at all, and that's perfectly fine.
|
||
|
||
To disable the shell entry from becoming default,
|
||
add an empty `REG_SZ` value called `NeverDefault` inside the `shell` key for the respective shell entry.
|
||
|
||
##### Pass to context menu handler
|
||
If there is a context handler available for invocation on shell entry click, it's possible to specify a so-called Verb Handler.
|
||
|
||
Create a new `REG_SZ` value `VerbHandler` inside the `shell` key for the respective shell entry
|
||
and specify the GUID of the context menu handler in the value.
|
||
|
||
|
||
|
||
|
||
|
||
##### No working directory
|
||
Disables the working directory from being added to the environmental path in the context of the application being run.
|
||
|
||
To disable pass-through of the working directory to the application,
|
||
create an empty `REG_SZ` value called `NoWorkingDirectory` inside the `shell` key for the respective shell entry.
|
||
|
||
##### Other options
|
||
Some options, though might sound obvious, have me scratching the back of my head.
|
||
Please tag me on [Twitter](https://go.enderman.ch/twitter) or [send a mail](mailto:contact@enderman.ch) my way if you
|
||
have the knowledge.
|
||
|
||
**A few examples:**
|
||
* `CanonicalName`
|
||
* `CommandStateHandler`
|
||
* `CommandStateSync`
|
||
* `Description`
|
||
* `VerbName`
|
||
|
||
#### Deleting entries
|
||
Even simpler — it's the opposite of adding one.
|
||
|
||
1. Locate the target extension.
|
||
2. Navigate to the `shell` subkey.
|
||
3. Find the shell entry to delete. The default value of the `command` key will usually contain the
|
||
executable name, it's best to verify the target application before deletion.
|
||
4. Delete the key.
|
||
|
||
**Multiple shell entries** can sometimes correspond to the **same item** in the context menu,
|
||
which might result in the item remaining in place despite the deletion.
|
||
|
||
#### Sorting entries
|
||
Now that's the funniest one. I even memed about it on Twitter.
|
||
The only way to sort the context menu is via the alphabetical order of its respective shell entries in the registry.
|
||
Yes. I am not kidding. Let the screenshots speak for themselves.
|
||
|
||
|
||
|
||
|
||
|
||
Yeah... I'd rather not comment on that.
|
||
|
||
##### Position override
|
||
Another silly and janky feature that has a limited number of use cases.
|
||
You can manually override the position of your context menu item to be...
|
||
either at the very top, or the very bottom.
|
||
Not much better than alphabetical sorting if you ask me...
|
||
|
||
In your entry under shell, create a REG_SZ value called Position.
|
||
If you want to force the context menu handler to the top, put Top as data, otherwise put Bottom.
|
||
|
||
Sometimes this may be necessary, as, for example, Microsoft dumps their regular alphabetical sorting strategy at
|
||
the bottom of the context menu, where display and personalization settings reside.
|
||
They simply specify the Bottom position for each of the entries.
|
||
If I recall correctly, they're still sorted alphabetically between themselves, as position override takes precedence.
|
||
|
||
|
||
|
||
##### Bottom line
|
||
Some of the default shell entries like Powershell have specific keys
|
||
(for the sake of that example, `ProgrammaticAccessOnly`) to control their appearance context menu.
|
||
|
||
As a rule of thumb, every time you're dealing with existing shell entries,
|
||
I REALLY suggest that you search for a way to modify them online before resorting to any of the general cases I've described above.
|
||
If you can't find anything even on the Internet, well, anything works.
|
||
|
||
### Uneditable entries
|
||
As for the Context Menu handlers, there's actually not much you can do.
|
||
They're located under the shellex\ContextMenuHandlers subkey.
|
||
|
||
|
||
|
||
Most of the time, the only data they contain is a lonely GUID. That doesn't help much.
|
||
|
||
|
||
|
||
So, to remove the Context Menu handler, you should delete the subkey under ContextMenuHandlers.
|
||
I strongly suggest you save the GUID it contained so that you could roll back at any time later.
|
||
|
||
|
||
|
||
Adding your own...
|
||
Well, that's complicated.
|
||
You actually have to write your own handler in a language supporting Windows API or any sort of abstraction of it.
|
||
For example, C# is a decent choice.
|
||
I don't suggest you waste time on this,
|
||
unless you're making full-on software that you want to make more accessible to Windows users.
|
||
|
||
## Dealing with locked keys
|
||
If the registry key is locked, and you don't have write permissions for it, it's owned by TrustedInstaller,
|
||
and you have to manually reclaim ownership of the key and allow yourself to make edits to it.
|
||
|
||
Optimal way: Using Process Hacker with the TrustedInstaller plugin or Winaero Tweaker,
|
||
run regedit as Trusted Installer and perform the necessary tweaks.
|
||
|
||
General solution:
|
||
|
||
Navigate to the key you want to take ownership of
|
||
Open the «Properties» window
|
||
Head over to the Advanced tab
|
||
At the top of the Advanced Security Settings it states Owner: TrustedInstaller. Click Change
|
||
Input your username into the Enter the object name to select (examples) text area.
|
||
Click OK
|
||
Check the «Replace owner on subcontainers and objects» checkbox
|
||
Check the «Replace all child object permission entries» checkbox
|
||
Click OK
|
||
Select Administrators (PC_NAME\Administrators) in the group selector and then check Full Control box in the Permissions window down below
|
||
Click OK
|
||
After performing above steps, you must have gotten full and almost complete (some registry values and keys are still protected after the general procedure) access to the desired key.
|
||
|
||
## Common registry paths
|
||
Here is a list of the most common registry paths.
|
||
|
||
#### Desktop Background — bottom rows
|
||
`Computer\HKEY_CLASSES_ROOT\DesktopBackground`
|
||
|
||
|
||
|
||
#### Folder Background
|
||
`Computer\HKEY_CLASSES_ROOT\Directory\Background`
|
||
|
||
|
||
|
||
#### Folder
|
||
`Computer\HKEY_CLASSES_ROOT\Directory`
|
||
|
||
|
||
|
||
#### Folder Item
|
||
This extends [Folder](#folder).
|
||
`Computer\HKEY_CLASSES_ROOT\Folder`
|
||
|
||
|
||
|
||
#### Drive
|
||
`Computer\HKEY_CLASSES_ROOT\Drive`
|
||
|
||
|
||
|
||
#### Library Folder
|
||
`Computer\HKEY_CLASSES_ROOT\LibraryFolder`
|
||
|
||
|
||
|
||
#### Library Background
|
||
`Computer\HKEY_CLASSES_ROOT\LibraryFolder\background`
|
||
Library background inherits from Folder Background,
|
||
but can't parse the `%V` macro, which results in the following error.
|
||
This is Microsoft's fault.
|
||
To my knowledge, there is no way to fix that.
|
||
|
||
|
||
|
||
|
||
|
||
#### All Files
|
||
`Computer\HKEY_CLASSES_ROOT\*`
|
||
|
||
|
||
|
||
#### All Filesystem Objects
|
||
That's different from [All Files](#all-files) — it's a further generalization that includes system drives and symbols.
|
||
`Computer\HKEY_CLASSES_ROOT\AllFilesystemObjects`
|
||
|
||
|
||
|
||
#### Type associations
|
||
Text: `Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\text`
|
||
Images: `Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\image`
|
||
Documents: `Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\document`
|
||
Audio: `Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\audio`
|
||
Video: `Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\video`
|
||
|
||
## Cleaning up the context menu
|
||
Most obnoxious default entries can be cleaned up using Winaero Tweaker.
|
||
I suggest you use it to make the process way more bearable for yourself.
|
||
|
||
|
||
|
||
|
||
|
||
#### Areas Winaero Tweaker is unable to reach to
|
||
Remove «Open PowerShell window here»
|
||
Navigate to Computer\HKEY_CLASSES_ROOT\Directory\shell\Powershell
|
||
Unlock key (The Windows Context Menu > Dealing with locked keys)
|
||
Create a new REG_SZ value ProgrammaticAccessOnly without any data
|
||
Navigate to Computer\HKEY_CLASSES_ROOT\Directory\Background\shell\Powershell
|
||
Unlock key
|
||
Create a new REG_SZ value ProgrammaticAccessOnly without any data
|
||
Remove «Open Linux shell here»
|
||
Navigate to Computer\HKEY_CLASSES_ROOT\Directory\shell\WSL
|
||
Unlock key
|
||
Delete WSL key altogether
|
||
Navigate to Computer\HKEY_CLASSES_ROOT\Directory\Background\shell\Powershell
|
||
Unlock key
|
||
Create a new REG_SZ value ProgrammaticAccessOnly without any data
|
||
Edit the «Edit» text context menu command
|
||
Navigate to Computer\HKEY_CLASSES_ROOT\SystemFileAssociations\text\shell\edit
|
||
Make sure you've read the article thoroughly, then do anything you want with it.
|
||
|
||
## Bottom line
|
||
No matter how terrible the context menu API might be for Windows, there's still a way to customize it.
|
||
Hope you found the tricks useful!
|
||
|
||
If you've spotted a mistake (be it orthographical, factual or any other)
|
||
in this article or want to add some important details or share any important knowledge on the subject,
|
||
please contact me on Twitter: @endermanch or hit me up on e-mail: blogs@enderman.ch
|