Re: [MiNT] WCOWORK operating mode

[Odd Skancke <ozk@atari.org>]

ons, 13,.07.2005 kl. 12.33 +0200, skrev Joakim Högberg:
> Hi all,
> 
> >> I have only a wish: "don't break the compatibility".
> >Well, if thats the only concern, then we dont have a problem!
> 
> I am beginning to realize that the way the new mode works is something
> that very few have understood!

 I'm beginning to see why Arnaud panic when there is talk about WCOWORK.
They want to completely lock themselves up by adding AES awareness to
every lib with functions like showing an image, display a text-editor
box. etc., etc. While such libs on all other platforms are there to
generate output into an arbitrary bitmap, these dudes what to make them
indipendantly AES aware. This is, excuse my french, totally idiotical.
No way I'm gonna take such designs into account.

> 
> >How would this new operating mode break compatibility? You can use it
> >or not.
> >If you like it and think it will ease your programming: Use it!
> 
> Ok, if I get this right, then the new workmode is:
> 
> 1) 100% optional. The app will report to the AES that it supports the new mode
> (if it does, of course), and if so the AES will let the app take advantage of the new mode. Right?

 Correct.

> 
> 2) 100% compatible. If an application does not explicitly support it, the AES will allow the app to
> work as before. That is, the default behaviour is the way it works in other AES's now. Right?

 Correct.

> 
> 3) A very clever extention of the way the AES works, since it allows new software to exploit it,
> whereas at the same time it is not being forced upon the programmer to do so! What is the setback?

 This is also correct. Altho it is fully the applications authors
choice, it is strongly adviced that WCOWORK mode is used when available.

> 
> I can only assume that those that are so hostile to this new addition have not fully understood the concept,
> or that there is some hidden reason why the idea would cause problems.

 I now know the reason. Arnaud told us the reason in another posting.
The reason is that because of braindead design of libs, those libs will
never work on anything beyond n.aes or MagiC. I'm gonna get flamed from
here to eternity and back for calling the design idiotic and braindead.
But that is the truth, if my understanding of it is what goes.

> 
> >If you dont like it and see no benefit: Dont use it!
> >It is as simple as that!

 Correct. But the benefits will soon show, hopefully.

> 
> If this is for sure the case, I think we can put an end to the current discussion regarding whether
> the support for eg. MagiC and N.AES should be a problem? I mean, if the new additions in no way
> breaks compatibility it seems plain silly to fight over it, right?

 Correct too :-)

> 
> >I dont think ozk wants to get rid wind_calc entirely. Well, yes, maybe
> >in new apps, where it can be avoided. But it has to be there all the
> >time otherwise a whole big bunch of software would be ruled out
> >immediately - and no one wants that!
> 
> And if I understand things correctly, then even the first example of a program taking advantage of the
> new mode (toswin & qed) still has the support set as optional. If you wish to save some extra Kb by
> only using the new mode in those apps, you need to specify this when compiling. Unless you do, these
> apps will still be working as before. Under all AES's that is has supported until now. (Hope I got that right too, Odd?)

 Yes, this is correct.

> 
> In short:
> 
> * WCOWORK operating mode should only be used for apps that requests it directly by sending the
> approprite AES call.

 Exactly.

> 
> * WCOWORK operating mode should not be used for apps that has not sent this AES call.

 Correct. WCOWORK is a new 'operation mode', a new AES programming
model. So applications that dont know (old apps) or dont want to support
WCOWORK mode dont have to. But, again, it is strongly adviced that
authors use it. Why? Listen to this; Because the USER will benefit!

> 
> *Programs in FreeMiNT CVS like Qed and Toswin will still be compatible with AES's that does NOT support
> WCOWORK operating mode. People who wishes to have a more stripped binary for XaAES, can however
> decide to compile binaries that supports WCOWORK operating mode exclusively.

 Correct as hell :)


> 
> 
> -If I have understood any aspect of this implementation incorrectly, someone please correct me!

 You have got it 100% correct ;-)



 Best Regards
Odd Skancke