davewt@NCoast.ORG (David Wright) (05/14/91)
Can anyone tell me if there is a simple way to get rid of the stupid windows that SAS/C opens up by default when you start a program from the WorkBench? I can obviously diddle with c.a and umain.c to eliminate this, but it seems like there MUST be an easier way to do this. I am using the "tinymain" option, in both my SASCOPTS file, and in the Blink ".lnk" file, and do not make any use of printf/fprintf, and so have no use for a default "stdin", "stdout", or "stderr". On a related note, what do you have to do to kill the CTRL-C trapping their startup code puts in by default. I have my own trapper which worked fine in Draco programs, but SAS/C seems to grab the signals before I have a chance to see them, and is dumping my programs without giving me a chance to clean up, close files, etc. Dave
chopps@ro-chp.UUCP (Chris Hopps) (05/15/91)
In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > Can anyone tell me if there is a simple way to get rid of the stupid >windows that SAS/C opens up by default when you start a program from the >WorkBench? I can obviously diddle with c.a and umain.c to eliminate this, >but it seems like there MUST be an easier way to do this. >[...] There used to be a peice of an Apprentice & Journyman included with Lattice, in the source drawer, but when 5.x came out, it was removed. This file explained all this and some more about optimizing code size from C. I have no Idea why they took this file out, and would appreciate it if they put it back. Anyway to answer your question, declare your main() like this void _main(... ^^^ the underscore tells c.a to not open STDIO/STDOUT (Almost possitive) anyway the net result is that the window disapears. NOTE: I wouldn't advise doing anything that uses STDIO/STDOUT if you do this, ie. printf, puts, gets... under 1.3 it will definitaley crash! > Dave Chris... -- ------------------------ The Royal Oak Chophouse Chris Hopps Royal Oak, Michigan ....umich!wsu-cs!ro-chp!chopps cs.wayne.edu!ro-chp!chopps
fjrei@kbsaar.UUCP (Franz-Josef Reichert) (05/16/91)
In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > Can anyone tell me if there is a simple way to get rid of the stupid >windows that SAS/C opens up by default when you start a program from the >WorkBench? I can obviously diddle with c.a and umain.c to eliminate this, >but it seems like there MUST be an easier way to do this. > I am using the "tinymain" option, in both my SASCOPTS file, and >in the Blink ".lnk" file, and do not make any use of printf/fprintf, and >so have no use for a default "stdin", "stdout", or "stderr". 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. > On a related note, what do you have to do to kill the CTRL-C trapping >their startup code puts in by default. I have my own trapper which worked >fine in Draco programs, but SAS/C seems to grab the signals before I have >a chance to see them, and is dumping my programs without giving me a chance to >clean up, close files, etc. See your manual P. L-156 to learn more about how to set the break trap to your favourite function entry. > Dave -- Best regards, Franz-Josef Reichert VOICE: +49 6805 7417 Kuchlingerstrasse 13 UUCP: ...uunet!cbmvax!cbmehq!cbmger!kbsaar!fjrei D-6601 Kleinblittersdorf GERMANY
alex@bilver.uucp (Alex Matulich) (05/16/91)
In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > On a related note, what do you have to do to kill the CTRL-C trapping >their startup code puts in by default. I have my own trapper which worked >fine in Draco programs, but SAS/C seems to grab the signals before I have >a chance to see them, and is dumping my programs without giving me a chance to >clean up, close files, etc. This is what works for me, on every platform I've tried, including Amiga: #include <signal.h> void ctrlctrap(int); /* prototype for ctrl-c trap handler */ main() { signal(SIGINT, ctrlctrap); /* cause ctrl-c to execute ctrlctrap() */ [etc..] } void ctrlctrap(int i) /* i is needed because signal() passes it */ { signal(SIGINT, ctrlctrap); /* do ctrlctrap() on next ctrl-c event */ } This will just cause all ctrl-c's to be ignored. If you want to actually do something else, like clean up allocated memory and shut down, just replace the signal() call in ctrlctrap() with whatever you want to do, free() this and that, close libraries, etc. -- _ |__ Alex Matulich /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: alex@bilver.uucp <or> ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"
jbickers@templar.actrix.gen.nz (John Bickers) (05/16/91)
Quoted from <1991May14.164909.19186@NCoast.ORG> by davewt@NCoast.ORG (David Wright): > I am using the "tinymain" option, in both my SASCOPTS file, and > in the Blink ".lnk" file, and do not make any use of printf/fprintf, and The line should look like: DEFINE __main=__tinymain > On a related note, what do you have to do to kill the CTRL-C trapping > their startup code puts in by default. I have my own trapper which worked The ^C trapping appears to be in the prelude to various C library functions. Particularly the IO ones (fread, etc). The solution is not to use those functions. The other solution is to find out what name these functions are calling and write your own do-nothing function with the same name. Your routine will be used instead of the library routine, and you'll be set. > a chance to see them, and is dumping my programs without giving me a chance to > clean up, close files, etc. If you're using the C library functions, they'll clean up automatically when you exit(). This applies to the fopen() file facilities and the malloc() memory management. > Dave -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
davewt@NCoast.ORG (David Wright) (05/17/91)
In article <chopps.0607@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: >There used to be a peice of an Apprentice & Journyman included with Lattice, >in the source drawer, but when 5.x came out, it was removed. This file Darn! And after I erased my old Lattice 3.xx and 4.xx disks when I got 5.xxx (Guess it's my fault for not poking around on them). >the net result is that the window disapears. NOTE: I wouldn't advise doing >anything that uses STDIO/STDOUT if you do this, ie. printf, puts, gets... >under 1.3 it will definitaley crash! 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. 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, and I used to be able to do this easily (in Draco, but then many things are easier in Draco than in C), but although the code I brought over from Draco compiles just fine, I never seem to get the break signals. What do you have to do to get things like SIG_BRKF to appear in your input stream, or, for instance, prevent a USER from breaking out by entering CTRL-C in the program, but allowing someone to use the "BREAK" CLI command to send you a CTRL-C and have it correctly (IE, call my handler only when I can safely process the event) handle it? Dave
davewt@NCoast.ORG (David Wright) (05/17/91)
In article <fjrei.9160@kbsaar.UUCP> fjrei@kbsaar.UUCP (Franz-Josef Reichert) writes: >In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >> On a related note, what do you have to do to kill the CTRL-C trapping >>their startup code puts in by default. I have my own trapper which worked >>fine in Draco programs, but SAS/C seems to grab the signals before I have >>a chance to see them, and is dumping my programs without giving me a chance to >>clean up, close files, etc. > >See your manual P. L-156 to learn more about how to set the break trap to your >favourite function entry. This is not what I want to do. I am quite familiar with the "onbreak()" type calls, but that is not how I want to handle the events. What *I* want to do is more like this: while(!gotError && !gotUserBreak()) { /* code here */ } I may have like 4 or 5 of these in various places throughout a single command (in my game), and I want the person to be able to abort the command (not the program) if they decide they have enough, for example when doing a "map 25:1214,820:2015" the person may decide partway through the map the don't need to see any more. Or if they are rebuilding a power report, and it is reading all the planets and is taking a while, they may want to abort the command, but NOT the program. So basically what I want is something that will evaluate down to a logical true or false if the user has pressed CTRL-C (or some other control character the operator has decided to allow). Under Draco you could do this very simply by &'ing bits with SIGBRKF_C, but this same method, although it compiles fine, appears to do nothing under SAS/C. Any ideas why? Dave
davewt@NCoast.ORG (David Wright) (05/17/91)
In article <3770.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > The ^C trapping appears to be in the prelude to various C library > functions. Particularly the IO ones (fread, etc). The solution is not > to use those functions. Just for your information, in case you ever are curious about this yourself, it is not part of the C library functions (although they would also see it), but rather part of the SAS/C "umain.c" module, which is linked into "lc.lib" and "lcr.lib". So the best solution is to copy umain.c from the "source" directory on one of the disks (if you didn't install all of them on your HD), rename it as "main.c" replace the line that assigns the result of the "Open(<windowname>..." with a NULL, and to comment out the line that installs the CTRL-C handler. Then just put this into the link list before your modules (after the "cres.o" or "c.o" module, though), and you will be all set. > > If you're using the C library functions, they'll clean up > automatically when you exit(). This applies to the fopen() file > facilities and the malloc() memory management. Yes, and does not apply at all if you are making use of any of the Amiga-specific calls, which you HAVE to do when allocating things like CHIP memory, opening libraries or devices, etc. In short, you can't rely on the SAS/C cleanup functions for anything you didn't get with normal C library functions, which may or may not be a small amount of your code, depending on whether you are writing for the Amiga or for portability. For another bit of information, an early test version of my console client for "Imperium" made use of the ANSI/SAS I/O functions (fread/write, etc.), and was almost totally ANSI (didn't work from WB right, either). In the words of one person it "seemed slower than 2400 baud". When I replaced the fread/write calls with the Amiga-specific calls the performance went up by easily 5 times or more. I would say display speed is now limited by the Amiga's text rendering speed itself, not the I/O functions in the library as it was before. Dave
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/17/91)
In article <1991May17.023000.1652@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > This is not what I want to do. I am quite familiar with the >"onbreak()" type calls, but that is not how I want to handle the >events. What *I* want to do is more like this: > > while(!gotError && !gotUserBreak()) > { > /* code here */ > } > > So basically what I want is something that will evaluate down to a >logical true or false if the user has pressed CTRL-C (or some other >control character the operator has decided to allow). Under Draco you could >do this very simply by &'ing bits with SIGBRKF_C, but this same method, >although it compiles fine, appears to do nothing under SAS/C. Yes, the SIGBRKF_C is also the right method in C. You must use the function SetSignal: while((SetSignal(0L,0L) & SIGBREAKF_CTRL_C)==0) { ... } And to disable the Lattice own Ctrl-C checking, insert following lines at start: #ifdef LATTICE int CXBRK() { return(0); } int chkabort() { return(0); } #endif This can also be found at some places in the blue 1.3 RKM's (although there you only find the first function, I think, the above version is from a posting by Richard Leinfellner in the developer's newsgroup). -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
chopps@ro-chp.UUCP (Chris Hopps) (05/17/91)
In article <1991May17.022136.1539@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >>the net result is that the window disapears. NOTE: I wouldn't advise doing >>anything that uses STDIO/STDOUT if you do this, ie. printf, puts, gets... >>under 1.3 it will definitaley crash! > 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. Ah but then what about being able to handle ansi code from workbench(ie. people to lazy to add WB Message handler...) under 1.3 some of this stuff would crash the system if there were no STDIN/OUT. Under 2.0 there is a nice icon that will bring up a cli line and then open a console so that these very same programs can be run under 2.0. But under 1.3 the window was needed, I figure when lattice added this "feature", it was under the assumption that someone who goes out of there way to handle WB messages, and handle IO correctly, won't mind prepending an underscore to there main() to disable such a "feature". > > 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, SAS/C Volume II pp. L156-157. onbreak() will setup an interupt handling function for you. then when you call chkabort(), it will check then (and only then) to see if a CTRL-(C|D) has been pressed, if so it calls the interupt function. Now if you return a value that is not zero from this function SAS/C will exit, otherwise it continues from that point. so if you do not want SAS/C to exit just set some global (eek) var. to indicate that a CTRL-(C|D), from your interupt function, then return(0); then have the regular program check the state of the global, if it is true, call your own exit routine, or whatever.... > > Dave Chris... -- ------------------------ The Royal Oak Chophouse Chris Hopps Royal Oak, Michigan ....umich!wsu-cs!ro-chp!chopps cs.wayne.edu!ro-chp!chopps
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (05/17/91)
In article <1991May17.022136.1539@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > 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 Wait() returns the signals set at a port and clears the signals. So you can say: signals = Wait(...); if (signals & SIGBREAKF_CTRL_C) { /* process signal */ } else if (signals & SIGBREAKF_CTRL_D) . . . -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/17/91)
In article <chopps.0607@ro-chp.UUCP> 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.0607@ro-chp.UUCP> 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.0607@ro-chp.UUCP> 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. <mike -- All around my hat, I will wear the green willow. Mike Meyer And all around my hat, for a twelve-month and a day. mwm@pa.dec.com And if anyone should ask me, the reason why I'm wearing it, decwrl!mwm It's all for my true love, who's far far away.
baxter_a@wehi.dn.mu.oz (05/18/91)
In article <1991May17.023000.1652@NCoast.ORG>, davewt@NCoast.ORG (David Wright) writes: ... > So basically what I want is something that will evaluate down to a > logical true or false if the user has pressed CTRL-C (or some other > control character the operator has decided to allow). Under Draco you could > do this very simply by &'ing bits with SIGBRKF_C, but this same method, > although it compiles fine, appears to do nothing under SAS/C. > Any ideas why? > > > Dave I sent you mail on this. Sorry it didn't get through. Move a copy of umain.c to you source directory, edit out the line handling cntrl-c, compile and link with your own module that handles the key hit you want to use the way you would handle any other key hit (RAWKEY or whatever). regards Alan
jbickers@templar.actrix.gen.nz (John Bickers) (05/18/91)
Quoted from <1991May17.024020.1828@NCoast.ORG> by davewt@NCoast.ORG (David Wright): > In article <3770.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > The ^C trapping appears to be in the prelude to various C library > > functions. Particularly the IO ones (fread, etc). The solution is not > yourself, it is not part of the C library functions (although they would also > see it), but rather part of the SAS/C "umain.c" module, which is linked into I meant that the actuall call to whatever's been put into _ONBREAK is done by the prelude to the IO functions. Either don't use the functions, or set _ONBREAK to something harmless yourself. The DEFINE __main=__tinymain should get rid of the Workbench window. If it doesn't, then sorry - it worked for me back when I was using 5.04. I haven't run any of my code from Workbench since I got 5.10. Using the DEFINE is a lot nicer, I think, then fiddling with umain. I did that too, ages ago, before I knew what __tinymain did. From another of your articles, you appear to be having difficulty reading the ^C signal. The following is the routine I use, which I derived by taking apart the Lattice one, I think. I use it in either of two ways: if (tabort(NULL)) die(); or: tabort(die); ------------------------------ 8< ------------------------------ ;************************************************************************** ;*** tabort.a (JJB TEMPLAR) *** ;*** Date begun: 3/8/89 - cut from Lattice's chkabort function. *** ;*** Last modified: 3/8/89. *** ;*** 15-May-90: allow NULL function pointer. *** ;************************************************************************** ;*** Use as follows: tabort(void (*)()); *** ;************************************************************************** CSECT text XDEF _tabort SetSignal EQU -$0132 _tabort: movem.l d7/a6,-(a7) ; use d7 and a6 moveq #$00,d0 ; no newsignals move.l #$00003000,d1 ; test signal 00003000 movea.l $0004,a6 ; ExecBase jsr SetSignal(a6) move.l d0,d7 ; move signals into d7 andi.l #$00003000,d7 ; test for signal 00003000 tst.l d7 bne.b break moveq.l #$00,d0 ; clear d0 == return(0) beq.b exit ; false break: move.l $0c(a7),d0 ; load break function beq.b skipfunc ; if no func, ignore movea.l d0,a0 jsr (a0) ; gosub it skipfunc: move.l d7,d0 exit: movem.l (a7)+,d7/a6 rts END ------------------------------ 8< ------------------------------ I've also used the following, when I've wanted to check for several signals at one time, and then process each one... ------------------------------ 8< ------------------------------ ULONG sigs; sigs = SetSignal(0L,0L); if (sigs & SIGBREAKF_CTRL_C) { mprintf("*** break.\n"); SetSignal(0L,SIGBREAKF_CTRL_C); /* clear the thing */ ... /* go away and die */ } ------------------------------ 8< ------------------------------ These work (or seem to work) under KS1.2. > Dave -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
billy@phoenix.pub.uu.oz.au (Jeff Coleman) (05/18/91)
In <1991May17.022136.1539@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >Draco compiles just fine, I never seem to get the break signals. What do >you have to do to get things like SIG_BRKF to appear in your input >stream, or, for instance, prevent a USER from breaking out by entering >CTRL-C in the program, but allowing someone to use the "BREAK" CLI command >to send you a CTRL-C and have it correctly (IE, call my handler only when I >can safely process the event) handle it? how about something like sigs=SIGBREAKF_CTRL_C|whateverelseuwant Wait(sigs); I assume you would have some type of loop and be waiting on message ports as well these signals. After the wait you could just do if (sigs & SIGBREAKF_CTRL_C) { whatever you want to do upon getting this signal } Don't forget to disable ctl-c/d/e catching. The RKM libs+devices is a useful tool for finding these things out. regards jeff. <-----------------------------------------------------------------------------> Jeff Coleman billy@phoenix.pub.uu.oz.au ..!uunet!munnari.oz!phoenix.pub.uu.oz.au!billy <----------------------------------------------------------------------------->
jay@deepthot.cary.nc.us (Jay Denebeim) (05/18/91)
In article <1991May17.023000.1652@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > This is not what I want to do. I am quite familiar with the >"onbreak()" type calls, but that is not how I want to handle the >events. What *I* want to do is more like this: > > while(!gotError && !gotUserBreak()) > { > /* code here */ > } > Try this: #include <libraries/dos.h> #include <exec/tasks.h> struct Task *mytask=FindTask(NULL); if (mytask->tc_SigRecvd & SIGBREAKF_CTRL_C) and so on... > > > Dave -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: UUCP: mcnc.org!deepthot.uucp!jay ====== Internet: jay@deepthot.cary.nc.us BBS:(919)-460-7430 VOICE:(919)-460-6934
fjrei@kbsaar.UUCP (Franz-Josef Reichert) (05/19/91)
In article <1991May17.023000.1652@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > So basically what I want is something that will evaluate down to a >logical true or false if the user has pressed CTRL-C (or some other >control character the operator has decided to allow). Under Draco you could >do this very simply by &'ing bits with SIGBRKF_C, but this same method, >although it compiles fine, appears to do nothing under SAS/C. > Any ideas why? Use chkabort() (P. L25) to figure out whether the user hits ^-C. Or have a direct look at the task's signal bits: #include <libraries/dosextens.h> if(SetSignal(0L,0L) & SIGBREAKF_CTRL_C) /* => ^-C pressed */ -- Best regards, Franz-Josef Reichert VOICE: +49 6805 7417 Kuchlingerstrasse 13 UUCP: ...uunet!cbmvax!cbmehq!cbmger!kbsaar!fjrei D-6601 Kleinblittersdorf GERMANY
jap@convex.cl.msu.edu (Joe Porkka) (05/19/91)
alex@bilver.uucp (Alex Matulich) writes: >In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >> On a related note, what do you have to do to kill the CTRL-C trapping >>their startup code puts in by default. I have my own trapper which worked >>fine in Draco programs, but SAS/C seems to grab the signals before I have >>a chance to see them, and is dumping my programs without giving me a chance to >>clean up, close files, etc. >This is what works for me, on every platform I've tried, including Amiga: >#include <signal.h> >void ctrlctrap(int); /* prototype for ctrl-c trap handler */ >main() >{ >signal(SIGINT, ctrlctrap); /* cause ctrl-c to execute ctrlctrap() */ Even better simply signal(SIGINT, SIGIGN); /* Ignore the signal completely */ Or you modify the startup code yourself - all the source code for it is included.
davewt@NCoast.ORG (David Wright) (05/20/91)
In article <chopps.0617@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: >Ah but then what about being able to handle ansi code from workbench(ie. >people to lazy to add WB Message handler...) under 1.3 some of this stuff >would crash the system if there were no STDIN/OUT. Under 2.0 there is a nice The only problem with this is that the window that SAS/C opens is very small, and most certainly not large enough to display and "real" text, maybe only 2 or 3 very short lines. Basically, it's useless. It would have been better for them to write up a function that would "throw away" the output without a system crash than open a window that people can't change easily. >icon that will bring up a cli line and then open a console so that these very >same programs can be run under 2.0. But under 1.3 the window was needed, I Actually, under 2.0 you have to ASK for that command line window by explicitly running the program as if it were from the CLI, which is NOT the same as running from the WorkBench. So this is not "fixed" even now, which is good, since there is nothing to be "fixed" at all. The operating system works the way it should. >someone who goes out of there way to handle WB messages, and handle IO >correctly, won't mind prepending an underscore to there main() to >disable such a "feature". Actually, that is NOT the best way to do it. When you declare "_main" you will be giving up most of the SAS/C startup/shutdown features that make it worthwhile to link with "c.o", "cres.o", etc. in the first place. What is porbably better is to do what several people suggested to me and copy "umain.c" from the "source" directory on one of the disks, rename it to "main.c", and remove the CTRL-C handler and window opening code. Then just put this as the first module after the startup module (c.o, cres.o, etc), and the "normal" _main will not be called in from "lc.lib". Works just great for me, does exactly what I want. >onbreak() will setup an interupt handling function for you. then when you call >chkabort(), it will check then (and only then) to see if a CTRL-(C|D) has been >pressed, if so it calls the interupt function. Now if you return a value that >is not zero from this function SAS/C will exit, otherwise it continues from >that point. so if you do not want SAS/C to exit just set some global (eek) >var. to indicate that a CTRL-(C|D), from your interupt function, then >return(0); then have the regular program check the state of the global, if it >is true, call your own exit routine, or whatever.... This is the ANSI way to do it basically, but in probably most "event" oriented systems is NOT the best way to do it. I want to have it do various things depending on what part of the program it is in when the signal arrives. Using functions like "onbreak()" pretty much assume you want to do the same thing every time the event occurs, which is basically a holdover from line-oriented Unix applications which (for instance) assume that a certain signal means to terminate (kill) the program. On the Amiga what appears to be the best method (to me at least) is to set one of the signals "bits" for the type of break you want to receive, and just OR them with the other bits you feed to "Wait()". This will work for MOST applications, but others, such as mine, which have many loops during which an abort would NOT be handled the same as in other loops, or even normal program flow, work better using the "SetSignal()" function, which is basically what I do, since I want to throw away any signals that occur when I am not in a part of the program that can handle them. Dave
markv@kuhub.cc.ukans.edu (05/20/91)
With 2.0, you can also hack umain.c to use the autoopen flag of the
CON: device, so the window only opens *if* there really is I/O.
Another nice thing about 2.0, is you can open _stderr with an autoopen
window that also has a wait, so the user (programmer?) gets time to
read the message if the file handle is used. This makes things like
perror() useful.
Another solution is to change UMAIN.c to open NULL: rather than open a
window. Note that you must use NULL: rather than NIL: since you need
a "real" file handle and handler.
Something that works under DOS, or under workbench on the Amiga is:
freopen("NULL:", "r+", _stdout);
/* etc for _stdin and _stderr */
The program is happy, _stdout goes to NULL: and all works, but the
effect of this is to close the file handle passed by Input() if the
program is a cli program which is a big no-no. But with Workbench,
the filehandle was opened by the startup, and will be closed by the
startup quite happily.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum Only... \ Good Cheer !!!
Academic Computing Services /// \___________________________
University of Kansas /// /| __ _
Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it
Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~carolyn@cbmvax.commodore.com (Carolyn Scheppner - CATS) (05/21/91)
In article <fjrei.9266@kbsaar.UUCP> fjrei@kbsaar.UUCP (Franz-Josef Reichert) writes: >In article <1991May17.023000.1652@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >> So basically what I want is something that will evaluate down to a >>logical true or false if the user has pressed CTRL-C (or some other >>control character the operator has decided to allow). Under Draco you could >>do this very simply by &'ing bits with SIGBRKF_C, but this same method, >>although it compiles fine, appears to do nothing under SAS/C. >> Any ideas why? > >Use chkabort() (P. L25) to figure out whether the user hits ^-C. Or have a >direct look at the task's signal bits: > >#include <libraries/dosextens.h> >if(SetSignal(0L,0L) & SIGBREAKF_CTRL_C) /* => ^-C pressed */ If you want to take care of CTRL-C's yourself (almost a REQUIREMENT if you are allocating., opening, or locking anything other than standard C files) then turn off Lattice's CTRL-C handling totally. Here's what we use: #ifdef LATTICE int CXBRK(void) { return(0); } /* Disable Lattice CTRL/C handling */ int chkabort(void) { return(0); } /* really */ #endif Then code like the SetSignal() check shown above will work. Note however than a CTRL-C hit on an Intuition window that YOU opened will NOT cause SIGBREAKF_CTRL_C to get set in your process. So in ADDITION, you must process either VANILLAKEY or RAWKEY events (I use VANILLAKEY - CTRL-C is msg->Code 0x03) -- ========================================================================== Carolyn Scheppner -- Tech. Mgr. CATS - Commodore Amiga Technical Support PHONE 215-431-9180 {uunet,rutgers}!cbmvax!carolyn carolyn@commodore.com I am fully operational and all of my circuits are funcTiOnINg pperrf... ==========================================================================
steve@wildcat.UUCP (Steve Holland) (05/21/91)
>In article <chopps.0607@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: >In article <1991May14.164909.19186@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >> >> Can anyone tell me if there is a simple way to get rid of the stupid >>windows that SAS/C opens up by default when you start a program from the >>WorkBench? I can obviously diddle with c.a and umain.c to eliminate this, >>but it seems like there MUST be an easier way to do this. >>[...] What you do with my version of Lattice/SAS (5.05) is simply link with blink define __main=__tinymain (your normal blink command-line) -- ----------->Steve Holland<----------- Internet: wildcat!steve@alphalpha.com| "I never let my schooling get in the USENET: ...!alphalpha!wildcat!steve | way of my education" -Mark Twain
chopps@ro-chp.UUCP (Chris Hopps) (05/21/91)
In article <MWM.91May17115248@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <chopps.0607@ro-chp.UUCP> 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. Yes I wrote this... >In article <chopps.0607@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: > The line should look like: not this though... >In article <chopps.0607@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: > > I would expect this. I don't use ANY of those functions, or any or this.... check your editor mike, I think it went flaky.... > > <mike > Chris... Sorry about the bandwidth, but I was misquoted.... -- ------------------------ The Royal Oak Chophouse Chris Hopps Royal Oak, Michigan ....umich!wsu-cs!ro-chp!chopps cs.wayne.edu!ro-chp!chopps
chopps@ro-chp.UUCP (Chris Hopps) (05/21/91)
In article <1991May20.020743.14630@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <chopps.0617@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: >>Ah but then what about being able to handle ansi code from workbench(ie. >>people to lazy to add WB Message handler...) under 1.3 some of this stuff >>would crash the system if there were no STDIN/OUT. Under 2.0 there is a nice > The only problem with this is that the window that SAS/C opens is very >small, and most certainly not large enough to display and "real" text, enough to alert you to the problem... >maybe only 2 or 3 very short lines. Basically, it's useless. It would have been >better for them to write up a function that would "throw away" the output >without a system crash than open a window that people can't change easily. I disagree, when debuging, I don't throw all that much info into that little window, just enough to find the problem. If it is too small, I re-size it. To have a window that is very large would be in the way, and to not have a window would take a nice debuging thing out. >>icon that will bring up a cli line and then open a console so that these very >>same programs can be run under 2.0. But under 1.3 the window was needed, I > Actually, under 2.0 you have to ASK for that command line window >by explicitly running the program as if it were from the CLI, which is NOT >the same as running from the WorkBench. So this is not "fixed" even now, which >is good, since there is nothing to be "fixed" at all. The operating system >works the way it should. but it DOES allow them to be run from the workbench, this is not a fix, but an enhancement. >>someone who goes out of there way to handle WB messages, and handle IO >>correctly, won't mind prepending an underscore to there main() to >>disable such a "feature". > Actually, that is NOT the best way to do it. When you declare >"_main" you will be giving up most of the SAS/C startup/shutdown features I haven't tried the umain.c stuff, it may be better. If I remember though the question was what is an easy way to get rid of the "Dumb windows from SAS/C programs on Workbench" _main is an easy way. > > > Dave Chris... -- ------------------------ The Royal Oak Chophouse Chris Hopps Royal Oak, Michigan ....umich!wsu-cs!ro-chp!chopps cs.wayne.edu!ro-chp!chopps
alex@bilver.uucp (Alex Matulich) (05/21/91)
jap@convex.cl.msu.edu (Joe Porkka) writes: >alex@bilver.uucp (Alex Matulich) writes: >>davewt@NCoast.ORG (David Wright) writes: >>> On a related note, what do you have to do to kill the CTRL-C trapping >>>their startup code puts in by default. > >>This is what works for me, on every platform I've tried, including Amiga: > >>#include <signal.h> >>void ctrlctrap(int); /* prototype for ctrl-c trap handler */ >>main() >>{ >>signal(SIGINT, ctrlctrap); /* cause ctrl-c to execute ctrlctrap() */ > >Even better simply > signal(SIGINT, SIGIGN); /* Ignore the signal completely */ Yes, I thought of posting that one too. I didn't because when I tried using SIGIGN in MSDOS, you would see ^C somewhere on the screen every time you pressed ctrl-c or ctrl-break. The solution I found was to just pass the address of your ctrl-c trap handler instead. Then it works silently. -- _ |__ Alex Matulich /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: alex@bilver.uucp <or> ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"
davewt@NCoast.ORG (David Wright) (05/22/91)
In article <chopps.0625@ro-chp.UUCP> chopps@ro-chp.UUCP (Chris Hopps) writes: >I disagree, when debuging, I don't throw all that much info into that little >window, just enough to find the problem. If it is too small, I re-size it. To >have a window that is very large would be in the way, and to not have a window >would take a nice debuging thing out. This is a valid point, and one I hadn't thought about. But if you are using the window for debugging, what do you do during CLI testing? In that case your programs I/O will appear in the same area as your debugging messages, unless you are always opening your own window anyway. I guess I just use CPR enough that I forget about using things like print statements to indicate what the code is doing, since I can set breakpoints and just WATCH what it is doing anywhere I choose. >but it DOES allow them to be run from the workbench, this is not a fix, but an >enhancement. I didn't mean I didn't LIKE the way 2.0 does that, I think it is excellent, since it allows you to run programs that would totally blow up under WB from the WB. What I meant was that even under 2.0 you can't just stick an icon on a file and expect it to work properly from WB if the programmer didn't expect you to do this. What I think would be neat would be a "tool" that would basically do the same thing as the 2.0 WB "execute" option, but allowed you to attach an icon to any program, and put in the icon's tooltypes the flags you wanted to pass to the program as if it was started from the CLI. That way you COULD create icons for any program, and have them executed exactly as if they were started from the CLI without having to use the pull-down menu option. (Another tooltype entry that allowed you to specify the I/O window size for the program would also be nice). Anyone want to program something like this up? >I haven't tried the umain.c stuff, it may be better. If I remember though the >question was what is an easy way to get rid of the "Dumb windows from SAS/C >programs on Workbench" _main is an easy way. Yes it is, and thanks for the suggestion. But for most people it is probably going to cost them more than it gives them. The SAS/C _main does some other work that you would basically have to duplicate if you wanted the same functionality at your "main()", which many beginning programmers might not figure out without looking at umain.c anyway, and for the most part (the CTRL-C stuff at least) it is well enough commented that it is fairly easy to disable both "features" if you choose. Dave
jbickers@templar.actrix.gen.nz (John Bickers) (05/23/91)
Quoted from <chopps.0625@ro-chp.UUCP> by chopps@ro-chp.UUCP (Chris Hopps): > In article <1991May20.020743.14630@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > The only problem with this is that the window that SAS/C opens is very > >small, and most certainly not large enough to display and "real" text, > > enough to alert you to the problem... What would be much nicer is plugging a single line error message ("can't open foobar.library", say) into the Workbench title bar, like Workbench itself does. Is there a nice way to do this? There are several advantages I can think of off-hand, as opposed to not using the DEFINE __main thing. * No annoying window. * No need to delay after displaying the error so the user has time to read it. * The user can recall the error message using the "Last Error" thing. * It fits in with the way Workbench works. The "version" program appears to be able to do this... > The Royal Oak Chophouse Chris Hopps -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***