Font_ApplyFields problem

[Jonathan Coxhead]

   On 5 Nov 2001, at 17:58, Tony van der Hoff wrote:

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

   This has been well-known for a long time---it's not new information, as far 
as I'm concerned.

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

   But it has been fixed! All the functions anyone needs are there, together 
with some older ones that may work only on older systems. There are *dozens* of 
functions in OSLib that only work on older operating systems, but the 
assumption is that OSLib may be used on any of them, so we keep on providing 
all of them. As I have written before, if you don't use them, they do no harm.

> The simple fix would be to change the existing 8-bit functions to take 16-bit
                                                                         ^^ 32
> 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.

   You just want to give these people extra work. Why? "It's for their own 
good"? Why not let them decide that?

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

   (I happen to know that the PRM itself is not RISC O S compliant (so to speak 
:-), at least up to RISC O S 3.5, in that under those operating systems, file 
handles were treated as 8 bits internally. I suspect they still are. But that's 
mostly irrelevant at this stage.)

   The question, is how can we make the upgrade path as easy as possible (so 
everyone can do it conveniently) but *not* compulsory, as that's a form of 
bullying. (A library should provided services, not enforce policy.)

   So here's my counterproposal: how about a new header file, called "osf32.h" 
or similar, that maps *all* the "short" names to the form with W:

      #define os_f                 os_fw
      #define xosfile_save_stamped xosfile_save_stamped_w
      #define osfile_save_stamped  osfile_save_stamped_w
      ... etc ...

   With this file, the only thing an application writer has to do to upgrade 
from 8- to 32-bit file handles is

      #include "oslib/osf32.h"

at the begining of each source file. If they don't do this, they get the old 
behaviour---binary (& source) compatible. If they do do it, they get the new 
behaviour, which is not binary compatible, but (assuming they have used os_f 
properly in all their source files) will still be consistent across the whole 
application.

   I've attached the skeleton of such a file. As well as redefining the 
symbols, it also checks that the various header files have not already been 
included---it would be an error to #include, say, "dosfs.h" before "osf32.h", 
because the functions would then have incorrect 8-bit prototypes. Luckily, 
"osf32.h" can check this, so it's completely "safe" from that point of view. 
(It also has to make sure that it includes the files in the order of their 
dependency, e g, arcweb.h after wimp.h. It does that too.)

   I don't see any way of making it easier than this, while still leaving the 
application writer in control of their own code---which I'm strongly in favour 
of!

        /|
 o o o (_|/
        /|
       (_/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osf32.h
Type: application/octet-stream
Size: 2295 bytes
Desc: not available
URL: <http://lists.compton.nu/pipermail/oslib-user/attachments/20011105/eb7d8cb8/attachment.obj>