The only part of Win32 that does not treat backslashes and forward slashes identically is the command interpreter (COMMAND.COM or CMD.EXE).

This type of assertion is rather common but it isn't quite accurate. I'll address several related assertions I've heard so some of my points don't apply directly to what halley said.

Cmd.exe actually handles forward slashes for path separators rather well. It has a preference for backslashes but this is more subtle than some people seem to think.

And there are several APIs that don't handle forward slashes at all. These include the registry and the common file dialogues (and some advanced APIs that you aren't likely to run into with Perl). And there is at least one file path construct that doesn't work with forward slashes (the \\?\ prefix only works with backslashes and only using wide characters, which means you have to use something like Win32API::File in order to use it).

But, in practice, forward slashes work in file paths in Win32 Perl most of the time and the most common problem you'll run into if you use them is that many programs (most programs provided by Microsoft) won't interpret them correctly when passed to them on the command line. This isn't because the command shell doesn't like them. This is because each Win32 program is responsible for interpretting its own command line and most Microsoft programs only allow / to be used for command-line options not for file paths (and a minus sign preceeded by a space sometimes also works for command-line options).

So the basic practical results are pretty much the same (which is probably why this meme survives well): You can almost always use / instead of \ for file paths in Win32 Perl. But if you use a file path in a command-line argument (such as with system or qx//), almost all programs will handle \ (some cygwin program don't handle \ quite as well as /) while many won't handle /. So if you don't know what program you are running, you should switch / to \ to be safe.

                - tye