Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucsdhub!jack!man!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.lang.c
Subject: Re: Determining the names of device
Message-ID: <162@nusdhub.UUCP>
Date: Mon, 19-Oct-87 14:32:49 EDT
Article-I.D.: nusdhub.162
Posted: Mon Oct 19 14:32:49 1987
Date-Received: Tue, 20-Oct-87 21:32:31 EDT
References: <122@nusdhub.UUCP> <155300012@mcomp>
Organization: National University, San Diego
Lines: 53
Summary: I don't see Why..?

In article <155300012@mcomp>, wnp@mcomp.UUCP writes:
> That is why all these "convoluted methodologies" are of interest. If
> the matter is SOOOO simple, why does MS-C, which frequently
> demonstrates greater knowledge of DOS than is available to the public, 
> not make the distinction between files and devices when using stat()?

Ask Microsoft why, but ill bet it has something to do with the facts
about device drivers under MS-DOS [A few of which are mentioned below]

Since the special character devices are not part of the file system,
MS-DOS does not handle them "correctly" according to the provisions
of stat.  Most of the returned valuse are irrational according to
the MS-DOS structure.

Since MS-DOS is not multi-tasking, barring the use of windows and such,
and the proper use of any character device requires you to open it
in order for it to be defined in your environment [In multi-tasking
extensions to MS-DOS you MUST open the device even if you intend
to then bypass the device driver and "do it yourself"] I dont see the
harm in opening any device [or file] "for reading" no matter what you
intend to do with it.

The NULL device is not _NOT_ at all garenteed to be at the head of
the device list.  The ORIGINAL NULL device usually is, by convention,
but any any device can only be opened once when sharing is involved,
and more than one device may need NULL.  That's why there is a bit
in the Device Status Word [Which the standard says you must NEVER
set when writing a device driver] which marks it as the "Current
NULL Device"

The quickest rule of thumb  for determining if the device is
a character device is:

1) If it's open, use ioctl()
2) If you only have a pathname, look for a colon.  If there is no
	colon, it is probably supposed to be a disk file.  If there
	is a colon, and it is the second character it IS a disk
	file.  If the colon is not the second character it IS
	either a valid character device, or an invalid file name.
3) If you really want to be shure, open it in compatibility mode
	as read only.  If it opens, it exists and is valid, and then
	use ioctl() to varify it's device/file standing.

The only case I am not SHURE of beyond any doubt is the "no colon
at all" as this has bounced around several times. [i.e.colon is/is not
required to open character devices.]

In most of the "generic MS-DOS extensions" traversing the device list
is not at all reliable.  [The first example of this that comes to mind
is MS-DOS running under unix do supervisor, in which you can't depend
on contiguous device driver lists.]

Robert.