Simply, none! You only are recommended to always having the QDOS clock set to the correct DATE, for directory-names purposes (re. below, "Newly created directories"). The QVFS should work within the standard Black QL (tested in QLAY 082+MINERVA 1.93+TK2.12) as well as with MINERVA (1.93 tested) & GoldCard, the QXL (tested with SMSQ 2.76), etc., or any SMSomethings...

Any job can independently activate its own independent instance of the QVFS by the following sequence of *Basic commands or, by its QDOS trap equivalents, after the QVFS was linked into QDOS:

1. assure you have the .dev option devices list ready (re below), "win2_inet_devices".
2. request QVFS access: ch = FOP_DIR("VFS .opn")
3. enable a set of devices: id = FOP_DIR("VFS .dev win2_inet_devices")
4. register the assignment files name: id = FOP_DIR("VFS .nam flp1_inetfiles")

In this special open string the name "VFS" must be written in capital letters, while the assignment symbols (".opn", ".dev", ".nam") must be written in small letters; each of its segments delimited by a blank space.

On success the 1st OPEN_DIR will return D0:=0 from a QDOS call or, the *Basic channel no. Any other consecutive attempt to OPEN_DIR a VFS channel from within the same job will returm that channels ID after a QDOS call in D0 or, as the pseudo error code to *Basic. It does not create a further channel. The above FOP_DIR can be substituted by VFS_FOP(4, ... ).

If the QVFS was set up some session before, with the same system files, this will be all that is required to enable acces to any (enabled) device and file by Inet style names.

The thus carried out setup will be inherited by the following jobs of its tree by searching back for an appropriate VFS channel at the time the actual QVFS operation was invoked. Therefore, if done from the 1st *Basic (job 0) at any time from then on any other jobs can acces the FS by Inet names.

For 1st time installation and for each separate configuration the following should be carried out, further:

1. setting up the devices list
2. setting up the files assignment lists for each (sub-)directory to enable

Those lists consist of several lines with two entries, each, the Inet name and the corresponding QDOS name, both of which are delimited by a <nul> character and separated by, at least, one blank space.

<nul>
is the code 0 ASCII character, which throughout this text may be taken for any character the code of which is below 32, the blank space, and is not 10, the line feed control code, <lf>.
Nevertheless, where applicable, any device supplied strings will be terminated by the true <nul> as the only one delimiting character code, reliably.
A little (but quite versatile!) editor capable of writing any code accompanies the package and thus the mandatory <nul> characters (below code 32) should not raise any difficulties.

• The devices list
  representing the physical root should be present and accessible on startup, already.

With the above example it will be expected as "win2_inet_devices":

/second networking hard disc/<nul>	n2_win2_<nul>
/w2/<nul>	win2_<nul>
# ...	... this is a comment line
/net1/floppy1/<nul>	n1_flp1_<nul>	# another comment
/printer<nul>	ser1ht<nul>	# a "simple" device
/incoming/<nul>	win2_inet_files_ftp_in_<nul>
/ftp/<nul>	win2_inet_files_ftp_in_<nul>	# doublette - a "link"
/InComing/<nul>	win2_other_files_bbs_in_<nul>	# case sensitive!
#
/CD ROM/<nul>	win2_cdrom_<nul>	# re below for r/o redirection

The lines layout must be within bounds:
- A line, including the <eol> charcters, <lf> or <cr><lf>, may not be longer than 448 bytes.
- The significant information may not reach beyond the 382th column of a line.
- The Inet name may not begin after the 190th column of a line.
"<nul>" symbolizing the ASCII <nul> or any other code below 32, except 10.
Leading spaces will be discarded.
Everything after a "#" number sign not within a name is a comment.
Names can be made of any characters in the code range of 32 to 255.
Inet device description (only!) entries begin with a "/" slash.
Inet directory names end with a "/" slash - Inet filenames may not end with a slash.
Assigned QDOS directory names end with an understroke "_".
Assigned QDOS names may not contain a "/" slash at all.
Any names are delimited with a <nul> character (re above).
The names are recognized case sensitive (for simplicity, Q+DOS behaviour unchanged!),
- i.e. for PC-DOS files access the assignment files name should be initiated in capital
- letters or, simply, just the inet type name of the directory assignment file the name of
- which was set with the initial .nam option be editted to the conformant writing mode.

• The files lists

