8 bit os_f handles

[David J. Ruck]

On Wed 29 Mar, Jonathan Coxhead wrote:
>    David wrote:
>  | No you wont, you'll get the typical user bug reports; "your program
>  | crashes" and RISC OS Ltd will get, "RISC OS 4.x is crap, since
>  | installing all my files are corrupted".
> 
>    I don't believe this.
> 
>    While it's likely that people will say "RISC OS 4.x is crap, since
> installing all my files are corrupted" (because they are using an 
> |os_f| version of OSLib), I think this can only happen with code they 
> do not have sources for: 3rd party apps and libraries. Changing 
> |os_f| to 32-bit won't help them *anyway*.

This is users we are talking about. They will not know the relationship
between 32bit handles and OSLib problems. They will look at the last
major change to their system and summise it is the fault of the OS
that files are becomming corrupted. They will not suspect program XYZ
which they have had for years is causing the problem.

>  | What do other people think? There must be more than 4 of us on this
>  | list?
> 
>    I think you *must* have been a politician in a former life! You 
> are losing the technical argument, so you are resorting to 
> demagoguery! ... or trying to, at least. :-)

You have one point of view, I have another. We have obviously reached an
impass, so it is only right to seek opions of the people that have to
use the library - thats what the list is here for after all.


It comes down to two choices:-


1) change os_f to 32bits

Advantages    : Fixes OSLib to bring it into line with the API.
Disadvatanges : Incorrect use of the library may fail

Library users will have to:-
1a) Recompile all source code with the new headers and library
1b) Check for any casts of os_f to byte sized quantities
1c) Check os_f's are not used in any persistant structures which will
    now differ in size between previous versions

   
2) leave os at 32 bits and introduce os_w and _w versions of all
   file system and other functions which use os_w
   
Advantages    : Does not immediately break existing code 
Disadvantages : Ensures existing code will break
                Extra work to change existing functions
                Makes OSLib larger
                Makes documentation confusing

Library users will have to:-
2a) Change all filehandling code to use the new funtions
2b) As 1a
2c) As 2b
2d) As 2c


Obviously I'm biased but I see 2) being more work for both the Library
maintainers, and library users.

---Dave

-- 
______________________________________________________________________

  David J. Ruck     Phone: 07974 108301     Email: druck at freeuk.com
______________________________________________________________________