Subject: Re: tos utilities
To: None <leo@wau.mis.ah.nl>
From: maximum entropy <entropy@zippy.bernstein.com>
List: port-atari
Date: 12/11/1997 07:17:23
>From: Leo Weppelman <leo@wau.mis.ah.nl>
>
>On Wed 10 Dec 1997, maximum entropy wrote:
>
>> >  Actually getting real programs to compile in this manner would be a
>> >  lot of work.  Does anyone else think this is a good idea?  If so, i'll
>> >  persue it further.  I'd hate to do all the work only to find out that
>> >  it would never be integrated into the tree.
>
>If you manage to get it done, I'll happily integrate it in the tree. I never
>felt the urge of 'fixing' this, but if you do, feel free ;-)

OK, that's good enough for me, I'll keep working on it.  I have
several other parallel ongoing NetBSD/atari projects in progress, so
don't expect anything right away.  Stay tuned for lots of patches some
time soon :-)

>> I see no reason not to support the same type of thing in the
>> NetBSD/atari tree, except that it will take some work to get it right.
>> Most of the work would involve figuring out some minimal subset of the
>> MiNTlibs and headers, and XHDI code, that we would need in the tree to
>> support this.  Since all the required code is public domain, this
>> should not be problematic with respect to distribution restrictions.
>
>Except that most of it bears an FSF copyright I think...

No!  The XHDI specs and code are public -- Only the implementation of
df contained in the XHDI package is copyrighted, so we wouldn't want
(or need) to integrate that.  As for the MiNT library, only a few
files are GNU copylefted (or similarly restricted).  The rest is
either BSD copyright or 100% public domain.  I can say that with some
assurance, since I was the MiNT library maintainer for a while and I
worked to keep it that way.

It shouldn't be at all difficult to avoid the restricted parts of the
mintlibs, for our purposes.  I expect we will only really need a few
headers, the runtime startup, and a few modules for IO -- open, close,
read, write, dup2, and (maybe) the stdio package are likely the
majority of what we'll need.  The rest should basically be just
baggage we can throw out, since the goal is not to provide a
full-featured TOS compilation environment.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.