LFN support:		- 1997/10/25 ska
====================================
Both the IO and DIR functions support the LFN interface of Win95. But
they are to hide this support behind the same interface for DOS and LFN.
Possibly one or more people will argue because of size etc. & how seldom
the program will be tried in a Win95 environment. OK, that's true, but
the most disturbing thing for me is that a DOS programs fails or makes
things I don't want, because it ignores the current environment. Also
note that under Win95 the longname is the primary name, the shortname is
derived from it. I'm tired of the circumstance that a DOS program saves
the shortname, then the directory moves and the shortname is no longer
valid, because at the new destination this shortname was already in use.

No question, a DOS only utility should not be overloaded with Win95 stuff,
but I guess a compile-time switch will help, in the (near) future.

Believe me, it's for your own protection! :)

The LFN support includes:
1) All functions that get passed a filename or a filename pattern in
will try the LFN API first, if that fails because this interface is not
present, they try the DOS API.
2) All functions that return a filename stick to the DOS filename convention.
3) A function to expand shortnames into longnames.
E.g.:
+ open() uses LFN by default, it gets passed the filename to be opened
+ getcwd() uses the DOS API, because it only returns a filename
+ findfirst() gets passed a filename and therefore uses the LFN API, but
returns the ffblk filled in the standard manner (though, the LFN values
are accessable, too).



SHARE support:		- 1997/10/25 ska
====================================
Share is a thing, that's cool, if the programs do support it well.
Unfortunately I'm very angry because of current implementation of the
CLib: One writes a "more"-like program using FILE* functions. No I view
a logfile and some other program tries to append some log messages. What
will happen? Well, becasue fopen() opens the logfile in SHARE compatibly
mode, the access is, of course, denied.  But that's not all, because of
the compatibly mode the other program might be interrupted into an
interactive "SHARING violation" error message.

Thinking of the times, when DOS did not know about SHARE (&
multitasking) at all, this behaviour is unacceptable. Therefore open()
does not open the file in compatibly mode by default, but with DENYWRITE
if write permissions is requested, or DENYNONE, if the file is opened
read-only.
