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

Re: [MiNT] wind_get/set mode



 Hello,

fre, 18,.03.2005 kl. 22.27 +0100, skrev Arnaud BERCEGEAY:
> Hello,
> 
> Sorry for my late answer. The discussion was about the constant:

 No problem :) I think most of us knows the lack_of_time problem...

> 
> #define WF_FIRSTAREAXYWH 13
> 
> we introduced in XaAES and MyAES.
> 
> The point is that some applications used that value (when it was  
> undefined) : the application checks the error code returned by the AES  
> when invoking wind_get(13), and then the application deduces from the  
> error code returned if the AES supports "modern" wind_set/get extensions.
> 
> It seems that for now, some applications use that feature to test the  
> availability of WF_OWNER.
> 
> On Tue, 1 Feb 2005 21:46:00 +0100, Gerhard Stoll <Gerhard_Stoll@b.maus.de>  
> wrote:
> 
> > AB> then this old application may believe that WF_OWNER is not supported
> > AB> by this AES.
> >
> > The application can believe that no new wind_get/set mode is present.
> 
> Please remember that the only legal way to check if new wind_get/set()  
> mode is present is by calling appl_getinfo().
> 
> All modern applications should use appl_getinfo() instead of the  
> wind_get(13) hack.

 Definately.

< ... >

> To sum up, i would vote to keep WF_FIRSTAREAXYWH as is (value already  
> supported by MyAES and XaAES at the moment).
> 
> If someone think it's really a bad idea to keep WF_FIRSTAREAXYWH=13, then  
> speak now. I'd like to release a new version of gemlib, with  
> WF_FIRSTAREAXYWH defined inside... and then other pieces of software will  
> use that value too. Then, it will be very hard to change WF_FIRSTAREAXYWH  
> to another value.

 I also think we should keep it as is. And I do wonder what applications
use wind_set(13) hack... would be nice to know so one could check for
sure what happens...

Best regards,
Odd Skancke