OSLib 6.11 Released

[Tony van der Hoff]

On Tue, 26 Sep 2000, at 17:23:09, Jonathan Coxhead
<jonathan at doves.demon.co.uk> wrote on the subject "OSLib 6.11 Released":

> | On Mon, 25 Sep 2000, at 14:04:50, Jonathan Coxhead
> | <jonathan at doves.demon.co.uk> wrote on the subject "OSLib 6.11 Released":
> | >
> | >   I'm not sure I like it either---it seems like it crosses some 
> | >abstraction barrier that it shouldn't.
> | >
> | Could you explain that a bit more, please, Jonathan?
>
>   It's a vague feeling, really ... the thing in the "..." (or the <...>) 
>is a piece of the C language used to import an interface, not really the 
>name of a file. It's just that in C they're so close it's hard to tell them 
>apart.
>
Well, I guess the point here is that in C, on any platform that I know
of, the interface maps directly onto an OS file. It is possible to
conceive of an operating environment where this is not the case, for
instance mapping onto a database table. 

However, as far as I know, no such environment exists, and is not likely
to in the foreseeable future, so this really ought not to cloud the
issue.

>   The established way of implementing hierarchical structure in imports 
>(and it's hierarchy that lets us hide names, after all), is to use headers 
>like
>
>      #include <sys/types.h>
>      #include <X11/Xlib.h>
>
>etc, and since this is "standard", it seems that it follows the "principle 
>of least surprise" to use it. Of course, OSLib is very non-standard in most 
>ways (being implemented entirely in assembler, for one thing, and for 
>making many assumptions about the precise layout of structures, for 
>another); that's why the feeling is only a vague one.
>
that seems eminently sane logic.

>   The division of OSLib into 4 is not supposed to seem arbitrary: it 
>follows the following logic:
>
>      Core---kernel routines
>      Computer---device drivers and low-level code
>      User---user interface and accessibility
>      Toolbox---er, the toolbox
>
Sorry, I didn't mean to use 'arbitrary' in that sense. During the
development of OSLib, you were at some point confronted with the 77
files per directory limit, and you chose to sub-divide the library into
those 4 sections (was toolbox added later?). The choice was perfectly
obvious and rational. However, you may have made an equally obvious and
rational decision to split it, say, according to PRM volume, arguably
that may have been preferable. In that sense your choice was arbitrary. 

>   Sure---the processing for the NEEDS directive in DefMod could locate the 
>file by doing a reasonably straightforward enumeration of some parent 
>directory. Then if the SWI file were moved in the source tree, the header 
>file would move in the output tree, and the references to it in other 
>headers would all change in the matching way (though that shouldn't be done 
>after a release was made, as all user #include statements would break).
> 
Yes, that makes sense. If we were to do that, and we wanted to retain
the current division, then I think I'd go for oslib/section/header.h
rather than the shorter form. That would certainly avoid any collisions.
>
>   I agree that that solution is not ideal.
>
If it is auto-generated, then perhaps it doesn't matter too much.

> | Possibly a nicer solution, but which would only work on filing systems
> | which allow unlimited files per directory, might be to do away with the
> | division, put all the headers together in a single directory, and
> | include that in the file name. That would probably mean distributing X-
> | files or ra-FS with OSLib, and requiring a module installation.
>
>   That would be good too: but I still think the *whole* directory name 
>shouldn't be there, just the last component. Then we could have
>
>      #include "oslib/os.h"
>      #include "oslib/osfind.h"
>      #include "oslib/wimp.h"
>      #include "oslib/keyboardshortcut.h"
>
Yes, I agree entirely.

>which follows every rule I know of for C. I guess most people on RISC O S 
>use something to get round the 77-file limit these days, so maybe the time 
>for the whole 4-part thing is over now.
>
It would be nice. However, the current installation and setup process
couldn't be simpler. Yet I regularly get requests from potential users
asking me how to set it up. It is patently obvious that they haven't
even tried! How much worse would this be if they had to install a new FS
as well? The chances of getting it wrong are too horrendous to
contemplate. I think we do need to keep these people, on their first
foray into C in mind. One might argue that if they have the wit to
install C, then they should be able to cope with raFS, but experience
suggests that they haven't even got past that first hurdle correctly.

Another point is that some users copy some or all their headers into a
RAM disc. Can a RAM disc contain a raFS directory?

It will break code. Where an application writer has (wrongly) used 10
character  file names, the adoption of a long filename capable FS will
cause the shortened file names to be not recognised. Of course this is
no different from moving to RISC OS 4, but you'd tend to expect that
sort of problem doing that, whereas whem upgrading to a new version of
OSLib with an embedded raFS, people will blame the release.



On Wed, 27 Sep 2000, at 08:40:45, Chris Rutter
<chris at willow.armlinux.org> wrote on the subject "OSLib 6.11 Released":

>On Tue, 26 Sep 2000, Jonathan Coxhead wrote:
>
>>    #include is relative to the file that contains the line (in ANSI C). The 
>> K&R rule was different, but not often seen now.
>
>Oh, okay, I thought so.
>
Well, I did say I expected to stand corrected ;-)

<snip sensible summary of situation>

The problem splits into two discrete areas IMHO. We have the question of
what to use internally within the OSLib headers, and what we expect the
user to put in his own #includes. It would be preferable to solve both
problems in one stroke, but this is not vital. 

The difference is that the user is able to tailor his own environment to
suit his own needs, whereas we internally have to provide a robust,
unambiguous environment suitable for all users, that can handle cross-
platform development. The latter is the more difficult IMHO.

>  * This however means that one must include things like "oslib/core/foo.h";
>    people are bound to dislike this.

This usage would be perfectly acceptable within OSLib's headers; the
user can choose to set his include path at whatever level necessary to
suit his environment and to avoid collisions. 

>  Thus either:
>
>      - insist upon filesystems that can cope with over 77 files -- with
>        the free availability of raFS, and the fact that development systems
>        will tend to be recent, and that OSLib isn't backward-compatible
>        with older versions people may be using on (say) RISC OS 2/3 machines,
>        this is reasonable: then destroy the subdirectories;
>
OSLib certainly should be backwards-compatible with older OSs, although
some parts may not be relevant; this has always been a major aim, and
will remain so. 

Development systems may tend to be recent, but we do not restrict the
use of OSLib to 'developers'. Subject to storage constraints, it should
be possible to develop on any old platform.

I have explained my unease about adopting raFS and X-files above. 

>      - move all the header files into an `oslib' subdirectory within their
>        `core', `computer', `user' or `toolbox' directory, and include all
>        of those in your search path.
>
This is, effectively the present situation. 
>Is there any other alternative?
>
-- 
Tony van der Hoff         |  mailto:OSLib at mk-net.demon.co.uk
Buckinghamshire, England  |  http://www.mk-net.demon.co.uk/oslib/
----------------------------------------------------------------