Slashes in DOS/Windows paths (was Re: issue with ddefine on win2k3)

[Kenneth Brody]

Quoting Jay R. Ashworth (Tue, 22 May 2007 09:38:10 -0400):

> On Mon, May 21, 2007 at 07:55:31PM -0400, Kenneth Brody wrote:
> > > I'm never clear on when DOS fp will translat pathname slashes and
> > > when it won't, either...
> >
> > Well, this is the Windows version, not the DOS version.  That, and the
> > fact that MS-DOS and Windows have always allowed forward slashes,
> > means that filePro doesn't need to "translate pathname slashes".
>
> So, let me get this straight: instead of one programmer knowing when
> it's necessary to have a certain direction of slash for things to work
> right, we'd rather have 20,000 programmers need to guess?  :-)
>
> Cause, "allowed forward slashes" is open to debate.  So far as I know.

Since MS-DOS 2.0 first supported directory trees, it has allowed
either "/" or "\" as a path separator.

Now, whether or not a particular executable permitted such a filename
is another story.  For example, command.com was designed such that a
forward slash was, by default, an indicator of a flag/switch, rather
than part of a filename.  But that was only because of the way that
command.com was written to parse the command line, and not because of
anything in the MS-DOS "kernel" itself.  You could, for example, pass
either "c:/filepro/filename/map" or "c:\filepro\filename\map", or
even "c:\filepro/filename/map" to INT 21/3D to open the map file.
I believe older versions of MS-DOS would even allow multiple slashes
in the path, like "c:\\filepro/\/\filename///map" without problem.
Of course, with UNC names, that's not really supported anymore,
AFAIK.  (At least, not on leading slashes.  I just checked, and it
does take "/././/\\\\/.//\\\\/fppath" just as well as "\fppath".
It doesn't take the same thing with an initial "//", however.)

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com