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

Re: [MiNT] WCOWORK vs WINDOM for components



on 7/22/2005 10:33 PM, evan@coolrunningconcepts.com wrote:

> I'll respond to your personally as there will be less clutter on this list.
> 
> Quoting Lonny Pursell <atari@bright.net>:
>> I'm also getting tired of reading stuff like this.    Nothing has been
>> forced upon you or anyone else.  The WCO "mode" is 100% optional.  What part
> 
> You got me all wrong.  I WANT WCOWORK mode.  Its just the implementation that
> could be improved.  If it could be implemented so that more people are likely
> to use it, and we can make it more flexible for the future, then why set
> something into stone now if there is already a better method?
> 
> Isn't it worth at least discussing?
> 
>> of optional do you not grasp?  The app has to specifically request this mode
>> of operation, otherwise it's business as usual.  You can still use your old
>> crappy libs from 1989 or whatever.
> 
> I'm well aware of how this works.  The problem is not crappy libs from 1989.
> The problem is mixing any libs written right NOW, 2005, that doesn't
> know about
> WCOWORK with something that does.   If this one one incompatibility can be
> overcome without losing features, and we can make Windom developers and other
> users happier and more accepting, then isn't it worth it?
> 
> I'm on the side of WCOWORK!   I think its a good idea.  I just want to
> alter the
> implementation before its set in stone.
> 
>> I've said it before and I'll say it again.  The ones who fear change simply
>> will not use the new mode.  The ones that do, yeah, they will break on magic
>> or some other AES.  But something has to break eventually, that is the
>> nature of progress.
> 
> I don't fear change!   If modified, I'll be using all WORK area coordinates in
> my next program, 100%.   The problem is that I'll be allowing dynamic plugins
> and if that plugin author chooses to not support WCOWORK, then I want
> things to
> still function correctly no matter what external code is linked.   I want to
> support the ability of choice, even though I personally prefer WORK based
> coordinates.
> 
> As people are so quick to point out to me, applications are lot more complex
> than just a single binary these days.

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.

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.
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.

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.

-- 
Lonny Pursell    http://www.bright.net/~gfabasic/