Font_ApplyFields problem

[Tony van der Hoff]

On 1 Nov 2001, in message <3BE15216.24757.BED69F at localhost>,
"Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

>    On 1 Nov 2001 Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> 
> > [OS_FW and W functions]
> > 
> > > However, given that we've now had a 18 month transitional period, what
> > > would users think of my renaming the 8-bit functions and handles as you
> > > suggest, thus allowing people to implement the old names as functions or
> > > macros in their own code, for which they can take responsibility?
> 
>    Why would you do that? It sounds like your giving people extra work for
> no  gain. *I* wouldn't buy software that did that.
> 
Well, some new evidence came to light since the last time this was discussed,
which has caused me to change my mind about this feature.

On page 2-532 the PRM states that:

"[file handle]. This is a small integer (typically going downwards from 255),
but must be treated as a 32-bit word for future compatibility. [...] On
exit, your filing system must return a 32-bit file handle that it uses
internally to [communicate with?] FileSwitch"

Based on this statement, in an admittedly obscure corner of the PRM, I am
moving towards the opinion that OSLib, if not bugged, certainly disregards a
PRM recommendation, and ought now to be fixed.

The simple fix would be to change the existing 8-bit functions to take 16-bit
arguments, but this is unacceptable, because re-linking old binary objects
with the new library would silently introduce serious bugs in user code. 

We must, regrettably, accept that there are users who have binary objects for
which the source is not available, either because it's lost, or because it's
part of a third party library, and we must support these users.

The 8-bit functions have been deprecated in OSLib for some while now, and
losing them entirely would achieve the objective of providing a conformant
interface via the W functions, but would not support binary compatibility.

So, my proposal is to re-name the 8-bit functions, so that they cannot be
"accidentally" linked; if anyone really wants to link them in, the can
provide their own thin veneer to resolve the symbols at link time. Anyone
else can continue to use the W functions, or again use a thin veneer to use
the intuitive function names. You are correct in that it gives people extra
work, this is quite deliberate, as it makes OSLib PRM compliant. I believe
that you are mistaken if you believe that constitutes no gain.

To make it easier on users, we could release these veneers with OSLib, as two
additional libraries, with the appropriate documentation to ensure users are
aware of the effects of using either version.

Nothing we do can be ideal at this stage, but I believe this is the optium
way of providing maximum future-safety, and binary compatibility, with least
inconveinience to users.


-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk