Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!cernvax!chx400!poole
From: poole@chx400.switch.ch (Simon Poole)
Newsgroups: comp.sys.atari.st
Subject: Re: UniTerm V2.0c and TOS 1.4
Message-ID: <1989Dec17.221248.26671@chx400.switch.ch>
Date: 17 Dec 89 22:12:48 GMT
References: <8912112347.AA10073@NARNIA.SAIC.COM> <25010@cup.portal.com> <8554@cs.yale.edu> <31623@iuvax.cs.indiana.edu> <25108@cup.portal.com>
Reply-To: poole@chx400.switch.ch (Simon Poole)
Organization: SWITCH Zuerich, Switzerland
Lines: 26

In article <25108@cup.portal.com> R_Tim_Coslet@cup.portal.com writes:
..............
>By the way, I think the real source of the problem is inside UniTerm (probably
>in the OSS Libraries, as you said)... sometimes after UniTerm bombs AES acts
>very strangely, and a reboot (either warm or cold) completely corrects this
>strange behavior.

This doesn't really supprise me since depending where the crash happens
a lot of stuff might not be (yet) in a state the desktop expects. Does
NewQueue do anything odd with memory allocation? UniTerm grabs all
available memory - 5k* (or whatever you have in the setup file) and
sometimes it seems as if GEMDOS memory allocation gets slightly confused
(which is not news to anybody). 

				Simon

* This is for the fileselector which doesn't check for enough memory
before it runs (I increased the value in on of the later revs because
the 1.4 fileselector needs a bit more (at least it did in the beta test
version).

-- 
------------------------------------------------------------------------
						Simon Poole
 poole@verw.switch.ch/poole@chx400.switch.ch/mcvax!cernvax!chx400!poole
------------------------------------------------------------------------