which.exe

Usage: which <executable> (download)

Locates a given executable in the system path and prints its location.

No reason for this except you don't need an entire cygwin installation to have little conveniences like this.

syncdir.exe

Usage: syncdir <A> <B> (download)

You give it two directories, and it copies everything from directory A to directory B (based on file dates).

One optimization involves only reading each directory listing once (makes a big difference for network drives).
Another is that the smallest files are copied first. This tends to move more useful per data per unit of time than dumb depth-first copiers. Why? Imagine a huge file sitting early in the directory tree, that's going to block your transfer. Now you have to figure out how to skip it -- pain in the ass. Sorting by size avoids this.

Examples of other options: /ext:.cpp;.h or /noext:.obj;.dll

addpath.exe

Usage: addpath <path> (download)

Modifies a variable in the registry (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path) to include your path.

Any program that's already running won't see the change, so you'd have to restart it.

Other path modifiers are either hard to use (they come with gazillion options so you actually have to study them for longer than it takes to do this with the Windows UI), or fuck up the key by not expanding %SYSTEMDIR% substrings in it and storing the result as REG_SZ. Also they don't check for duplicates and happily add your path to the search path multiple times.

Limitations of user interfaces.

I'm against user interfaces and for visualizations. I'll define the terms now. An interface is supposed to show you the whole thing and define your interaction. A visualization assumes you have the structure in your head (at least on some level of detail), and tries to show you a piece of that structure in more detail.

A visualization can have controls in it that affect the underlying thing, which, you might argue, makes it an interface. But the difference is that an interface is at the "root", and describes everything, and a visualization is a "leaf".

The reason I got to think about this is that there is not a single useful graphical programming language out there. There must be a reason for that. Actually, the reason is not hard to find. These guys waste valuable space on the screen arranging boxes. While they do that, they inadvertently engage the programmer's obsessive-compulsive instinct in a counterproductive way, making said programmer rearrange the boxes until they look good. For even the simplest problems (bubble sort) that's impossible. [If someone points me to a beautiful-looking bubble sort implemented in a visual language, I'll change this to "heap sort" to hopefully stump them for good :-)].

Supposing that you could arrange flow control boxes in a way that makes a heap sort look good, will they really reflect the true nature of heap sort, its tree-like, jumpy nature? No, that has to be visualized in the mind's eye. But the mind's eye is not an independent organ, it requires the physical eye not to be actively busy. So a graphical language actively blocks you from thinking. Here I'm presuming that programmers think visually, and I would say that's very much the case.

So, unless a direct visualization (which respects the structure of the problem) is possible, it's better to stay away from the visual stuff so as not to preclude the human from creating that visualization inside their head.