The files assignment lists are of the same structure, listing any file by its full path name, but without the device description, as known from the standard QDOS style directories display. Those lists - wherein the Inet type names entries do not begin with a "/" slash - can be produced semi-automatically with VFS_SYNC or the appropriate VFS OPEN call and may then be editted with Inet names to suit.

With the above examples the QVFS would expect a file "inetfiles" in each of the enabled (sub-)directories and/or devices.

• produce an assignment file: id = FOP_DIR("VFS .nam win1_")
• another assignment file : id = FOP_DIR("VFS .nam win1_inet_")
• probably a PC-DOS device: id = FOP_DIR("VFS .nam flp2_")
• and networking : id = FOP_DIR("VFS .nam n3_mdv2_")

This is the registering open call, with the only difference that the file names end with an understroke to notify a directory name - regardless of the media structure possibly establishing "true" directories or not - which than the system evaluates to producing the appropriate assigment lists:

• "win1_inetfiles"
• "win1_inet_inetfiles"
• "flp2_INETFILE" in the PC-DOS disk.
  Its own Inet name in this file should then be editted conformant to the true writing mode.
• "mdv2_inetfiles" in the remotely connected QL.

Wherein the QDOS filenames will appear translated to Inet style names with any "_" understrokes being replaced by a "/" slash, except the very last one which will be replaced by a dot "." if it is within the last five characters of a filename (as opposed to a directory name). Any further conversion can be editted.

As a means of security any QDOS files not listed in the assignment files are not accessible via the QVFS. It can create and register new files, but delete or overwrite only already registered ones.

• Redirecting to R/O devices, etc.

/next/directories/filename<nul> /dev3_filename<nul> # QDOS path fully specified

QVFS v06:
Directories newly created by the QVFS will also appear that way, redirected to the basic directory (the device) with an arbitrary name, which will be orderly recognized from within the QVFS, internally.

A QDOS names entry beginning with a slash will be considered as the full device+filename description.
- wherein "device" should comply to the (habitual) QDOS conventions of the device named by a
- (three characters) text string, plus a decimal digit 1..8 and an understroke, optionally preceded by a
- NETworking symbol, i.e. a letter, a decimal digit, and an understroke.

... that is it.

The QVFS will now take over the files open calls after the chain of "simple devices" was passed and check the names for their Inet-style properties and process those names that fit.

Inet-style names will be recognized if they begin with a slash "/", or if the beginning is one of the symbols "./" for the working directory path or "~/" for the home directory path.
The names will be expected specified as the full path+file names, explicitely, or after internally expanding the HD or WD path's symbols.

The other Inet names special symbols are

This is much like the LINUX/UNIX FS's, with the exception that those systems do the path-to-root extension internally, which they can, because they safely "know" of what an environment they are in - which the QVFS OPEN call thus can not, and requires the user to at least notify the system of which kind of FS to use. The only extra action required, though, if a name does not already begin with a slash to denoting a fully specified root path is inserting the leading "./" to make a "current path's" name recognizeable. - For **X style automatic WD insertion re below, "naming mode preference".

QVFS 05:
Further, any QDOS style filenames wherein a "/" character was found and which do not begin with one of the above mentioned symbols will be tried Inet style in the working directory and, responded to with a bad name error (-12) if no match found - unless the VFS branch was set to QDOS preference.

No QDOS name designed to be accessible by an Inet-name should contain a character code of 0 till 31. Those characters can be used as another means to exclude a QDOS file from QVFS access.

Several additional features will be available to any job that is an owner of a VFS channel or any successor of such a job. Thus, if assigned to the 1st *Basic job any other program in the QL which was executed after has access to the Inet style FS and its long pathnames - if not some error "protection" within those jobs themselves prevent their use!

• New files (OPEN_NEW, etc.)
  

When creating new names the path will be taken as set, and the filename added with its first character plus any other characters taken from its end until the QDOS limits are reached. For instance

• Newly created directories
  QVFS v06

Directories of any level, created by the QVFS, will always enable filenames translated to QDOS of up to 27 characters without being truncated. The Inet style path+filenames are limited to the sum of 255 characters, over all. No limits on the number of nested sub-directory levels exist.

