libauto and application.library

Have a question about our Software Developer Kit? Ask them here.
User avatar
Daytona675x
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 34
Joined: Wed Jan 22, 2014 5:18 pm
Location: Cologne, Germany
Contact:

libauto and application.library

Post 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
Warp3D driver code-basher and bug-smasher - btw.: driver writing is nothing mysterious
JosDuchIt
Posts: 291
Joined: Sun Jun 26, 2011 5:47 pm
Contact:

Re: libauto and application.library

Post 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 ?
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: libauto and application.library

Post 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!
JosDuchIt
Posts: 291
Joined: Sun Jun 26, 2011 5:47 pm
Contact:

Re: libauto and application.library

Post by JosDuchIt »

Got it.
Thanks
User avatar
jaokim
Beta Tester
Beta Tester
Posts: 90
Joined: Sat Jun 18, 2011 12:41 am

Re: libauto and application.library

Post 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.
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: libauto and application.library

Post 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.
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: libauto and application.library

Post 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??
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: libauto and application.library

Post by xenic »

Disregard my previous message. I forgot to specify version 2 in GetInterface(). Duh.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: libauto and application.library

Post 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.
Workbench Explorer - A better way to browse drawers
User avatar
ZeroG
Posts: 124
Joined: Sat Jun 18, 2011 11:31 am
Location: Germany

Re: libauto and application.library

Post by ZeroG »

Simply build your own libauto, look at this nice script to learn how:
http://os4depot.net/index.php?function= ... ibauto.lha
Post Reply