VBRANDT@DBNUAMA1.BITNET (06/12/89)
In Info-Atari16 Digest #276, imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) writes: >When TOS 1.4 becomes available to the general public, it'll be pretty >obvious from the Desktop Info box what its name should be. Don't forget that many people only have a monochrome monitor. :-) > ... it might be worthwhile to have a >"version-checking program" so that people can know what TOS version >they're actually using. ... It definitely might be useful. Unfortunately, most software checks the version date. For example, the ICD hard disk driver knows about the Beta ROM date, but fails to recognize my 1.4 version, which is dated Feb 22, 1989. Also, in Digest #277, he writes: >In article <801@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes: >:The Sversion() Gemdos function allegedly provides this information, but on my >:STFM it returns a value of 0.19. Does anybody know whether Sversion() really >:works? >Hmm, Sversion is returning a float value? Hmmm... ;-) >Sversion() returns the GEMDOS version number, not the TOS version. The >GEMDOS version number for your machine should be 0x1300 (our version >numbers are all WORD values); I'm not sure how you get 0.19 from that,... Many shells display it that way, there's a logical explanation which I had figured out at one time. ;-) >but... In any case, the TOS version number is in the OS header. To >get the TOS version number, use the pointer to the OS header (sysbase) at >0x4f2. The TOS version number is the second word of the OS header. Does anyone ever check there ?? I doubt it. Since Atari documented Sversion() as "the OS version call" (and the IBM equivalent *does* return the current OS version number), many people relied on that call. >To add to the version number confusion, the AES has its own version >number too (returned in global&0a on appl_init)! To add even more, what now is the *real* TOS 1.4 version, the one dated 22-02-1989, the one dated 04-06-1989, or the one I'll get next week, with a version date somewhere in May ?? :-) :-) :-) All have $0104 coded in the ROM header, as they should. The only possible way for a program to tell them apart is by checking the ROM header date code. >Can you now see why we don't like to give OS releases specific version >numbers? ;-) Yeah, quite. We need a little version checker program, authorized by Atari. PS: Whatever happened to that environment-setting accessory ? It could pop up a little dialog, telling us: TOS/GEMDOS/AES version # and date code. ---------------------------------------------------------------------------- Bitnet: VBRANDT@DBNUAMA1 Volker A. Brandt UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt Angewandte Mathematik ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU (Bonn, West Germany)
andyc@hplsla.HP.COM (Andy Cassino) (06/13/89)
| | Unfortunately, most software checks the version | date. For example, the ICD hard disk driver knows about the Beta ROM date, but | fails to recognize my 1.4 version, which is dated Feb 22, 1989. | Yikes! Does this mean that my ICD host adaptor won't work with TOS 1.4 until I get a new rev of ICDBOOT??? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Andy Cassino % % uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com % % Hewlett-Packard Lake Stevens Instrument Division % % 8600 Soper Hill Road Everett, WA 98205-1298 % % (206) 335-2211 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
kbad@atari.UUCP (Ken Badertscher) (06/14/89)
In article <5440035@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: | | | | Unfortunately, most software checks the version | | date. For example, the ICD hard disk driver knows about the Beta ROM date, | | but fails to recognize my 1.4 version, which is dated Feb 22, 1989. | | | | Yikes! Does this mean that my ICD host adaptor won't work with TOS 1.4 until | I get a new rev of ICDBOOT??? ICD did A Bad Thing. Actually 2 bad things. First, they shouldn't have released ANY software that relied on ANY Beta TOS releases. All developers who got early releases of the latest TOS were warned and foresworn not to base any software on any features of the intermediate release; we sent it out to allow them to test their existing software. DON'T BASE ANYTHING IN YOUR SOFTWARE ON INTERMEDIATE OS RELEASES. Second, they shouldn't have based anything on the date of the TOS ROMs. As I have said before, there are three supported OS releases; ROM TOS, Mega TOS, and the one that is forthcoming. Each has a different OS version number in the OS header. ROM TOS and Mega TOS have the same GEMDOS version number, because GEMDOS didn't change between those OS revisions. What's worse, dates in the OS header will vary from country to country, so by checking OS header dates, you not only make your software version dependant, you make it country dependant as well. USE THE OS VERSION NUMBER, NOT THE OS DATE, IF YOU MUST CHECK OS VERSIONS. 'nuff said. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
kbad@atari.UUCP (Ken Badertscher) (06/14/89)
In article <8906121449.AA01174@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET writes: | Don't forget that many people only have a monochrome monitor. :-) Indeed... ;-) | Does anyone ever check there ?? I doubt it. Since Atari documented Sversion() | as "the OS version call" (and the IBM equivalent *does* return the current OS | version number), many people relied on that call. Honk. Wrong... Sversion is documented as follows: "Return GEMDOS's (sic) version number (in byte-reversed format).... GEMDOS version numbers and TOS version numbers are *not* one and the same." Thanks for your support. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>