🚀 go-pugleaf

In article <7431@gryphon.CTS.COM> mriley@pnet02.cts.com (Mark Riley) writes:
)
)Look, it's MY mistake that I mentioned 1.3 needs a ROM change.  This
)stems from lack of information about what version does what.  Apparently
)1.3 is not the version that is going to introduce major functions
)that are not compatible with earlier versions.  I think this would
)be called 1.4, instead.  That may be the one to be scared of, who
)knows.

V1.4 has major enhancements in kickstart/rom.  Don't be scared, we're
your friends.

)As an example, I understand that there is going to be overscan support
)in 1.4 (or whatever it's gonna eventually be called.)  What's going to
)happen when a program wants an overscan screen using this new function
)when running on 1.2. 

Good example.

)It's not going to get it.  I'm sorry, but a
)message like "SuperProgram V1.0 needs 1.4 in order to run - Sorry,
)you're S.O.L.)" just is not going to cut it with me. 

No need.  It can say "this program needs V1.4 to do overscan."  People
in tune with the overscan issue know that what V1.4 will really bring
to the party in overscan includes:

1) Access to user-preferred overscan dimensions.
2) Mouse ranging over entire overscanned screen without performing 
  illegal poking of internal data structures.

The program can use interim solutions if it finds V1.4 unavailable.
Typically, a new feature is simple enough to use that the only minimal
code is required to conditionally take advantage of the new feature.

One does this by opening the V1.2 library, then checking its version to
see if it is in fact V1.4.  You can set a global for later testing or
even even modify some indirect function vectors to adapt to the
current release.

A good example in V1.2 is auto-activating string gadgets.  Numerous programs
would activate the gadgets for you if V1.2 was around, and note in the
manual that you'd have to click in them if you hadn't upgraded.  I like
this: it makes the customer aware of advantages in upgrading.

)I've seen enough of this on the Mac, why must it happen here? 

Because upgrading system code is sort of universal.

)People already can create overscan displays.  Makes no sense to me.

There are advantages gained in the overscan support for V1.4.
Interim hacks collide with each other, and they might blow the f*ck up on
V1.4, since they creatively poke all sorts of data clearly marked private.
(I hope we don't read that people poking system-private data is ANOTHER
reason we should never upgrade the OS!)
Now overscan is SUPPORTED.  If you program it in accordance with V1.4,
you can count on it working in V1.5, and beyond.

Maybe you are prepared to look six months down the road, maybe you
have to do so, but clearly it's stupid for us.  Just extend the time
frames: two years from now, everyone will be writing programs for V1.4,
no problem.

In the meantime, you can easily write programs which SELECTIVELY take
advantage of new features in V1.4, and make the big leap to requiring it
at such a time as your market research indicates that it is wise.

Your philosophy would have lead us to not having auto-activating string
gadgets at all, wouldn't it?

As you have often pointed out in other public forums, there are special
requirements to doing system software.  I claim one of them is appreciating
long-range benefits of progress.

)-Mark-

	jimm
-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.