chu@acsu.buffalo.edu (john c chu) (10/05/90)
I remember a while back there was a thread about things to be aware of when writing Desk Accessories. Stuff about mallocing, file pointers, what happens to the DA when a program terminates etc. Of course, I wasn't paying too much attention to it at the time and now I need the information. So, can someone out there please email me that material and any other "do's and don'ts" of Desk Accessory writing? Thanks. john chu@autarch.acsu.buffalo.edu
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (10/06/90)
In article <39204@eerie.acsu.Buffalo.EDU> chu@acsu.buffalo.edu (john c chu) writes: >I remember a while back there was a thread about things to be aware of >when writing Desk Accessories. Stuff about mallocing, file pointers, >what happens to the DA when a program terminates etc. Of course, I >wasn't paying too much attention to it at the time and now I need the >information. I think the easiest summary is "don't keep any operating system resources tied up when you call evnt_multi". That means no mallocing and no open files. Then the only exception is that you can malloc memory right when you start up, before you call evnt_multi for the first time. [In that case the memory becomes owned by the desktop, which never exits, so the memory never gets deallocated.] Of course, if you're running RTX or Mint, you can do more. Then you can arrange for another process to allocate memory or leave files open. -- "Restraint, hell. I'm just too fucking busy." -- Bill Wisner
steve@thelake.mn.org (Steve Yelvington) (10/06/90)
[In article <1990Oct5.175429.3070@murdoch.acc.Virginia.EDU>,
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes ... ]
> In article <39204@eerie.acsu.Buffalo.EDU> chu@acsu.buffalo.edu (john c chu) writes:
>>I remember a while back there was a thread about things to be aware of
>>when writing Desk Accessories. Stuff about mallocing, file pointers,
>>what happens to the DA when a program terminates etc. Of course, I
>>wasn't paying too much attention to it at the time and now I need the
>>information.
>
> I think the easiest summary is "don't keep any operating system
> resources tied up when you call evnt_multi". That means no mallocing
> and no open files.
I'm the one who raised this question a couple of months ago.
I've mailed off to comp.binaries.atari.st a completed desk accessory
for filtering MicroEMACS files into a format suitable for PageStream.
It should show up on the net Real Soon Now.
Because of the limitations on calling Malloc(), I wound up simply
tossing out the idea of vacuuming a whole file into memory before
massaging the data.
I thought I'd just use fgets() and fputs() ... but you can't do that,
either, at least not with Sozobon C, because dLibs has dynamic memory
allocation buried deep in the buffered i/o routines.
I didn't feel up to rewriting the whole buffered i/o library, so I made
do with two routines (see below) that make direct GEMdos calls. The
reading routine is horribly slow, but that doesn't seem to be a practical
problem in the DA I wrote.
The functions follow. PPerhaps someone else will find them useful.
#include <osbind.h>
/*
* Function: fhgets
* Input: Pointer to data buffer, limit on the length of the buffer,
* and a vald open GEMDOS file handle.
* Output: Fills in the data buffer if possible. Returns a pointer to
* the buffer, or NULL if end of file has been reached.
* Description: fhgets is like fgets, but it works (s-l-o-w-l-y!) from
* GEMDOS file handles. We have to write this because dLibs has
* memory allocation deeply rooted in the stdio package, and
* we want this program to run as a DA, which must not
* hold mallocked memory.
*/
char *fhgets(data,limit,fd)
char *data;
register int limit;
int fd;
{
register char *p = data;
char c[1];
register int bytes_read;
while(--limit > 0)
{
if ((bytes_read = Fread(fd,1L,c)) < 1)
break;
if ((*p++ = c[0]) == '\n')
break;
}
*p = '\0';
return((bytes_read <= 0 && p == data) ? NULL : data); /* NULL == EOF */
}
/*
* Function: fdputs.
* Input: pointer to a null-terminated array of char, and a valid open GEMDOS
* file handle.
* Output: Sends the string to the file and returns the number of bytes written.
* Description: Works like fputs. A newline is not appended.
*
*/
int
fhputs(s, fh)
char *s; int fh;
{
return (Fwrite(fh,(long)strlen(s),s));
}
--
Steve Yelvington up at the lake in Minnesota
Internet: steve@thelake.mn.org
UUCP: {plains,rutgers,apple,cray}!umn-cs!thelake!steve