AmigaOS 3.2 and beyond

[alancfrancis]

I think V50 is AOS4.0 ?

[bubbob42]

Originally Posted by Matt_H

Out of curiosity, what are your internal criteria for bumping up the internal version numbers? In other words, what makes 3.2 v47 instead of e.g. v46.5?

Finally a question about numbers that's not tainted by politics/thingswemustnottell.

For libraries: We bumped to V47, because we extended the API with new Tags, Functions, etc. The version bump is needed so programmers who would like to use the new functions could be sure they would be present by requesting version 47 as minimum when calling OpenLibrary().

For other components: Many updated or new programs of OS3.2 also use the V47 API, so they were bumped as well.

[Debvgger]

Liking 3.2 so far, thank you very much for your work.

[Olaf Barthel]

Originally Posted by Matt_H

Out of curiosity, what are your internal criteria for bumping up the internal version numbers? In other words, what makes 3.2 v47 instead of e.g. v46.5?

As Marcus already mentioned newly introduced operating system API dependencies are the best single criterion.

A weaker criterion are functional changes which are made to an older component, and this updated component then becomes part of a new operating system release. Commodore did that with scsi.device, for example, in Kickstart 3.1. Not all Kickstart ROMs would use scsi.device V40, but would use an older version (V39) instead.

[Romanujan]

Originally Posted by Phantasm

Versions 50+ are already in use as Kickstart 4 and software could easily get confused when requesting specific versions of libraries if they ask for v50 (or higher) of a particular library assuming that they are getting a kickstart 4 (compatible) version.

I wonder how many M68K software behaves like this.

[Warty]

Originally Posted by alancfrancis

I think V50 is AOS4.0 ?

See, this is why I'm always happier just ignoring the existing of 4.x and pretending it never happened.

I see the problem though, thanks.

#define MINVERSION  40

