🚀 go-pugleaf

In article <9322@bloom-beacon.MIT.EDU> (Rich Carreiro) writes:

>I have some questions about C startup code - what exactly does it have
>to do? 

All it _has_ to do is set up the "environment" for the "main" program.
C programs want stdin/stdout/stderr setup, and to have arguments parsed
into the argv array. Assembly programs don't care. The startup code is
also responsible for opening whatever minimum set of libraries you will
need, and since it will regain control after your program exits, for 
closing those libraries as well. In Lattice's case they also take care
of handling the workbench startup message you get sent when the user
double-clicks on an icon that activates your program. 

[Code example deleted]

>I compile each with 'lc -v filename' and they compile fine.  I next do
>'blink from ourstart.o+beep.o to beep lib lib:amiga.lib' [I have
>Latice 5.02]  and it links fine.  When I run it, instant Guru 4.  

My guess is that your code never manages to open Intuition, falls out
the bottom of main with an undefined value, and falls out of your startup
code into uninitialized memory. At some point you have to call Exit() to
get back to your original CLI. 

>Finally, all the books on C pertaining to the Amiga talk about linking
>with the AStartup.obj and LStartup.obj startup codes.  I have gathered
>that LStartup.obj is now c.o and is used when you want Lattice library
>(lc.lib) I/O.  Astartup.obj was used when you didn't care about UNIX
>commend line emulation and wanted Amiga, not lattice I/O - in this
>even you also linked amiga.lib AHEAD of lc.lib.  My question is - with
>Lattice 5.02, what is the equivalent of Astartup.obj?

Well, Carolyn Scheppner put a bunch of startup modules on BIX and on
a Fish disk I believe. These were TWStartup et al. They are the what 
{A|L}Startup.obj became. Generally, with the 5.0 libcall stuff and
and judicious programming you can link with _no_ libraries and get
a really tight executable. 

>Any answers, comments, corrections to any of this will be more than
>appreciated.

Not real helpful but a couple of pointers to work on ...


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.