Newsgroups: net.micro.mac
Subject: LighspeedC -- A Review (long!)
Message-ID: <848@harvard.UUCP>
Date: 9 Apr 86 03:24:09 GMT
Article-I.D.: harvard.848
Posted: Tue Apr  8 22:24:09 1986
Date-Received: 9 Apr 86 10:19:00 GMT
Organization: Aiken Comp Lab, Harvard
Lines: 173


There have been a couple of postings about the new LightspeedC
compiler, and since I recently ported a large (2200 line) program from
Aztec to that environment, I figured that the net might be interested in
my reaction.  I had been using Aztec for about a year, and my familiarity
with Unix-style utilities and the speed of the Aztec compiler made me
very satisfied.  One week of Lightspeed has convinced me to switch: the
environment is superior, both in design and execution, and the compiler
brings new meaning to the word "fast."  I have some benchmarks below, but
they only tell part of the story.  The best part of Lightspeed is its
"feel" -- a whole range of features make it effortless to use and seemingly
even faster than the numbers would indicate.

Environment
===========
Lightspeed is one big application, about 170k on the disk, and
requires 512k to run.  The compiler deals with programming tasks using
a data structure called the project.  Projects are basically lists of source
files and libraries included in the program.  A window with the names
of these files is always on the screen.  The visual representation of
the project makes some tasks more natural, as well as fast.  The
segmentation, if any, of the program is represented by the grouping of
the names in the window: to change it you just drag them around.  This
is much nicer than long linker commands.  To edit a source file you 
just double-click on a name -- avoiding both the typing of Aztec and the
SFGetFile dialog of other systems.  The project also contains the object
code produced by compiles (so no .o files) and other information to speed
development.  Make dependencies are generated automatically, i.e. it checks
source files for #includes and keeps track of when you change what.  This
isn't as powerful as Unix make, but it's good enough for most tasks and
best of all, it's totally transparent.  One cost of using the project
format is disk space: the project file for my 76k program totaled over
200k; by contrast, the .o files produced by Aztec for the same program 
totaled 86k.
The editor is included in the single application: it is comparable
to MDS Edit, with the one significant plus of multi-file search.  This
eliminates much, though not all, of the need for grep.  The integration
between the compiler and editor is very close.  When the compiler finds
an error, you are popped into the editor at the line of the error.  
Compiling open files takes into account changes since your last save
and the Make utility marks the file as not compiled if you then quit
without saving changes.  The editor is quick with scrolling, does not
mess up with large cuts and pastes, and handles at least a dozen open
files.  The one drawback to the close integration of the system is that
you could not easily use another editor if you wanted.  Fortunately, the
included editor is good enough to diminish that problem.
Programs under development can be run from within Lightspeed,
through some sort of executive.  The program run is real machine code,
and runs as fast as a stand-alone version, but when you quit you return
to Lightspeed with your project still open.  To build a stand-alone
application file takes a little while (for my program, 1 minute), and
yields a standard Mac application.

Speed
=====
Think is really pushing the speed of the compiler, and rightly
so:  while not quite as impressive as those advertised by Think (reasons
below), my benchmark figures essentially confirm the hype.  Here's what
I got compiling a 2200 line program, broken into 16 source files:

Configuration: 1Mbyte Mac Plus, with one 800k disk drive and one 300k
Ram disk.  In both cases, all system files, source, and libraries were
on the floppy, include files and the compiler/editor/linker were on
the ram disk.

Times are in seconds, turnaround refers to the time necessary to recompile,
link, and run the program after changing one typical source file.

Aztec ver. 1.06gLighspeedC Beta

compile all files:1320550
link/run:12726
turnaround:25876
code size in bytes:7079276860

