Starting with AmigaOS SDK 53.24, both Application Library interfaces (application and prefsobjects) must be at version 2. This is due to changes in the Application Library API which had broken standard tag support until version 2 interfaces were introduced.
But looks like libauto has not been updated to do so, you end up with a version 1 interface.
Not that it's important to me since I'm not using libauto anymore, but I remember running into trouble here back then.
Cheers,
Daniel
Warp3D driver code-basher and bug-smasher - btw.: driver writing is nothing mysterious
I was resurrecting an old project, which used application library interface v 1, and libauto, and this problem dawned upon me -- not in compile time, but in runtime!
I see and hear what you're saying about not using libauto, since you loose control over the versions. But in my honest opinion this rather sudden breakage of compatibility, is kind of... bad. In the application.library autodoc the reason for this is that the tag parsing code was broken -- fine, these things can, and will happen. But I don't understand why version 1 of the interface is so forcefully deprecated but, and brakes my application in runtime? Wasn't part of the reason for introducing the interfaces with versions, the ability to have several versions functioning in parallell?
I can in part understand the need to fully deprecate broken functions, but to introduce runtime errors for this is just very bad. Why am I not as a developer warned at compile time of this? I mean, this is a public API, and I'm not cutting any corners.
Even after I changed my code to manually open the application.library and interface -- like your'e supposed to do -- I got no warning or compile error, but instead this runtime error requester when using interface version 1.
To me the whole interface scheme, and in particular its versioning just seems very ill-designed. I mean, if my application is going to fail when using version 1, why not just make version 1 the same as version 2?
I'm sorry for being blunt, and I might not get all the technical details that motivate the interface scheme, but to break an API in runtime -- with re-compiled sources, just seems very broken to me.
My understanding.. Which may be wrong..
"Normal" progression of a library adds new features, increments library version, and as long as backward compatibility is intact, we all dance happily around the campfire.
"Normal" use of interface pointers allows the collection of functions under specific namespaces.. And multiple interfaces for specific groups of additional stuff.. Like IPCI.
But this specific case involved a library using tag defines that were not in the correct ranges for the OS tag functions to work properly. So the decision to create a new interface was unfortunate, but still better than abandoning application. Library in favor of newapplication.library... We're just doing the best we can to correct an oversight. If my understanding is wrong, I trust that smarter people will correct me.
How do you verify if you get version 1 or 2 interfaces ?
I don't use libauto for just that reason.. you lose control over versions.
But if you already have an Interface and you want to know what version it is, try
if(1 == IInterface->Data.Version)
{
}
or something like that
Have Fun!
I just checked the Interface version for application.library and it was version 1. I used this with OS4.1FE:
IDOS->Printf("Application Interface Version: %ld\n", IApplication->Data.Version);
Did somebody forget to change the Interface version for application.library?? If so then you might need to check the library version instead. However, you would need to know at what revision the application.library tags were changed. Does anyone know what library version and revision to check for??
I just added application.library support to my program and had the same concern with libauto. Tested like Lyle suggested, still opening v1. I got a huge pop up error about it when ran my program.
I came up with a solution (hack) for libauto:
After verifying that the correct version of application.library opened