Old AmigaOS 4 versions and new software

When I released MediaVault I got some feedback that the app doesn't work on some people's systems, which proved that they didn't use the latest version of AmigaOS 4.1 FE for their own reasons.

Those discussions, although they can be bypassed with a simple reply "Sorry, it supports only the latest version...", still trouble me.

Most of the developers would like to use the latest implementations, with the latest versions of available tools, with the latest updates. And that is happening for many reasons, like it is really exciting to use new stuff.

There are a few questions in my mind that I'd like to discuss with you.

How many are using older versions of AmigaOS 4 on their main computer?

Should the developers have backward compatibility for those versions, so as to not exclude these people, even if that increases the complexity of the application? Does it justify the effort?

Should the developers use only the latest features so to push more people to update their computers?

What's your opinion?

@walkero

Not a dev so take my thoughts with a pinch of salt.

A lot of our software is the result of one dev or small teams of devs.

If we were to add that further complexity of supporting older systems, what is the downside?

More time needed so some projects wont happen due to lack of time interest on the part of the dev(s)?
Slower development time of projects taken on by dev(s)?

All things being equal and we had big teams of devs like the mainstream OS's, I would suggest as much backward compatibility as is feasible.

In our world, I think that would be a big ask.

Cheers

@walkero

Old version normally have old libraries or other dependant parts as well.

No way to keep your code maintained to workaround flaws, bugs and missing features not present in those outdated releases.

So, no, never go that path.

Add a disclaimer that your programs always need the latest OS and updates and you're good

@walkero

you need to knowing when something was added in what version, it was added.

In SDK it also suggests using interface 2 in application.library, because the SDK no longer support interface 1, this means you must compiling it with a older SDK, to support older platforms.

I think will be up to some of the users of this systems, to maintain backwards compatibility. Or special builds for special systems.

@Walkero

I'd say target only the latest os4.
It's so cheap to upgrade so there's no reason to not do it.
Some people might have some mixed components from older versions because they feel they have some problems with later components but it's not easy to support them eighter.

Possibly a distinction could be made between those who still use the old AmigaOS 4.0 (how many?) and those who use AmigaOS 4.1 instead ... but for those who use OS4.1, since it does not even require any expense there is no valid reason not to update their system to the latest release...

In general I see no reason not to update your system, on the contrary writing software that takes advantage of the new features/fixes is an incentive for users to update

@walkero
In my opinion, developers should care about and support the most recent versions of publicly available libraries. The most recent updates to libs and to the whole OS fix critical bugs, without which software will function incorrectly or not at all. And again, IMHO, it is preferable not to allow your program to run on any version lower than what you require. For example, with GL4ES, we specially added version checking to ogles2 and warp3dnova, so we will not have bug reports that something does not work, only to realize later that the user is using some 20-year-old library, which has since had hundreds of updates.

Our updates in the OS are not a "bloated mess of things we don't need" like on some mainstream OSes; our updates in the OS are bug fixes (some of which hit every user, and there are tons of reports about them), improvements, and better stability, without which some parts of the OS just work wrong or not at all.

If you support an old version of anything, you only create a mess for yourself and the OS developers. Quite frequently, there are reports that "something does not work!" or "there are bugs!" and then, step by step, you realize that it does not work on some users' setups because it uses very old versions of some libraries, and your apps, of course, do not work as expected.

Why should you downgrade your software if developers are working hard in their spare time to add features to the OS for the purposes for which they are intended to be used, rather than skipping them because someone wants to run on OS 4.0 update 1? If the user chooses not to update, he should take the risk that most of the new software will not work for him.

Supporting old versions of operating systems or libraries does not encourage developers to work harder on improvements and bug fixes or users to upgrade and report bugs, which only serves to improve the overall experience. Some users will undoubtedly prefer to remain on OS 4.0 and use a Radeon 9250; however, they should not expect others to wish to remain on the same level, even on our obscure platform, indefinitely.

