[A83] Re: CRT (was SDCC port)

To: <assembly-83@lists.ticalc.org>
Subject: [A83] Re: CRT (was SDCC port)
From: Peter-Martijn Kuipers <hbyte@hbyte.net>
Date: Wed, 29 Jan 2003 18:00:56 +0100 (CET)
In-Reply-To: <4790.63.100.91.176.1043857539.squirrel@webmail.itmom.com>
Reply-To: assembly-83@lists.ticalc.org

I agree that keeping the library in an app isn't the best way to go.
Well, a separate libraries are hell anyway.... even in Windows.....
However, I'm inclined to think that in the argumentation there should be a 
difference between 
- having an enormous amount of small libraries that get 
updated once every few time units, and of which you never know of which 
one you should get a new version..... 
  and
- having one runtime library that should be distributed with every 
C program in case the user doesn't have it, and will only be updated when 
TI hands out a new OS.

The latter would be the situation discussed..

But anyway, using apps for output on the 83+(SE) platform would be quite 
an idea. They offer IMHO enough space for a statically linked library.
And C would be a great way to write apps.....

--Peter-Martijn Kuipers


On Wed, 29 Jan 2003 corey@acz.org wrote:

> They 'key' and I stress 'key' problem with that is compatibility.
> 
> Either you keep a bad version of a library call and allow 
> compatibility or you change it and make everyone change their 
> programs.
> 
> Since this isn't a shell, there's no set grouping for each library 
> really.
> 
> This 'could' be avoided but would be a big headache if using 
> libraries in that manner.
> 
> corey
> 
> > On Tue, 28 Jan 2003 17:13:43 -0500, Gavin Olson wrote:
> > 
> >> Yeah.  Libs are a pain.  There is a generation of programs for 
> the
> >> TI-89 that require a combination of libraries, with differing 
> levels
> >> of support for OS and hardware (damn the 89's hardware rev!)
> >> revisions.  The newer generation of programs requiring no libs 
> are
> >> much easier to deal with.  Of course, the 89 has way more 
> room to
> >> waste on redundant code, too.  Perhaps you could do this:  
> When a
> >> program runs, it checks for other programs using the libs.  If it
> >> finds one, it points itself to the program with the libs and 
> deletes
> >> its own set of the libs.  This leads to problems if you delete the
> >> first program to be run on the calc, but allows you to include 
> libs in
> >> every program but only have one copy on-calc.
> > 
> > It would be easier to put libc in an app. Plenty of space there. 
> 83+
> > only then though.
> 
> 
>

References:

[A83] Re: CRT (was SDCC port)

From: <corey@acz.org>