[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] appl_getinfo(APGI_VERSION(=96)) implementation



ons, 15,.12.2004 kl. 21.33 +0100, skrev Arnaud BERCEGEAY:
> Hello,
> 
> >  appl_getinfo(96, aes_id, long_name, version, status, arch),
> 
> Wow... 5 strings just to describe the name of the AES...
> 
> I think we can go down to 3 useful strings, and leave a 4th spare string  
> in order to have 4 return values like in most AES functions.
> 
> >  where aes_id is the short name, space-padded to fit 8-bytes, for
> > example "   XaAES".
> 
> good.
> 
> i prefer left aligned text (to be homogenous with other AES application  
> strings.
> 
> > Long_name is a null-terminated string filled with a more descriptive
> > info-line, for xaaes now "XaAES - a MultiTasking AES for MiNT".
> 
> good.
> 
> I think that AES can put in the 3rd string a free string with all the  
> informations that may describe the AES, for example the version number,  
> the alpha/beta/release status, the target architecture, the compiler used,  
> the date of the compilation, etc...
> for example: "release 1.23beta for m68k, compiled 25th dec 2004 with gcc  
> 2.95"

 yes, this looks like a good idea. I'll change to this.

> 
> If an application need a particular information (for example the version  
> of the AES), then standard appl_getinfo() call (with data returned in  
> intout[]) is far better.

 yes, agreed.

> 
> so, we get a new appl_getinfo_str() function:
> 
> char aes_id[8], aes_name[256], aes_version[256];
> appl_getinfo_str(96,aes_id,aes_name,aes_version,NULL);
> 
> on the AES side:
> control[0]=130
> control[1]=1         Elements in intin
> control[2]=1         Elements in intout
> control[3]=4         Elements in addrin
> control[4]=0         Elements in addrout
> 
> 
> and with the standard appl_getinfo() function:
> 
> short aes_minor, aes_major, aes_status, aes_arch;
> appl_getinfo(96,&aes_minor,&aes_major,&aes_status,&aes_arch);
> 
> on the AES side:
> control[0]=130
> control[1]=1         Elements in intin
> control[2]=5         Elements in intout
> control[3]=0         Elements in addrin
> control[4]=0         Elements in addrout
> 

 Do we really need that? I think that it is easier if one call returns
all if user wants it to, as I proposed earlier, where the only
difference is the control[N_ADDRIN]. If this shows 0, the call is a
standard one, if its 5 (or 4) it should fill the respective strings in
addition to the standard intout[] elements. (see my original posting
about this issue). This is how it is implemented in XaAES now.




Best regards,
 Odd Skancke