This benchmark may or may not be typical.  I believe that on
a hard disk system, or if the source and project files were on ram-disks,
Lightspeed's edge in compile speed would be even greater.  Most of the
time cited above was spent reading source and writing output to a slow
floppy: the actual compilation is over 250 lines/second (as displayed
by their line counter).  Think claims that it takes 2 minutes to recompile
Lightspeed in itself (1 Mbyte source) on ram disks, and I believe it.
On the other hand, using faster io devices would help Aztec in the link
comparison, since Lightspeed links in ram (for my program, in 1.5 seconds!).
As for code size, I think that the difference may be due to Lightspeed linking
in more stdio code than I need: I'll look into that when I get the release
version with source for libraries.
So how does Lightspeed do it?  There are a number of reasons.  Since
it's one program, it doesn't have to repeatedly load the compiler.  Most
of the linking is taken care of at compile time (the project document makes
a global symbol table possible) and libraries are linked only when you add
them to the project, not at every make (which makes sense, as they probably
didn't change).  The compiler does everything in ram, with no temp files,
and I'm sure that helps a lot.  Also, there is no cascading error recovery--
the first error sends you back to the editor -- although I don't think that
won them a lot of speed.  On the other hand, the compiler checks for the
number of arguments to toolbox calls, does all the pre-linking, and still
beats Aztec hands down.  So it's very fast, but they seem to have made it
fast the old-fashioned way: painstaking optimization.
The best thing about Lightspeed's speed is the way it changes your
work habits.  With Aztec I was loath to recompile the program with just
a single change, and having to alter a global include file (and thus
trigger re-compilation of every source file) was a prospect to be met
with dread.  Lightspeed makes it easy to make small changes and then see
what happens.  There's even a "Check Syntax" option that rivals the speed
of an interpreter (since it doesn't write output) making it easy to check
your work during a long type-in session.

Bugs
====
Alas, there are always bugs.  One that I found is particularly
insidious for programs using floating-point, and apparently was not
fixed before shipping.  An error in the way casted expressions are
processed results in the following:

#define CONSTANT any-integer

int foo;

if ((double)foo == (double)(foo-CONSTANT))
printf("Bug!");

printing out a message.  The bug manifests itself with implicit casts
also -- x/foo evaluates to the same thing as x/(foo-CONSTANT), where
x is a double.  This bug is serious, and Think was very attentive when
I called it in.  A week later, however, I called back and it hadn't
been fixed; meanwhile the compiler is shipping.  Anyone contemplating 
using Lightspeed for floating point should be aware of the problem, 
and perhaps wait for an update.  The work-around is to cast the int 
to a double before the arithmetic, a small loss in performance and 
a large loss in programmer convenience.  I'm still looking
for the last occurances of such expressions in my code.

Portability
===========
Lightspeed handles standard K&R C, with the following differences/
features of note:

Structure passing by values
Argument # checking on toolbox calls
No inline assembly -- must link in assembler output separately
"pascal" keyword for pascal-style routines (just like Aztec)
Explicit string conversion with CtoPstr and PtoCstr (like Aztec)
16 bit ints, 32 bit longs and floats, 80 bit doubles (uses SANE)

I ported my program in two evenings with occasional glances at
the documentation, all the while learning how to use the Lightspeed system.
The biggest hassles were renaming include files and dealing with points.
Aztec provides a macro to pass points to LineTo and MoveTo (for example)
by casting them to a long.  Since Lightspeed checks number of arguments,
it had to be replaced with a macro that separates a point into its 
structure elements.  The documentation is written toward users of other
Mac C compilers (Consulair, Megamax, and Aztec) and points out many of
the differences.  All in all, the manual looks good although I didn't need
to look at it much.

All in all, I think that Lightspeed is simultaneously the cheapest
and best Mac C compiler available.  Think has to fix the floating point
bug, and it would be nice if they provided a means of converting project
files to other formats (there is an MDS => Lightspeed conversion utility)
but otherwise it looks great.  If the advertised Quicksilver Pascal compiler
uses the same technology, Apple's Workshop could have serious competition
before it's even released.

Jim Matthews
matthews@harvard

The above views are mine, and may or may not reflect those of my employer
and Harvard University.

I'm sure that LightspeedC and Quicksilver are trademarks of Think Technologies,
that Aztec is a trademark of Manx Software, and that MDS is a trademark
of Apple Computer Corporation.

 6-Apr-86 10:42:33-PST,8755;000000000001
Return-Path: <INTMET@A.BBN.COM>
Received: from A.BBN.COM by SUMEX-AIM.ARPA with TCP; Sun 6 Apr 86 10:42:24-PST
Date: Sun 6 Apr 86 13:02:53-EST
From: INTMET@A.BBN.COM
Subject: LightspeedC, a rview
To: info-mac@SUMEX-AIM.ARPA

LightspeedC, a new C compiling system for the MacIntosh, is a delight.

The product is an integrated application building environment.  I see
the product as broken into these pieces (show here with a quick
synopsis):
   -> A compilerFastest, Bestest of the current Mac products.
   -> A project managerA wonderful idea, beautifully executed.
   -> An editorNothing special
   -> A set of librariesVery complete, and very well documented.
   -> A converter for MDS .rel files
I haven't used it (a trap door?).
   -> A manualvery good, very complete, hype/chatty
   -> A set of standard Mac Developer's tools:
         - ResEdit, RMaker, MacBugs, etc.
   -> Mac Interface           Very standard

I'll leave benchmarks to people who take them seriously, I for one
despise them.  The entire system is without question the fastest most
usable way to develop applications for the Mac, that I have used.  It is a
much faster way to build stuff than the other Mac C environments.  It is
not as fast a Vax11/780 with 4.2 Unix on the weekend.

The most innovative aspect of the system is the project management,
auto-make, linking aspects.  First, let me talk about some of the more
simple stuff.

Compilers for micros aren't generally very good.  This one is much
better than most.  It sure is fast.  They must of bit-diddled it for
quiet a few late nights.

The compiler supports a number of things to ease living with the Mac's
pascal heritage:  pascal strings ( "\PPascal String" ),  functions
who's parameters are will follow to be pascal conventions, and line
Tool box traps.  You seem to be unable to add new traps to the system.

Struct's maybe passed by value.  They are unique among the Mac C
compiler's in choosing to pass Points by value.  This makes converting
to Lightspeed quite a chore.

The editor is a disappointment.  It is simple and Mac like.  It lacks
undo.  Unlike a lot of o8`%5A1h
*%Q=IM1JQ:MU%1Q:%Q!"!@care it takes to get a fast/large file
editor on the Mac.  For example
text inserted into the middle of a huge file goes in smoothly.  You may
set the window font as you like.

There is magnificent support for searching.  Egrep style patterns (and
replacements) are supported.  This is very nice.  It isn't awk/sed but
it will do.

Since the editor is integrated into the single application your stuck
with it.

The libraries are very complete with about 200 functions.  They support
the entire range of string functions, printv, stdio, etc.  These are
well documented in a classic unix manual style.

It is possible to write assembler code using the MDS assembler, and
then convert the MDS libraries into their project manager's formats.
MDS isn't included so you'll have to spend extra if you want to do
that.

The system can produce most all the various flavors of code resources
that are common on the Mac.  I was unable to figure out how to produce
a package without having MDS, but who makes packages anyway?

The manual really shines in some places.  The documentation for MacBugs
is wonderful.  The discussion of the subtle issues in desk accessory
writting is, having had to figure this out myself once, delightful.
The manual starts with a lot of hype, which is forgivable since they
are obvious very proud of their product.  There is an epilogue, 
it was written by a recent cash paying attendee of some Science
Fiction Fairie.

The manual contains a very detailed specification of their
implementation of C, something that is lacking from most all C compiler
documentation.  A detailed set of library documentation is makes the
buyer feel confident that they are careful craftsmen.  Against that
background I feel I can complain: there needs to be detailed
(reference manual style) documentation of the project/command
structure of the application.

The Mac Interface is very standard, which is good.  The dialogue boxes
lack the care of a good graphic designer.  Undo is not supported,
except in desk toys.  The about LightspeedC...  command is a rush.
The down side of their very standard Mac interface is, if you
use Excel a lot you get very enamored of Microsoft's extensions.

I have had a good deal of trouble using the application on my
HFS/HD20/Fat-Mac.  They have been very helpful.  They assure me it was
extensively tested on many configurations so they are are confident it
must be a problem unique to my situation.  I hope this is what Consumer
Reports might refer to as a correctable cosmetic flaw.  I have owned my
copy for three days.

Think Technologies is the company that build MacPascal.  LightspeedC is
not copy protected, each sale apparently has a unique serial number.
(Note that MacPascal isn't copy protected anymore either).

The product was built with one goal, get the feel of an interpreter in
a linking/compiling environment.  They succeeded via these devices:
   -> Link on the fly using jump tables.
   -> Have a very fast linker.
   -> maintain a currently linked application with associated data:
        call this a "project."
   -> Have a rarely used "build step" that removes project info and
removes extra jump table entries.
And of course about a dozen other ideas to hold it all together.

Project provide a way to expose the large scale structure of your
application.  In C the largest construct is the file (include or
source).  A project consists of:
   a set of input parts consisting of:
     a set of source files,
     a implicit set of include files,
     a set of libraries,
   a target kind of code:  ( application, device driver, code resource... )
   a set of options:
     searching options: ( case sensitive, wrap around, ... )
     confirm options: ( confirm save, ...)
     compile options: ( MacBugs symbols, profile )
   a dependency graph between sources
     - a model of uptodateness in that graph
   a symbol table of all external symbols
   a set of loaded/compiled object code
 
The dependency graph allow them to automaticly batch compile everybody
effected by an edit to any file.  This isn't as complex a concept as
the unix Makefile.  Each object has only a single flag associated with
it, and only a single, wired in, operation is known that will remove
that flag.  Only the include file dependency graph is known to
understood by the program.

The user may turn the flag on or off by hand.  The major use of this
feature is to amaze you friends with how fast it compiles your entire
system, but it is also used to inform Lightspeed that you changed
something behind it's back.

Upon request, in a manner analogous to unix make's use of file dates to
infer uptodateness, the flags may also be brought into sync with the
filesystem's file dates.  The purpose of this is to inform it of changes
you make to files outside the Lightspeed system, or via other projects.

Apparently the only thing to do at "link time" is to check for
unresolved symbols.  If you edit a file, recompile, link, and launch it
only takes a few seconds.  This is usually done with the single
key stroke cmd-R or "Run" command.  When you quit from your application
you will fall back into LightspeedC, i.e. it install's itself as the
shell when you are in the debug loop.  The slowest step of that loop is
returning to Lightspeed (narc).

Libraries come in two types and three flavors:
  Project libraries:
    - other projects,
  Real libraries:
    - projects that have been converted to libraries, and
    - libraries converted from MDS .rel libraries.
Objects in real libraries are loaded only upon request.  Apparently you
can only convert MDS .rel files to Lightspeed libraries, not visa-versa.

The unix power user will be frustrated, since this isn't make, and
there is no way to add additional operations.

What is wonderful about the Mac is that about every few months somebody
brings out a product that is delightfully innovative.  This is one such
product.  The importance of a fast compiler and linking on the fly has
always been under-rated.  If you write in C for the Mac it is well
worth the $175.00, list price.  If you are patient then  you can wait
for the discounters to move in.  You might do well to wait a month for
the first wave of cosmetic fixes.

  LightspeedC
  Think Technologies, Inc.
  420 Bedford St.
  Lexington, MA 02173         Customer Service: (617) 863-1099

     - ben hyde, cambridge mass. 
[ From Delphi - Jeff ]

Name: LIGHTSPEEDC CONVERSION SAGA
Date: 8-APR-1986 14:09 by PEABO
 
This is the story of my experience with converting a medium sized application
program from the MANX Aztec C development environment to the LightspeedC
development environment from THINK Technologies, Inc.

-------------------------------------------------------------------------
This is a report on the conversion of a medium sized application program
from the MANX Aztec C programming environment to LightspeedC(tm) from
Think Technologies.

I'm not going to go into detail about LightspeedC since you can find out
about that from other sources.  However, to summarize, it is an interactive
development environment for C on the Mac which emphasizes quick turnaround
time.  It collects the files used in building a program into a 'project',
which is a data structure analogous to a UNIX-like makefile and all the
object code and libraries used in the compile/link.  The source files are
still maintained as standard text files.  A built-in editor accesses files
and can be used in conjunction with multiple file searches, with or without
regular expression matching.  Time between closing the edit window and
launching the rebuilt application can typically be in the range of 10 to
30 seconds depending on how many modules need to be recompiled.  After the
program is debugged, an additional step is performed to produce a clickable
application module from the project workspace.

--------------------------------------------------------------

The nitty-gritty:

I received my copy of LightspeedC on Friday, April 4, and like any cautious
developer would do, I first read the manual to find out what kind of surprises
I might be in store for.  Finding none, I proceeded to install LightspeedC
on my system.  (I am using a MacPlus with an Apple HD-20.)  The manual
mentions that LightspeedC works with HFS, but doesn't go into detail about
how to install it.  They refer repeatedly to 'put this and that on the same
volume', and that does translate accurately to an HFS environment if you
reword it as 'in the same folder'.  My working configuration (after some
experimentation) looks like this:

Desktop
 AA Light            <----- folder for Lightspeed stuff, easy to click
                            from Standard File dialogs
  Compiler           <----- 96 files:  compiler, includes, and libraries,
                            including library sources for my convenience
  Demo               <----- I haven't looked closely at these
  LCRelease          <----- other misc files from the release disks
  #include catalog.c <----- a C file which includes all the .h's
  StdInclude         <----- a project file for #include catalog.c

I put the LightspeedC application in my Waystation menu, so I never have
to open the AA Light and Compiler folders when launching the development
environment.

Elsewhere in the HFS hierarchy, I created a folder with all my MANX project
stuff.  This folder looks like this:

Desktop
 Project             <----- named the same as my program, with a P appended
  Source             <----- .c's, .h's, .r and .rsrc, LightspeedC project
                            workspace, and clickable application, totalling
    about 21 files
  MANX Obj           <----- the MANX make file, .o's, and comparison copy
                            of the application, also .lnk and .sym, so I
    have something to refer back to (discard after)
  Misc               <----- some other related files I didn't feel like
                            leaving out in the Project folder
  a couple files     <----- that I want to be able to get at quickly

I might at some point decide to bring the contents of Source up to the top
level of the Project folder, since it would make the treewalking easier.

At this point I got rid of about 90 files used by the MANX compiler which I
had to leave on the Desktop of my HD-20.  Halleluiah, a clean desk at last!
(The version of MANX I am running is 1.06F and it does not function unless
the shell, compiler, linker, assembler, all utility programs, all includes,
and all source files are on the desktop in a pseudo-MFS configuration.)

So I started up LightspeedC and told it to run the project, which causes it
to ascertain that everything needs recompiling.  Kaboom!  "Include file
not found".  So this is surprise number one:  most of the include files
for the Mac managers are named differently in LightspeedC from the way they
are named in MANX.  OK, I can dig it.  It is good practice using the editor
to rewrite the includes.  Most of the names are obvious variations (such
as menu.h => MenuMgr.h), but a few require some investigation (like pb.h
=> FileMgr.h).

Then I told it to rebuild, and got surprise number two.  Syntax error.  Sure.
There doesn't appear to be anything wrong with the statement it is complaining
about.  I should mention that the compiler does not produce a list of errors
as output.  When it hits the first error it zips back to the editor and
leaves the cursor at the left margin of the line it doesn't like and an
alert box at the top of the screen saying what is wrong.  Cute bug icon.  You
click the alert out of existence, make the fix, close the window, and rebuild.

Well this works great when you are making small changes, but in the case of
a conversion, it can be a bit tedious.  (Think Technologies admits this is a
potential hassle.)  The real problem in this case though, was that the error
message 'syntax error' was not real helpful.  However, most of the other
error messages are not as obscure, so I won't complain very much.

It turned out to be a conflict between a symbol I #defined to fix a bug in
the MANX toolbox.h file.  The symbol was defined properly in the LightspeedC
include, so I took the patchwork out of my .c file.

I think the alert box ought to display the C code *after* preprocessing of
macro invocations, and with the point of the error highlighted.  This would be
a feature not found in other C compilers, and a very appropriate method of
improving ease of use.

Now we get into the interesting case:  syntax error on "struct Rect rect;".
Turns out that MANX does this:

    struct Rect
    {
        short top;
        short left;
        short bottom;
        short right;
        };
    typedef struct Rect Rect;

but I had been in the habit of saying "struct Rect" anyway.  LightspeedC
does this instead:

    typedef struct
        {
        int top,left,bottom,right ;
        } Rect ;

so the only valid way to use this is to say "Rect rect;".  OK, so I do
another multi-file search and destroy.  The multi-file stuff works very
well, by the way, and will probably encourage me to split up my programs
into smaller source files.

(I'm not real enthusiastic about the use of "int" in these .h files.  I
always use "short" or "long".  MANX and LightspeedC both use "int = short",
but I also develop programs for the VAX, which uses "int = long", and there
are other Macintosh C compilers that use "int = long".)

Next I ran into some very minor differences in the spelling of field names
in structures, and a major difference in the way the ParamBlock is declared.
In MANX, the fixed part of the PB is declared and there is a giant
union of the variants for file, volume, etc.  LightspeedC cuts out some
of the excess structure, so the intermediate field names need to be
changed.

Also, since LightspeedC supports passing of structures, I don't have to use
the pass() macro to convert Points to longs in calling sequences.  Rather than
edit out the pass()'s, I using a #define to make pass() do nothing.  I'm not
dumb -- it is a LOT harder to put the pass()'s back in than to take them out!

Somewhere along the way I needed to do a multifile search of the standard
.h files.  No go, they aren't listed in the project, so you can't search
them.  (Later I did see some of them listed in the project box, so there is
more to this that I understand just at the moment.  It probably depends on
the state of the project, such as whether a given .c file is open or not.)

It was at this point that I followed the advice of the manual and created
the StdInclude project referencing "#include catalog.c".  Now if I have to
search the system .h's, I close the project I'm working on, walk the HFS
tree over to my compiler folder ("Aha!" you exclaim, "that's why he called
it 'AA Light' on the Desktop.")  Well, this is dandy, but it takes too
damn long to get from the context of the error to the StdInclude project,
and I find I lose my train of thought seriously, even though it's only 10
or 15 seconds.  Too many mouseclicks in the process.  There should be a
way of opening a second project read-only for the purpose of searching, or
of opening a folder of files as if it were a Project list.

Let me also mention at this point that the editor is very good, but has a
few peculiarities.  For one thing, if you do a search and replace and click
Replace Again too many times, it winds up pasting extra copies of the replace
string into the text right after the last legitimate one.  This sounds like
a bug to me.  The other will affect only users familiar with MDS Edit -- the
trick of selecting a bit of text and invoking the Find dialog to get the
search string pasted from the selection does not work.  Instead you have to
Copy and Paste into the Find dialog.  Tabs and return characters are easily
incorporated into find/replace strings though.  Just hold down Option while
typing tab or return.

OK, back to the saga.  After a bit of work, I got clean compiles all around,
and of course the link failed.  I should mention that I had already segmented
the code to match the way I had done it with MANX.  This is very easy, because
the project list window shows the the segments of the program by drawing
horizontal rules between segments and you simply drag the source module names
around to associate them with specific segments.

So I inserted a few libraries into the project.  I had to do a little
experimenting to find out which libraries contain which modules, but it was
easier (and FASTER) to just plug libraries in by trial and error and see which
symbols got resolved than to open up the book and look up the library calling
sequence descriptions to see which module each of the unresolved symbols was
in!

Kaboom!  Code segment 1 overflowed the 32768 barrier.  It seems that the
LightspeedC library is not very granular, and one of my favorite routines,
sprintf() was responsible for dragging in about 16K of code.  (Actually it is
not just sprintf() that is doing this, but you get the picture -- big runtime
library.)  So I dragged the standard I/O package off into a segment of its
own and that fixed the problem.

When the linker diagnoses errors, it leaves a list of errors in a small window
on the screen.  I suppose you can Copy the contents of this window into the
Clipboard if you need to keep the list around in a file while you fix things,
but I didn't try it.  Note the difference in philosophy:  an error during
compile is diagnosed in isolation and you are sent to the editor to fix it,
whereas the link shows you all the errors it can find.  Except for during
massive infusions of code, I think this works very well.  When you are first
developing a large chunk of code, you can easily compile repeatedly to check
syntax (it takes about as long as Saving the file does).  So by getting into
proper habits, you should never be faced with repeated and annoying cycles
between the editor and the compiler.  On the other hand, having a complete
list of linker errors was essential for the rapid determination of which
libraries were needed to complete the link.

Note that all these compile and link cycles were managed by the automatic
build procedures triggered when I try to RUN the application.  It is also
possible to compile a specific module or check the link without running the
application.  When you edit inside the LightspeedC development environment,
it notes when you update something and computes the make list quickly.  If
you edit outside LightspeedC, you have to tell it to check the modification
timestamps explicitly (a little slower) when computing the make.

The first time the link was OK, the program launched.  It also ran just fine.

Then I tested the turnaround performance by making some trivial changes to
the program.  All worked very nicely and speedily.  I tried out MacsBug, and
was very pleased with the results.  (LightspeedC allows you a choice of getting
procedure names inserted into the code or not.  MANX does not.  Until now, it
has not been as easy to work with MacsBug as it should have been, because of
the lack of symbols in the disassembly.  I'm looking forward to a more
enjoyable low level debugging as well as drastically improved turnaround time.)  The big deal from
my point of view is that with this fast turnaround, source level debugging should be a peach.  No
longer will there be any point to worrying about how many print statements to put in to get
information, since it does not take 5 minutes to get another make done.

The last step was to build the application.  This ran pretty fast, and it
produced a clickable application module which worked just fine outside the
LightspeedC environment.  The only problem is that it is 17K bigger, and this
I attribute mainly to the problem with the library routines.  Aztec C seems
to be pretty good about avoiding unnecessary runtime overhead, and in addition
I have been suppressing the floating point library, since I don't need it for
the program I am writing.  LightspeedC has a way to go in this regard, but
I don't regard that as a fundamental defect, but rather an opportunity for
improvement in the next release.

It's also not clear what the deal is if library routines are called from more
than one segment.  You can include the library in the root, but in MANX it
was possible (and required) to list the libraries in each segment that might
have symbols not yet resolved.  MANX is not too clear about what they do
either, since a symbol called from segment 7 and segment 13 might more properly
go into segment 1 than segment 7 or both segments 7 and 13.

That brings up one last point:  the licensing agreement has the following
language in it:

        You have the right to include object code derived from the
        libraries in programs that you develop using the software and
        you also have the right to use, distribute and license such
        programs to third parties without payment of any further license
        fees providing you include the following copyright notice (no
        less prominently than your own copyright notice) in the graphic
        display of your software, in the documentation for it, and on the
        labels affixed to the media on which your software is distributed:
        "Copyright 1986 THINK Technologies, Inc.  Certain portions of
        this software are copyrighted by Think Technologies, Inc."

Well, I regard that as an advertisement, and I'm not interested in being
compelled to advertise another company's product in my own, EVEN THOUGH I
THINK IT'S A GREAT PRODUCT.  What this means is that I should write my own
library routines (I might want to do that anyway, given the problems with
the size of the library code).  Or, I maintain some compatibility with MANX
so that when I finish developing, I can go run the code through the MANX
compiler to get the final executable product for shipping.  What a pain.

My point is that I bought a DEVELOPMENT SYSTEM from THINK, *not* a nifty
C library.  Come on guys, you have a great product, don't get into the nickel
and dime business with this silly copyright notice.  If I like your product
(I do) I'll tell several thousand of my closest friends about it, and that
will be a much better exposure than forcing your name into my product image.

--------------------------------------------------------------

Peter Olson
DELPHI ICONtact Mac User Group SIG Manager

PEABO @ DELPHI
PEABO @ Unison
PEABO @ MCI Mail
PEABO @ GEnie
[76174,1670] @ CIS   :-)