Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Dumb windows from SAS/C programs on Workbench Message-ID: Date: 17 May 91 16:52:48 GMT References: <1991May14.164909.19186@NCoast.ORG> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 63 In-Reply-To: chopps@ro-chp.UUCP's message of 15 May 91 16:35:21 GMT In article chopps@ro-chp.UUCP (Chris Hopps) writes: So you can rename your main() function entry as '_main()'. That's simpliest, as long as you aren't doing any terminal- or file-I/O. Be aware, this also disables argument passing via the command line. If you use _main(), you should call _exit instead of exit() to exit. It also gets passed a single argument (if you're called from the CLI), the complete command line. You get to parse it yourself if you need to. In article chopps@ro-chp.UUCP (Chris Hopps) writes: The line should look like: DEFINE __main=__tinymain If you're using registerized parameters, it's DEFINE @_main=@_tinymain In article chopps@ro-chp.UUCP (Chris Hopps) writes: I would expect this. I don't use ANY of those functions, or any other I/O functions from lc.lib, only Amiga functions, for which I have specifically opened a file with "Open()". That's why I don't understand why they open that window for you. They should just let it alone if you run from WB, and have people handle it themselves. After all, you have to parse the WB options differently, anyway. They open the window for you because lots of people _don't_ expect to be run from the WB. They prevent the machine from crashing should you try that. It's a safety feature. There are instructions in the manual for turning it off. If you really aren't using any lc code at all, then don't link with their startup code. Change the name of your main to something else (like start), and make sure it's the first piece of code in the first .o file you link. It'll get run by the system on a CreateNewProc. Of course, you'll also have to do everything the Lattice startup code is doing for you that you _do_ need; setting up ExecBase at the very least; probably opening DOSBase. If using cres.o, you've got a bit of work ahead of you. Oh yeah - you have to compile with stack checking turned off, and use either large data or "load a4 on startup" (__saveds ought to be useable, but...). But the big question now is how do I get to receive CTRL-[CDEF] interupts? Many people sent me instructions on how to disable the SAS default CTRL-C handler, and it has indeed allowed my program to ignore CTRL-C interupts. But what I really want to do is to be able to check to see if there has been an interupt since the last time I checked, Disable the SAS handler, then use standard Exec function calls for checking on signals. It's still easy. Disabling the SAS handler is not required if you don't use the SAS startup code.