OSLib 6.11 Released

[David Bryan]

Daniel Ellis wrote:

> On Thu 28 Sep, David Bryan wrote:
> > Tony van der Hoff wrote:
> > 
> > > Well, say the top-level OSLib directory is called <OSLib$Dir> . Then the
> > > default OSLib$Path would be defined as:
> > > 
> > > <OSLib$Dir>.,
> > > <OSLib$Dir>.types.,
> > > <OSLib$Dir>.macros.,
> > > <OSLib$Dir>.core.,
> > > <OSLib$Dir>.computer.,
> > > <OSLib$Dir>.user.,
> > > <OSLib$Dir>.toolbox.,
> > > <OSLib$Dir>.types.oslib.,
> > > <OSLib$Dir>.macros.oslib.
> > > <OSLib$Dir>.core.oslib.,
> > > <OSLib$Dir>.computer.oslib.,
> > > <OSLib$Dir>.user.oslib.,
> > > <OSLib$Dir>.toolbox.oslib.
> > > 
> > > Quite a handful, but still manageable, except under RO2, but I think we
> > > can safely ignore that.
> > 
> > With
> > 
> >   Set OSLib$Dir ADFS::HardDisc4.$.OSLib
> > 
> > the old definition of OSLib$Path comes to 214 characters, which is
> > OK.  The one above comes to a whopping 439.  AFAICR, this is not
> > going to work on anything before RO 3.7.  So, the extra layer of
> > path variables look necessary.
> 
> Surely not if it's defined as a macro?  i.e.
> 
>   setmacro <oslib$dir>.user.oslib....
> 
> instead of
> 
>   set <oslib$dir>.user.oslib....

Oh, this does help.  I was expecting buffer overflow; FontInstall
still has a buffer overflow problem on RO 4.02.  As a macro it's
284 characters long... time for a shorter alternative to
OSLib$Dir ?

-- 
David Bryan