OSLib 6.11 Released

Wed Sep 27 01:23:09 BST 2000

   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.

   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.

   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

 | To me, it seems like an elegant solution to a problem that affected a
 | number of people, including myself. It has worked fine while I've been
 | using it.
 | >
 | >   As far as I can see, the best way to decrease the chance of collision 
 | >with other headers is to use the already-existing division of OSLib into 4 
 | >functional units: Core, Computer, User, Toolbox. 
 | 
 | Whereas the path name scheme was a simple change to DefMod, your
 | proposal would require manual changes to each and every module, at least
 | a day's tedious work, which at present I am neither prepared nor able to
 | expend. There may be a way of automating it, but I can't think of a
 | practical one right now. 

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

 | Even putting that aside, those divisions are not natural, imposed by the
 | 77 files per directory limit, and are, to some extent, arbitrary. They
 | are currently totally flexible, only determined by environment
 | variables. I wouldn't want to promote them into the body of the code.

   I agree that that solution is not ideal.

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

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.

   (I just got RISC O S 4 and ArmLinux on my RISC P C!! Happy, happy! Now 
all I need to do is find something to read my SCSI tapes, currently 
inaccessible under either RISC O S or Linux :-( :-(

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