is there a way for me to ADD that example into the "netsh /?" results?
Michael wrote:
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
How can I edit the manpage for the Windows netsh command.
Since the beginning of wireless networking I've never been able to remember the syntax for the netsh command, and worse, it's always needed when I am
off the network so I can't even look it up on my laptop when I need it.
The command to get the name of the Ethernet NIC is easy enough to remember. ipconfig | findstr "Ethernet adaptor"
But then it gets a bit more complicated when you ask for more information. netsh interface ipv4 show config "eth0"
But it's really hard to remember the syntax to set the subnet & gateway. netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
Worse, "/?" help doesn't really help (try it & let me know if it does).
So is there a way for me to ADD that example into the "netsh /?" results?
On 3/16/2023 11:33 AM, Andy Burns wrote:
Michael wrote:
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
If there was a way to edit an executable,
Windows Update would only replace it and
your notes would be lost :-)
  Paul
Since the beginning of wireless networking I've never been able to remember >the syntax for the netsh command, and worse, it's always needed when I am
off the network so I can't even look it up on my laptop when I need it.
...
But it's really hard to remember the syntax to set the subnet & gateway. >netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
How can I edit the manpage for the Windows netsh command.take a screen pic and save it
Since the beginning of wireless networking I've never been able to remember the syntax for the netsh command, and worse, it's always needed when I am
off the network so I can't even look it up on my laptop when I need it.
The command to get the name of the Ethernet NIC is easy enough to remember. ipconfig | findstr "Ethernet adaptor"
But then it gets a bit more complicated when you ask for more information. netsh interface ipv4 show config "eth0"
But it's really hard to remember the syntax to set the subnet & gateway. netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
Worse, "/?" help doesn't really help (try it & let me know if it does).
So is there a way for me to ADD that example into the "netsh /?" results?
On 3/16/2023 12:55 PM, Paul wrote:than rebuilding a relatively huge software system--which I could not have done on my own even if I wanted to). But modifying a few words in RAM fell under my control! ; ) But it was not a Win-10 system (apologize for being off topic).
On 3/16/2023 11:33 AM, Andy Burns wrote:
Michael wrote:
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
If there was a way to edit an executable,
Windows Update would only replace it and
your notes would be lost :-)
   Paul
You're the expert on virtually all matters concerning computer hardware to me. But strictly speaking, it's not hard to write a program to edit an executable. In fact, I have written code to edit machine code sitting in RAM (because that was far faster
In the same manner, I have edited .jpg files directly (with java or C++), just to convince myself that it doing so is as straightforward as I anticipated that it would be. You just have to look up the way .jpg files are formatted, where their headerends, etc. Standards (and protocols) are one of the secrets to civilization! I know you know that, but I think most people do not realize that (or care! lol).
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
Andy Burns said:
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
netsh interface portproxy add v4tov4 listenport=xxx listenaddress=192.168.xx.xx connectaddress=192.168.yy.yy connectport=yyy
Because the lanmanserver service starts early and binds to 445 on all interfaces, you may need to install a virtual kernel NIC driver in order
to get an interface with a "spare" IP address to listen on, it was
available from MS last time I needed it on Win7, not sure about Win10.
It's even better when other people remember your notes for you ;-)
Did you recognize it instantly or did it take a while?
Worse, "/?" help doesn't really help (try it & let me know if it does).
So is there a way for me to ADD that example into the "netsh /?" results?
On Thu, 16 Mar 2023 09:28:02 -0600, Michael <michael@spamcop.com> wrote:
Since the beginning of wireless networking I've never been able to remember >the syntax for the netsh command, and worse, it's always needed when I am >off the network so I can't even look it up on my laptop when I need it.
...
But it's really hard to remember the syntax to set the subnet & gateway. >netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
I know it's not what you asked, but if you really get in a bind you can probably just use the GUI for doing all of that. No syntax to remember.
On Thu, 16 Mar 2023 14:44:49 -0500, Char Jackson wrote:
On Thu, 16 Mar 2023 09:28:02 -0600, Michael <michael@spamcop.com> wrote:
Since the beginning of wireless networking I've never been able to remember >> >the syntax for the netsh command, and worse, it's always needed when I am >> >off the network so I can't even look it up on my laptop when I need it.
...
But it's really hard to remember the syntax to set the subnet & gateway.
netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
I know it's not what you asked, but if you really get in a bind you can
probably just use the GUI for doing all of that. No syntax to remember.
For those (like me) who got excited at the thought of a GUI version
of netsh, after some googling I don't think there is one.
But for the OP's specific issue, changing IP addresses, here's a
helpful video showing how to do _that_ in GUI: >https://www.youtube.com/watch?v=XiPzxXJ7KB4
netsh, as with many tools, gives you only top-level help if you use
"<prog> /?". You have to drill down to get to a directive or even sub-directive to add /? to get help on the [sub]-directive, like:
netsh /?
netsh interface /?
then
netsh interface ipv4 /?
then
netsh interface ipv4 set /?
then
netsh interface ipv4 set address /?
You could start at the end if you know all the args you want to specify,
but I usually have to drill down through the help levels.
There are no man pages in Windows like there is in Linux. Help is built
into the program. There is the 'help' command, but that just lists some DOS-mode programs.
On 16.03.2023 16:28, Michael wrote:
Worse, "/?" help doesn't really help (try it & let me know if it does).
So is there a way for me to ADD that example into the "netsh /?" results?
Create you own help file for things you want to know
but always forget. For example, create a batch file
with the name "helpme.bat" in a director which is in
your %path% with a content like this:
@echo off
set topic=netsh dir copy
set topic=%topic% move type
set topic=%topic% mkdir
echo.
for %%i in (%topic%) do if [%%i]==[%1] goto :%%i
echo help is available for:
echo %topic%
echo.
goto :eof
:netsh
echo netsh interface ipv4 set address name="eth0" static 192.168.0.2 255.255.255.0 192.168.0.1
echo.
goto :eof
:dir
echo anything
echo you want to
echo know about
echo dir
echo.
goto :eof
:copy
echo anything
echo you want to
echo know about
echo copy
echo.
goto :eof
:move
echo anything
echo you want to
echo know about
echo move
echo.
goto :eof
:type
echo anything
echo you want to
echo know about
echo type
echo.
goto :eof
:mkdir
echo anything
echo you want to
echo know about
echo mkdir
echo.
goto :eof
Worse, "/?" help doesn't really help (try it & let me know if it does).
So is there a way for me to ADD that example into the "netsh /?" results?
Create you own help file for things you want to know
but always forget. For example, create a batch file
with the name "helpme.bat" in a director which is in
your %path% with a content like this:
VanguardLH wrote:^^^^^^^^^
netsh, as with many tools, gives you only top-level help if you use
"<prog> /?". You have to drill down to get to a directive or even
sub-directive to add /? to get help on the [sub]-directive, like:
netsh /?
netsh interface /?
then
netsh interface ipv4 /?
then
netsh interface ipv4 set /?
then
netsh interface ipv4 set address /?
You could start at the end if you know all the args you want to specify,
but I usually have to drill down through the help levels.
There are no man pages in Windows like there is in Linux. Help is built
into the program. There is the 'help' command, but that just lists some
DOS-mode programs.
I tried that, using a logical sequence, and also got stuck at a different point of the tree but it didn't seem that it would ever work logically.
netsh /?
... interface - Changes to the 'netsh interface' context ...
netsh interface /?
... ipv4 - Changes to the 'netsh interface ipv4' context.
netsh interface ipv4 /?
... set interface - Sets interface parameters. ...
netsh interface ipv4 set interface /?
On 3/16/2023 11:28 AM, Michael wrote:
How can I edit the manpage for the Windows netsh command.
Worse, "/?" help doesn't really help (try it & let me know if it does).take a screen pic and save it
So is there a way for me to ADD that example into the "netsh /?" results?
In powershell, you can mark the text and copy it, to a text file.
On 17.03.23 09:46, Herbert Kleebauer wrote:
I don't like sticking things into my $PATH so I added it to the AppPaths.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\manpage.exe
@default=c:\path\manpage.bat
So that "Win+R" & then "manpage" would get the results over the years.
But it only flashed when I did that, even when I linked to a shortcut:
@default=c:\path\manpage.lnk
I don't like sticking things into my $PATH so I added it to the AppPaths.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\manpage.exe
@default=c:\path\manpage.bat
So that "Win+R" & then "manpage" would get the results over the years.
But you have to do this for every utility you use. I add one directory
to the PATH variable, for historical reason this is "D:\dos622\befehle"
(I used this first when transferring DOS utilities to Win98). Single
exe utilities (like unzip, 7za, unrar, wget and so on) or batch programs
are stored directly in this directory. Utilities with additional data
(like "midnight commander", "tiny C compiler", "ffmpeg" and so on) have
there own directory in d:\dos622\. Because they are not in the PATH
variable I add a batch file to D:\dos622\befehle to start them, e.g.
tcc.bat with the content: d:\dos622\tcc\tcc.exe %1 %2 %3 %4 %5
This way I can just copy the directory d:\dos622 to an other PC
and all is working without first having to make registry entries.
But it only flashed when I did that, even when I linked to a shortcut:
@default=c:\path\manpage.lnk
Just add a "pause" at the end of the batch so the windows stays open
until you press a key. But it is simpler to always have an open CMD
window with Midnight- or Far-Commander running.
We're both doing the same thing but different ways.
You're using the PATH for what it was designed for.
I'm using the AppPaths for what it was designed for.
On 3/16/2023 11:33 AM, Andy Burns wrote:
Michael wrote:
is there a way for me to ADD that example into the "netsh /?" results?
Not really, just use notepad to create your own, err, notes.
If there was a way to edit an executable,
Windows Update would only replace it and
your notes would be lost :-)
On 3/16/2023 2:41 PM, Bill wrote:
On 3/16/2023 12:55 PM, Paul wrote:
On 3/16/2023 11:33 AM, Andy Burns wrote:
Michael wrote:
is there a way for me to ADD that example into the "netsh /?" results? >>>>Not really, just use notepad to create your own, err, notes.
If there was a way to edit an executable,
Windows Update would only replace it and
your notes would be lost :-)
   Paul
