There are basically three main ways to do an app replacement: (to clarify, by "app replacement", I mean replacing something a way such that you can invoke the new app the same as before, without having to edit shortcuts, file associations, etc.)
Method 1: Directly replace the Windows executable (unclean)
If your app is standalone (e.g., Notepad2), you can just replace the appropriate file in I386 with your app.
If your app is not standalone, then you will need to create a launcher for it, install your app to %ProgramFiles% (or whereever), and replace the Windows executable with the launcher (which will then subsequently call your app)
Pro: This is the simple and obvious way.
Con: Replacing system files will usually result in digital signature warnings from Windows File Protection. This is thus an "unclean" method.
n.b.: If the new app has a digital signature, then you can do a direct replacement without getting signature errors. For example, it's possible to cleanly replace Calculator with Calculator Plus, as long as you do not modify the executable and thus invalidate the signature. In the specific case of Calculator Plus, it's probably best to solve the help file problem by patching accessor.inf (sample addon) instead of hacking the executable and thus invalidating the signature.
Method 2: Use an image "hijack" (clean)
Examples of apps that use this method include Microsoft Sysinternals Process Explorer and my Notepad2 replacement installer. This method uses the "Image File Execution Options" registry key to cause Windows to launch your app whenever someone tries to run the "hijacked" app.
For example, my Notepad2 2.x replacement installer uses the following key (a slightly different key is used for my NP2 3.x installer and newer, but the concept is the same):
Code: Select all
[Notepad2.AddReg]
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe","Debugger",0,"%16422%\Notepad2\Notepad2.exe"Pro: Clean replacement that doesn't create digital signature warnings or upset WFP.
Con: Need for a launcher if that extra first parameter on the command line creates problems.
Method 3: Take advantage of path search precedence (clean)
When searching the PATH for an executable, Windows first searches the current directory and then the PATH variable, from left to right. This allows you to "replace" certain Windows apps by placing them in a location and adding that location to the start of the PATH environment variable, thus ensuring that Windows finds your app first, before it finds the old app.
For example, my method of replacing MAKECAB and EXPAND is by placing them in "%ProgramFiles%\Utilities" and then adding "%ProgramFiles%\Utilities" to the beginning of the PATH variable.
To add a path to the beginning of the PATH variable, you can either manually edit the registry (which carries the risk of clobbering any existing changes made to the PATH variable), use setx from Microsoft's resource toolkit (which carries the downside of converting the REG_EXPAND_SZ string into a REG_SZ string), or use my addpath tool (this is the tool that I use to set the environment variable for my own MAKECAB/EXPAND replacement addon)
Example: addpath pre "%ProgramFiles%\Utilities"
Pro: Clean replacement that doesn't create digital signature warnings or upset WFP.
Con: Does not work if the path to an app is explicitly specified (e.g., if someone explicitly runs "%SystemRoot%\system32\makecab.exe" instead of just "makecab.exe" or if the app is run from the directory of the old app (e.g., if you run makecab.exe from %SystemRoot%\system32). As a result of these limitations, this method makes sense mostly for command-line apps.
Recommendations
Personally, I never use method #1 (direct replacement). I always use method #3 (path precedence) for command-line apps (e.g., MAKECAB and EXPAND) or method #2 (image hijack) for all other apps (e.g., Notepad2). I avoid method #1 because I'm a perfectionist who likes to have zero WFP errors on my systems.
Good to know some of these things lol.
