Font_ApplyFields problem

[Tony van der Hoff]

On 24 Oct 2001, in message <000701c15cc2$216bac80$efe886d9 at oemcomputer>,
Kevin Bracey wrote:

> Hi there,
> 
> I've been using OSLib for some time in Zip 2000, and I'm finally getting
> around to reporting a problem :)
> 
> In all versions of FontManager up to and including 3.36, Font_ApplyFields
> corrupted R5-R7. The OSLib veneers don't know this, so font_apply_fields
> ends up not being APCS compliant.
> 
Thanks for the report, Kevin. I'm not too sure as to the best way to fix this
right now, but it'll get my attention.

> I also had a note that the Font_FindField veneers passed the first
> parameter in R0 instead of R1, but this appears to be fixed (although I
> can't see it in the change logs).
> 
Yes, this appears to have been fixed for V5.41. Don't know by whom, but it
obviously did get missed from the changelog. Thanks.

> Oh, and can I add a vote for getting rid of all those horrible W functions?
> At a minimum can we have something that we can #define (or not #define) to
> make os_f 32-bit and get rid of them?
> 

What, in particular, do you find so objectionable to the W functions?

I don't really we want to re-open this can of worms. One overriding
constraint that OSLib developers have placed upon themselves is that
backwards compatibility should be maintained where ever possible. 

The OSLib developers regard 32-bit file handles as a re-interpretation of the
RISC OS specification, with (at present) either 8 or 16-bit handles being
acceptable. Therefore functions needed to be available for both types.

The opposite (and strongly held) opinion is that 8 bit file handles were
never valid, and that their use constitutes a bug in future OSs. Of
that reason, compatibility should not have been an issue in the first
place, and we should have changed the base functions to 32-bit to safeguard
future compatibility.

I personally believe each religion has its validity, and for better or worse
a decision was taken in favour of the compatibility retainers, much to the
chagrin of the compatibility predictors. The argument could have continued
for ever, and flares up every now and again, as here.

Your suggestion of a compile-time switch could be a nice solution to the
problem, but has its drawbacks. You are probably aware that OSLib is machine
generated from a DefMod language. This language doesn't allow for
options, but it may be possible to manually change types.h and types.hdr to
include a switch in the way you suggest. I think this may introduce
maintainability issues, but I'll give it some thought. 

Meanwhile, I'm copying this to the OSLib-user list, in case anyone else wants
to contribute. Please, though, let's have no repeat of the religious wars!

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