All in all, why should you make it harder for yourself just to please a user who does not want to update and feels that it's you who need to care about his unwillingness to update some libraries?

Yup, it depends of the new/updated feature IMHO.

If such feature is somekind of WIP/beta/testing, well is up to the coder to add it.

In the other hand if such "updated feature" has been there since looong time, even if it isn't used on "general", then she/he can warn/say "dont' use if if you are not uptodate, stick with old working version". Or if the coder wants to support old/new/beta featires on same programm, then it's upto her/him.

my 2 cents (aka my own opinion).

From a developer stand point I'd say it's up to you to decide what you do or do not support. It's not like we are developing commercial software and making all kinds of money in this market. We are doing it for the enjoyment, so we should develope in the manner we enjoy developing. If adding backward compatability is something you enjoy the challange of and think is important, there should be nothing stopping you from doing it. Personally I just use the features I need to add the features I want to add. Having said that, I have refrained from using new enhancer features up to this point because, it's not a standard part of the OS. I would like to use some of the new enhancer features but at this piont I don't want to spend the time to use them and also put the effort into backward compatablity. As time goes on I'm getting closer to feeling like I would like to use the enhancer features, especially if it makes the implementation of a feature a lot easier, but so far I haven't and if I do, I do not plan to add extra code to keep backward compatability.

As a user, I keep my system up to date with the latest enhancements, including the enhancer package, and enjoy using the newer features. I don't expect new program to be backward compatable. It's unfortunate that enhancer route had to be taken to contuine forward progress on the base OS but given the situation, it seems to be the only way to move the OS forward. I do appreciate programs that take advantage of it though and wish more people would embrace it.

@walkero

After all these years, I would not expect a programmer to support AmigaOS 4.0.

In general, I think it makes sense to target the most recent publicly available version of AmigaOS4.

So, for now that would be AmigaOS 4.1 FE Update 2

For example, if a new program requires Enhancer components, then it would be polite to specify that in the requirements.

For example, one program I use needs several of the Enhancer Core classes. These requirements are specified in the docs and on OS4Depot.

In my own case, I am limited by my hardware.

My MicroA1 is an excellent little system for my needs, but I am limited to the onboard Radeon 7000 graphics and 32 MB video ram.

I am running AmigaOS 4.1 FE Update 2 plus selected bits and pieces from Enhancer Software 2.2


---
redfox

@walkero

BTW, today I downloaded MediaVault and WOW!!

Thanks so much.

---
redfox

If I've originally written something for an older OS version I will try to keep the compatibility in - unless I've had to rewrite it due to OS bugs. If an update is free it doesn't make much sense to retain compatibility with the previous update.

If in writing something new it will always be for the latest version, and then I'll work out later if it actually uses new features 😀 - if not it should be compatible with older versions but may not stay that way.

If I'm writing for OS4 and OS3 then the compatibility workarounds for OS3 tend to mean it works on old OS4 too.

It's usually not worth expending effort supporting old versions of the OS, but if you've written the code already and it's easy to do so, leave it in.

@walkero

OS4.1 Final Edition has been around for many years and its price was in no way prohibitive. Update 2 is free, so I believe the developer can make a safe bet that OS4.1 FE Update 2 is the system most if not all OS4 users have installed. As others have pointed out, keeping backwards compatibility can be tedious, and in our tiny ecosystem, developer time and energy are limited.

@walkero

As a user, I don't always immediately upgrade to the latest version of something, as for every bug it fixes and new feature it adds, it also may break something or add new bugs. For example, I stayed with OS 4.1.6 for some time after FE was released, because the initial incarnation of FE was rather buggy. It was only after Update 1 came out that I switched to FE.

As a developer, I try to keep users like me in mind when writing software, and generally make some attempt at supporting older versions of the OS/libraries/MUI/whatever. I try to avoid using conditional code to add backwards compatibility, as it makes the code hard to read and maintain. But if I can use a DOS function that only supports 32-bit file sizes, for example, when I know that my application will never generate files large enough for that to be a problem, then why not? Likewise, does that gee-whiz new feature really add value to the user, or would the program be just as useful -- though maybe less sparkly -- without it?

