rlcarr@athena.mit.edu (Rich Carreiro) (08/05/88)
I have asked this previously and got a rather patronizing letter from someone telling me to read the manual. I looked at the manual for the nth time and couldn't find the info - so I ask again: How do Astartup.obj and Lstartup.obj map into Lattice 4.0? I assume that Lstartup.obj is now Lattice's c.o. What of Lstartup.obj? Any help will be greatly appreciated - thanks in advance! ******************************************************************************* * Rich Carreiro "MIT isn't Hell. It's where you go when * * rlcarr@athena.mit.edu you've been bad in Hell." - Anon. * *******************************************************************************
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/09/88)
In article <6562@bloom-beacon.MIT.EDU> (Rich Carreiro) writes: > How do Astartup.obj and Lstartup.obj map into Lattice 4.0? I assume > that Lstartup.obj is now Lattice's c.o. What of Lstartup.obj? Some Amiga history here. Back in the beginning, when Autoconfig memory was just a glimmer in Dale's eye, there was the "Developers Kit." This included, among other things, a copy of the MetaCompCo assembler and Lattice C version 3.02 labeled as "Amiga C V1.0". Now in those early times, it was very difficult to make a program that could run both from the CLI and the Workbench, so there were two startup modules supplied. AStartup.o would collect the WorkBench startup message, and LStartup.o would parse CLI arguments into that ever popular argv array. Time passed and Commodore stopped supporting Amiga C, more by attrition than by design I suspect, and Lattice began to market and improve their product. Now at the 4.0 version number. By now, Lattice had figured out that you didn't *really* need two startup modules since one could do the work of both AStartup and LStartup, and since their other compilers all used c.o they combined the capabilities of both startups into their one c.o startup module. The only problem with this was that to do this they were forced to open a window on the workbench when they started up so that printf's and other stdio operations wouldn't guru the code. They do give you an out however by letting you recompile _main.c with TINY defined. I guess they figure that if you know how to do that then you won't leave a printf() to stdout in your code. Carolyn Scheppner has done some startups that are available on BIX that allow for reentrant code. --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.
jms@antares.UUCP (joe smith) (08/09/88)
I took a C class in which the instructor was running Lightspeed-C on a Mac. One interesting thing it did was to not open a window until it was necessary. In particular, if a program did not execute a printf call, no window was openned. Would this be possible to do on the Amiga? To modify the console.device (and/or all routines that call it) to create a default console window instead of invoking the guru if no console window were open at the time. I can foresee one problem; who takes responsiblity for releasing the memory used by this new window. -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/10/88)
In article <118@antares.UUCP> jms@antares.UUCP (joe smith) writes: > ...In particular, if a program did not execute a printf call, >no window was openned. Would this be possible to do on the Amiga? Simple in theory, a bit tougher to do it so that it would please everyone who uses the compiler. In the startup module one puts some "illegal but unique" value into the StdIn and StdOut file handles. Then one rewrites the stdio library routines to check for this value before using the handles. If they are this illegal value, then the routine calls the "build a window and fix up these two handles" routine. On exit, if the handles have legal values in them they are Closed(). This would slow down stdio by a fraction. And in some cases (where the application has closed the workbench) can still cause a catatropic failure. But it is probably better than nothing. Personally, I would like to see the startup code open a window if TOOLWINDOW= is defined in the tool types and open NIL: if it isn't. --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.
pds@quintus.uucp (Peter Schachte) (08/11/88)
In article <63562@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <118@antares.UUCP> jms@antares.UUCP (joe smith) writes: >> ...In particular, if a program did not execute a printf call, >>no window was openned. Would this be possible to do on the Amiga? > >In the startup module one puts some "illegal but >unique" value into the StdIn and StdOut file handles. Then one rewrites >the stdio library routines to check for this value before using the handles. >If they are this illegal value, then the routine calls the "build a window >and fix up these two handles" routine. On exit, if the handles have legal >values in them they are Closed(). Couldn't this also be handled by building a device, call it MAYBE:, that, when opened, does nothing, but when first written to, opens up a CON: window? And, of course, when MAYBE: was closed, the CON: window would be closed, if it existed. The startup code would be rewritten to open MAYBE: instead of CON: for a workbench startup. This has the advantage that the stdio stuff wouldn't have to be touched, and so I/O to files wouldn't be slowed down by checking the file handle for the special value. It also has the advantage of working for either C compiler, or even (gasp!) another language. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (08/11/88)
In article <6562@bloom-beacon.MIT.EDU> rlcarr@athena.mit.edu (Rich Carreiro) writes: >I have asked this previously and got a rather patronizing letter from >someone telling me to read the manual. I looked at the manual for the nth time >and couldn't find the info - so I ask again: > >How do Astartup.obj and Lstartup.obj map into Lattice 4.0? I assume >that Lstartup.obj is now Lattice's c.o. What of Lstartup.obj? When we sold Amiga C (aka Lattice 3.03), we provided two startups - LStartup.obj and Astartup.obj. When Lattice sells Lattice, they currently provide only the LStartup.obj but they call it "c.o". LStartup.obj (aka c.o) does the following: - Normal startup stuff like command line parsing and handling of Workbench startup msg and passing of WBenchMsg to application - Sets up Lattice filehandles for Lattice stdio (causing much of the LC.lib IO stuff to be linked to your code) - Opens a small window for output on Workbench startup (unless you take special steps) - Sets up some variables needed by LC.lib rtns and Lattice stack checking code When using LStartup.obj, you generally - #include <lattice/stdio> (and maybe other lattice headers) - don't need to -v on LC2 - Link Lstartup.obj your.o ... LIBRARY LC.lib, Amiga.lib (causing all std and file IO calls to be satisfied by LC.lib since these want Lattice filehandles, and just Amiga system calls to be satisfied by Amiga.lib stubs) AStartup.obj does the following: - Normal startup stuff like command line parsing and handling of Workbench startup msg and passing of WBenchMsg to application - Sets up Amiga filehandles for Amiga stdio (which consists of a limited printf, getchar, etc. in Amiga.lib - these functions are described in the AW RKM Exec) When using AStartup.obj, you generally - Do NOT #include <lattice/stdio> (or other lattice headers) - Must use -v on LC2 to disable Lattice's insertion of stack check code - Link Astartup.obj your.o ... LIBRARY Amiga.lib,LC.lib, Amiga.lib (limiting you to the stdio and file io "C" functions in Amiga.lib - these functions want Amiga (Open(...)) filehandles - and generally limiting your use of LC.lib functions to non-Lattice-specific functions such as string functions and non-power-of-two-math.) You might ask "Well, why would I WANT to use Astartup.obj ?" If you have a pretty Amiga-specific 32-bit program, and don't need (or can't use) all of the Lattice stuff, you can usually reduce the size of your program this way, sometimes significantly. Astartup.obj is the startup used by most of the C and Assembler programs provided on Workbench, Extras, etc. It is the startup used on the OS guy's Suns with the Greenhill's compiler. It's the startup and way of writing/linking I use when working native to write Greenhill's compatible Amiga-specific (rather than compiler-specific) code for inclusion on Workbench and Extras. (They need to be able to remake the whole system, including all of the programs on Workbench and Extras) If you see an example in the Amiga manuals (except for a couple of Lstartup ones I wrote) you can be sure it was written using Astartup.obj, Amiga.lib printf and file IO, etc. (Note - I wrote the Lstartup ones when Amiga C was the only C compiler for the Amiga, and it was sold by us.) -- ========================================================================== Carolyn Scheppner -- CATS Commodore Amiga Technical Support PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn "Under the multitasking operating system, the trackdisk.device is the defied interface..." - Bryce ==========================================================================