Internal version number of OS4.1.1?

Hello, I want to take conditional action in my program based on whether OS4.1.1 (ie. "AmigaOS 4 Update 1") (or later) is present or not.

So, I need to know what the values of the lib_Version and lib_Revision nodes of version.library would be on OS4.1.1.

This information doesn't seem to be in the SDK or anywhere else.

Update 1: 53.2
Update 2: 53.3
Update 3: soon :)


But noting the different versions in the Autodoc seems to be a good idea, so I'll record this as enhancement request for hopefully the next SDK.

@Minuous

As far as i remember, Rigo with his CodeBench, do some kind of check in it for "did user have update2 or later or not". Dunno how he do it , but should to add, that by some strange reassons when i trying to install codebench few days ago on my update2, programm say "sorry, you do not have update2 or later" , or kind :)

In other words, there is some way, but dunno how right that way is.

@ kas1e

As Minuous implied with his question and myself with my answer, the way to identify a certain AmigaOS release is by checking the version and revision of version.library. That's the only viable and supported way.

Of course you could check for some other components known to first arrived in a certain AmigaOS release (like BOOPSI classes or so), but that's dangerous as users are much more likely to fiddle with any other component than version.library.

@kas1e

I think that what Minuous search is somethings different, he need some more info about OS4 versions to be able to support/not support certain functionalities availible in recent OS4 releases but not availible on the old versions

Somethings like, if version --> 53.x --> use URLOpen command, else --> use OpenURL.library

CodeBench checks the exec.library version. If any user starts to mess around with previous kernels on an installation, then they deserve exactly what they get :)

Simon

@Rigo
Quote:

:) Yeah, i think the same. But all what i change lately, its only kernel on kernel.debug , but very possible that from previous update, right :) Through, i was in hope to see something "your kernel are too old, need exec.library XXXX, mess with installation"? window, not just "yot not have update2" (while i have it, just kernel changed :) ).

Btw, why exec, and not version.library as Cyborg point ?

@samo79
Quote:

Of course. But if he want to use only 1 library changes, better just to check only that library. But if he want to check on whole update/version of OS (to make code not just "library funcs related" , but just because some parts of code can be just different since some update), then he need to know exactly update/version of os (and does not matter what libs user have) , and so then cyborg's answers about version.library, or rigo's way about exec.library.

But anyway, imho better to check on library version of all the libs which you want to use, and in case of non-correct version spawn a window "sorry, you not have xxx versino of xxx library, but you have xxxx instead".

Quote:

Maybe because exec.library is already open and thus don't need additionnal code just to check which version the OS is?

@abalaban
Quote:

Maybe. But as Cyborg say version.library are the main for that purposes, i assume that its good to use only it then. And opening a library to check a version, its can't be called "additionnal code", because if you even worry to check any libs version, its no matter opened library already, or add one more openlibrary/iface and dispatching in end.

Quote:

As I said, if you want to swap kernels around from distribution to distribution, you get exactly what you deserve. I'm actually surprised it works for you at all, as there are components in Update 2 that require features in the latest kernel.

Remind me to ignore any bug reports you may post...

Simon

@kas1e

Yep but in this case we are not talking about the number of a specific library but if a component is availible or not, this is the case of URLopen or Ringhio etc ..

@Rigo

Quote:

Sound a bit ungenerous to me :-/

Quote:

For Ringhio you can check application.library version.

For URLOpen you can check for the presence of C:URLOpen, l:launch-handler or that URL: is mounted. I'd probably check version.library for that though, as it's a bit "bitty".

Ot just assume everybody on v53 has kept up-to-date and tell them to shut up if things don't work :)

@Chris

Ok thanks for the tips

Quote:

Ungenerous? Yeah, so I'll take a bug report with an outdated Kernel and spend hours trying to find it. Shall I bill you for that wasted time?

No? How ungenerous...

Simon

@Rigo

No but write: "Remind me to ignore any bug reports you may post" after all the very useful work and reports from kas1e seems really excessive to me ...

I do not want to open any controversy aniway, just a consideration, so peace

OK, How about I re-phrase it then:

Remind me to consider any bug reports that you submit as NULL and void until you run the correct Kernel.

Does that sound better?

Simon

Well when you say "any" i think you mean "any"

If Kas1e used an old kernel you may be right considering this particular bug report as incorrect, but again you say "any"

At the end i still prefer somethings more kindly aniway ...

@thread

All these different ways to check for the O/S version don't sound all that consistent to me.

IMO there should be a function call on an interface somewhere (IExec?) called GetOSVersion.

It could return something like the following:
- public version number string (i.e. "4.1.1")
- major version (4)
- minor version (1)
- service pack/maint release number (1)

I use a win32 API call named "GetVersionEx" and it gives back similar information.

Having to decode library versions seems a bit hack-ish.

@Rigo
I think you a bit overreacted. You can be sure that when we worring about ppp-ethernet.device bug, setup was "right", without mess with kernel (at least if there was kernel.debug, then it of couse wat from the same update).

That bug about which we worry happens 2 years ago with very first version of OS4.1, and happens the same with every update and every update, so thinking that its because of mess in system are wrong for sure.

The reasson why i use kernel.debug, its because i do some code from time to time, but you can be sure i am adequate enough to make testing on normal setups, without mess. Just by some unluck trying to setup codebench on debug.kernel few days ago, nothing more.

I'm assuming 53.3 == OS4.1.1; if that isn't correct, please correct me.