8 bit os_f handles

[Jonathan Coxhead]

   David wrote,

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

   No library change can help them. In fact, it is *not* users we are 
talking about, it is programmers. Only programmers compile code. If 
they compile code, they can easily change it to use |os_w|. That's 
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

   Changes the definition of "incorrect use of the library" in an 
incompatible way.

   Causes previously correct code to be broken.

 | 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

   (You mean "leave os_f at 8 bits and introduce os_w ...", I 
presume?)

 | Advantages    : Does not immediately break existing code 

   In fact, never breaks any code at all. Completely safe.

 | Disadvantages : Ensures existing code will break

   Not true.

 |                 Extra work to change existing functions

   True, but if you are going to recompile something anyway, you can 
easily make this change.

 |                 Makes OSLib larger

   Marginal.

 |                 Makes documentation confusing

   Not at all.

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

   So, in fact, a very similar list. Since you have to do (1a) 
anyway, you might as well to (2a), and this will remind you later on 
that you have done 1a, so you don't check the same file more than 
once.

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

   And so it is---no disagreement there. It is simply a question of 
offering a choice, instead of forcing people to do something they may 
not wish to do.

   Imagine someone has a complicated programme that would break if 
file handles were 32 bits (maybe it's memory-limited, and has an 
array of file handles in it somewhere), and they don't want to get 
the new FileSwitch. They should be able to continue using OSLib to 
develop their programme. They would curse if we broke their programme 
for them, and for nothing (the FileSwitch they have is an 8-bit one, 
remember).

   I know your response: "we don't care about them, we'll make them 
upgrade". But where do you draw the line? Which (binary) changes are 
acceptable, and which are not? It's conceptually much simpler to just 
say, "*no* binary changes are acceptable", and live with that.

   You don't care if *you* break *their* programme---but what if the 
tables are turned, and they break yours? You hate Microsoft when they 
do it: why do you think people won't hate you, if you play the same 
trick on them?

   It's just a necessary part of a communal software development.

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