8 bit os_f handles

[Jonathan Coxhead]

   John wrote:

 | >I betcha there are no such things, and (if anyone's tried to make 
 | >them) they didn't work.
 | 
 | Are you challenging me ? Note I said >255 value filehandles, not
 | "more than 255 filehandles".

   I'm not challenging you. (Why? Do you feel challenged? :-)

   When David kicked this particular ball into the air, I asked 3 
questions:

 |    (1) Can you explain in what way you think maintaining 
 | compatibility can "only constrain the development of the library"?
 |
 |    (2) Is there an example of a filing system that needs 32-bit 
 | handles?
 |
 |    (3) Why do you think that it's bad for Microsoft to break 
 | backwards compatibility, but o k for OSLib to do so?

   None of them has yet been answered, by him or by anyone else.

   If you have an example of a filing system (that works) that uses 
32-bit file handles, don't be shy! Name it, and I, for one, will be 
the wiser.

 | > Remember, FileSwitch keeps track of *all* file handles that are 
 | > issued by *any* filesystem. As I recall, it only keeps 8 bits of
 | > information about each one, so using more is not possible.
 | 
 | I'm not talking about extentions allowing more than 255 
filehandles,
 | I'm talking about extentions giving you filehandles with a value
 | bigger than 255.

   I think I covered that, didn't I? How could it keep track of file 
handles with values > 255 if (as it does) it only keeps 8 bits for 
each one?

 | >    I'm still not convinced that we will see any product, that is 
 | > recognisable as "FileSwitch", that has 32-bit handles. My guess
 | > would be that in the course of such a major rewrite, many other
 | > incompatible changes would get made.
 | 
 | Like ? As I said before, the RISC OS PRM's do not declare
 | filehandles as 8 bit values.

   Like ... ummm ...

   Well, I'm only guessing, you understand, but the sorts of things I 
was thinking of are

         ---allocating more than 12 bits for the file type; 

         ---allocating 8 bytes rather than 5 for the time;

         ---supporting last-read and last-modified times for files;

         ---supporting symbolic links;

         ---more sophisticated access protection (owner/group, or
      access lists).

 | > A change to a 32-bit handle 
 | > interface in OSLib, is a change to support what is, at the moment
 | > (and with the best will in the world), "vapourware".
 | 
 | Not correcting this bug makes the people's life @ RISCOS Ltd/Pace 
more
 | difficult.  If they want to issue filehandles with values bigger 
than
 | 255, they will receive complaints of people seeing problems with 
OSLib
 | compiled programs.

   I've said this before, but the answer is still the same, so I'll 
repeat it: the complaints will only come from people who have not 
upgraded their software. There is nothing we can do to help them! The 
best that we can do is give people the capabilities to modify the 
software so it works: at the very least, this demands that they 
recompile it. Ok, so, if they are going to recompile it, they may as 
well do a global search and replace of |os_f| to |os_fw|, 
|osfind_openin| to |osfind_openin_w|, etc.

 | Who gets blamed ?

   Lazy developers? The idiot who first decided that OSLib file 
handles were 8 bits wide? Someone like that, anyway.

 | The wrong ones IMHO.
 |
 | >    If I still had anything to do with making OSLib decisions, 
the 
 | > only thing I would do at the moment is wait to see what actually
 | > appears. I expect that there are going to many compatibility
 | > problems with upgrading to a 32-bit FileSwitch, and the handle 
width
 | > will be the least of them.
 | 
 | Please give examples.

   I'm no oracle, and again, these are hypothetical, because we 
haven't yet seen a 32-bit FileSwitch. The most complicated area is in 
the support of image file systems, and they are one of the areas 
where people like to experiment. I would guess that the exact 
semantics of concurrent access to files within image filing systems 
might easily change in an incompatible way that would affect existing 
programmes, for example.

 | >  | >    That's not true---they will only fail to run if they get 
a
 | >  file | > handle that is actually >255. This might never happen. 
| |
 | >  Euh, why "never" ?
 | > 
 | >    People who don't get the new FileSwitch will never get 
handles 
 | > with more than 8 bits. Why should they have to go to the trouble 
of
 | > upgrading, for something they don't need? This is more 
Microsoftish
 | > philosophy.
 | 
 | But as a programmer, I want my programs to be run on as many 
versions
 | of RISC OS as possible, the old ones and future new ones and I do 
want
 | to maintain only one version, i.e. the one assuming filehandles 32 
bit
 | wide. Therefore I want OSLib to treat filehandle as 32 bit values 
like
 | defined in the PRMs.

   So use |os_fw| as soon as it appears. To give yourself complete 