You're the expert on virtually all matters concerning computer
hardware to me. But strictly speaking, it's not hard to write a
program to edit an executable. In fact, I have written code to edit
machine code sitting in RAM (because that was far faster than
rebuilding a relatively huge software system--which I could not have
done on my own even if I wanted to). But modifying a few words in RAM
fell under my control! ; ) But it was not a Win-10 system (apologize
for being off topic).
In the same manner, I have edited .jpg files directly (with java or
C++), just to convince myself that it doing so is as straightforward
as I anticipated that it would be. You just have to look up the way
.jpg files are formatted, where their header ends, etc. Standards (and
protocols) are one of the secrets to civilization! I know you know
that, but I think most people do not realize that (or care! lol).
I have edited executables before.
But because you have to use a disassembler to figure out
where you are and so on, this is not a preferred hobby
or anything. I do it only when I have to.
Some executables on Windows are signed, but others are not.
Freethinker wrote:
We're both doing the same thing but different ways.
You're using the PATH for what it was designed for.
I'm using the AppPaths for what it was designed for.
I think, there is a big difference. The first is "one for all"
and the second "one for one". I add a single directory to
the PATH variable when I set up a new PC. That's all what
is needed for the current and all future utilities I use.
You have to do it for any utility you use and, if you setup
a new PC, you have to do it again for all of them.
Note: OP originally posted to:
alt.comp.os.windows-10
alt.comp.os.windows-11
alt.internet.wireless
When Kleebauer replied, he stripped out the last 2 newsgroups leaving:
alt.comp.os.Windows-10
Then when he replied later, he added:>
alt.comp.microsoft.windows
which does not exist on my NNTP server. Maybe it does on his.
Regardless of cause, I removed the *.windows newsgroup since it was
probably a typo. My reply was therefore submitted to just:
alt.comp.os.windows-10
If I added back the original 2 newsgroups that Kleebauer stripped, this subthread would appear disconnected from the *.windows-11 and *.wireless newsgroups perhaps causing confusing for why there was missing posts.
Herbert Kleebauer <klee@unibwm.de> wrote:
Freethinker wrote:
We're both doing the same thing but different ways.
You're using the PATH for what it was designed for.
I'm using the AppPaths for what it was designed for.
I think, there is a big difference. The first is "one for all"
and the second "one for one". I add a single directory to
the PATH variable when I set up a new PC. That's all what
is needed for the current and all future utilities I use.
You have to do it for any utility you use and, if you setup
a new PC, you have to do it again for all of them.
AppPaths is defined in the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
The PATH environment variable consists of sysPATH (global) and userPATH
(per Windows account).
Unlike PATH which can have sys (global) and user constituents, the
AppPaths registry entries are under HKLM, so everyone sees those.
Sorry if I misunderstood. In "one for all" and "one for one", no way to tell which one was which.
I think, there is a big difference. The first is "one for all"
and the second "one for one". I add a single directory to
the PATH variable when I set up a new PC. That's all what
is needed for the current and all future utilities I use.
You have to do it for any utility you use and, if you setup
a new PC, you have to do it again for all of them.
AppPaths is defined in the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths ^^^^^^^^^^^^^^^^^^
\___ Everyone gets this.
The definition is under HKLM, so every Windows account will see those definitions.
Yes, you misunderstood completely what I said. I have more than
100 utilities (.exe .com .bat) in d:\dos622\befehle (many don't
work anymore in 64 bit Windows because they are 16 bit code).
By just adding one entry to the PATH variable when setting up
a new PC, all these utilities are available from any directory
in a CMD window because there location is in the PATH variable.
That's what I called "one (entry) for all (utilities)".
If you use the AppPaths method, you need a registry entry for
each of the more than 100 utilities. That's what I called "one
(entry) for one (utilities)". And if you get a new PC, you have
to create all these entries again.
No, you cross posted also to:
alt.comp.microsoft.windows
Usenet is dead, especially the alt. hierarchy.
Yes, you misunderstood completely what I said. I have more than
100 utilities (.exe .com .bat) in d:\dos622\befehle (many don't
work anymore in 64 bit Windows because they are 16 bit code).
By just adding one entry to the PATH variable when setting up
a new PC, all these utilities are available from any directory
in a CMD window because there location is in the PATH variable.
That's what I called "one (entry) for all (utilities)".
If you use the AppPaths method, you need a registry entry for
each of the more than 100 utilities. That's what I called "one
(entry) for one (utilities)". And if you get a new PC, you have
to create all these entries again.
Usenet is dead, especially the alt. hierarchy.
On Sun, 19 Mar 2023 17:36:29 +0100, Herbert Kleebauer <klee@unibwm.de>
wrote:
Usenet is dead, especially the alt. hierarchy.
Certainly dying, but fortunately not yet dead.
Personally using the AppPaths registry entries should really only be
done by installers. Far too much a nuisance for a user to be
monitoring, editing, exporting, backing up, and restoring these registry entries. So, I, like you, use the PATH envvar. Since I want access to
my utilities under any Windows account, the tools path gets added to the sysPATH. I really don't want to add it to userPATH since I want to use
those tools under any Windows account, including Administrator if shit happens and I need to resort to use that account that I would otherwise
never touch except for emergencies (and because user profiles can get corrupted, I also have an AdminBackup account as a backup to the emergency-only Administrator account).
For example, if you want to open up the Windows font folder, you just type "Win+R fonts"
You can do all that using the %path% as Herbert suggested but unless you
put all your executables and shortcuts and batch files into the same
folder, it will mess up %path% won't it?
Worse, how do you run firefox.exe from three different locations using the %path% when it's super trivial to run each of those from the App Paths subkey (as explained in another thread on the subject I posted later)?
You can also run programs and open up folders and run any shortcut.
These are just off the cuff examples I typed up for Stan Brown.
This is my App Paths sub key to bring up all the %keywords% from MS.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\%.exe
@Default=C:\path\keywords.ppt
In addition, you might have firefox in your path but maybe you want to run
a different firefox, which the App Paths sub key allows you to easily do.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f4.exe
@Default=C:\different-path\firefox.exe
To run each of these, you'd only need to pin the Win+R icon to the taskbar and then tap that icon and a selection of previous choices can be made
from a list of the most recently used that Windows automatically maintains.
This is probably what I'll use for the next decade or two because
it's simple and obvious and elegant enough to be easily remembered
and when needed, it's eminently extensible as it's self explanatory.
You can do all that using the %path% as Herbert suggested but unless
you put all your executables and shortcuts and batch files into the
same folder, it will mess up %path% won't it?
Worse, how do you run firefox.exe from three different locations using
the %path% when it's super trivial to run each of those from the App
Paths subkey (as explained in another thread on the subject I posted
later)?
The App Path is useful if you want to open something up without having
to create a shortcut (although the App Path can run a shortcut also).
It's probably important to note (because it's not intuitive) that the
name of the subkey can be anything but it must end with "exe" for
some reason.
To take a common example likely everyone has, this common app path sub
key:
HKLM\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
@Default=C:\path\firefox.exe
Doesn't actually have to be "firefox.exe" but even "f.exe" would work.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f.exe
@Default=C:\path\firefox.exe
Where those sets of options can be targets inside separate shortcuts,
but where those shortcuts don't have to clutter your GUI if you use
them a lot at all you need to remember is f1, f2 and f3 to run them.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f4.exe
@Default=C:\different-path\firefox.exe
Why not have both tools so tasks better suited for the %path% use the Phillips screwdriver and tasks suited to App Paths use the Flathead?
For example, if you want to open up the Windows font folder, you just type "Win+R fonts"
Or you type "start fonts" in a CMD window.
You can do all that using the %path% as Herbert suggested but unless you put all your executables and shortcuts and batch files into the same folder, it will mess up %path% won't it?
There is no big difference, you put all im ONE registry and I put
it in ONE directory.
Worse, how do you run firefox.exe from three different locations using the %path% when it's super trivial to run each of those from the App Paths subkey (as explained in another thread on the subject I posted later)?
You put 3 entries in the registry, I put 3 batch flies (f1.bat, f2.bat f3.bat) in the directory which is in the PATH.
You can also run programs and open up folders and run any shortcut.
These are just off the cuff examples I typed up for Stan Brown.
This is my App Paths sub key to bring up all the %keywords% from MS.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\%.exe
@Default=C:\path\keywords.ppt
And I could use a batch file with the content:
start C:\path\keywords.ppt
In addition, you might have firefox in your path but maybe you want to run a different firefox, which the App Paths sub key allows you to easily do.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f4.exe
@Default=C:\different-path\firefox.exe
A batch file f4.bat with the content:
C:\different-path\firefox.exe
To run each of these, you'd only need to pin the Win+R icon to the taskbar and then tap that icon and a selection of previous choices can be made from a list of the most recently used that Windows automatically maintains.
And where is the difference. You type f4 and firefox is started, either because there is a batch file f4.bat in the PATH-directory or because
there is an entry in the registry.
You can do all that using the %path% as Herbert suggested but unless
you put all your executables and shortcuts and batch files into the
same folder, it will mess up %path% won't it?
I have a C:\Batch folder containing all my .bat files.
For some
programs, they're installed or copied under C:\Programs but in
subfolders for each program. I have added the subfolders to PATH for SysInternals and Nirsoft, but the rest I don't use that often, so I just
use .bat files to find them which, of course, are in my C:\Batch folder.
So, I've got about 3 folders that I add to PATH (and in the sysPATH
envvar since I want the same access under any Windows account under
which I login, including the Administrator account used only for emergencies): C:\Batch, C:\Programs\SysInternals, and
C:\Programs\Nirsoft. Any other progs under C:\Programs (each in their
own subfolder) are easily ran using the .bat files under C:\Batch. If I
add shortcuts to the Start menu, desktop, or Taskbar toolbars, well, the
path is already specified in the shortcut.
I consider the AppPaths registry entry for use by installers of
programs. That's really meant for their management. AppPaths is
intended for app registration.
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
As with the AppPaths registry key, there is an Applications registry key
for the same purpose. Apparently more app info can be stored under the Applications/<prognam> keys than for AppPaths/<progname>. So, now you
have 2 keys, and all their subkeys, to track, synchronize, backup to
.reg file, and import.
If you edit the AppPaths and Applications subkeys, you could end up
fucking up what the installed added, and what the program expects.
Worse, how do you run firefox.exe from three different locations using
the %path% when it's super trivial to run each of those from the App
Paths subkey (as explained in another thread on the subject I posted
later)?
AppPaths and Applications registry keys only specify a single path to
the executable, not 3 selections for multiple paths.
If you are creating the AppPaths subkeys for multiple but separate
instances of Firefox, like a subkey named firefox.exe, another named firefox2.exe, and another for firefox3.exe, why can't you do that using shortcuts, or .bat files in your batch folder added to PATH?
The App Path is useful if you want to open something up without having
to create a shortcut (although the App Path can run a shortcut also).
Edit the registry to add a subkey under AppPaths, add all the subkeys
under that subkey for command->open, etc. Or define a shortcut. I
don't see one is easier than the other. In fact, to get all the
sub-subkeys correct under an AppPath/<progname> key is more difficult.
It's probably important to note (because it's not intuitive) that the
name of the subkey can be anything but it must end with "exe" for
some reason.
The subkey for <progname> is expected to match on the executable
filename.
That you give it a different program "name" in AppPaths is
because you're creating multiple keys pointing to the same program, but supposedly something is different in each, like adding an argument to
the open command. You're creating multiple AppPath/<prog> subkeys with different names like you creating multiple .bat files with different
names that call the same program, but with something different in each
.bat file for why there are multiples of them for the same program
(although with .bat files, you could use command-line arguments when
calling the batch file to specify how to different execute the program).
To take a common example likely everyone has, this common app path sub
key:
HKLM\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
@Default=C:\path\firefox.exe
Doesn't actually have to be "firefox.exe" but even "f.exe" would work.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f.exe
@Default=C:\path\firefox.exe
So, you are not defining separate AppPaths subkeys with differing
prognames, but creating aliases using AppPaths to point at the same
program? Harken the DOSKEY command, or same-content .bat files
executing the same scripts all residing in a folder added to PATH, or differently named shortcuts all pointing to the same program. Several
ways to skin the same cat.
Where those sets of options can be targets inside separate shortcuts,
but where those shortcuts don't have to clutter your GUI if you use
them a lot at all you need to remember is f1, f2 and f3 to run them.
Shortcuts never have to clutter a GUI. Put the .lnk shortcut files in a folder you've added to your PATH envvar, like the same one where you're storing all your .bat files. .lnk shortcut files are executable, so you
can call them from the command line, too.
Create a shortcut on your
desktop. Have it load "C:\Program Files\Mozilla Firefox\firefox.exe"
(or whatever path you like where an instance is found - and works from
there) along with any command-line arguments. Then move it to your
common batch folder (which has been included in PATH). Name the
shortcut "fx12". In a command shell, run fx12.lnk (you have to include
the extension). Voila, Firefox opens from the shortcut stored in a
PATH'ed location.
HKLM\Microsoft\Windows\CurrentVersion\App Paths\f4.exe
@Default=C:\different-path\firefox.exe
That can run afoul of the program using its install-time defined
AppPaths subkey, like when it runs an external updater that expects run
the executable from the same path as where the updater was stored. Lots
of programs expect pathing to be consistent which means the user hasn't fucked it up. That is why I said AppPaths (and Applications) are really
for installer-defined and program-managed pathing.
We can argue more example and scenarios, but it comes down to which is
easier to manage. For you, you like AppPaths (and might now explore the Applications registry key, too). For others, they see no need to putz
around in the registry for what they similarly accomplish with PATH, shortcuts, batch scripts, or other more "normal" methods of defining executable paths and arguments.
I knew about AppPaths many years ago. Despite its possible convenience,
I didn't see it as a plausible means to management pathing from my perspective, and I wasn't going to fuck with how installers, updaters,
or programs were expecting those keys to be defined.
On 21.03.23 19:38, VanguardLH wrote:
You can do all that using the %path% as Herbert suggested but unless
you put all your executables and shortcuts and batch files into the
same folder, it will mess up %path% won't it?
I have a C:\Batch folder containing all my .bat files.
What if you maintain batch files on external drives and in multiple locations? Do you really add a billion entries to the %path% in that case?
I realize what you're doing is putting everything into a single
folder, but that's a limitation that you don't even think about for
the App Paths tool.
It's two different ways to do the same thing, which both will do.
It's like having two grinding wheels or two different grits of sandpaper.
Why would you argue against having the right tool for the job at hand?
For some
programs, they're installed or copied under C:\Programs but in
subfolders for each program. I have added the subfolders to PATH for
SysInternals and Nirsoft, but the rest I don't use that often, so I just
use .bat files to find them which, of course, are in my C:\Batch folder.
According to Microsoft, this is precisely why they created the App Paths subkey in Windows XP.
They're two tools that will do the same job.
One is suited to some jobs better than the other.
I consider the AppPaths registry entry for use by installers of
programs. That's really meant for their management. AppPaths is
intended for app registration.
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
I'm sure it is.
So what?
As with the AppPaths registry key, there is an Applications registry
key for the same purpose. Apparently more app info can be stored
under the Applications/<prognam> keys than for AppPaths/<progname>.
So, now you have 2 keys, and all their subkeys, to track,
synchronize, backup to .reg file, and import.
Yes. But you're arguing that you shouldn't have a Dremel tool because
it can handle all sizes of bits, even if you only really use the
cutting wheel.
You can't blame the Dremel tool because it does more than you need it to
do. The way I use the App Paths is with just the "@Default" but if you want to use it with different bits (as you're describing) then that's not a negative.
If you edit the AppPaths and Applications subkeys, you could end up
fucking up what the installed added, and what the program expects.
That's kind of like saying that a kitchen should only have forks because if you use chopsticks, you could end up fucking up the plate of spaghetti.
AppPaths and Applications registry keys only specify a single path to
the executable, not 3 selections for multiple paths.
If you are creating the AppPaths subkeys for multiple but separate
instances of Firefox, like a subkey named firefox.exe, another named
firefox2.exe, and another for firefox3.exe, why can't you do that using
shortcuts, or .bat files in your batch folder added to PATH?
What is your reason for not wanting a variety of shovels to use when you
want to use them, where all shovels end up doing the same thing, don't
they?
The App Path is useful if you want to open something up without having
to create a shortcut (although the App Path can run a shortcut also).
Edit the registry to add a subkey under AppPaths, add all the subkeys
under that subkey for command->open, etc. Or define a shortcut. I
don't see one is easier than the other. In fact, to get all the
sub-subkeys correct under an AppPath/<progname> key is more difficult.
I'm not sure why you're arguing repeatedly against having multiple shovels. Don't use the Edging Shovel when you prefer to use the Trench Shovel.
The subkey for <progname> is expected to match on the executable
filename.
That's just false.
You think that.
But it's false.
It's a keyword.
It can be anything.
It's OK if a shovel has a fiberglass handle instead of a hickory handle.
So, you are not defining separate AppPaths subkeys with differing
prognames, but creating aliases using AppPaths to point at the same
program? Harken the DOSKEY command, or same-content .bat files
executing the same scripts all residing in a folder added to PATH, or
differently named shortcuts all pointing to the same program. Several
ways to skin the same cat.
Again, you may prefer to dig a trench using a pickax and a shovel while I might want to dig that same trench using just the shovel. Why do you care?
What if I don't want to put all my shovels in one tool shed?
What if I just want to leave some scattered about?
You're at the point that you bought too many Monty Python arguments, where, in the spirit of Monty Python, my rebuttal is that I always set up Firefox
to disable updates using this simple registry file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Mozilla\Firefox]
"DisableAppUpdate"=dword:00000001
BTW, I could easily set up an App Paths subkey to "disable" and
"enable" the updates at the typing of a single command, while you'd
probably set that up using the %path% which is fine.
I'm not sure why you are arguing against having two types of shovel, each
of which has their own pros and cons, and both of which can do any job.
An example is Microsoft didn't build in a way to open up any desired document just by typing a single word like "family" to open "family.xls".
If you were editing the PATH envvar for billions of entries, you'd also
be editing billions of entries under AppPaths. Yours is a bad argument.
I realize what you're doing is putting everything into a single
folder, but that's a limitation that you don't even think about for
the App Paths tool.
No, the limitation with AppPaths is you have to specify a subkey for
EVERY program, and you have to be familiar with all the subkeys under
the AppPaths/<prog> subkey.
Mine is not a limitation. It is *organization*.
Having all exe paths
solely specified in the AppPaths registry entry is like those boobs that
pile every entry in their Start menu in a 1-level hierarchy: a mess. I
also use subfolders in the Start menu to organize those entries, and I
even organize the Start menu tiles into groups.
I am arguing your method isn't better than mine, or of others. You want
to extol AppPaths, but it isn't the panacea you proclaim. Just another method to a similar end.
According to Microsoft, this is precisely why they created the App Paths
subkey in Windows XP.
What you can specify is limited compared to what you can script inside a batch file. Just how, in an AppPaths entry for a program, are you going
to perform any setup before loading a program, do cleanup after exiting
the file, or do anything other than simply specify the executable?
For example, I use a stream capture program called Jaksta, but I don't
like how it leaves behind on its exit a bunch of data that gets reused
in the next session of Jaksta. It's for recovery, like a resume
function, but I don't want it. I can run commands after the program
exits in a batch file to cleanup after its exit (make it pristine
again). Can't do that with an AppPaths entry.
There are programs that
when you exit really don't exit. Their window disappears, but their
process remains. In a batch script, I can kill the process to ensure it really does unload when I "exit" the program. I have batch files that
edit the registry either by using a .reg file or specifying the actual
keys using reg.exe. Requires several regedit lines, and perhaps
multiple executes of reg.exe which cannot be specified in a single open command subkey under a progkey under AppPaths. What if you want to
flush the local DNS cache? Requires more than one command to do
properly. Perhaps you can specify a .bat file in an AppPaths subkey,
but why? You must already have the batch file, and it's in your
C:\Batch folder which is included in PATH.
They're two tools that will do the same job.
One is suited to some jobs better than the other.
Nothing you can do in AppPaths that can't be done in a .bat file.
Lots of things you cannot do with an AppPaths entry that you can do in a
.bat file.
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
I'm sure it is.
So what?
"What" is you don't know how the OS or apps will be using AppPaths, and you're putzing around in there.
You are also unaware (despite giving you an article mentioning it) that
the maximum string length for an open command in an AppPaths progname
entry is MAX_PATH * 2. Probably the same for the shell when running a
batch inside it; however, rather than list too many arguments on the
command line, you could slice the commands apart in a batch. There are programs that are recursive, and their command line can get very long.
Yes. But you're arguing that you shouldn't have a Dremel tool because
it can handle all sizes of bits, even if you only really use the
cutting wheel.
Another bad analogy. I mentioned that you have two chuck sizes to
manage instead of one.
You can't blame the Dremel tool because it does more than you need it to
do. The way I use the App Paths is with just the "@Default" but if you want >> to use it with different bits (as you're describing) then that's not a
negative.
Why are you arguing about the 2nd registry key (Applications)? I
mentioned it because it is yet another means of doing what AppPaths
does, so you have to manage 2 keys, not 1.
If you edit the AppPaths and Applications subkeys, you could end up
fucking up what the installed added, and what the program expects.
That's kind of like saying that a kitchen should only have forks because if >> you use chopsticks, you could end up fucking up the plate of spaghetti.
You're not the one programming the spaghetti as to what is allowed for
its eating utensil.
What is your reason for not wanting a variety of shovels to use when you
want to use them, where all shovels end up doing the same thing, don't
they?
Another bad analogy. Instead you are calling the same shovel by
multiple names, but the shovel is still a shovel.
I'm not sure why you're arguing repeatedly against having multiple shovels. >> Don't use the Edging Shovel when you prefer to use the Trench Shovel.
You wandered again. I said which incurs more difficulty in creating and editing and managing. You are still focused on wanting multiple aliases
to the same program defined by AppPaths.
Oh, by the way, all this registry key "stuff" is moot unless you are
logged under a Windows admin-level account.
Guess you've never created
restricted accounts for users that you don't want fucking up the setup.
None of the non-admin users can get into the registry. regedit.exe
won't work for them. Double-clicking on a .reg file won't work. Also,
just because the user happens to be the owner of a computer doesn't mean
they log into an admin-level Windows account by default. Many users log
into restricted user accounts to increase security. What a nuisance in having to logout and login to get into an admin-level account, and then logout and login again to get back to the safe restricted Windows
account. With shortcuts or batch files, they don't get barred from
creating and editing those.
It's a keyword.
It can be anything.
Not if one program expects to call another with a specific name with
which it was coded. I'll give an example: games. Many games load a preloader program that then loads the game program. The preloader could
be called anything in AppPaths, but the actual game program is expected
by the preloader to have a specific name.
It's OK if a shovel has a fiberglass handle instead of a hickory handle.
Another bad analogy. Would you want to use a metal shovel to dig into
an area of ground that has electrical wiring?
Again, you may prefer to dig a trench using a pickax and a shovel while I
might want to dig that same trench using just the shovel. Why do you care?
Another bad analogy. You're just full of them.
You are creating
aliases in AppPaths, like firefox.exe, f1.exe, and f2.exe. You are
using multiple names for the same program. A shovel by any name is
still a shovel.
What if I don't want to put all my shovels in one tool shed?
What if I just want to leave some scattered about?
Bad analogy again. Instead of a common folder for all batch files,
you're using a common AppPaths registry key under which to store all
your aliases. So, you're still putting all your shovels in one shed.
Plus your analogies suck, especially since you attempt to use
them to belie what is really happening.
BTW, I could easily set up an App Paths subkey to "disable" and
"enable" the updates at the typing of a single command, while you'd
probably set that up using the %path% which is fine.
No, I just disable the Mozilla Maintenance service. However, Mozilla is rude. If I visit menu -> Help -> About, Firefox will look for and
install updates although all I wanted was the current About info. So,
after disabling the service, don't visit Help -> About.
I'm not sure why you are arguing against having two types of shovel, each
of which has their own pros and cons, and both of which can do any job.
That's your bad interpreation of my statements. You want to use a bad analogy to counter argue.
The argument isn't about shovels, or policies (in the registry), or
anything other than using AppPaths (and Applications) in the registry.
Stay on topic.
Your argument, so far, is that using AppPaths is better.
Sorry, I don't see that. In fact, the more you're in the registry, the
more likely you'll fuck it up.
With writing shortcuts or batch files, I
don't have to use them, or can fix them, and not risk corrupting the
registry making the OS unusable or unbootable. The registry is not for boobs, or even casual users.
They should stay out of there unless they
have take precautions, like saving an image backup of the OS
partition(s).
Do you save an image backup to restore the OS back to the
exact same state as before before every registry edit should you do
something untoward in the registry?
You might be perfect, but I and
others have occasionally thought what we were looking at is where the computer is making changes only to find out we changed something else.
When you perform a delete in the registry, there is no undo function.
Say you thought you were pointing at AppPaths, and wanted to delete a
subkey for a program. Instead the AppPaths entry was hightlighted when
you hit Delete. Poof, there goes all those AppPaths entries. There is
no undo. If you didn't backup beforehand, those entries are toast
forever. That's one explosive shovel.
An example is Microsoft didn't build in a way to open up any desired document just by typing a single word like "family" to open "family.xls".
Family.bat in the PATH-directory with the content:
start family.xls
You make an entry in the registry, I make an entry in the
PATH-directory.
I think you see differences where no differences are.
It's
just a matter of preferences where you want to store the
information.
The registry is a global data base which is manipulated
by many programs. My PATH-directory is fully under my control,
no other program makes any changes nor can my changes affect
other software. Functionally it is something like a second
private registry which can't interfere with the rest of the
system. I can transfer it to an other PC without the need to
first extract it from the global registry and then import
it on the new PC.
I also install, if possible, portable versions of software
which don't make any entries in the registry but store all
information in ini files in the program directory. This way
you can easily copy it to an other PC (without an installation)
or directly use it from an USB stick on any PC.
You can also store all your writings in a single global
.doc file in the Windows directory and just specify the
pages to print if you want to print one of the letters.
I prefer to have a separate file for each letter in
a user defined directory.
An example is Microsoft didn't build in a way to open up any desired
document just by typing a single word like "family" to open "family.xls".
Family.bat in the PATH-directory with the content:
start family.xls
You make an entry in the registry, I make an entry in the
PATH-directory.
I'll give you the same mano a mano challenge that I gave Vanguard.
Tell me HOW many steps it is for you to execute the family.xls in practice. I suspect it's _half_ the number of steps to do the same thing with App Paths.
Half.
I don't understand what you want to say. Didn't you say, you use
<WIN>-r family
You would exactly use the same command if you hadn't made the registry
entry but put the above batch in the PATH-directory. There is no
difference in the behavior, but only in the place where the information
is stored.
In that case, the App Paths test.exe won out over the %path%\test.bat file.
So Windows first checks the App Paths, and *then* it consults the %path%. That's useful in & of itself to override %path% on a case-by-case basis.
So Windows first checks the App Paths, and *then* it consults the %path%.
That's useful in & of itself to override %path% on a case-by-case basis.
test.exe wins against test.bat. Put a test.exe in your PATH-directory
than you will know what wins, PATH or App Path.
But I suppose, PATH will win:
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
The file is sought in the following locations:
The current working directory.
The Windows directory only (no subdirectories are searched).
The Windows\System32 directory.
Directories listed in the PATH environment variable.
Recommended: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Also I have to assume you're aware of pinned shortcuts, although we
all know many people have a desktop full of them, I assume yours is
clean so that only a small number of shortcuts are pinned to your
taskbar currently.
and you have to be familiar with all the subkeys under the
AppPaths/<prog> subkey.
App Paths is no more complex than the %path% is and you can save it once inside the registry as a Favorite so you don't have to look for it again.
For me, only the stuff I want to put in the App Paths go into the App
Paths sub key. Mostly those I wrote myself. Mostly files I use a lot.
Mostly directories I use a lot.
If something is already in the %path%, I don't bother putting an App
Paths sub key for it unless I use it so much that it's more efficient
to use the App Paths but that's what the Windows menus are for.
So my App Paths is mostly just for "my things", and not for everything.
For example, I use a stream capture program called Jaksta, but I don't
like how it leaves behind on its exit a bunch of data that gets reused
in the next session of Jaksta. It's for recovery, like a resume
function, but I don't want it. I can run commands after the program
exits in a batch file to cleanup after its exit (make it pristine
again). Can't do that with an AppPaths entry.
How do you *start* that Jaksta program?
I'll bet it's more steps than starting it using the App Paths sub key.
That's not true. It means you don't understand App Paths.
You really need to understand it before you say what you just said.
The App Paths subkey definitely does things the %path% doesn't do.
In fact, that's why it exists.
I'm not even going to respond to that given you clearly don't understand
how teh App Paths subkey works (see above where it's clear you don't).
You're not the one programming the spaghetti as to what is allowed for
its eating utensil.
Call me confused.
Oh, by the way, all this registry key "stuff" is moot unless you are
logged under a Windows admin-level account.
I'm not sure why you say that as I've been using Windows since Windows
95 and I have no problem with Windows 10 as a use (with administrator privileges) but I don't use the PC any other way and neither do most
people.
If you're dealing with a company computer, don't mess with the
registry.
Guess you've never created restricted accounts for users that you
don't want fucking up the setup.
I'm not advocating messing with the registry if you don't own the
computer.
BTW, I could easily set up an App Paths subkey to "disable" and
"enable" the updates at the typing of a single command, while you'd
probably set that up using the %path% which is fine.
No, I just disable the Mozilla Maintenance service. However, Mozilla is
rude. If I visit menu -> Help -> About, Firefox will look for and
install updates although all I wanted was the current About info. So,
after disabling the service, don't visit Help -> About.
It was just an example.
If you don't want to use a rake, you can use a leaf blower instead.
Both do the job but each is different.
Sorry, I don't see that. In fact, the more you're in the registry,
the more likely you'll fuck it up.
You need to take up your grievances with Microsoft, not with me.
They should stay out of there unless they
have take precautions, like saving an image backup of the OS
partition(s).
Why are you dumping all your grievances about Microsoft on me?
Your entire argument is that you don't like the registry?
When you perform a delete in the registry, there is no undo function.
I haven't corrupted a registry in two decades.
I just want others to know about the App Paths subkey. And I've
accomplished that.
It's only after I rename the App Paths "test.exe" to something other than "test" that the %path% wins out over my App Paths in that specific test.
I'm a bit of a neat freak. I don't like messes. That means not having
1 tier to the Start menu, but organized in folders for category of
programs, and subfolders under there for each program. I've seen users scanning their eyes up and down in a long Start menu trying to find an
entry.
There is now a search (just start typing when the Start menu is
display) but that requires you remember the first character(s) of the
entry to find it in a results list from which you pick the one you were looking for. It's still better than having to scan a mess of 1-tier
entries.
There is now a search (just start typing when the Start menu is
display) but that requires you remember the first character(s) of the
entry to find it in a results list from which you pick the one you were
looking for. It's still better than having to scan a mess of 1-tier
entries.
I didn't know I could do that. Thank you!
I'm a bit of a neat freak. I don't like messes. That means not having
1 tier to the Start menu, but organized in folders for category of
programs, and subfolders under there for each program. I've seen users scanning their eyes up and down in a long Start menu trying to find an
entry. There is now a search (just start typing when the Start menu is display) but that requires you remember the first character(s) of the
entry to find it in a results list from which you pick the one you were looking for. It's still better than having to scan a mess of 1-tier
entries.
I've tried pinned shortcuts, but don't like them. Consumes realestate
in the Taskbar even when the programs are not running. There is an
indicator showing if a pinned shortcut has a running instance of that
program (it's a tiny indicator, like a blue bar along the top), but I
dislike having my Taskbar polluted with shortcut icons for apps that
aren't even running.
I have a 2-row Taskbar. Bottom row is for toolbars (folders) for: QuickLaunch (emulate the old QuickLaunch toolbar), web browser, communication, info & games, security, tools, address bar. The 2-row
setup also makes the systray bigger, so I get more clock data (time, day-of-week, mm/dd/yyyy), and 2 rows for systray icons (but I still hide
many of them, just show the most used). Got rid of the Search box since
it is superfluous. Just open the Start menu and start typing to get the
same search results. The top row of the Taskbar is *only* to show
currently running programs. I also have the Taskbar configured to group icons for the same program, and use the popup thumbnails to pick which
in the same set on which to focus. I've played off and on with the
auto-hide option, but found too many programs don't resize when the
Taskbar is unhidden resulting in the bottom portion of the app's window getting obscured by the Taskbar, so I just stick with always-show for
the Taskbar.
If that level of organization is not sufficient, I will use the virtual desktop manager to group windows in a screen, like web browsing in one desktop, coding in another desktop, writing letters in another, playing
a game in another, and so on. Windows 10's virtual screen manager is sufficient for me. Before that I used Dexpot. There have been times I wanted multiple monitors, but multiple desktops is good enough, so far.
Pinned shortcuts to the Taskbar is for users that don't mind clutter.
Instead of pinning shortcuts to the Taskbar, I have shortcuts in
toolbars shown in the bottom row of a 2-row Taskbar. I can have a hell
of lot more shortcuts in toolbar than pinned ones in the Taskbar. In
fact, I purposely squash some toolbar to show a right-ward
double-chevron to popup a list of more shortcuts that are normally
hidden. For example, in the web toolbar that is squashed down to show
only 1 icon (for Firefox), the chevron that displays the popup list
shows: Firefox (private), Firefox (safe), Kill all Firefox, No Proxy, Microsoft Edge. There used to be more, but the list got pared down.
Taskbar toolbars are a far better solution to shortcut access than using pinned shortcuts.
and you have to be familiar with all the subkeys under the
AppPaths/<prog> subkey.
App Paths is no more complex than the %path% is and you can save it once
inside the registry as a Favorite so you don't have to look for it again.
Okay, let's test that claim. You already know the subkey under AppPaths
has the syntax <progname>.exe. Under that subkey, what are the possible
data item names and values? There can be more than just the "(Default)"
key defining a path to the program. There can also be a PATH data item
with a path value. What's the difference between (Default) and PATH
data items? What other data items may be defined under the <progname> subkey? What are the SaveURL and UseURL data items for? How about the
data items that are unique to a program? What are the sub-subkeys, if
any, under the <progname> subkey for? Maybe they define multiple
protocols supported by the program, or other arguments.
I mentioned there is also the Applications registry key which has a
similar purpose to the AppPaths registry key, except the Applications
subkeys can have more data on identifying the program, and its
attributes or arguments. I gave the MS article mentioned how
Applications has more attributes than does AppPaths. Here it is again
(with a pointer to the section on the Applications key):
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration#using-the-applications-subkey
Do you have that document memorized, so you know how to properly define
the <prognam> subkey along with all the data items that are appropriate
for each program?
For me, only the stuff I want to put in the App Paths go into the App
Paths sub key. Mostly those I wrote myself. Mostly files I use a lot.
Mostly directories I use a lot.
AppPath entries cannot point at folders.
You're not using AppPaths to
specify how to find all executables (and AppPaths never has done that
even with all installers). It's up the installer as to whether or not
it adds an AppPath/<progname>.exe subkey. For you, you're just adding a
few AppPath subkeys for some of your programs. However, you're still
editing the registry. regedit.exe is not a safe tool for editing the registry.
There is no undo. If you delete something, it's gone forever. If you
make a mistake in the registry, you'll have to restore from an image
backup (you cannot individually restore the registry files since even
admin users won't have permissions), or always remember to export the registry (or, at least the parent key under which you intend to edit) to
save a .reg file that you can use to restore back to before your screw
up. When editing the registry, all changes are immediate. Some
changes, like under HKU, require you to logout and log back into your
Windows account to effect the changes. When Windows loads, it reads the
HKLM and HKC hives, and when you log into a Windows account the
HKU/<sid> hive is read. The registry is read from files, but stored in memory for fast binary access. Registry API calls are against the
memory copy, but editing is against the files, so you need to get the
files to overwrite the memory copy. Sometimes F5 (refresh) will work,
or exiting the registry editor which does the refresh. Yet sometimes
you have to logout and login, or even restart Windows, to effect the
changes. The biggest danger to editing the registry is the lack of an
Undo. No matter how much anyone professes to be an expert or uber-guru,
we all mistakes, like deleting the wrong stuff. Editors accomodate our mistakes by having Undo (and often multiple undo through a history
feature). No undo when registry editing. Oops! Shit!
With editing a .bat file, you always have Undo (Ctrl+Z) to get back what
you deleted. And nothing is effected until you later run the batch
script.
If something is already in the %path%, I don't bother putting an App
Paths sub key for it unless I use it so much that it's more efficient
to use the App Paths but that's what the Windows menus are for.
The installer will decide what to do. It can: update the PATH settings (sysPATH for global reference, or userPATH for per-account access),
create a shortcut with "Start in" specified to change to that as the
working directory, add an AppPath or Applications entry, a combo of
those, or none of them.
There is also an order to scanning the aggregate PATH envvar. sysPATH
gets used first, then userPATH. That is, the string is concatenated as sysPATH + userPATH. If you don't specify the file extension for an executable, and .exe in sysPATH gets used first before the same-named
file in userPATH. That's why, for example, I add C:\Batch at the head
of sysPATH instead of in userPATH. I want my batch files by the same filename (but with .bat extension) to get used before any .exe by the
same filename found farther down in sysPATH or down in userPATH. I may
want a .bat file to override an .exe file. I might specify the
extension (and have gotten into the habit of always including it) to
make sure which file I actually want to run, but sometimes I forget to
add the extension, and want to run jmr.bat instead of jmr.exe. Both can
be found in the aggregate PATH envvar, but the \Batch folder in PATH is before the folder for JMR. Sometimes I want something differently setup
for an executable by using a batch file, they have the same names, both
are executable (.bat and .exe), but I was the .bat to be found before
the .exe when they have the same filename. This works because AppPaths
is used last to find an executable.
- The current working directory.
- The Windows directory only (no subdirectories are searched).
- The Windows\System32 directory.
- Directories listed in the PATH environment variable.
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Shortcuts don't require a search if the Start In field is non-blank
(i.e., specifies the path).
So my App Paths is mostly just for "my things", and not for everything.
Okay, understood. However, when there are more traditional and safe mechanism, I recommend *against* editing the registry. Too dangerous.
Even self-proclaimed professionals, like you and I, make mistakes.
For example, I use a stream capture program called Jaksta, but I don't
like how it leaves behind on its exit a bunch of data that gets reused
in the next session of Jaksta. It's for recovery, like a resume
function, but I don't want it. I can run commands after the program
exits in a batch file to cleanup after its exit (make it pristine
again). Can't do that with an AppPaths entry.
How do you *start* that Jaksta program?
I'll bet it's more steps than starting it using the App Paths sub key.
Exactly. Both start up and shutdown of the app has additional steps
that cannot be specified in a single command line.
Sometimes ffmpeg.exe is left behind after exiting JMR. That is a
problem with orphaned ffmpeg process that become unresponsive. Jaksta
can't do anything about the problem. ffmpeg.org would have to fix it.
So, before loading Jaksta, I make sure there are no orphaned ffmpeg
processes that JMR might try to use, and after exiting JMR all ffmpeg instances are killed.
After editing JMR, I purge its 2 library folders and URL cache. Those
are kept across JMR sessions as a resume feature, like your computer
crashed or had a power outage, and you can start JMR later to resume
from where it got stopped. You might even deliberately stop JMR, and
want it to resume in a later run of JMR. I don't want any of that, and
the library and cache often get full of antiquated entries. I'm a neat freak, so I do cleanup after exiting JMR.
JMR also works by using a transparent proxy to monitor web traffic, especially to inject its certificate to intercept HTTPS traffic. I've
had the computer crash, or a power outage, or JMR crash which left in
place its proxy definition (Internet Options -> Connections -> LAN
settings -> Proxy server). Previously I didn't realize the proxy was
still active, but was screwed, so it interfered with web traffic. I'd
be in a web browser trying to connect to an HTTPS site, but Windows is
still defined to use JMR's proxy which is an unusable state, so I
couldn't visit any HTTPS sites - until I realized JMR's proxy was
probably the culprit, and I have to reset the proxy settings in Windows. Easier to call another batch file that was used to reset the proxy
settings in the registry using reg.exe. I called a separate batch file,
so it was usable by itself should I suspect web connects were failing
because of something defining a proxy setup.
Not anything possible using a single command line in an AppPaths
command. But this is probably an extreme case of what AppPaths is not intended to support, and probably not likely to be anything you want to
do, either. While I can work with program authors on bug fixes, I don't
want to wait until they get around to fixing the problems, especially if
the devs consider something a feature that I want disabled (oh, yes,
devs always know better what users should be afflicted with).
That's not true. It means you don't understand App Paths.
You really need to understand it before you say what you just said.
Or, I could retort that you don't understand how batch scripts can do
the same, AND can be far more robust by committing more than just
loading an exectuable.
The App Paths subkey definitely does things the %path% doesn't do.
In fact, that's why it exists.
Oh really. Then why is it the *LAST* method of finding an executable?
It is a catch-all location, if there is an applicable entry.
I'm not even going to respond to that given you clearly don't understand
how the App Paths subkey works (see above where it's clear you don't).
You would like to believe that I don't understand. So far, I've proved
more about how AppPaths and Applications are defined and used than you.
You're not the one programming the spaghetti as to what is allowed for
its eating utensil.
Call me confused.
The installer defines the AppPaths entry, if it so decides. The program
can create one, too. Different code, but each using the registry API to define or modify the same key or data items within it. However, you are
not touching those AppPaths entries, so that hazard is avoided. You are adding AppPaths entries only for your own programs, so you or your code
are acting as the installer or program managing that registry key.
Oh, by the way, all this registry key "stuff" is moot unless you are
logged under a Windows admin-level account.
I'm not sure why you say that as I've been using Windows since Windows
95 and I have no problem with Windows 10 as a use (with administrator
privileges) but I don't use the PC any other way and neither do most
people.
You use an admin-level Windows account. I cannot speak as to what
account type gets used by the vast majority of users. I do know many
users want additional security, especially against any malware that gets
past any anti-malware defense, so their daily-use Windows account is
either Standard or Guest. If they want to install software, or edit the registry, they switch from their daily user hat to logout and then login under an admin-level Windows account to wear their sysadmin hat. The
malware gets the same privileges as the Windows account under which you
are logged into. Anything you can do is also what malware can do. A restricted, standard, or guest account is not what malware wants. It
loves users that always log under an admin-level Windows account. An
easier target.
If you're dealing with a company computer, don't mess with the
registry.
Guess you've never created restricted accounts for users that you
don't want fucking up the setup.
I'm not advocating messing with the registry if you don't own the
computer.
The "company" could be the parents that own the computer, and don't want their kids easily messing it up. Unless you physically protect your computer, anyone can change anything. Kids seems to have lots of free
time to break stuff.
BTW, I could easily set up an App Paths subkey to "disable" and
"enable" the updates at the typing of a single command, while you'd
probably set that up using the %path% which is fine.
No, I just disable the Mozilla Maintenance service. However, Mozilla is >>> rude. If I visit menu -> Help -> About, Firefox will look for and
install updates although all I wanted was the current About info. So,
after disabling the service, don't visit Help -> About.
It was just an example.
If you don't want to use a rake, you can use a leaf blower instead.
Both do the job but each is different.
Your method would be to go to shed, get a shovel, rake, pick axe, or
some tool, go back into the house, and flip the inside light switch.
You make the solution much harder than just disabling a service.
Sorry, I don't see that. In fact, the more you're in the registry,
the more likely you'll fuck it up.
You need to take up your grievances with Microsoft, not with me.
Taking up an issue that drive car tars over a fire melts them is the
fault of the driver that decided to drive over the coals, not who manufacturered the tires.
The registry is what it is. And regedit.exe is what it is. And putzing around in the registry is fraught with hazard. Deny it as much as you
want, but anyone reading your contrary retort would see how inane was
any claim otherwise. Edit the registry is dangerous. Editing a .bat
file is safe.
So, let's hear your retort on which is safer and which is more risky:
- Editing the registry?
- Editing a file?
I don't care if you claim you've never made a mistake. I would already
know that was a lie. Everyone that edits the registry learns by doing,
and that incur learning from mistakes. Oh, yes, only you have never hit
the Delete key when looking at something but the pointer is elsewhere.
They should stay out of there unless they
have take precautions, like saving an image backup of the OS
partition(s).
Why are you dumping all your grievances about Microsoft on me?
Your entire argument is that you don't like the registry?
You want to avoid the obvious where editing the registry is far more
risky than editing a file. It is not Microsoft's fault that you chose
to edit the registry without no recovery available (no Undo). YOU chose
to take the risk.
Using your own garden tool analogies: It is not the fault of the pick
axe maker that you swung the tool which had it impale your butt.
I'm reminded of the idiot that sued Sears because he incurred loss of
fingers and a chunk of missing scalp because he used a lawn mower as a
hedge trimmer. His argument was that Sears was at fault for him inappropriately using the lawn mower, and the manual never said the
mower couldn't be used as a hedge trimmer.
That regedit.exe or reg.exe or .reg files can be used by a user doesn't
make it a safe tool. It's just a tool, and the user assumes the risk.
When you perform a delete in the registry, there is no undo function.
I haven't corrupted a registry in two decades.
Funny. Reminds me of a Law & Order episode where the defendent's lawyer tried to get bail dismissed, because the defendent never killed anyone before. The prosecutor argued that not killing before is not an excuse
to dismiss bail.
You saying you've never made a mistake while editing the registry
doesn't dismiss the risk that *other* following your advice would incur. You're perfect. Most users are not.
I just want others to know about the App Paths subkey. And I've
accomplished that.
I'm arguing your advice is risky to those other users, because it
involves modifying the registry by the user. There are safer methods.
There are folks that extol registry cleaners. That's okay for gurus
that not only understand the registry (and that there are only 3 real
hives, and the others are pseudo-hives that are aggregates of the real hives), and prepare for editing the registry (reg backup, image backup), realize that searches can point to entries that have nothing to do with cleaning remnants left behind after a program's uninstallation, realize
the dependencies between multiple registry entries, and so on. The tool should only be used to provide a convenience to those who already know
how to manually edit the registry the same way. Registry editing by the uneducated is dangerous, like giving someong a scapel and telling them
to go operate on someone. The tool wielded by the inexperienced and unprepared is a formula for trouble.
The same for any registry editing suggested to others when there are
safer methods: bad advice. There is no reason to recommend registry
editing when safer methods are available.
I will grant that editing the AppPaths entries is unlikely to cause catastrophic disaster to the computer. I don't like shooting at the
range when boobs come there to squirt out bullets as fast as they can
while pointing the muzzle all over the place, like at other shooters.
Yep, they know how to pull the trigger. Doesn't take much to figure
that out. Shooting someone else is not what they can handle. Yep, you
can shoot your OS by putzing around in the registry. It's okay advice,
and brings up an alternate method of pathing, but it seems something you recently discovered and feel a need to share without considering the
risk it puts to other users.
On 23.03.2023 01:50, Freethinker wrote:
It's only after I rename the App Paths "test.exe" to something other than "test" that the %path% wins out over my App Paths in that specific test.
I did only a quick testing (so I may be wrong) but as I see it:
If you use "start progname" it use %PATH% first and then "App Path"
If you use "<WIN>-r progname" it use "App Path" first and then %PATH%
The first place in the above search order it finds an executable,
it is executed (no matter whether it is a com exe or bat). Only
if there are more executable in this directory, the order is
.com , .exe, .bat
If you open a CMD window and type
wordpad
you get a not found message (because it is not in the %PATH%).
If you use
start wordpad
Wordpad is started (I suppose, because of the "App Path" entry)
<WIN>-r wordpad also starts Wordpad.
wordpadfails
start wordpadworks
Now create a wordpad.bat in a PATH-directory with the content "pause". "wordpad" and "start wordpad" now start the batch.
Whereas "<WIN>-r wordpad" still starts Wordpad.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 02:40:31 |
| Calls: | 6,666 |
| Calls today: | 4 |
| Files: | 12,212 |
| Messages: | 5,335,606 |