Wolfgang Lenerz writes:
> > >Please let me have your ideas.
> >
> > 1) Some solution that addresses the filename length & seperators issue!
> > (Build on current or devise new, with backward compatibility)
>
> Umph, going right for the jugular, aren't we?
;) Dont pretend you dont want this, too!
> > 2) New job header definition to fit the name of the directory from
> > which program was launched. (And modification of calling procedures
> > (EX and all that))
> That actually tallies a bit with the first wish, since right now it will
> be difficult to distinguish between dirs and filenames: which part of
> "win1_iod_bim_dddb_keys" is the dirname, and which part is the
> filename?
It wouldnt be too difficult to modify the EX (EW, ET) Thing to figure that
out because it could first open the filename provided in an
EX "devn_dir1_dir2_name_exe"
statement as a directory and get the directory name from there and then pass
it on to the job. Currently (a6,a4) points to the data space of a new job.
If the first word of the dataspace contained a marker, eg $4AFB or $DDDD or
"%H" or whatever, followed by a string containing the directory name, a job
could on startup test for the presence of a name and then read it (or ignore
it altogether and use the whole space for its own purposes). Afterwards it
could discard it or even alter it if required. The name field should be of a
guaranteed *minimum* size of, say 44 bytes. AFAICS this doesnt cause a
problem with running new programs on old machines as if there is no marker
the facility doesnt exist. Old programs on a modified OS wouldnt know about
it and therefor ignore it as before. In the latter case the only side-effect
would be that in some cases you might waste up to 46 bytes of memory per
instance, as that would be the minimum dataspace allocated to any job. Of
course any old job expecting a zero-filled dataspace on entry would be in
trouble! A suitable Sbasic function to access this directory name (from
compiled SB jobs) would also be required, eg HOMED$ (and ditto for C etc)
If a job were set up as a Thing each new instance of the job would inherit
the initial home directory.
> > 3) A series of standard tests for platform/system-related facilities
across
> > the board. (Dummy toolkits for older systems in the intersts of
universal
> > compatibility.)
> You mean 'is this facility present' ?
> Or 'is this hardware present'
> or both? (probably!)
Specifically:
MACHINE
PROCESSOR
HOSTOS
EMULATOR
DISP_TYPE
There may be more, but this should be a useful start. Non-SMSQ/E QLs could
have a specifically tailored dummy toolkit for loading first thing. The
point is that all systems would be expected to provide this facility. All
this in the intersts of standardisation, which again is in the interests of
helping programmers and hobbyists to write programs for the widest possible
audience with a minimum of fuss.
Per
