OSWord_ReadLine

[Jonathan Coxhead]

   On 5 Nov 2001, at 18:56, Tony van der Hoff wrote:

> > > OSWord_ReadLine has always been deprecated in RISC OS, but supported
> > > by OSLib. Given that its restrictions make it potentially dangerous
> > > in use, I now propose to make it obsolete. 
> > > 
> > > Similarly, OSWord_ReadGCol was made obsolete in PRM5a. I propose to
> > > do similar in OSLib.
> > > 
> > > Do any users have a problem with either of these changes?

   The trouble with any changes like this is that OSLib may be used by people 
developing on older OS's, under which those functions are not obsolete.

   I have never met a library user who *asked* for functions to be *removed.* 
Most users are quite happy with the other option---if you don't want to use the 
function, just don't use it. Library providers should not be in the business of 
"bondage and discipline" (Make them upgrade! We know that they want to 
really!), but should simply provide all options.

> > With a view to DefMod generating code for riscose could they be left in
> > but a `deprecated' flag added to the grammar and DefMod made to skip
> > them for C library generation?

   As I noted before, "deprecated" is a relative term: OSLib works on all RISC 
OS's, at least back to RISC OS 2, and maybe before. This is a point of pride 
for me, and should be for all of us: no code written using OSLib has ever been 
broken by changes to OSLib itself.

   If you look at the CONFIGURE symbols in "osbyte.h", you'll see a lot of 
"deadwood" where a CMOS byte changed function: for example

      #define osbyte_CONFIGURE_PRINTER                141
      #define osbyte_CONFIGURE_UNPLUG11               141
            /*RISC O S 3.60+*/

Should I have removed |osbyte_CONFIGURE_PRINTER|, because byte 141 changed 
meaning? No, because OSLib is used on RISC OS's below 3.6. A clever application 
will check the OS version and do the right thing. But even a stupid application 
will still compile and work as intended, provided it isn't run on RISC O S 3.6. 
And many applications are just written for personal use, and have no need of 
the extra complexity.

   (In fact, I'm still disappointed that I never quite got round to making 
veneers for RemV and CnpV, even though they were obsolete long before OSLib was 
started. The problem is that they take the processor flags as an input 
argument, so there's a small technical challenge.)

   Now, if anyone wants to go over all the SWI files, and annotate every 
function, type and symbol with its validity range in terms of RISC OS version 
numbers---an enormous job!---then we could change DefMod to emit symbols for 
only those functions that work for a certain version. We could have a "RISC O S 
3.6+" "osbyte.h" that included 

      #define osbyte_CONFIGURE_UNPLUG11               141

only and a "RISC O S 3.5-" "osbyte.h" that included

      #define osbyte_CONFIGURE_PRINTER                141

only. (Obviously, changes to the SWI file grammar would be needed.)

   There would still have to be an option to emit *all* symbols, so that 
application writers can check the version at run time, and adapt the behaviour 
accordingly, while still being able to compile the source code on some 
particular version.

   Would this be useful? I suspect so, slightly. Would it be worth the time it 
took? I suspect not. It's complicated and messy, and (even worse!) subjective.

> The problem has gone away in this particular instance (see thread in -user).
> However, thre are other SWIs that are not implemented in OSLib for various
> reasons; usually because they aren't APCS compliant, or were already obsolete
> when OSLib was written, and therefore were never embodied. DefMod declares them
> as ABSENT.

   ABSENT is mostly used (a) for SWI's that have multiple reason codes, so are 
split into multiple veneers (e g, OS_GBPB and the like), or (b) for SWI's that 
just cannot be called from C (e g, OS_EnterOS). I think that everything else is 
in there, warts and all, no matter how obsolete it may have been, or 
subsequently become. 

> I believe that relying on the OSLib SWI files for riscose will, in the long term
> be fraught with problems, both for you, and for us. Your problem with
> MessageTrans serves to illustrate this problem. If you were to require extra
> fields in the SWI files, specifically for riscose, then this would place a
> maintenance burden on the OSLib developers, which is unlikely to be acceptable.
> I know you haven't suggested it, but I find it difficult to envisage a scenario
> where the SWI files contain elements to support riscose. Another back-end for
> DefMod is maybe easier to envisage.

   A few simple changes (such as I suggested for MessageTrans_Lookup) would be 
OK, but I agree that adding lots of extra information that is not generally 
used would probably do more harm than good. The new MessageTrans_Lookup veneer 
would be generally useful, after all.

> By all means use the SWI files, but I suggest you supplement them with
> exception files for riscose. That way you'd be able to overcome the mismatch
> between the two objectives.

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