Hmm. Maybe it would be ok to leapfrog the 50s, and go to 60 at some point? (is 4.x in active development still? Or even just tack on a 100, so it goes 47, 48, 49, 150, 151?

Seems to me the team is making pretty significant changes with 3.1.4 and 3.2, so it's not really an academic exercise: you're going to hit the limit of 50 within 5-6 years at current pace, no?

My CD came today, and let me say this: Great job on the installation doc! I especially like the back inside cover.

Does anyone know why there is no FAQ available on the Hyperion site? The front page says it's available to registered users, but I'm registered, and I don't see anything in the downloads section or FAQ section??

[Romanujan]

Originally Posted by Warty

See, this is why I'm always happier just ignoring the existing of 4.x and pretending it never happened.

I don't know what the developers intend to, but IMHO there is no good, universal solution possible. I fear there will be some versioning changes which will prevent old (classic) software from properly reporting library versions (they will show something like 49.xx even on OS 3.12 in the distant future) - not fun at all.

[Phantasm]

Originally Posted by Romanujan

I don't know what the developers intend to, but IMHO there is no good, universal solution possible. I fear there will be some versioning changes which will prevent old (classic) software from properly reporting library versions (they will show something like 49.xx even on OS 3.12 in the distant future) - not fun at all.

The problem with that is that when you request a minimum version of a library using openlibrary at the moment you only have the option of specifying the major part of the version number - you cannot request eg you want 49.32 as a minimum. This could be changed I guess but it leaves little option for separating out major and minor releases. You could move to a multi-part version numbering system eg 49.1.1 49.2.1 etc i guess but i've no doubt that whatever the devs decide to do it will be a significant change and will end up breaking something as that probably can't be helped

[Minuous]

You can check the lib_Revision field of the library after opening.

[coldacid]

Can always start treating the `version` argument to OpenLibrary as signed and start over again from LONG_MIN!

[wiser3]

How about we jump from v49 to v60. Yeah it screws over OS4.x stuff, but there isn't much of it and that's ok with me.

[Warty]

Originally Posted by Olaf Barthel

Can't think of a reason why it won't

Come to think of it, I don't remember if we actually baked a SuperKickstart disk as part of the distribution. Hm... but https://aminet.net/util/misc/MakeSuperDisk.lha should see you through.

Has anyone got this working yet?

I dug out an old PowerCD I found in a dumpster 15 years ago and after installing AmiCDFS on my 1.3/3.1 A3000, the 3.2 disk loaded right up. Installation was smooth. (after rebooting some interesting things happened, LoadModule didn't like my AMAX partition, but... )

However, when I put the super kick I made from my bonus code and from the kicka3000.rom file into DEVS/ as "Kickstart", and reboot, it get flashing yellow screen after a while. I also made a super kick 1.3/3.2 disk, and that doesn't work either. I reverted to the 3.1 kick in DEVS, and computer comes up fine.

file size of the 31 superkick is identical to file size of 32 super kick. 526848.

I used that same kicka3000.rom file with UAE and didn't have any trouble.

[Romanujan]

Originally Posted by wiser3

How about we jump from v49 to v60. Yeah it screws over OS4.x stuff, but there isn't much of it and that's ok with me.

Precisely (or re-use 50.x version). OS 4 never really took off, OS 4.2 development was announced nearly a decade ago and is still not available, Tabor was announced 6 years ago and is still not available, probably not much 68k software can utilize 50.x extra features. IMHO the most problematic might be some installers, trying to install PPC binaries - but this isn’t anything unfixable.

[Ulysses13]

Add a zero and go to 500.

Avoid bumping into established canon by travelling into the far future, just like Star Trek Discovery...

[Olaf Barthel]

Originally Posted by Ulysses13

Add a zero and go to 500.

Version numbers of libraries cover the range of 1..255 for now unless program code uses the exec.library/MakeLibrary function (which is rarely used because there is a more convenient way to accomplish this). The limitation is in the 'Resident' structure:

struct Resident {
    UWORD rt_MatchWord;	/* word to match on (ILLEGAL)	*/
    struct Resident *rt_MatchTag; /* pointer to the above	*/
    APTR  rt_EndSkip;		/* address to continue scan	*/
    UBYTE rt_Flags;		/* various tag flags		*/
    UBYTE rt_Version;		/* release version number	*/
    UBYTE rt_Type;		/* type of module (NT_XXXXXX)	*/
    BYTE  rt_Pri;		/* initialization priority */
    char  *rt_Name;		/* pointer to node name	*/
    char  *rt_IdString;	/* pointer to identification string */
    APTR  rt_Init;		/* pointer to init code	*/
};

This is what's being used when a library or device is loaded into memory and initialized. No workaround for this limitation is available yet, but, as I mentioned, we have a few ideas on how to resolve the version numbering issue

[Olaf Barthel]

Originally Posted by Warty

Has anyone got this working yet?

Not yet. We have a good idea now as to what's going on (the MMU setup which makes the SuperKickstart resident gets wiped out when the Kickstart is initialized for the first time). This still needs a bit more research & development, I'm afraid

[Daedalus]

Regarding OS4, there's still a small amount of development going on, with the most recent update being released just before Christmas. It's currently using V54.x components.

I happen to use 68k software that's OS4-aware, so there's definitely software that could fall foul of such a versioning conflict unless it's somehow worked around.

It's not ideal, but OS4 has a concept of API versions, which means a single library can have multiple different interfaces, which allows overlapping and potentially incompatible functions to be segregated. If no specific interface version is requested, you get the old 3.1-style interface for compatibility with older software, and to use newer versions of the functions, you need to request an appropriate API version. Perhaps a similar scheme could be adopted, or even the same scheme, with the 68k exec defaulting to requesting a specific 68k interface version?

[E-Penguin]

----- Library Base Structure ----------------------------------*/
/* Also used for Devices and some Resources */
struct Library {
    struct  Node lib_Node;
    UBYTE   lib_Flags;
    UBYTE   lib_pad;
    UWORD   lib_NegSize;	    /* number of bytes before library */
    UWORD   lib_PosSize;	    /* number of bytes after library */
    UWORD   lib_Version;	    /* major */
    UWORD   lib_Revision;	    /* minor */
    APTR    lib_IdString;	    /* ASCII identification */
    ULONG   lib_Sum;		    /* the checksum itself */
    UWORD   lib_OpenCnt;	    /* number of current opens */
};	/* Warning: size is not a longword multiple! */

Scope for using the revision field? Should be good all the way through to V49.255...

[Daedalus]

In other news, there's a behavioural thing with 3.2 that I find a little odd: dragging an icon into the Shell window to enter the icon's path is a nice feature to welcome back, but the Shell window doesn't get activated when the icon is dropped, meaning I'm repeatedly caught out, typing the rest of my command into the ether. Both OS 3.9 (ViNCEd) and 4.1's Shell windows are activated when you drop an icon in, and I can't think of any reason why it would be preferable to leave the icon's window active instead. If you were going to manipulate more icons, you'll click the window and activate it during that operation anyway, whereas if you're using the Shell, chances are you're going to want to at least press enter after dragging in an icon, if not type some more. Any chance this behaviour can be changed?

[ProfPlum]

Hi folks.

I received my copy of OS 3.2 yesterday and installed it last night.
On my A2000 with Vampire V500+ v2, setpatch causes a guru.
This is with the A1200 3.2 rom mapped (vampiremap).

Other than that, all is fine.

Anyone experienced the same issue and is there a workaround?

Thank-you.