Path: utzoo!attcan!uunet!mcvax!nikhefh!gert
From: gert@nikhefh.hep.nl (Gert Poletiek)
Newsgroups: comp.sys.atari.st
Subject: New ST ROMS (and breaking old applications)
Keywords: gemdos,patch
Message-ID: <525@nikhefh.hep.nl>
Date: 22 Aug 88 08:41:59 GMT
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 56

To Allan Pratt (are you listening????)

Would you mind telling the net which applications would break when Malloc is
fixed?

If old software breaks when Malloc is fixed, did Atari tell the developers of
those applications that their applications go bezerk on a fixed OS?

Why shouldn't serious developers have their software fixed in a reasonable
amount of time? Or is it that Atari does not want to loose applications of
companies that gave up the ST line long ago??

I believe that the OS should be fixed NOW, without looking back at all the
fancy stuff from companies that have gone out of the ST business. Atari won't
loose any important (read business [that's what atari is aiming for eh?]) 
applications: serious business applications are served better by providing a
reasonably well performing OS than support for backward comaptibility with an
OS that has so many weak areas.

And PLEASE, do provide documentation with it. Something like 'Inside ST;
telephone book edition' like for the MAC is what is needed. Look what chaos is
created now: lots of books are available for GemDos and all other parts of
the ST's OS. And all have sections in them that tell people that such and
such undocumented feature works this way or that way.

Atari should document it's OS (BTW they promised to have docs 2 years ago;
some outside company would do that; did that company drop the ST line too??)
and boldface print that 'this is what this call is for, and nothing else'.
If Atari does not do that you're bound to end up with ill behaving programs.
(Look for example at the old 'db' debugger of Mark Williams Co.: that didn't
work right on Mega roms because they had to do things that could not be done
with a system call, so they had to use some undocumented features...)

I don't think that developers are to blame for that (e.g, if I want to get
the current settings of the serial port and find that there is no call in the
OS to get me that information, I simply have to dig that out of the
Hardware): if there are OS calls to get something done developers will use
that, not their own work around.

And PLEASE, don't say that the OS is documented in the developers package. Even
the GemDos 'manual' that goes with it contains bugs.


Gert Poletiek

NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics
          Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands
UUCP:     {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert
bitnet:   nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet

From september 1st 1988:

Gert Poletiek  Dept. of Math. and Computing Science, University of Amsterdam,
               Kruislaan 409, NL-1098 SJ  Amsterdam, The Netherlands
UUCP:          {decvax,cernvax,unido,seismo}!mcvax!uva!gert
bitnet:        uva!gert@mcvax.bitnet, U00025@hasara5.bitnet