Font_ApplyFields problem

[Jonathan Coxhead]

   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.

   Now, if the OS was changing, and there were versions that required file 
handles to be wider than 8 bits, I would support distributing a version of 
OSLib that had all the os_f functions deleted from it, for use by people with 
that version of the OS. That would be a useful service: it forces them to fix 
all the bad assumptions they have made in their code.

   But that could never be the only version, because to support the older 
versions of the OS, which have 8-bit file handles, we'd still need to 
distribute the os_f functions.

   Many, many of the veneers in OSLib only work on some versions of the OS: for 
example, all the code to do with wide sprites, many of the OSByte values, etc 
etc. The general rule is that OSLib provides *all* functions that have *ever* 
been in use by any version of RISC O S. Then the developer can always write 
code that targets a specific version, knowing that that function will always 
have that meaning. If the OS itself wants to return an error for an obsolete 
SWI, we let it do that itself. OSLib remains completely agnostic about that. If 
you like, you can think of it as the run-time library for a cross-compiler, 
where the different versions of RISC O S are the different targets. (Of course, 
they are very similar :-)

   If you look through the comments, you'll find many of the form

      "(RISC O S 3.5)"

This is as formal as I tried to be about documenting the validities of the  
different facilities. I can imagine a version of DefMod that takes a RISC O S 
version number as an argument, and generates only those veneers and #defines 
that are valid on that version. It would be an **enormous** job, and a 
nightmare to test effectively.

   But as all versions of RISC OS use 8-bit file handles at present, the valid 
range for both the 8- and 32-bit forms is "Arthur 1.0--present". So even if we 
had such a scheme, it wouldn't cause the veneers for the 8-bit handles to go 
away, unless they were artifically flagged as "obselete in RISC O S 4". 

   Which takes us back the first question---why would you do that?

        /|
 o o o (_|/
        /|
       (_/