I'd imagine if C:\Windows\System32 were missing from the path statement, ipconfig not running would be the least of your worries.
C:\Windows\System32 contains a large number of the executables and dynamic link libraries (DLLs) that allow Windows to function.
An entry in the system Path settings tells the computer to look in that specified location for executables and files that programs are referencing.
While it would seem that a good program would not rely on Path variables but should directly reference the location of any and every file it is dependent on, the Path statement allows multiple similar OSes to coexist on the same drive (Windows XP in the C:\WinXP\ folder, Windows 7 in C:\Win7\, etc, which would result in different and incompatible .\System32\ directories), and allows for more easy and flexible upgrading of framework files (look for the newest version of the .Net libraries in a versioned directory where they are installed rather than a central directory where they may overwrite each other in an undersireable way).
So a program looking to use the functions of Windows XP's built in zip handling would call zipfldr.dll and the OS will return the functions of that executable stored in C:\Windows\System32\zipfldr.dll. If you look through that directory, you should see many files that you'll probably recognize as common scripting commands or functions critical to the OSes operation.
I've never removed the C:\Windows\System32 entry from my path statement and I don't think I ever will (though I suppose testing this in a VM with rollback functionality shouldn't be too hard) and so I cannot say for certain what would happen if it were completely missing.
Suffice it to say, pretty much any batch script would completely not function, and the abilities of your OS would be severely curtailed.
Others have already noted how to add C:\Windows\System32 to the Path statement if it is missing, and so I'll not repeat that here. But I would not be surprised, since this is the only function you've found to be not working, if there were something else wrong here.
Best Answer
WinDiff is not a command-line tool, it is a windowed program (though it does take command-line arguments).
Furthermore, it is part of Visual Studio, not Windows. However, you can also get it in the Windows XP Support Tools.
It’s pretty easy to use, but you can get more out of it by setting the options correctly (eg: uncheck the
Ignore Blanksoption and set the editor, preferably one with a jump-to-line command-line argument).In addition, there is a good front-end for it as well as a shell-extension.