If there's a compelling reason to use the latest version of something (for example, it fixed a bug that my application can't reasonably work around, or it adds a useful new feature that it's not practical to reproduce some other way) then I'll certainly do so. But I'll also at least look at whether I can work around the bug, or if I really need that new feature.

Balanced against all that is the stark reality that there are far more Amiga programs that need to be written than there are developers to write them, so whatever makes it most efficient (and enjoyable, since most of us are not in it for the money) to work on Amiga software is the way to go. If for any given programmer that means only using/testing with the very latest version of everything, then so be it. But please do publicize the requirements so no one will be caught by surprise, and have the program display a helpful error message and safely quit if it encounters an outdated version of something, rather than crashing or not working properly.

@walkero

Quote:

We know how I got stuck on that one.

Before I checked I thought MediaVault was NAS manager app. LOL.

Did they say how it didn't work? Or was it an obvious version fail and error?

I tend to think support the minimum you need. I wrote a few 68K commodities back in day and the minimum I supported was OS2. Now by the time I wrote them I was fully established on OS3 so wouldn't have wanted to use them myself on anything less. But they didn't need anything more than v37 in the code so didn't require it. Even my simple installer scripts were coded to use different components depending on what version was used.

These days I prefer OS4 coding but even then I keep old stuff in just in case it runs on an older version. Since if it doesn't need a new version I don't want to demand it. For example there is a particular version of Exec where allocating memory with AllocSysObject() has a bug because it doesn't clean the memory when it should so extra tags needs to be given. I suppose it's a slight kludge as I need to check for it but it's been there for years.

@LiveForIt

Quote:

In particular application.library as there was an obvious error in interface 1 that every one missed.

I found even trying to use version 1 gave me compiler error. Knowing the ramifications of it when I added support for it in a project I decided only interface 2 was supported. If it failed that feature just didn't work. Since it wasn't required by the main code. I just wanted to use it for notification so no big deal if it didn't open.

@smf

Quote:

I am one of those people. And I don't have mixed feelings on the matter. When I found Update 2 had a hardware conflict with my video card I had to mix an older Kickstart back in. So for me it's a fact I have problems. Sure, I could put my old HD5450 back, with no 3d. But, I had bought my R7 250 new AFAIK, because I found it had 3d support. I could locate an old card but I spent time locating a new card for my X1000 system. It still wouldn't solve the issue of why Update 2 conflicts with my card. But, boy can I pick 'em!

@Hypex
When you have found hardware conflict, it need reporting and fixing of course ! But someting make me think that you just on very old RadoenHD lite version, which need to be replaced on latest Radoen HD Lite, or on normal full RadeonHD driver, and there will be no conflict.

As you have it now, you can't expect that most software will works ok for you and devs should know that when you report any bugs about anything that your system is combain of all sort of different components from different updates .

Quote:

Was it reported anywhere ?
Did you create already boot iso with latest RadeonHD lite , or with just latest RadeonHD driver ?

@All
That exactly an example why you not need to worry about older versions of everything, because in all the case one who have older version of something, have a mess on their setups no one else have, and your programm can act differently.

this summer I returned to the Amiga after 10 years of absence due to lack of time. very soon I found that the amigaos I left in version 4.1.3 had evolved and newer versions of old programs as almost all newer programs did not work on my system. two months ago I upgraded my sam440ep to 4.1fe and today I upgraded my pegasos2. I believe that upgrading to os4.1fe is necessary. at the same time I upgraded both my a3000 and my a1200 to os3.2. the differences between the two systems are big. I would like hyperion to bring the two systems as close as possible.

I think in our little community it is reasonable to develop for and state that an application will run on a base of AmigaOS 4.1 Update 2. I don’t see the point of running an older version of the OS on this particular platform.