8 bit os_f handles

[Jonathan Coxhead]

   John wrote,

 | 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 can understand that point of view, and I wish more and more that 
I'd done it that way from the beginning. But I didn't :-( :-(

   I could fault your reasoning here---just because a file handle is 
returned in a register doesn't make it 32 bits wide. How else could 
it be returned, after all? I would rather call it an "ambiguity" in 
the P R M's. But I admit that history is firmly on your side.

 | I do *not* care how FileSwitch is internally managing its 
filehandles
 | as as a programmer I have to make abstraction from it.

   I agree with that as well---but you have to make the right 
abstraction. If you had looked at FileSwitch, and seen how extensive 
the 8-bittedness of file handles is, you might have more sympathy for 
my mistake; but I don't suppose you would be any less convinced it 
was a mistake. I'm pretty much convinced at this point myself! 
Certainly, I have no evidence that any other published interface 
would have failed to work if |os_f| had been 32 bits from the 
beginning.

 | 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.

   That's not true---they will only fail to run if they get a file 
handle that is actually >255. This might never happen.

   And in any case, there's nothing we can do about it. That code is 
already out there, in binary form, and possibly the sources have been 
lost. We can't force people to recompile their code, any more than we 
can force them to change |os_f| to |os_w|. The question is simply 
whether we maintain a fixed relationship between source & object (as 
I advocate), or if we try to fix bugs by introducing new ones---
because that's what changing |os_f| to 32-bits would do.

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

   Absolutely---but not by breaking code.

   Here's an argument based even more firmly in logic: the 
compatibility-breakers say, "you can get the benefits of wide handles 
by recompiling, and if you can't recompile, your code (which 
previously was perfectly good) is now broken; and we don't care". The 
stability-advocates say, *if* you can recompile, **then you can 
change the source to get the new effect**. But we *also* point out 
that your old binaries will still work (unless they encounter 
circumstances they were not written to cope with---that's a problem 
no-one can solve, anyway). They will not under the compatibility-
broken scheme.

   And note that the brokenness in the first case---overwriting 
memory you don't own---is more severe than in the second.

 | > [...] 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...

   Well, quite. You seem to have changed sides in the discussion here!

 | 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.

   How about this instead: a big warning that says:

      A future version of FileSwitch may return handles >255. Any
      code that uses |os_f| will then behave unpredictably. To
      safeguard against this possibility, the new handle type |os_w|
      should be used instead. All existing FileSwitch calls that use
      |os_f| have been cloned with 32-bit versions whose name is the
      same as the 8-bit version with |_w| appended.

   This is no worse than the change to |long long| for file sizes, or 
to |wchar_t| for character data, and it exactly parallels them, both 
in its reason for being necessary (extended interface), and its 
resolution (extra calls for the new types).

   Now, how about font handles ... do we also need |font_w|? 
Including font_find_font_w(), font_lose_font_w(), font_paint_w(), 
etc, etc, etc??

   Deary dear ...

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