@geennaam

The date of my last surviving Update 6 backup is from 2013.
4.1FE ISO date is Jan 2015
So been a long time .

@Spectre660

I returned to the amiga scene just two weeks ago. Been away for at least 5 years. Now waiting for my X5000 and aoa4.1 Fe sam440ep edition to arrive. So for the time being I am stuck with 4.1 update 6. Will buy the enhancer software plus and other software as soon as I have the X5000 up and running.

But that aside. The Enhancer Software Core V1.1 requires 4.1 update 6 as minimum according to the readme. But that is clearly not the case. Unless the issue is located in the backend of the amisphere and updater software or there are unlisted/overlooked dependancies of the Enhancer core edition components.
I am not trying to blame anyone. Just writing down the observations and issues that I experience with the enhancer software core edition in the hope that it would solve my issue and help others who experience the same issue. And naturally there is also some frustration that my problem was ignored on both amigaworld and amigans until today.

In my opinion we are all in this together to try to make the best of the current situation.

@geennaam

I could try to test under 4.1 update 6 if I can get my backup to boot.

@geennaam

Quote:
I'm afraid you're right. Originally, Update 6 was indeed agreed on as the minimum requirement for the Enhancer, but that was years ago. Since then many people have joined the Amiga Developer team and have produced new Enhancer stuff. It's quite possible that, in the meantime, the Final Edition has silently become understood as the minimum common denominator. Which, by the way, makes every sense because Update 6 is really ancient, the Final Edition (especially after Update 1) is much better, and its price is in no way prohibitive.

So I guess we just need to change the readme

I suggest you change the minimum required release to the latest physical release: Final Edition, but without update 1 + 2.

@trixie

I would have expected that software still checks for the minimum version of dependancies.
Amiupdate also pushed Ibrowse 2.5.4. This version terminated with an message that my installion lacks graphics library V54.0. (So FE as minimum)

Maybe it is time to cleanup Amistore as well. I came across several other software that claim update 6 as minimum requirement.

Anyways, if eveything goes well then my X5000 will arrive on monday.

The cost of FE for the sam440ep might be only 30 euro. But it is almost everywhere out if stock. Alinea Computer in germany was the only one out of 6 stores that I tried who was able to supply this version.

Why would anyone not be on the latest version? It's not as if it's expensive.

Note however there's no dependency management in Amiga OS anywhere.

@NinjaCyborg

correct me if I am wrong but if you open a library then you should check for the version. This is afaik how it is supposed to be done on amigaos. Don't know how this works with classes and shared object (.so). Under the assumption that using classes and shared object work in a similar fashion then the program should exit in a clean manner with an error message if the minimum version of a dependancy is missing.

@geennaam

What are you talking about? I said, there's no reason for anyone to not be on the latest version of OS4

@geennaam

Quote:
You're right, such a check should be in place. I can see three reasons why it is not always the case:

1) The OpenLibrary() and OpenClass() functions only take the library/class version as parameter, not the revision. It needs an extra step to check for the revision, and some devs just don't bother to take it.

2) BOOPSI classes have seen rather tumultuous development in the past years, so it's easy for the programmer to lose track of which version of the class introduced which feature.

3) Many of the examples in the SDK link the program with -lauto, which opens the libraries for you (but without any version checking - it simply opens whatever is available) for the sake of making the code shorter. As the examples have served as learning material, new programmers might have inadvertently picked up a bad practice that is not recommended for serious software development.

Quote:
It's the same with classes because they are implemented as libraries. Not sure how you're supposed to check the version of shared objects because I never use them.

@NinjaCyborg

I replied to this part of your post:

"Note however there's no dependency management in Amiga OS anywhere"

@trixie

Version number is in the filename of the .so object, if don’t have file you don’t have the version, program does not start, that’s how works on Linux, the file without version numbers are soft links that point to file with version number. Bad programs will use the file without version numbers, but then elf loader will noticed that it has missing linking to functions.

Not sure about dynamically loaded .so files, programs that use .so files as plugin, however I know its documented.

I have noticed that Amiga developers put Amiga version strings into the strictly linked clib's *.a files, this is wrong as now program gets that version string from static linked library.

@geennaam

I’m not sure you need something as complicated a dependency management, it won’t be too hard to find the OS version, and check if the program supports it, and only download new package / lha if the program supports the OS version. not sure you need an extra DB, you put min version in the. lha filename.

If OS is updated, you need to bump the min os version, that is also problem as you need to recheck everything.

I think the bigger problem is remembering what stuff is supported in etch OS version and update, I’m afraid the only way you truly know if it’s not working is if people report problems. Simple solution is bumping the min OS version every time they make new software release, but that might exclude people, who might be able use it.

--- deleted ---