> On Thu, 24 Sep 1998, H. Peter Anvin wrote:
> >> According to several sources, space _is_ invalid in MS- and IBM-DOS at
> >> least. (IBM DOS Technical Reference, page 2-4; Using IBM DOS 4.0, page 23;
> >> Microsoft MS-DOS 4.0 Users Guide and Reference, pages 16 thru 17;
> >> Microsoft MS-DOS 5.0 Users Guide and Reference, pages 69 through 70) The
> >> fact that some questionable(?) process lets you create them doesn't change
> > The manuals say so, but the OS disagrees. COMMAND.COM doesn't like
> > it, though. Note that you're reading the *user guide*, which isn't
> > exactly a spec.
>
> Note all of the books referenced also have the word "Reference" in them,
> like "Technical Reference" etc. Also, I thought we were talking of the
> times the command-interpreted (command.com) _was_ the OS at least to a
> very high degree ;) But, well, there's the interrupts...
>
> However, my references clearly say no spaces even with the interrupts.
> Whether they are wrong, or whether it's just a bug in the implementation
> to allow them I do not know, and don't have a machine around to see/test
> it.
Part of the problem is that all of those references are to modern MS-DOS,
as such, and this is a misleading point of view. MS-DOS is built on top of
many layers, including what amounts to a CP/M (or is that C/PM? Ye gods,
I've forgotten!) compatability layer. I doubt those books describe how you
can invoke some file services within a .COM program by calling an
indirect function near the beginning of your segment, which is merely one
of these holdovers. You could (and can) do several things with DCBs (is
that right? It sounds right) that you couldn't do with the FindFirst and
FindNext calls, because the FindFirst and FindNext were the "new &
simplified for your convenience!" style. (Which, incidentally, didn't
include a FindCancel call, much to the consternation of everybody in years
to come.)
I'm also half-willing to bet (but only half) that those references don't
mention that DOS is willing to accept '/' as a path separator just about
everywhere (regardless of the settings that controls what COMMAND.COM uses
as path and argument separators.)
Consider it another way: if Microsoft had it's way, and MS-DOS was
considered "just a bootstrap for Windows", then for how long do you thing
people will still remember how to write DOS device drivers? How many
Windows programming references will describe this "buried" functionality?
> However, I see at least NT and Linux (patched with the patches this thread
> started from, or not) deal happily with the spaces even in basic FAT
> records. Altough "ren f f?f" -> "ff" for example. 'ren f "f f"' works.
I also seem to recall that OS/2's "metadata-under-DOS" stuff used a file
name of "EA DATA".
P.S. Any errors in this post are purely the result of my poor memory. I
assure you that I knew the correct version at some point, so just remind
me gently.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/