Makeshifts last the longest.

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).

        - tye (who wishes the escape character for Per's ' was ' not \)

I didn't know that, thanks! (Been a while since I've done any serious work on Win32 systems.)

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.