Page 1 of 3

libauto and application.library

Posted: Thu May 08, 2014 9:39 am
by Daytona675x
Hi,
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

Re: libauto and application.library

Posted: Wed Jan 21, 2015 7:33 pm
by JosDuchIt
Just noted this thread.

I do use libauto, has this issue been fixed ?

How do you verify if you get version 1 or 2 interfaces ?

Re: libauto and application.library

Posted: Wed Jan 21, 2015 9:18 pm
by LyleHaze
JosDuchIt wrote:Just noted this thread.

I do use libauto, has this issue been fixed ?

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!

Re: libauto and application.library

Posted: Thu Jan 22, 2015 8:58 pm
by JosDuchIt
Got it.
Thanks

Re: libauto and application.library

Posted: Wed Mar 04, 2015 11:40 pm
by jaokim
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.

Re: libauto and application.library

Posted: Thu Mar 05, 2015 12:12 am
by LyleHaze
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.

Re: libauto and application.library

Posted: Thu Mar 05, 2015 5:14 pm
by xenic
LyleHaze wrote:
JosDuchIt wrote:Just noted this thread.

I do use libauto, has this issue been fixed ?

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??

Re: libauto and application.library

Posted: Thu Mar 05, 2015 6:01 pm
by xenic
Disregard my previous message. I forgot to specify version 2 in GetInterface(). Duh.

Re: libauto and application.library

Posted: Thu Apr 09, 2015 2:13 am
by mritter0
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

Code: Select all

if (!ApplicationBase || !LIB_IS_AT_LEAST((struct Library *)ApplicationBase,53,1))
{
    // error message
    return(FALSE);
}
Then close the library and re-open it with v2:

Code: Select all

IExec->DropInterface((struct Interface *)IPrefsObjects);
IExec->DropInterface((struct Interface *)IApplication);
IExec->CloseLibrary(ApplicationBase);
if (!(ApplicationBase=IExec->OpenLibrary("application.library",53)))
{
    // error message
    return(FALSE);
}
IApplication=(struct ApplicationIFace *)IExec->GetInterface(ApplicationBase,"application",2,NULL);
IPrefsObjects=(struct PrefsObjectsIFace *)IExec->GetInterface(ApplicationBase,"prefsobjects",2,NULL);
It appears libauto still closes the library.

Re: libauto and application.library

Posted: Thu Apr 09, 2015 8:05 am
by ZeroG
Simply build your own libauto, look at this nice script to learn how:
http://os4depot.net/index.php?function= ... ibauto.lha