8 bit os_f handles

John Tytgat John.Tytgat at aaug.net
Tue Mar 28 23:14:58 BST 2000


In message <200003282101.NAA29631 at purple.trimedia.sv.sc.philips.com>
          "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

>    David wrote,
>  | > I know that the point is to supply correct code. The only sense
>  | > in which the code is "broken" at the moment is a sense that you
>  | > have defined for yourself. That doesn't make it true!
>  | 
>  | Sorry but it is the API, not a matter of my opinion.
> 
>    The A P I is 8-bit. That's true---at the OSLib level, and at the 
> FileSwitch level as well (as we go to press ...).

That's not true.  With all respect Jonathan, but the documented API talks
about filehandles returned in a 32 bit word (register).  So a filehandle is
32 bit wide.  The fact that it just returns values betwee 1 - 255 is just
a coincidence.

I do *not* care how FileSwitch is internally managing its filehandles as
as a programmer I have to make abstraction from it.  I just want to make
sure that my programs linked today will work in the future when there
are >255 value filehandles (potentionally it is just being done by a
simple module which hijacks the OS_Find/OS_GBPB/... vectors).

>    If the FileSwitch interface becomes 32-bit, the OSlib interface 
> will evolve to keep pace.

...and in the meanwhile all programs linked with today's OSLib
potentionally won't run anymore.  Great.

>    The fact that the OSLib interface is 8-bit looks like a mistake. 
> If only I could remember exaclt why I did it, I'd know for sure. :-(

Everybody makes mistakes.  Let's move forward and try to correct these.

> [...]
>  | Do any of the users in this mailing list have any code which will
>  | break if os_f is redesigned as a 32 bit, and the application
>  | recompiled? Its easy to tryout by just modifying the os.h header.
> 
>    This doesn't matter one bit. Hundreds of copies of OSLib have gone 
> out, and I have no idea who's using them. Neither does anyone else. 
> Even if the answer was "none", I'd still argue for compatibility: 
> it's a professional ideal.

It also gives a professional touch when your programs keep on running
on a new OS without having to sputter "hold on, I need to recompile"
and send out hundreds update copies...

Let's add a big warning to the next OSLib version : using this version
requires a full recompile and note that filehandles (os_f) are now 32 bit
wide instead of 8 bit.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven



More information about the oslib-user mailing list