Manage Learn to apply best practices and optimize your operations.

Rescue Old Windows 10 Applications from Oblivion

Reading over recent TenForums threads, I was reminded that the Snipping Tool is slated for retirement in a future Windows release. How? A worried user  asked how to keep using it even after it’s gone from future code bases. Turns out this is fairly easy to accomplish as long as you take certain preventive steps in advance. OTOH, if you maintain access to an older backup, you can perform those steps when that backup is mounted and its files are accessible. Yes, fellow geeks, it is possible — easy, even — to rescue old Windows 10 applications from oblivion. I’ll explain how below, but here’s where the concern about the Snipping Tool originates, straight from its opening screen:

Note the euphemistic language for retirement/removal: “moving to a new home.” Ha!

How-to: Rescue Old Windows 10 Applications from Oblivion

Turns out, two key elements work inside all built-in Windows applications. Element one is the executable code that makes the application work; Element two is the UI information that provides labels, messages, and info to users in their chosen UI language while the application is running. Both pieces are necessary, but the language piece must reside in a specially-labeled folder dependent to the folder in which the .exe file lives. Let’s use the Snipping Tool as our example to show how this can be accomplished.

Grab the .exe file you need

Find the .exe file name. Again, we’re using Snipping Tool as our example, but you can use this technique for any Windows executable you wish to preserve. Thus, right-click Snipping Tool in the Start menu, then open its Properties window. There, on the Shortcut tab, you’ll find the following data for its Target field:


On most PCs, the environment variable %windir% resolves to C:\Windows, so that really means that the .exe file resides in C:\Windows\system32. So that’s where you want to go to grab that .exe file. Let’s say you put it on your D: drive in a folder named OldSnipTool (for Windows, this translates into D:\OldSnipTool, as a directory path).

Grab the corresponding .mui file

Next comes the UI file, which takes the extension .mui. This stands for Multilingual User Interface, and provides the resource files that Windows uses to deal with the UI in some specific language or another. Finding this file requires two bits of information. First, you must know that language name for your chosen UI language. Look for that as the folder name for the dependent folder from which you’ll grab the corresponding .mui file. It has the same name as the executable file, and ends with a .mui extension. Thus, given an .exe file named SnippingTool.exe we’re seeking a file named SnippingTool.exe.mui. A quick hop into Explorer file search (or my personal fave, Voidtools Everything) can find this for you quickly, and will show you the language label(s) that you’ll need for the second bit of information. It (or they) will name your subsidiary folder(s) [I include the optional plurals here because some people may need more than one UI language for some installations].

Thus for example, the version of this file that I want shows up with the following directory path: C:\Windows\System32\en-US\. Note that I bolded the language version I need — namely en-US. This stands for English-US, or the version of English spoken/written/read in the USA. Microsoft calls these names Language Code Identifiers (LCIDs) and maintains a set of complete references for such things if you want to see their take on it. I usually use search to show me in my current Windows install what I need to think about instead. In this case that’s en-US.

Copy the Files into Appropriate Folders

Based on my example set-up, SnippingTool.exe goes into D:\OldSnipTool. Next, I need to create a new folder therein named \en-US. Then, I copy the corresponding.mui file into that folder. This produces the following file structure, as shown in File Explorer:

It takes two File Explorer windows to show contents of parent and child folders. Here you see the .exe in the parent, and the .mui in the properly-labeled child folder.
[Click image for full-sized view.]

Now, if you visit the parent directory and double-click the .exe file, the application should launch as expected. I just tried it on the files I set up for this example, and it works as expected. It should do likewise, with any pairs (or sets) of .exe and one or more corresponding .mui files. Each of the latter, of course, must be ensconced in a properly-labeled language identifier-based child folder. With all that in place, you should be good to go.

Virtual Desktop