Message-Id: <3.0.1.32.19971029125703.007ca690@yacker.xiotech.com>
Date: Wed, 29 Oct 1997 12:57:03 -0600
To: DJ Delorie <dj AT delorie DOT com>
From: Randy Maas <randym AT acm DOT org>
Subject: Re: 971009: FileSysExt's Rev D. p2
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <199710290010.TAA28357@delorie.com>
References: <3 DOT 0 DOT 1 DOT 32 DOT 19971015163553 DOT 0069d4d4 AT yacker DOT xiotech DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

I believe I may have miscommunicated a couple of things. 

1. I didn't intend to change the copyright of, or intend to copyright any
of the material.  I meant more or less to indicate that someone (in this
case me) changed that block of code.  I am moderately aware of the attempts
to have all GNU/GNUish stuff with a clear copyright reference.  I was under
the impression that the copyright notices were placed by a script (using
copyright.cc) for consistency, and had to be within X lines of the start to
be considered clear.

2. I did not delete any copyright as far as I am aware; if I did, I
apologize.  In the case of _close.c -- I wrote that one flat out (checking
that the calling parameters matched the documentation).  I diff'd it
against the official _close.c out of consistency.  I did not intend to
place a copyright notice on it.

3.  Coding style.  I could not find a style sheet.  If there is a style
sheet, please point me to it.   Is there a preferred ident style over the
one I use?  I'll get these in order:
>Please use the same coding style as everyone else.  No spaces after the #
>Please use the same template all the other includes use.

4. Slashes & Longish file names.  My carelessness.  I'll have it proper
next time.

5.
>                       You may not replace the low-level DOS calls with
>emulations.

I'll make sure I put the DOS calls back they traditionally have been.  My
goal by have the DOS calls as FSExt (and pointing def_fsext to it) was to
make it easy to replace default file system interface (eg, with win32 or to
make plugins to use filesystem functions but have them redirected to the
host program)

6. Generic names: Ok, I'll fix this.   I'll use the suggested prefix
_fsext_ unless anyone has a better idea.    Although I want to be sure on
the _ipc functions -- I choose the name _ipc_pipe (and similar) to be bland
and unlikely (but clear what it was).

7.  Duplicate function names.   This one I am very confused on.  I checked
for the existence of _link, _lseek, _pipe, and _unlink.  I couldn't find
any documentation or code implementing them.   If I am wrong, please let me
know (and how I can prevent this from recurring).

>> @node _link, file system
>
>We *have* a function called link.  If you want FSEXT to work right,
>you have to hook that one so that programs will use FSEXT even when
>they don't realize it.  There's no benefit in writing a new API since
>we'd have to go changing all the other programs too.
>
>> off_t _lseek(int handle, off_t offset, int whence)
>> void _pipe(int filedes[2])
>> int _unlink(const char* src)
>
>Same here.

link  shallowly call _link, etc.  I am pretty sure I posted that code;
again, if I botched that let me know and I'll post the code.

8. 
>> void __FSEXT_Emu_add(__FSEXT_Function* Func)
>
>What's the point of this?  We should only be extending functions that
>already exist, not adding new ones that need to be emulated.

I tend to think the "Emu" is the most regrettable thing here and mostly at
odds with what I was trying to achieve. 

However, I was trying to address a way of extending djgpp programs (by add
on libraries and such)  for a certain type of functionality.  Let me give
the example I was concerned with.  Suppose an add-on was supporting "link"
as "symbolic" links (outside of .exe files) by simply adding items to a table:
	linked file name:real file name
Works great as a FSExt because it would be executed before the _link that
does a file copy.  (Ignoring the incompatability with programs that don't
have this add on).  It'd emulate "open" by doing a lookup and then opening
the real file name (letting whatever emulate those file operations).

Let's also say this (or these) program was also using a local RAM disk (ie
a FSExt that simulated files in memory) that also provided "link"
functionality.  The link add-on above is meant to provide functionality
only when it is not present.  As an FSExt, the soft-link would have to be
installed before the RAM disk  (or any other "link" providers) to work
properly and not conflict with the RAM disk.  My mental debate was between
"blame the victim for poor choices" and "segment the functionality."  

I'd be comfortable to remove "emu" --- and ecstatic if a better way is
found to address that example.  

Randy Maas