protection, you can use the trick I outlined earlier (#define os_f 
junk/ #include "os.h"/ .../ #undef os_f) to make sure that any uses 
of |os_f| in your code are caught as errors by the compiler.

 | It is easier to recompile and test the code (eventually also source
 | eyeballing) than to change any instance of os_f into os_w and to
 | recompile, test, etc.

   No-one denies that, but the stability-supporters say that the 
disadvantage (that code can fail in arbitrary undefined ways) is a 
bigger counter-argument.

 | Which OSLib based modules without source are around ? I don't know 
a
 | single one ?!

   I don't either ...

   Does that mean there aren't any?

 | > But why should we want to do this, when there's a perfectly
 | > simple upgrade path that doesn't require us to browbeat people
 | > into doing things in a new way?
 | 
 | - To keep things as simple as possible in OSLib.

   To paraphrase Albert Einstein, "OSlib should be as simple as 
possible ... but no simpler".

   Obviously, we should make the upgrade path as simple as possible, 
by making the relationship between the 8- and 32-bit calls as 
systematic as possible. Then, it's pretty simple to do the upgrade in 
5 minutes with an editor.

 | - To make sure that users of the OSLib don't be tempted to use the 
8
 | bit
 |   filehandles ever.

   Documentation.

 | - To stop the idea that there is such a thing as an 8 bit 
filehandle.

   Documentation too.

 | The issue is that an OSLib based program using os_f today is *not*
 | correct and might fall over when encoutering filehandles with value
 | bigger than 255.  So your statement does not apply for this os_f
 | issue.

   You're just playing semantic games now. Any OSLib programme that 
has used |os_f| is already using an 8-bit file handle, and it works 
perfectly well at the moment, and will do for the foreseeable future 
(unless you are one of those people who foresees a 32-bit FileSwitch, 
see under "Cassandra", above). If all those programmes were broken, 
as you claim, OSLib would never have been used by anyone for 
anything. You can't just redefine "correct" to mean what you want it 
to mean! A programme that uses |os_f| on a system with an 8-bit 
FileSwitch was, and remains, and always will remain, "correct". It 
will become (in some sense) "incorrect" only when it is put on a 
machine with a 32-bit FileSwitch---and at that point, it is clearly 
operating outside its original design parameters (as they would say 
on Star Trek).

   But, (I'll say it again), there is nothing we can do about this 
anyway---the programme would have to be recompiled to fix that 
problem, and if it's being recompiled, it can be changed to use 32-
bit handles at the same time.

 | Bang!! Whose bug is this? It's not in the module---it
 | > described everything correctly, as at the time it was written.
 | 
 | Of course not.  Filehandles are not 8 bit values, not yesterday, 
nor
 | today, nor tomorrow.  That interface is broken.  Very though 
situation
 | I admit, but it is broken.

   Again, this is just playing with words. I defined |os_f| to be 8 
bits as a matter of intent, not by accident. Code written using it 
works perfectly well today. (But Richard van der Hoff has made 
exactly these points already.)

 | You're sticking your head in the sand.  It is an OSLib problem from
 | the beginning.  Don't waste time by inventing clever mechanisms 
which
 | do not correct the bug but cycle around it.

   Are you telling me what to do?

 | Those modules will break
 | in the future anyway.  The modules and their interface need to be
 | updated.

   No-one denies this. We only disagree on how to do it.

 | But the programmer needs to make programs which can run on RISC OS 
3.5
 | *and* a RISC OS version where we have filehandle values bigger than
 | 255 ! If the programmer didn't read the warnings that from now on 
os_f
 | is 32 bit and that all libraries using OSLib needs to be 
recompiled,
 | then he didn't do his job properly.

   "If the programmer didn't read the warnings that from now on 
|os_f| is deprecated and superseded by |os_fw|, and that all 
libraries using OSLib needs to be modified and recompiled, then he 
didn't do his job properly."

 | Nobody would let the 'hacker' (in your story) go away like that.

   They wouldn't like it, that's for sure, they'd curse and swear and 
say, "he's as bad as Microsoft".

 | Letting os_f live
 | forever as 8 bit is asking for problems in the future too.  How are
 | you going to make sure that people aren't going to use os_f in new
 | code ?

   Why should we? As a library provider, our role is very different 
from someone writing code to be run by end-users (regardless of 
whether the code is read by them, or only executed). The library must 
continue to support those who do not wish to use 32-bit file handles, 
because they are a (sad) reality. Existing FileSwitches cannot return 
handles > 255. (I am happy to continue asserting this until someone 
demonstrates that it is wrong.)

   I count 49 deprecated calls in OSLib 5.61: e g,

      Function:    podule_hardware_address()

      Description: Returns an expansion card or extension ROM's base
                   address, and the address of an expansion card's
                   CMOS RAM - prefer Podule_ReadInfo

Do you think that they should be withdrawn immediately? After all, 
"no-one should be using them"; "have you ever heard of a library that 
uses them?"; "anyone who uses them clearly doesn't know what they are 
doing, and isn't doing their job properly". All those arguments 
apply. But it's far, far better to simply document the call as 
superseded, and let people change their own code in their own way, at 
their own pace. Not trying to beat them with the stick of compilation 
errors (or worse, possible run-time errors), but lead them with the 
carrot of clear documentation.

 | The sad thing will be that the people who are providing >255
 | value filehandles (RISCOS Ltd, Pace, any third party making 
filehandle
 | extentions) will be blamed instead of the programmer wrongly using
 | os_f in his OSLib based programs.

   I disagree. I think that blame will be easy to attach squarely 
where it belongs, and modification of incorrect code will be 
correspondingly easy: it belongs to whoever has the source code, and 
they have to change it.

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