Re: [MiNT] WCOWORK vs WINDOM for components

[evan@coolrunningconcepts.com]

Quoting Lonny Pursell <atari@bright.net>:
> If you got something to say regarding WCO I suggest you send it to the list
> for all to see and not to my personal e-mail box.

Well, I figured people were tired of hearing this since we seem to be 
saying the
same things over and over and getting nowhere, and the message was directed at
me from you, so why bother the whole world?  But .. if you insist.

> I sent ozk a detailed e-mail with my ideas on WCO.  How to do it differently
> with new API messages.  Regretfully it didn't end up on the list because of
> the BROKEN reply problem with this list and I was to lazy to fix the header.

Has anyone looked into the "List-Post:" header that I mentioned?  Anyone wanna
give me access so I can fix it?

> But needless to say Ozk explained to me my WCO is the way it is, and I fully
> accept his reason for not considering my idea.  It made sense to me.

Could you forward it to me?  Cause I don't quite get the picture yet.

> I still don't understand the problems with libs.. blah... whatever. If you
> have an old lib, simply do not invoke the option for your app.  If you are
> using windom, you should know what it is and isn't capable of??  As the
> coder you have the source code??  Sure hope so.  Thus you simply DO NOT
> invoke the WCO mode.  It does not magically turn itself on.  Windoms happy,
> your app is happy, it runs as it did before and so on and so forth.  You are
> making this way more complex than it really is.

You don't understand.  I WANT to use WCOWORK.  I like it.  But you cannot be
guaranteed that you have the source for all libraries you link with.  There is
something called "modularity", and if done properly, what one module 
does won't
interfere with the other.  WCOWORK breaks that simple fundamental principle
since as soon as you set that mode for one module, the API of other modules
changes.  More advanced applications might have dozens of libraries and
components and you shouldn't have to go through them all and make sure 
they all
support WCOWORK to make sure you can use it.  The modular approach seems to be
the correct approach.

For any WCOWORK mode call designed to stop me from altering the FULL
coordinates, I can take the FULL coordinates that I want, pass them to
wind_xget() to calculate the WORK coordinates and pass that into the AES call.
Now I just bypassed whatever the API change was trying to prevent.  So, 
why not
just keep the original calls the way they were and give me new ones to 
use in my
modules, so that programming can stay modular?   I've yet to see how changing
the API over presenting new calls is a huge win.   I'm not being argumentative
- just explain it to me!