8 bit os_f handles

[David J. Ruck]

On Tue 28 Mar, Jonathan Coxhead wrote:
>    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!

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. This ensures objects are
recompile should something in the library headers change and the executable
is linked with the new library.

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

Sorry but it is the API, not a matter of my opinion.

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

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.

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

>  | 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. Program A *statically* linked with OSLib X does not effect in any
way Program B linked with OSLib version Y.


>  | > Does anyone have any sense of how likely 32-bit file handles are
>  | > going to be?
> 
> and David replied ...
[snip]
>    Well, sure, but that doesn't answer the question, does it? (Are 
> you a politician? :-)

No but I am under NDA.

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

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.

---Dave

-- 
______________________________________________________________________

  David J. Ruck     Phone: 07974 108301     Email: druck at freeuk.com
______________________________________________________________________