8 bit os_f handles

[Jonathan Coxhead]

   David wrote,

 | If source files are not dependant on all headers included
 | (automatically generated dependencies using AMU and Acorn Make) and
 | the executable isn't dependant on the library the make file is 
broken.

   Look, you are doing yourself no good at all by repeating, over and 
over again, the same damn thing. It's still not true! When a library 
is provided by a third party, people just **do not** include 
dependencies on that library in their makefiles. If this were true, 
every makefile have dendencies on the version of the O S it was 
intended for, in case it need to be recompiled when the user did an 
upgrade!

 | > 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!
 | 
 | Sorry but it is the API, not a matter of my opinion.

   The A P I is 8-bit. That's true---at the OSLib level, and at the 
FileSwitch level as well (as we go to press ...).

   If the FileSwitch interface becomes 32-bit, the OSlib interface 
will evolve to keep pace.

   The fact that the OSLib interface is 8-bit looks like a mistake. 
If only I could remember exaclt why I did it, I'd know for sure. :-(

   I promise you that, compared to the work of giving FileSwitch 32-
bit handles, the work of adding |os_w| to OSLib will be a walk in the 
park, picking the daisies. So will modifying user code to match.

 | Again if *might* someone rely on non transportable features such as
 | supplying completely unlinked object files, you cannot try and 
support
 | this, it just doesn't make sense.

   It does so make complete sense!!! You seem unable to distinguish 
between what you want, and what is!

   We *do* support those who rely on features such as supplying 
unlinked object files! Also, those who want to write binary 
structures to disc and read them back, those who want to do remote 
procedure call bindings including arbitrary O S types, and every 
other bizarre, baroque and creative use of the library that we 
haven't thought of. 

   *You* may not like what those people do, but we are happy that 
they are writing interesting code, and we are committed to keeping it 
working!

 | >    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. 
 | 
 | This is unbelievable complacency!

   It's not complacency at all, it's a natural consequence of what 
happens in an evolving system. When files >2GB started appearing in 
UNIX, did anyone say, "let's make lseek() return a |long long|"? No. 
Instead, they intruduced llseek(). Same for us.

 | >  | 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!
 | 
 | I'm sorry but yo have completely missed the point. This is what 
they
 | had to do because its a Dynamic library and cannot change its 
binary
 | interface, with out breaking all programs that use it. OSLib does 
not
 | have this constraint.

   Of course it does.

 | Program A *statically* linked with OSLib X does
 | not effect in any way Program B linked with OSLib version Y.

   Libraries might not be statically linked (duh!)---a library is 
just a collection of object files. Symbols are still unresolved in 
them. In the old days, before SharedCLibrary was in ROM, we had 
o.Stubs (which linked to the SharedCLibrary module) and also 
o.ANSILib, and you could choose either one. o.RISC_OSLib only got a 
module version even later (and it was part of SharedCLibrary).

   I don't know what the current state of RISC O S shared library 
technology is at the moment (poor, I suspect), but others are 
perfectly entitled to ship library files which are just that---a 
bunch of useful functions, in a library file.

 | > Does anyone have any sense of how likely 32-bit file handles
 | >  are | > going to be?
 |
 | No but I am under NDA.

   We can take that as a "very likely", and do the work for |os_w|, I 
think :-)

 | Do any of the users in this mailing list have any code which will
 | break if os_f is redesigned as a 32 bit, and the application
 | recompiled? Its easy to tryout by just modifying the os.h header.

   This doesn't matter one bit. Hundreds of copies of OSLib have gone 
out, and I have no idea who's using them. Neither does anyone else. 
Even if the answer was "none", I'd still argue for compatibility: 
it's a professional ideal.

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