Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!usenet.ins.cwru.edu!ncoast!davewt
From: davewt@NCoast.ORG (David Wright)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Dumb windows from SAS/C programs on Workbench
Message-ID: <1991May17.024020.1828@NCoast.ORG>
Date: 17 May 91 02:40:20 GMT
References: <1991May14.164909.19186@NCoast.ORG> <3770.tnews@templar.actrix.gen.nz>
Organization: North Coast Public Access Un*x (ncoast)
Lines: 36

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