I finally gave in and decided to update XP to SP3. One of the things that bothers me about SP2+ and which caused me to put it off for so long is that it requires fully-qualified paths for file-types and Explorer verbs.

For example, in SP1, you could do something like the following:

REGEDIT4

[HKCR\txtfile\shell]
"@"="Notepad2"

[HKCR\txtfile\shell\Notepad2]
"@"="notepad2.exe %1"

Assuming that notepad2.exe is in the path, then you could open a text file by either running it directly or by selecting Notepad2 from its context-menu.

In SP2+, this will not work and displays the Open With… dialog instead. To fix it, you must use a fully-qualified path to the executable:

[HKCR\txtfile\shell\Notepad2]
"@"="e:\tools\editors\text\notepad2\notepad2.exe %1"

This change (which renders the PATH variable essentially pointless) was a security enhancement added to SP2’s Great Security Update, and it makes sense in that it prevents path-injection attacks.

However it is more trouble than it is worth because if a virus can modify your system path variable, then it’s already gotten access to the system and can do whatever it wants. Moreover, it only affects Explorer; running things from the command-prompt still works as before. In addition, it only works for the primary command; that is, the following still works if infectednotepad.exe is in the path:

"@"="e:\tools\misc\shellexecute.exe /c infectednotepad.exe %1"

This change doesn’t really provide any extra security; instead, all it does is to cause the user to have to spend hours scanning through the registry in each of the 6-10 different places where file-types, applications, and Explorer verbs can be registered, searching for unqualified paths and replacing each and every one (replacing only the main entry in HKCR is not sufficient because there are levels in other locations that compound and confound the problem).

“Fixing” the items can be an insurmountable task for a system that has already been configured and used for any length of time, especially if third-party programs have been added.

Is there a way to turn this “feature” off and let the PATH variable do its job again?

I finally gave in and decided to update XP to SP3. One of the things that bothers me about SP2+ and which caused me to put it off for so long is that it requires fully-qualified paths for file-types and Explorer verbs.

For example, in SP1, you could do something like the following:

REGEDIT4

[HKCR\txtfile\shell]
"@"="Notepad2"

[HKCR\txtfile\shell\Notepad2]
"@"="notepad2.exe %1"

Assuming that notepad2.exe is in the path, then you could open a text file by either running it directly or by selecting Notepad2 from its context-menu.

In SP2+, this will not work and displays the Open With… dialog instead. To fix it, you must use a fully-qualified path to the executable:

[HKCR\txtfile\shell\Notepad2]
"@"="e:\tools\editors\text\notepad2\notepad2.exe %1"

This change (which renders the PATH variable essentially pointless) was a security enhancement added to SP2’s Great Security Update, and it makes sense in that it prevents path-injection attacks.

However it is more trouble than it is worth because if a virus can modify your system path variable, then it’s already gotten access to the system and can do whatever it wants. Moreover, it only affects Explorer; running things from the command-prompt still works as before. In addition, it only works for the primary command; that is, the following still works if infectednotepad.exe is in the path:

"@"="e:\tools\misc\shellexecute.exe /c infectednotepad.exe %1"

This change doesn’t really provide any extra security; instead, all it does is to cause the user to have to spend hours scanning through the registry in each of the 6-10 different places where file-types, applications, and Explorer verbs can be registered, searching for unqualified paths and replacing each and every one (replacing only the main entry in HKCR is not sufficient because there are levels in other locations that compound and confound the problem).

In addition, Microsoft obviously realize that his “feature” was pointless because they removed it in Vista. In Windows 7, the first example works just like in SP1.

“Fixing” the items can be an insurmountable task for a system that has already been configured and used for any length of time, especially if third-party programs have been added.

Is there a way to turn this “feature” off and let the PATH variable do its job again?