8 bit os_f handles

[David J. Ruck]

On Mon 27 Mar, Jonathan Coxhead wrote:
>  | Arrrrrh! Any changes to library should result in a complete  rebuild of
>  | any projects that use it - anything else is extreamly dangerous.
 
>    That's exactly my point. "Changes to [a] library *should* result 
> in a complete rebuild of any projects that use it." The trouble is, 
> they often don't.

Then the users makefile is broken and they no doubt will experience many
other problems. The point is you should be supplying correct code, not
working around other peoples potential problems.

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

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

> If RISC O S had  any useful concept of shared libraries, OSLib would be an
> obvious  candidate to become one. The interface is more important than the
> the implementation, in some ways.

Agreed and there would be a problem if were a dynamically linked library.
 
>    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 is just good luck.

> I described a way to add wide handles without breaking compatibility---
> I said it was "a lot of work", but really it's just a question of 
> finding all occurrences of OS_F and adding a similar definition 
> ending in W that uses OS_W. It would take maybe an hour or 2, and it 
> would fairly hard to make any mistakes, as DefMod would catch most 
> syntax errors. 

Its a nasty unnecessary bodge that will:-

a) confuse users to which version of calls to use
b) not encourage people to change their existing code to use these new calls
   leaving the bug in place and ready to bite.

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

>    (When SUN change a UNIX system call, do you think they demand 
> everyone who used the previous version recompile and/or relink their 
> programmes? Absolutely not!

But this isn't a change to a system call, its a change to a library
which calls the system calls. 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)

>  | Putting this limitation on
>  | yourself artifically can only constrain the development of the
>  | library.
> 
>    This just doesn't make sense! The library can develop in any way 
> that's necessary. Bugs can be fixed, new features can be added, 
> whatever anyone wants. Can you explain in what way you think 
> maintaining comptibility can "only constrain the development of the 
> library"?

I think your work around adequately described the constraints you are
placing on yourself to correct a problem of your own making. The
whole idea of the OS_Lib is that it is the *thiest* wrapper of system
calls possible, an exterainous calls should be avoided.

>    It's true that Microsoft products have a feature of built-in 
> obsolescence. Word 4 can't read a Word 2 document. This is a 
> deliberate marketing ploy to force people into a continuing cycle of 
> upgrades. I reject it utterly. 

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. After that you'd have the situation where you'd have up to
40MB of DLL's loaded with the release and debug versions of MFC40 an MFC42
loaded while developing. I suggest we avoid this.

>    One of Acorn's most competent programmers went into FileSwitch/ 
> FileCore once to do a bit of tidying up and to add image filing 
> systems. He hugely underestimated the time it would take, overran the 
> time he estimated by 2-fold, and came out visibly shaken. This is 
> largely irrelevant, except that to show that Acorn filing systems are 
> an area where angels fear to tread.

The existing code has reached the end of the line. The 3.1 code has been
hacked to support >512MB discs and hacked further for the >15bit map
descriptors (long filenames and large directories being the easy bit),
and all credit to Matthew for getting it into shape for RISC OS 4, because
what we saw on 3.8 seemed terminally shaky.  Some nice shiney new
C will be written for the 32 bit version of RISC OS, and to allow >256G
discs which will be with us before you think.



[Back to os_f]
> | > No-one answered, so the consensus was to leave it alone, as it
> | > was lots of work for a net gain of nothing whatsoever.
> | 
> | A net gain of not breaking the vast amount of software that is linked
> | with OS_Lib on a the future version of RISC OS?
> 
>    That hasn't been written yet, so how can it be broken?

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. 

> *If* we  decide to support this---and we easily might---all we need to do
> is  supply an interface (the W thing) so that such code can be written. 
> But we shouldn't fool ourselves into thinking that it can be the same code
> that exists today, because that (correctly) assumes a file handle is a byte.
                                  ^^^^^^^^^^^
                                  No!
                                  
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.

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

We are extremely lucky not to see the effects of file handle exhaustion
more often. Heavy users such as font manager, image filing systems, DTP
packages and webrowsers all have to contain work arounds to release file
handles in a non optimal way. 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

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

Cheers
---Dave

-- 
______________________________________________________________________

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