The underlying QDOS FS is limited to no more than 15 sub-directory levels, by the filename length limit of 36 (31 if NETworking) characters. This has been overcome by simulating the Inet-names style directories in a way that no limits at all apply to nested directory levels. Those appear as they should when maintained with the QVFS routines, but reside all in the basic QDOS directory of the device concerned, not nested at all, with an arbitrary unique filename, derived from the current DATE value. Therefore each call to creating a directory will be delayed by about one second, to guarantee for unique names in case of fast consecutive such attempts.
This naming mode does not apply to names created by VFS_SYNC, etc., thus it will be essential to keeping the assignment files safe, as it would be very difficult to restoring the correct directory structure after such a file was lost. - Which can be done by backtracking the 1st assignment of those files.

• Write-only channels

An additional OPEN mode was introduced, OR-masking the common QDOS open code in D3 by the value of 8, thus modifying any standard OPEN call to its write only mode.
After opening the channel will return with the file pointer set to EOF.
Any attempt to reading from such a channel will be responded with the err.ef (-10) error code in D0.
The new commands FOP_WO, OPEN_WO and VFS_FOP support this mode in *Basic programs.

• Directory channels
  QVFS v06: access limitations reduced.

Another OPEN mode can be forced by ORing the standard code with 16, or be left to the system which regardless of what was requested will always use the OPEN code of 17 when OPENing a channel the name of which ends with "/." or "/..", where the actual QDOS channel will be opened r/o as OPEN_IN.
A thus opened file will be regared as an Inet type directory file the entries of which can be read with a specific INPUT (or io.fline) call - re below. Because the QDOS does not permit shared r/w access to the standard directory devices no new files can be created while the directory file concerned is opened on behalf of any other QVFS call.

QVFS v06, modified:
New Inet type directories - the names of which end with a slash, and are till unknown to the system - can be created with the open code 18. Due to the above mentioned QDOS reasons no files of the initial directory level and its successors can be acessed until the end of this process.
While an empty initial assignment file will also be produced by this call (or an existing one left untouched) a VFS_SYNC call will be required to enabling access to any previously unknown conformant files.

• Deleting files

