libauto and application.library

Have a question about our Software Developer Kit? Ask them here.

libauto and application.library

Postby Daytona675x » Thu May 08, 2014 10:39 am

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
User avatar
Daytona675x
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 34
Joined: Wed Jan 22, 2014 6:18 pm
Location: Cologne, Germany

Re: libauto and application.library

Postby JosDuchIt » Wed Jan 21, 2015 8:33 pm

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 ?
JosDuchIt
 
Posts: 286
Joined: Sun Jun 26, 2011 6:47 pm

Re: libauto and application.library

Postby LyleHaze » Wed Jan 21, 2015 10:18 pm

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!
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 507
Joined: Sat Jun 18, 2011 5:06 pm
Location: Georgia, USA, just North of the Florida border

Re: libauto and application.library

Postby JosDuchIt » Thu Jan 22, 2015 9:58 pm

Got it.
Thanks
JosDuchIt
 
Posts: 286
Joined: Sun Jun 26, 2011 6:47 pm

Re: libauto and application.library

Postby jaokim » Thu Mar 05, 2015 12:40 am

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
jaokim
Beta Tester
Beta Tester
 
Posts: 89
Joined: Sat Jun 18, 2011 1:41 am

Re: libauto and application.library

Postby LyleHaze » Thu Mar 05, 2015 1:12 am

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.
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 507
Joined: Sat Jun 18, 2011 5:06 pm
Location: Georgia, USA, just North of the Florida border

Re: libauto and application.library

Postby xenic » Thu Mar 05, 2015 6:14 pm

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: 1020
Joined: Sun Jun 19, 2011 1:06 am

Re: libauto and application.library

Postby xenic » Thu Mar 05, 2015 7:01 pm

Disregard my previous message. I forgot to specify version 2 in GetInterface(). Duh.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
 
Posts: 1020
Joined: Sun Jun 19, 2011 1:06 am

Re: libauto and application.library

Postby mritter0 » Thu Apr 09, 2015 3:13 am

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
mritter0
 
Posts: 184
Joined: Mon Aug 25, 2014 10:41 pm
Location: Bettendorf, IA, USA

Re: libauto and application.library

Postby ZeroG » Thu Apr 09, 2015 9:05 am

Simply build your own libauto, look at this nice script to learn how:
http://os4depot.net/index.php?function= ... ibauto.lha
User avatar
ZeroG
 
Posts: 114
Joined: Sat Jun 18, 2011 12:31 pm
Location: Germany

Next

Return to SDK Support

Who is online

Users browsing this forum: No registered users and 2 guests