[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] wind_xget()
> > Ok, in that case .. is it OK if we use;
> >wind_get(handle, WF_FIRSTAREAXYWH, area_x, area_y, area_w, area_h);
> >and leave the original WF_FIRSTXYWH unchanged? I will implement it right
> >now.... if there are objections, please speak up.
> For me no problem, I have add this feature for Arnaud in the past, so
> what think Arnaud? For me no problem.
Lets await his comments then...
> >>In MyAeS I have add an appl_getinfo() extension for know wich AES and
> >>version is avaible (I think better than search in
> >>a cookie list!)
> >>#define AES_NAME_AND_VERSION 96
> >>case 96: /* AES_NAME_AND_VERSION */
> >> pb->intout='My'; /* 3 first value are a short name for
> >>the AES*/
> >> pb->intout='Ae';
> >> pb->intout='S\0';
> >> pb->intout=0x0067; /* last value is version with lower
> >>byte, the major version number and lower byte the minor number version
> >>all in hexadecimal */
> >>I dislike add new fonction feature because most of time never use, this
> >>only because a lot of people ask me to know wich AES is use, and I
> >>didn't wan't add cookie.
> > Not sure what you mean here. I also dislike adding functions for this,
> >and I strongly dislike the wind_set(WF_XAAES) thing.
> It's very strange way!
Yes it is. Weird to put system/version checks there.
> > I have kept this
> >only because Arnaud asked me to keep it. Are there any apps that check
> >XaAES presence this way?
Arnaud, do you think it will be a problem removing this, and come up
with a way to obtain such info via appl_getinfo() instead?
> > However, I will add appl_getinfo(AES_NAME_AND_VERSION) to be consistent
> >with MyAES. But I would also like to make more versioning info available
> >via appl_getinfo(). I have halfway implemented appl_getinfo(0x58xx)
> >where xx is a mode between 0 and 255. (0x58 == 'X'), and mode 0 returns
> >the following;
> > ap_gout1 = Minor version number
> > ap_gout2 = Major version number
> > ap_gout3 = Arch (for example, 0 means m68k, 1 means ppc, etc)
> > ap_gout4 = Status (for example, 0 means stable, 1 means beta, 2 means
> >alpha etc.)
> Yes good idea.
> > We should agree on the version number, tho. In addition to this, I
> >would like to add more verbose info available via appl_getinfo() when
> >the above appl_getinfo() exists. For example, and idea, if we use 96 to
> >return versioning info like I suggest (96 is only available in MyAES and
> >XaAES as of yet, and we can change it because not too many apps use it
> >yet?) we can call this mode APGI_VERSION.
> No version at this time, perhaps next release of EBModel, but really no
> problem to change something to this.
That sounds great.
> >#define APGI_VERSION 96
> > Then we can say that "If APGI_VERSION is available, APGI_AESINFO is
> >also available" (whose function number we agree on).
> > appl_getinfo(APGI_AESINFO, &aes_sname, &aes_lname, &aes_arch,
> > where pointers to char-buffers which the AES fills in is passed in
> > This will then tell the application that extended appl_getinfo
> >(APGI_AESINFO) is available by calling appl_getinfo(APGE_VERSION), like;
> >have_aesinfo = appl_getinfo(APGI_VERSION);
> >if (have_aesinfo)
> > min_ver = intout;
> > maj_ver = intout;
> > arch = intout;
> > status = intout;
> > /* since APGI_VERSION exists, APGI_AESINFO also exists */
> >appl_getinfoAPGI_AESINFO, &short_name, &long_name,
> > &arch_string, &status_string);
> > Opinions on this?
> 2 remarks about this:
> 1) You not need to do test if(appl_getinfo(APGI_VERSION))
> you can only do
> if(appl_getinfo(APGI_AESINFO, &short_name, &long_name,&arch_string,
> ...blabla software do what he wan't about this informations
> because appl_getinfo() return 0 if not avaible
> 2) For homogeneity with other appl_getinfo() there is no way to put
> pointer to appl_getinfo() this only short value, I think it's not a very
> good idea that we need do specific code in gemlib to manage this, no? I
> have start to think about 64bit system AES, this a very hard problem
> enough, with pointer, I'd like not add too much problems with AES, there
> is already enough! Second add pointer it's more problem with memory
Well.. I think the intention of the control array in the aes parameter
block is there to allow for such extensions. Furthermore, the
addrin/addrout arrays are defined to be "pointers of arrays", so I dont
see a problem here. And there will be no problems with MP as it is the
Operating System writing data into a buffer whose address is passed in
the call, much like any other write calls (Fwrite() for example). The
design of TOOLBAR, MENU's, etc. is another matter.. as the AES cannot
copy these things into secure memory, and thus have to access things
from the correct context.
> I have add a small modification too in appl_getinfo(), for ressource
> load capacity, I have already post here my need, without answer I have
> do this
> case 2: /* AES_SYSTEM */
> pb->intout=Getrez(); /* Getrez() */
> pb->intout=256; /* nombre de couleurs support‚s par AES object
> library stupide! */
> pb->intout=1; /* couleurs icones support‚es */
> pb->intout=1+2; /* 1-> long ressource as AES 4.0 define, 2->long
> ressources as Interface define */
> I need this because I have correct Vision that use a very buggy version of xrsrc! that have a lot of trouble with MyAeS (I don't know where this version was found!), and because I didn't wan't correct this part of code, I wan't only use standard rsrc_load() when present, actually I have force to do this and it work perfectly, but of course on other system like NAES it crash! If you not see any incompatibility (I notice myself nothing) it could cool that we do the same.
Yes, I will change it to be like that. Thanks :)