The QDOS trap call to deleting a file will not be propagated to the simple devices handlers. This also applies to FORMAT and works out as a safe means to protect the QVFS from external sabotage. Nevertheless, to facilitate the necessary files maintenance a substitute "idelet" can be called with the io.open QDOS trap (trap #2, D0=1) the mode flag set to -1 (in D3), which will outcomment the registered entry in the assignment list and delete the assigned QDOS file, while any other -ve mode flag can be used to just invalidating the Inet name while leaving the QDOS file intact (QVFS v04).
IDELETE is the corresponding new *Basic procedure.

• Formatting

...with an Inet name is not possible (re above).
It can be done from any QDOS program, though, using the standard *Basic/QDOS calls.

• Linked files or directories

Links to other files or directories can simply be installed by assigning another Inet name to the same QDOS name or, by the same Inet filename in different directories to different QDOS names; and by a redirected full QDOS name ("/device+filename") assigned to any possible Inet path+name, where then any further levels of redirection could be introduced with the "DEV" virtual device, etc.
But, still, simultaneous multiple access can only be enabled with all channels in the r/o mode - which is a QDOS feature the QVFS (in its present state) cannot override.

• Working directory - WD -

The working directory is much like the TK2 device default, but more suitably implemented to the QDOS style multitasking systems, as any job(-tree) with a VFS channel will maintain its own independent path.

A path, ending with a "/" slash, can be passed to a VFS channel via the QDOS trap fs.heads or by the *Basic function VFS_WD, which additionally returns the previously set path. The working directory, if set, can then be abbreviated with the symbolic pathname of "./" followed by any further directory level, the backstep symbol(s) inclusive, and the filename requested.

The VFS-device QDOS-traps io.sstrg and io.fstrg - *Basic PRINT and INPUT - are implemented such that they push and pop a directory segment to/from the WD path (re below, *Basic and QDOS extn's).

• Home directory - HD -

Another directory path inherent to the VFS channels, each, the only difference of which to the "working" directory path is that it can only be set and manipulated from job 0 (the supervising basic *Basic job) or from the particular VFS channels owner job. *Basic function: VFS_HD, re below.

• Naming mode preference

The QVFS can be set to preferably use Inet style names, always inserting the working directory path if no slash leads the channels OPEN names, or to QDOS names only mode, not recognizing any Inet style names at all. The standard mode is 1st trying to decode an Inet name by its leading characters, as stated above, and if that failed and the name does not contain a slash character, proceding to the QDOS directory-devices for further names decoding.
Several specific OPEN names exactly as written below set the FS preference:

1. QDOS names only: old_flag=VFS_FOP(4,"VFS .fss QLF")
2. Inet names only : old_flag = VFS_FOP( 4, "VFS .fss VFS")
3. Standard mode : old_flag = VFS_FOP( 4, "VFS .fss STD")
   This mode will also be set if neither of the above .fss-specifiers fit.

"old_flag" will be returned as a +ve 32-bit number (in D0 to QDOS, or as ERNUM to *Basic) with bit 30 set and the flag code in the l.s.byte, -1:Inet-, 0:Standard-, 1:QDOS names decoding mode, and can best be read after some sedecimal conversion, i.e. HEX$ (TK2) or TO_BASE$ (IO2).
The current state can be locked or unlocked by a special sd.extop call (re below), which will be executed if called from job 0, only (*Basic function re VFS_LOK).

• Error messages

An error code extensively used by the VFS OPEN routines is the "bad name" error (-12), which is the only one that can safely, i.e. with no other effects, prevent the TK2 routines from inserting its globally set device defaults. Thus the QVFS channels opening errors messageing is not very informative.
The bad name error can be triggered after a bad name was recognized, but also instead of the "not found", "already exists" or "in use" errors. And, it will be returned, due to temporary inaccessiblity of the directory file, if at any level in the search path a file creation or deletion process is currently being run by another job. Often some more precise information can be gained from the internally stored error code in the cdt variables of the VFS channel involved (*Basic: VFS_ERR) which will be set whenever possible.

• System security

1. FORMATting via the Inet names system is not possible.
2. Different jobs can be assigned different devices lists to.
   Different trees jobs cannot access eachothers separate devices lists.
3. The supervising VFS channels are further protected (re below, QDOS traps).
4. Unless currently in use by an i/o trap call the channel details remain hidden.
5. The devices assignment list cannot be changed.
6. Devices not listed under no circumstances can be accessed other than by the QDOS native FS.
7. The files assignement files (by internal QVFS routines) will never be visibly left open.
8. Locking the FS preference will prevent the job concernd, and its successors, to changing FS access from the mode currently valid.
9. No files of a particular directory branch will be found if an intermediate level assignment file is currently in use by a files deleting or creating QVFS routine.

For instance, setting up a very secure system could be done by

1. assigning a VFS channel to job 0, with QLF preference,
2. starting any (parent-)jobs to be used within a particular session, set to VFS preference,
3. locking the preference setting, by VFS_LOK with any VFS channel currently existing.
4. providing files access in (new) programs via the QVFS, only.

• A few words to program(mer)s

There is no simple means of distinguishing a directory device name from a name meant to describe a simple device other than by a trial open and directory read which can help to finding out wether a device is capable of files and/or directories simply because the appropriate QDOS traps work, or not in which case a non-directory device might have been found.

Further, the QVFS does provide an sd.extop call, and thus cannot be distinguished from a CON type channel that way, either. But, for those who still feel they cannot trust the QDOS routines a special marker was provided in the handler and in the channels definition tables - re below.

Another warning: Do not falsely interpret the physical data returned by the fs.xinf call, providing some extra media information, unlike the logical data of a directory entry supplying a uniform header structure for each of the several types of QDOS channels.

The QVFS *Basic extensions

• IDELETE inetname$
  

• OPEN_WO #channel, inetname$
  

• VFS_SYNC "qdosdirectory_"
  

• VFS_INI
  

• VFS_PUSH [[#]vfs_channel,] "inetdirectory/"
  

• VFS_UNL
  

• channelnumber = FOP_WO( inetname$ )
  

• inetfileheader$ = VFS_DIRH( [#]chan[, entry_no] )

• ernum = VFS_ERR( [[#]vfs_channel] )

• channelnumber = VFS_FOP( open_mode, any_type_name$ )
  

QVFS v06, modified:
Names ending with "/" will be used to create a new directory, if "open_mode"=2 was passed, and not being responded to with an open channel; the call returning the VFS-ID on success, -12 otherwise.
Creating a new directory will insert any conformant QDOS files to the corresponding QDOS directory, and, if not already existing, produce an empty Inet names assignment file. Re-synchronizing will only be required to enabling any existing (additional) QDOS files - re VFS_SYNC, VFS open trap.

• oldpath$ = VFS_HD( [[#}vfs_channel,] inetpath$ )

• inetfileheader$ = VFS_HEAD( [#]chan | inetname$ )

• vfs_channel = VFS_ID( [job_number | job_id | jobname$] )

• oldstate = VFS_LOK( [[#]chan,] flag )

• topdirectory$ = VFS_POP( [[#]vfs_channel] )
  

• VFS_RNUM
  

• ermum = VFS_TST
  

• oldpath$ = VFS_WD( [[#]channel,] inetpath$ )
  

Yet unsolved...

1. Removing a job which is the owner of a VFS channel can leave its system channels open.
2. Directory read errors might occur due to timing problems via the NETwork fileserver which sometimes did corrupt the cdt pointer in the QDOS tables - the reason of which is still a mystery.
3. Occasional timing errors were encountered when calling the directory read traps from a secondary *Basic job - which are non-destructive and can be overcome by re-reading.
4. Early timeout and incorrect data handling in the SMSQ/E versions was the reason for other errors with (slow) NETworking NFS channels, resulting to the destination channels left open.
5. In the Standard QL (un-expanded, or with TrumpCard) any external i/o-calls with a channel to the root directory, e.g. IDIR"/", got stuck, while no other directories did produce that error.
6. The SMSish systems seem to unrecognized overwriting the slave blocks of a single file to which multiple concurrently opened r/o channels exist, not re-fetching them on an attempt to read. This can work out to any number of Inet directories appearing unreadable, though most often remaining accessible. "Normal" r/o access might result in a bad media error (-16).

Any idea? - email

Modified Inet type channels QDOS-Traps:

Data sizes 32 bit if not stated otherwise.
Registers not mentioned remain unchanged or, if applicable return the standard QDOS values.

• opening a channel by its Inet name an auxiliary (non-directory device's) channel definition table will be set up carrying some maintanance data and the pointers to the original channels handler and cdt.

io.open D0=1    D1/A0 parameter passing and D0 error code as usual.

	D3	OR-Mask 8       "open w/o" modifier:

	D3	Any OPEN mode can be OR masked to the corresponding r/o mode.
		Reading operations will be responded to by the err.ef (-10) error code.
		QDOS-i/o-traps disabled are D0 = 0..3, 8..11, 69, 72 and 78+.
		The filepointer will initially be set to EOF.

	D3	OR-Mask 16      "idir" modifier:

        D3      17              "read idir", directoryfile, r/o; alternatively
	D3       1		plus the Inet name ending with "/." or "/..".
		This mode will be set internally if the path+filename supplied
		ends with "/." or "/..", and passed to QDOS as standard "r/o".

	D3      18              "create idir", create a new directoryfile; alternatively
	D3       2		plus the Inet type name ending with "/".
		An Inet type directory entry will be created in the current level
		assignment file and a uniqely named QDOS directory and, if not yet
		present, an empty corresponding QVFS directoryfile newly set up.
		This mode will be modified, internally, from a call to create a 
		new file if the path+filename supplied ends with a slash "/" and
		be responded to with
		D0 = the supervising VFS channels ID on success or,
		D0 = -12 if the directory was not installed
		A0 undetermined, this call leaves no open channel.

        D3      -1              "idelete"
                Replacing the standard io.delet call (D0=4).

        D3      -ve             "iremove"			QVFS v04
	D3	any -ve value but -1 can be used to recoverably invalidating the
		Inet to QDOS assignation, by out-commenting the entry concerned,
		and not physically deleting any data.

• i/o trap calls are serviced such that the current QDOS state will be transferred to the original cdt, the handler and cdt set to the original values and the original i/o routine be called with no registers changed, including the stacked data that came into the call.
  Thus providing access to any channels in a way determined no other than by the host system.

	NOTE:
		For the special operations on Inet-style directory files
		D3:=-1 is almost mandatory, uncertain (though not unsafe)
		operation might result, otherwise.
		The repetitive nature of certain calls occasionnally may lead
		to unexpectedly long execution times of up to several seconds,
		depending on the storage media involved.


D0=02, 03               io.fstrg, io.fline                      fetch a string/line of bytes
		modified handling for directory type channels, only, re below.

D0=71                   fs.headr                                read the (file)header
	IN:
		D2.L = 512 used to return the Inet type 512 bytes header.
		D2   any other value used to return the QDOS standard data.
		A1   buffer address, if D2=512 odd A1 values will be rejected.
	OUT:
		D0 = -13, err.te if validating failed or odd address encounterd
		D1   received length (512, any value other than D2 is an error)
		A1   points to after the 512 bytes buffer space; for the received
		     data structure re to "fs.headr type QVFS fileheader", below.

D0=74                   fs.renam                                rename a file
                        *** yet to be implemented ***
		D1 specifying the over all length of the string at (A1)+.
		A1 even address pointing to the new QDOS type name with leading
		   count.w, followed by the <nul> terminated new Inet type name
		   at the next even address.
                The trap call will 1st modify the Inet assigned name by 
                outcommenting the old and appending the new pair of names,
                then call the QDOS routine. Thus the Inet name will even 
                appear changed if the QDOS call failed! - Which can be 
                recovered only by editting the assignment file concerned.

		D0 = -12 (err.bn) will be returned if D1 was out of bounds,
		D0 = -13, err.te if validating failed or odd address encounterd

Directory type "ccc/." channels special i/o handling (trap#3):

D0=02, 03               io.fstrg, io.fline                      fetch a string/line of bytes
	IN:
		D2 = 512 to fetching the current directory entry,
		D3 = -1 (almost) mandatory (re above),
		D3  at any other value can result to incomplete data transfer.
		A1  buffer address; if D2=512 odd values of A1 will be rejected.
	OUT:
		D0 = -13, err.te if validating failed or odd address encounterd
		D1  received length (should be no other than 512)
		A1   points to after the 512 bytes buffer space; for the received
		     data structure re to "directory type QVFS fileheader", below.

		The buffer will initially be set to all -1, which when this value can
		be read anywhere in the leading 52 bytes or in the Inet name space
		denotes the data not being read (D3 was not set to -1?), and the
		filepointer left at its previous state, enabling loss free re-reading.

QVFS v05:	The root directory headers will be made up from the devices
		assignment file, only, no QDOS headers being fetched, because
		of frequent QDOS/PIF related errors.
		

D0=66			fs.posab
	IN:
		D1 = number of the entry to be addressed,
		     further data as fs.posre.

D0=67			fs.posre
	IN:
		D1 = number of entries by which the reqired directory entry
		     is displaced to the current one.
	OUT:
		D1 = QDOS style file position at the beginning of the
		     line containing the directory entry requested.
		     If the absolute number results to -2 or -1 the file pointer
		     will be read as zero, while the next consecutive directory
		     reads will start at the the pseudo headers of the current (-2)
		     or the one step back directories, "." and "..", respectively.

• Closeing a channel will 1st discard the auxiliary data block, then determine the pysical definition table, set A1 to its address, and jump into the original system routine.

"VFS"-Channel QDOS-Traps:
Those calls apply to the QVFS control channels, only.

• channels allocation (trap #2):

D0=02                   io.open

	  D1 = -1 or owner job ID
	  D3 =  any non-directory type code
		Setting up a very simple NUL-device channel,
		returning EOF on any reading operations and responding OK 
		to writing, with D1 set to D2 on entry, A1 advanced by D1.

	  D3 =  4  directory type,
		the general purpose QVFS supervising channel mode:
	  A0 =  ptr to a special name as explained above,
		which must be written exactly as stated (below).
		The actions concerned apply to the calling jobs VFS channel.

		"VFS .opn"
			registering a QVFS instance to the channels owner job
		"VFS .dev devN_filename"
			registering the enabled devices list.
		"VFS .nam devN_filename"
			registering the 1st files assignment list
			and determining the lists filename used
			throughout this QVFS instance.
		"VFS .nam devN_directory_"
			producing a complete assignemt list of and in the 
			directory specified, the listfiles name will be as 
			passed with the above .nam registering call.
		"VFS .fss VFS"
			Set QVFS mode to Inet names preference.
			Any names 1st will be tried for Inet style feasibilty,
			with the WD inserted to lead the name if applicable.
		"VFS .fss QLF"
			Set QVFS mode to QDOS names preference.
			Disabling the Inet names decoding.
		"VFS .fss STD"
			Set QVFS mode to standard preference, i.e. if Inet type
			names check failed passing control to the QDOS devices.

• i/o (trap #3):

D0=01                   io.fbyte
                Not implemented

D0=02, 03               io.fline, io.fstrg                      pop from WD
                Pop latest directory segment from working directory path.
                FLINE can be accessed with the *Basic command INPUT.
        IN
                D2      buffer length
                D2 = 0  flag to clearing the path entry
                A1      buffer address
        OUT
                D1      segment length
                A1      points to the <nul> byte after the segment string

D0=05                   io.sbyte
                Not implemented

D0=07                   io.sstrg                                push to WD
                Append a directory to the working directory path.
                The string should be terminated with a <nul> byte.
                SSTRG can be accessed by the *Basic command PRINT.
        IN
                D2      string length
                A1      buffer address
        OUT
                D1/A1   as io.fline

D0=09                   sd.extop                                user defined

        Can only be accessed by job 0 or by the VFS-channels owner job.
        Parameters & execution routine user supplied. QVFS data re below.
        Odd values of A2 will be rejected, if not in the range of 1 to 9.
        Registers a0/a3/a4/a5/a6 will safely be restored, internally.

        IN:     D1/D2/A1        user supplied data.
                A2              user supplied execution address.

        ENTRY:
                D0      -15     err.bp
                D1/D2           parameter
                D3              set by QDOS (0 or -1)
                D4              what originally was passed as A2
                D5      0       Null
                D6      47      "/" character
                D7              undetermined
                A1              parameter
                A2              actual call address
                A3              handler base address
                A4/A5           undetermined
                A6              QDOS system variables
                A7              SSP
        OUT:
                D0     -2       after an unauthorized call.
                D1/A1           as supplied by the user defined routine.

        Special:

        A2 = 09
                Store a new 'home' path
                Accessible by job 0 and the VFS-channel owner job only.
            IN:
                A1      buffer, string with leading count.w.
            OUT:
                D1/A1   as io.fstrg

        A2 = 07
		Read old & store new WD
                Accessible by any job.
            IN:
                A1      address of a buffer at least 256 bytes of size.
                        The buffer size will not be checked internally!
            OUT:
                D1/A1   as io.fstrg

        A2 = 05
		Read old & store new HD.
		Accessible by job 0 and the VFS-channel owner job only.
		Parameters as A2=07

        A2 = 03
		Lock/unlock decoding mode.
		Accessible by job 0 only.
		D1 =/= 0 locking flag, unlocking otherwise.

D0=70                   fs.heads                                set WD
                Set fully specified working directory
                Parameters as io.sstrg.
                The string further delimited by a <nul> character.

D0=71                   fs.headr                                read WD
                Read working directory of the VFS-channel's owner-job(s chain)
                Parameters as io.fline
                D2 = 512 can be used to fetching the 'home' path.

D0=74                   fs.renam                                set 'home'
                Set 'home'-Directory.
                Accessible by job 0 and the VFS-channel owner job only..
        IN
                A1 buffer address of string with leading count.w
        OUT
                D1/A1 as io.fstrg

QVFS system tables. - Preliminary -

Items size 32-bit if not stated.
There is no free space unless explicitely denoted available to the user.
Actual label values can be found in "qvfs_dat", included in the QVFS archive.

• Secondary cdt data

Offsets refer to the base address of the channel definition table, as supplied with A0 in an sd.extop call.

	name	disp	size	use
	dflg	24		signature "VFC"<<8
	dhnd	28		handler base address of primary channel
	doco	32		open mode as passed with D3 
	dcdt	36		primary cdt
	dchn	40		primary channel ID
	dvfs	44		ID of supervising VFS channel
	dvjp	48	6 .b	i/o trap redirection entry point
				(subroutine call destination address can vary!)
	dhrt	54		primary's i/o return address
	dhcd	58		2ndary (this) cdt base address
	dcvfs	62		address of the supervising VFS cdt
	dfpos	66		current directory entry number
	ddpos	70		current directory entry filepointer
		...		(internal workspace & auxiliary data)
	dnam	594	258 .b	count.w + Inet type full path+filename
	dqnm	852	 46 .b	count.w + QDOS type full device+filename
		...

• VFS handler data

Displacements refer to the handler base address, as supplied with A3 in an sd.extop call.
The Inet type auxiliary channel handler linked to the VFS handler by the displacement of (pdtab-pfxntl).

	name	disp	size	use
	pfgnm	-36		"QVFS" signature
	pfver	-32		"VF06" current release no.
	pxcde	-28		base address of the extension code (QVFS v06)
	pqver	-24	.w	bcd packed QDOS version number
	pfqfl	-22	.b	-1:SMSQ/E, 0:QL, 1:SMSQ
	pqlfl	-21	.b	0:QL hardware present (IPC), -1 otherwise
	pmifl	-18	.w	-1:MINERVA, 0 otherwise
	pfctab	-8		base link into VFS channels' posn qclnk(a0)
	pfccnt	-4	.w	count of VFS channels currently open
	pdirt	-1	.b	actual OS' directory file encoding flag
	pfxntl	00	10 .l	VFS handler reference
		...
	pqnmi	40		ID of initial .nam option channel
	pqnmc	44	.w	usage counter
		...		(.dir & .lok currently unused)
	pqdvi	64		ID of initial .dev option channel
	pqdvc	68	.w	usage counter
	pdtab	72	48 .b	2ndary handler reference
	pqdir	120	48 .b	(another dummy handler, yet unused)
		...

• VFS cdt data

Displacements refer to the base address of the channel definition table.

	name	disp	size	use
	qoco	24		open mode as passed with D3 on open
	qnam	28		.nam option channel ID
	qnmc	32		.nam option cdt address
		...
	qdev	52		.dev option channel ID
	qdvc	56		.dev option cdt address
	qdvh	60	4*8 .b	.nam ... .dev channel handler address
	qdvu	62	.w		usage counter
	qdvl	64	.w		length of QDOS device description
		...
	qclnk	92		VFS cdt link address
	qsnam	96	4*64 .b	count.w+name of the system files
		...
	qiwdr	412	256 .b	working directory path
	qihom	668	256 .b	home directory path
		...
	qiwrk	932	448 .b	workspace, volatile, can be used in extop routines
		...
	quser	1762	128 .b	user data (free space)

• QVFS vectored routines (QVFS v05)

  Displacements count from the beginning of the extension code - re. <pxcde>.
  Vectors are 16-bit pointers relative to their own addresses.
  Registers not mentioned remain unchanged.

0002		vfs_fnd
	IN:
		-/-
	OUT:
		D0 VFS-channel handler base address, or -ve

0004		vfs_cid
	IN:
		-/-
	OUT:
		D0 currently valid VFS channel ID,
		   0 or -ve if no such channel exists.
		D1 the callers job ID
		D2 the VFS channels owner job ID
		A2 the VFS channels base address

0006		vfs_rnm
	IN:
		A0 a VFS channel ID
	OUT:
		D0 that channels internal QDOS error code.
		   -6 if no such channel exists.

• The fs.headr type QVFS fileheader (QVFS v05: extended)

		000...063 standard assigned QDOS header
		wherein 004 .w will be set to -1 if this is an error header
		064...081 count.w+QDOS-devicename
		082...249 reserved for future use
		250 count.w of QVFS path (w/o filename)
		252 count.w of QVFS device description
		254 count.w of the..
		256...511 Inet filename, <nul> terminated

• The extended directory type QVFS fileheader (fline/fstrg only)

		000...063 standard assigned QDOS header
		064 count.w of the...
		066...075 QDOS device name.
		082 count.w of qdos device+path description, current level
		084 count.w of qdos device+path description, previous level
		086 flag -1 if no QDOS header produced (con, pipe, etc)
		088 this directory entries consecutive number
		090 and filepointer.l to the assignement files line
		094...249 reserved for future use
		250 length of Inet device+path description,
		252 length of Inet type device description,
		254 length of the...
		256...511 Inet path+filename, <nul> terminated.

QVFS License

Anyone may use the QVFS in a particular computer free of charges, no matter what for.

Any commercial entities, those things inclusive which someone may be begging a "donation" for, that somehow make use of, rely on, or may be accompanied by, the QVFS require a license the fee of which is determined by the number of pieces intended to be sold, payed to the author in advance:

10	DM 40,-		Pounds Sterling	20,-	U.S. Dollars	40,-
50	DM 150,-			60,-			110,-
200	DM 400,-			160,-			290,-
(Or any foreign currency equivalent to the above Pounds Sterling rates.)
The above rates are subject to change without public notice 
and do not include any foreign trade taxes nor customs fees.