Font_ApplyFields problem

[Tony van der Hoff]

On 6 Nov 2001, in message <97f34bd54a.druck at druck.freeuk.net>,
David J. Ruck <druck at freeuk.com> wrote:

> On 6 Nov 2001 Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> > Any user who needs 8-bit binary compatibility will get it by default; any
> > user (there can't be many) who opts for 8-bit source compatibility can
> > set the switch in his make file (surely that's minimal *extra work*);
> > anyone else gets PRM-compliant 32-bit handles. Everyone can use the short
> > symbols, and migrate from 8 to 32 bit by simply undefining a constant.
> > Would that finally satisfy everyone?
> 
> I'm in complete agreement with Tony over this, which makes a nice change
> doesn't it. :-)
> 
Oh, I knew we could agree eventually; despite angry words, I have always held
your opinions in high esteem, except maybe in this one tiny matter :-)

> However one thing has always puzzled in over this debate which has been
> stated from the beginnig, Tony last mentioned it:-
> 
> On 1 Nov 2001 Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> > The problem is that of users re-linking binary object code for which
> > either the source is unavailable (e.g. 3rd party libraries), or lost.
> > Linking an old module against a new OSLib would be disasterous. There are
> > plenty of arguments why people who try this should get all they deserve,
> > but we, the OSLib developers, try to avoid such issues.
> 
> This has always struck me as an unwise thing to do, as although binary
> capability may be maintained, there could be unforeseen functional
> differences, and if you dont have the source to the program and you find
> issues in testing, you are stuck.
> 
In an ideal world you are undoubtedly correct. You and I would expect *never*
to do it; nor would any other 'professional' developer. But, pragmatically,
the need will occasionally arise.

> The only reasons for relinking in the first place would be to either fix a
> bug in the program that is known to be due to the library or to gain
> increased performance from the new code. Both these are fairly unlikely
> with OSLib as its a thin wrapper around SWI's. Relinking just because there
> is a new version is unwise and potentially dangerous.
> 
Imagine a develper who has completed an application (A), consisting of a
large number of source modules. He has archived this away, and moved on to
other things, which has involved installing a new version of OSLib. He -
foolishly, maybe - does not archive the OSLib version against which A was
built. 

At some later time, he wishes to make a change to A. Upgrade, bug-fix,
whatever. On examination, the archive contains all the object modules, but
some of the sources are missing. Maybe they were sourceless third party
modules or libraries; maybe the archive was faulty, who knows? 

Alternatively, and maybe more plausibly, A was linked against a 3rd-party
library, which itself was built against an OSLib using 8-bit handles. You may
be correct in asserting that any professional will recompile his sources, but
he is unlikely (even if he could) to rebuild support libraries.

Fortunately, he has sufficient of the source available to make the necessary
changes, and can therefore rebuild his application *provided the link step
succeeds*. So that's what he tries. If, in the meantime, xosfile_save_stamped
has changed from 8 to 32 bits, the link will succeed, but result in faulty
code. One way of preventing that would be to remove xosfile_save_stamped, so
that the link would always fail. Jonathan, correctly, would call this
"bullying" ;-)



> So out of interest how many OSLib users relink against the library without
> recompiling the source? 

Not forgetting those who relink against the library *and a support library*
and *do* recompile the source. 

> If it a substantial number then the current policy of binary compatibility
> is the right one, but if not the libraries developers are placing artifical
> restraints on themselves, which could be relinquished to simplify
> development and make more radical decisons in future.
> 
To my mind (and don't forget that I'll end up doing most of the work), if
there is only one user in the next year who does this, and I can save him
from getting in a dreadful pickle, then the job is worthwhile. I guess this
is another aspect of professionalism.

As we now -finally- seem to have devised a way of doing this without
inconveniencing those who want to upgrade, we're all on a winner. 

The only remaining question is why on earth didn't I?, Jonathan?, you?,
anyone else? come up with this solution 18 months ago? Maybe we were all so
busy defending our entrenched positions that we lost sight of the objective.

Cheers, Tony

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