Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!apple!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: TOS
Message-ID: <1567@atari.UUCP>
Date: 16 Jun 89 18:02:30 GMT
References: <8906090105.AA10969@ucbvax.Berkeley.EDU> <1550@atari.UUCP> <4601@ttidca.TTI.COM>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 36

In article <4601@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside) 
writes:
> In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
> ...[edited]
> >Sversion() only gives the version number for GEMDOS, and that didn't
> >change between original ROMs and Mega ROMs.  The TOS version number is
> >available as the second word of the OS header, whose address can be
> >found at _sysbase, $4f2.
> 
> The GEMDOS version is changed with the release of TOS 1.4, I see from
> and earlier posting.
> 
> So, when software wishes to take advantage of TOS 1.4 features (such as
> the improved file selector), should the feature be enabled via the
> Sversion call, or a check of the OS header?
> -- 
> *George R. Woodside - Citicorp/TTI - Santa Monica, CA 
> *Path:       ..!{philabs|csun|psivax}!ttidca!woodside

You should use the version number appropriate to what you're up to.  If
you want to know if you have the new file selector, you definitely
should NOT check the GEMDOS version number.  AES and GEMDOS are not
inseparable.  Check the AES version number (it has one) or the OS
version number (described above).

You could check the GEMDOS version number to see, for example, if a
Dfree() call will take all day or not (old ones do, new ones don't).  It
is possible to have new GEMDOS but not new anything else (e.g.  with a
RAM-loaded GEMDOS, currently only used for internal development). 

It's best not to tie unrelated things, like the GEMDOS version number
and the file selector, together. 

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