8 bit os_f handles

[Jonathan Coxhead]

   David wrote ...

 | Then the users makefile is broken and they no doubt will experience
 | many other problems.

   How on earth can you say "the user's makefile is broken"? It's 
just not the case! The makefile works fine!

 | The point is you should be supplying correct
 | code, not working around other peoples potential problems.

   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!

 | > Sometimes, object files are distributed in binary form---you 
don't
 | > want people to be *able* to link with an  incompatible past 
version.
 | 
 | I dont know of anyone supplying libraries for by third parties as
 | unlinked plain object files. All the libraries I've seen (and I 
have
 | most of them) are supplied as proper library chunk files which have
 | been partially linked against OSLib, so the problem doesn't arise.

   Again, you are making an assertion backed by nothing a vague sense 
of hope that that is how things ought to be. "Most" is not "all". In 
the real world, people don't always behave according to the way that 
you would most like.

 | > OSLib is a library, but it's also an interface.
 | 
 | A statically library's interface is defined by the header files 
not by
 | the binary object.

   Another assertion of an untrue fact. The interface has a *binary* 
definition. Why do you say this? I gave an example

      os_f f;

      ... xosfile_openin ("MyFile", &f) ...

that would break if the binary definition was changed. Please don't 
ignore the facts!

 | >    Maintaining compatibility with old code is a courtesy to those
 | >    who 
 | > have any investment (in worktime or money) in the library.
 | 
 | I cannot see you doing anyone any favors by continuing to ship
 | incorrect and potentially dangerous code. The OS_Find API is quite
 | clear, it returns 32 bit words, anything else is wrong. Because it
 | happens to work with most (not all as Stuart has pointed out) code
                                         ^^^^^^ "Stewart"
 | is just good luck.

   You can'y justify inflammatory phrases like "incorrect and 
potentially dangerous", "happens to work" and "just good luck" unless 
you have an example of a filing system that needs 32-bit handles. Do 
you?

 | > I described a way to add wide handles without breaking
 | > compatibility
 | 
 | Its a nasty unnecessary bodge that will:-
 | 
 | a) confuse users to which version of calls to use

   That's a question of documentation. We have a mechanism for 
flagging deprecated calls ("- prefer ..."). RISC O S has lots of 
these (and we support them all, even the funny OSWord calls with 
unaligned integer arguments [e g, |OSWordPointer_SetPosition|]!).

 | b) not encourage people to change their existing code to use these
 | new calls leaving the bug in place and ready to bite.

   Assuming that 32-bit handles happen, if and when they feel that 
they want to fix this bug, they can. Until they do, they get the 
existing behaviour. 

 | >    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.
 | 
 | It will only help people who have somehow managed bodge the
 | install of the library and mismatch the header and library files.

   Binary compatibility!

 | If sun supply a broken library, they
 | issue a new one, and suggest you recompile forthwith. (Usually on a
 | weekly basis between Solaris 2.1 and 2.6)

   :-)

 | I think your work around adequately described the constraints you 
are
 | placing on yourself to correct a problem of your own making.

   I don't see it as a problem--- though it's a constraint, to be 
sure. Once you come to see compatibility as an area where no 
compromise is permitted, it becomes interesting to try to see how to 
make it work. Sometimes it's easy, sometimes it's hard---that's when 
it can seem like a problem of one's own devising. I don't think it's 
any less of a sensible goal for being sometimes a bit tricky to 
achieve.

   For example, when |ColourTrans_SelectTable| was extended for RISC 
O S 3.5, it gained an output argument |R4 = .Int: size|. Since it 
wasn't present in the RISC O S 3.0 version, I couldn't just add it to 
the exit conditions, because that would have broken perfectly valid 
user code. Instead, I added |EXIT (R4?)|, to make sure that the 
register was saved over calls, and added a new call, 
|ColourTrans_SelectTableForSprite|, which gave access to the new 
functionality.

   Similary, when |Font_SetPalette| was given a new function---
setting the palette by means of true colours, accessed by setting R6 
to "True" on entry---the change was to add a veneer |Font_SetTrue- 
Palette| that did that. Also, the old veneer was changed so that it 
explicitly set R6 to 0. This means that there is no chance of getting 
the new feature "by accident", it keeps the users code the same, and 
it exposes the new ability of the O S.

 | The whole
 | idea of the OS_Lib is that it is the *thiest* wrapper of system 
calls
 | possible, an exterainous calls should be avoided.

   As I pointed out, there is no time or space overhead in using 
OS_W. The wrapper is as thin as it can be---in fact, it's exactly the 
same thickness as the existing wrapper.

   But though OSLib is very thin, it's very, very wide. It covers all 
interfaces to RISC O S, even deprecated ones. Not everyone wants to 
keep updating their code whenever a new release of a library comes 
along, and both courtesy and professional competence indicate that we 
should not expect them to.

 | Dont get me on to Microsoft. They had been shipping versions of 
MFC40
 | DLL with VC++ 4.0 and 4.1, but when they updated it for release 
with
 | VC++ 4.2, found they couldn't recompile the suite with it so had to
 | change the name to MFC42DLL.

   But this is **exactly** what you are proposing we do with OSLib!!!

   Can't you see that? Really?? It's very clear to me!

 | The existing code has reached the end of the line.

   Then we should go for OS_W.

 | Because any extension to the OS which causes it to commonly use >8
 | bit file handles will be expected not to break code which uses the
 | already defined 32bit API. 

   But I claim the A P I is 8-bit.

   I suppose this is the real source of the disagreement. I did it as 
8 because that's what I saw; I admit it was never documented 
explicitly, and choosing 32 bits may have been more sensible. But no 
matter where we think the mistake lies---my brain or the P R M---we 
have to make the best of it.

 | > code that exists today correctly assumes a file handle is a byte
 |                          ^^^^^^^^^
 |                          No!

   You can't argue with that---it's true!

 | My view is, ist better to flush out any problems at the earliest
 | stage. There is no bug worse than and old bug - as has happened 
here
 | it use because ingrained and it much more difficult to make changes
 | the longer you leave it.

   Well, sure. That means we should add the OS_W features now not 
later, so that everyone has a chance to upgrade. It doesn't mean we 
should silently break code for people who may be working in an 
entirely different area. Software is tricky enough to write when you 
only have your own bugs to worry about!

   We're still in a much better position than the UNIX world, with 
its lseek32(), llseek() and various other messes ...

   I asked ...

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

and David replied ...

 | RISC OS would certainly
 | benefit being freed from this restriction from the days of the
 | BBC B's OS.
 | 
 | 32bit handles are also likely to be needed if any resource 
management
 | system is to be used, that can still allow inter-task handle 
sharing

   Well, sure, but that doesn't answer the question, does it? (Are 
you a politician? :-)

   There's a bit difference between something being desirable, and 
being feasible in a given timescale with given resources. I was 
asking more about the latter.

 | > 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
 | 
 | Its just keeps getting worse, trying to perpetuate this problem!

   Not at all. When you go to sleep, just doze off murmuring to 
yourself, "Backwards compatibility matters ... Backwards 
compatibility matters ...". Very soon, you will see the light, my 
son. :-)

   So, you have 3 questions to answer, if you wouldn't mind:

   (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?

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