Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: bios function 0x7f
Message-ID: <1268@atari.UUCP>
Date: 21 Dec 88 19:37:03 GMT
References: <1263@atari.UUCP> <3774@druhi.ATT.COM>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 32

In article <3774@druhi.ATT.COM> dlm writes:
> in article <1263@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says:
> > Great! This is exactly the kind of "It works, so use it" philosophy...

> 	It just thrills me to see Atari programmers saying they will
> break things just for fun.  But they are never petty or vindictive.

> ... Or the fact that 2 years ago an Atari programmer 
> said this was a useful feature and would be left in.

No, we're not petty or vindictive.  What makes you think we are? I
*didn't* say I would break things just for fun.  It is more than
possible that a future, seemingly-harmless change to the code in the
trap handler will make the described hack stop working. 

This issue illustrates the thing which has hamstrung improvements to the
OS from Day 1: whenever we talk of making something better, people
complain that they were relying on the old, undocumented, bogus
behavior.  Want to know why I can't speed up Pexec? Because people rely
on the entire heap, not just their declared BSS, being clear.  Want to
know why I can't get rid of Malloc limitations? Because people use
memory they don't own, and also rely on multiple Malloc's returning
contiguous memory. 

Who promised that this "feature" would be left in? I have been here more
than 2 years, and I never heard about it.  Worse, it was not commented
in the code, which is the final arbiter of what has been promised. 
Blame whoever made that promise, not me. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt