[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