Actually, many, many MS program don't handle forward slash as a path separator (from the command line) and even some of the default "dialogues" don't (so if you get an "open file" dialogue, you probably can't use /).

cmd.exe does handle / as a directory separator (command.com doesn't), but that only matters when using / in the command path, not when using / later in the command line. This is because command-line processing is done separately by each executable (because DOS gives programs their command line unlike Unix that gives programs a list of their command arguments).

So, in particular, "link" needs to interpret / on the command line to find the options you are giving it. But testing shows that "/libpath:c:/perl\lib" works since "link /libpath:c:/foo/nologo" still prints the "logo" (while "link /libpath:c:/foo /nologo" doesn't).

Also, there are some advanced things that only work with \ and/or in Unicode. For example, Registry keys and values can contain / but can't contain \ (so you can't use / as a path separator for Registry keys). And you can't disable "path parsing" by putting "//?/" in front of the path to the file you are trying to open. So if you want to open a file who's path is longer than MAX_PATH characters, you have to preceed it with \\?\ in Unicode (and use the "wide character" interface).

The thing is now whether or not link is smart enough to figure out that / is also a directory seperator.

CU
Robartes-

link doesn't need to figure out anything - if it passes that path verbatim to the OS I/O calls, the right things will happen.

Makeshifts last the longest.