8 bit os_f handles

[Jonathan Coxhead]

   David wrote ...

 | If I write
 | > 
 | >       os_f f;
 | > 
 | >       ... xosfile_openin ("MyFile", &f) ...
 | > 
 | > and compile with a byte-wide |os_f|, but then link to a version 
of
 | > OSLib that thinks it's a word, I'll overwrite 3 bytes of memory 
that
 | > are not mine.
 | 
 | Arrrrrh! Any changes to library should result in a complete 
rebuild of
 | any projects that use it - anything else is extreamly dangerous.

   That's exactly my point. "Changes to [a] library *should* result 
in a complete rebuild of any projects that use it." The trouble is, 
they often don't. Sometimes, object files are distributed in binary 
form---you don't want people to be *able* to link with an 
incompatible past version. The possibility of mistakes should be 
eliminated at the earliest possible time.

 | >    But in any case, that's what we have now, and we never break 
 | > backwards compatibility. This is a professional-quality product!
 | 
 | But this is a statically linked library so does not require you to
 | keep binary interface compatibility - only synamic linked libraries
 | like the Shared C library need to do this.

   OSLib is a library, but it's also an interface. If RISC O S had 
any useful concept of shared libraries, OSLib would be an obvious 
candidate to become one. The interface is more important than the the 
implementation, in some ways.

   Maintaining compatibility with old code is a courtesy to those who 
have any investment (in worktime or money) in the library. I 
described a way to add wide handles without breaking compatibility---
I said it was "a lot of work", but really it's just a question of 
finding all occurrences of OS_F and adding a similar definition 
ending in W that uses OS_W. It would take maybe an hour or 2, and it 
would fairly hard to make any mistakes, as DefMod would catch most 
syntax errors. So, to

      SWI OSFind_Openin =
         (  NUMBER 13,
            ENTRY
            (  R0 # 0x40 "Opens an existing file with read access
                     only",
               R0 | OSFind_Flags: flags,
               R1 -> .String: file_name,
               R2 -> .String: path
            ),
            EXIT (R0! = OS_F: file)
         )

we would add

      SWI OSFind_OpeninW =
         (  NUMBER 13,
            ENTRY
            (  R0 # 0x40 "Opens an existing file with read access
                     only (wide handle)",
               R0 | OSFind_Flags: flags,
               R1 -> .String: file_name,
               R2 -> .String: path
            ),
            EXIT (R0! = OS_W: file)
         )

   If we do it this way, no-one needs be concerned what version of 
OSLib they are linking to, as if they use a version that's too old, 
they will get a link error, and if they use a version that's too new, 
everything will work happily. There is no overhead in time or space 
for executable programmes. This is a win-win situation.

   (When SUN change a UNIX system call, do you think they demand 
everyone who used the previous version recompile and/or relink their 
programmes? Absolutely not! The new call gets a new number at the end 
of the syscall table (like a SWI number), even though it has the same 
name as the previous version. Code that used the old call still works 
(the old entry point works in the same way), but new code uses the 
new value in the new way. This is binary compatibility, and it's 
important. It's more important for key components, viz, system 
software, than it is for "outer" things like applications. OSLib is 
system software in this sense.)

 | Putting this limitation on
 | yourself artifically can only constrain the development of the
 | library.

   This just doesn't make sense! The library can develop in any way 
that's necessary. Bugs can be fixed, new features can be added, 
whatever anyone wants. Can you explain in what way you think 
maintaining comptibility can "only constrain the development of the 
library"?

   It's true that Microsoft products have a feature of built-in 
obsolescence. Word 4 can't read a Word 2 document. This is a 
deliberate marketing ploy to force people into a continuing cycle of 
upgrades. I reject it utterly. 

 | >    (2) Throughout RISC O S, the code assumes its a byte, so it's 
not
 | >    
 | > going to change.
 | 
 | That is not a valid assumption,

   It's not an assumption, it's a fact!

 | much of RISC OS is going to be
 | re-written in the near future.

   Now *this* is an assumption. It may or may not be a true one---
it's certainly been said for about 10 years now, so I wouldn't bet 
the farm on it!

   One of Acorn's most competent programmers went into FileSwitch/ 
FileCore once to do a bit of tidying up and to add image filing 
systems. He hugely underestimated the time it would take, overran the 
time he estimated by 2-fold, and came out visibly shaken. This is 
largely irrelevant, except that to show that Acorn filing systems are 
an area where angels fear to tread.

 | While you cannot guess all the
 | implications of this now, simple things such as ensuring the 
current
 | API is implemented without any invalid assuptions will mean code 
has a
 | much better change of continuing to work.

   The *current* A P I *is* implemented without any valid assumptions.

 | >    (3) If we wanted to change to wide handles, I think we would
 | > have to do the following:
 |
 | > [...]
 |
 | >    But it's a lot of work!

 | And not necessary. Just make os_f of type bits, and put in the
 | replace not for the next version that code needs to be recompiled.
 | The implications of doing this are less for file handles as they
 | are transient objects and should not be stored on disc as part of a
 | structure, whos length may now have changed.

   How do you know? This is a vague hope, at best!

 | >    No-one answered, so the consensus was to leave it alone, as it
 | >    was 
 | > lots of work for a net gain of nothing whatsoever.
 | 
 | A net gain of not breaking the vast amount of software that is 
linked
 | with OS_Lib on a the future version of RISC OS?

   That hasn't been written yet, so how can it be broken? *If* we 
decide to support this---and we easily might---all we need to do is 
supply an interface (the W thing) so that such code can be written. 
But we shouldn't fool ourselves into thinking that it can be the same 
code that exists today, because that (correctly)  assumes a file 
handle is a byte.

> So, is there any new discussion arising from that lot?

   It looks like there is! :-)

   Does anyone have any sense of how likely 32-bit file handles are 
going to be?

Does anyone want to go through and add the OS_W versions? I count 2 
files in Core that use them, 8 in computer and 2 in User (including, 
for example, Wimp, which would just need the addition of

      TYPE Wimp_MessageSaveDesktopW =
         .Struct
         (
            OS_W:                  file,
            Wimp_SaveDesktopFlags: flags
         )

and

      SWI Service_WimpSaveDesktopW =
         (
            NUMBER 0x30,
            ENTRY
            (
               R1 # 0x5C "Save some state to a desktop boot file (wide
                     handle)",
               R0 = Wimp_SaveDesktopFlags: flags,
               R2 = OS_W: file
            ),
            EXIT
            (
               R0 -> OS_Error: error,
               R1! = .Bool: unclaimed
            )
         )

etc etc etc. H'mm. It could be quite fun to go through and do them 
all ...)

 | On a slighly different note; everyone should be thinking ARM 32 bit
 | mode conversion from now on. Its going to be a vast amount of work 
for
 | every RISC OS developer, and one of the things we need to rely on 
is
 | that essential libraries such as OSLib, will be both 32bit ready 
and
 | cater for all existing API's and new extensions.

   Yep.

 | Removing potential problems such as os_f now, will mean a lot less
 | work over the cirtical times to come.

   Agreed.

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