< Previous  |  Contents  |  Next >

7: DOS Plus

A Short History

Throughout its history the growth of DOS has been something of a chicken and egg event. With the development of 16-bit processors towards the end of the 1970s the DOS era began. DOS was developed directly from an Operating System called 86-DOS, itself a direct development of CP/M. In fact so similar were they that programs, files and complete discs could be converted between one and the other by the simple mechanical process of running a conversion program.

The Microsoft Corporation acquired the rights to 86-DOS and further developed it, producing the first version of MS-DOS (Microsoft DOS) version 1.0, in 1981. Digital Research were, at the same time, developing CP/M86 as a growth path for its existing CP/M user base and as a competitor to MS-DOS, but they suffered delays in development. The intention of both was to offer their Operating System to IBM, who were then producing the first of their new range of PCs, and who intended to offer a choice of several Operating Systems with these machines. MS-DOS was one choice and CP/M86 would have been another had it been available in time for the new machine launch.

Due to the hardware design policies practised by IBM, MS-DOS actually appeared in a slightly modified form, using customised chips in the hardware to replace some of the software functions of MS-DOS. This IBM PC version of DOS was called PC-DOS. This was just before the liberated time of new anti-trust legislation in the USA. Previously IBM had largely confounded the competition, preventing them from gaining a foothold in IBM markets by using dedicated hardware to replace some software. This meant, it could be argued, that anyone who produced IBM compatible PCs was actually copying IBM hardware designs, not merely using a similar Operating System.

This theory was one of several eventually challenged in court and, while the conclusion was less than clear, in a practical sense the important point was that IBM did not win. As a result anyone could produce PCs, no matter how similar they might seem to IBM's machinery – so they did. The PC boom had begun, and that assured the future of the original MS-DOS as the standard business PC Operating System, with IBM continuing to supply PC-DOS. Since then the two have always been developed along the same lines while maintaining their fundamental differences.

At the present time there are literally millions of PCs which use one variant or another of DOS as their Operating System. Had Digital Research been quicker in developing CP/M86, it might very well now hold the position held by MS-DOS. They were not and so found it necessary to add a 'front end' DOS emulator to their 86 series Operating Systems to provide compatiblilty with MS- and PC-DOS. This Operating System became known as DOS Plus. CP/M86 is still used as an Operating System in its own right, but not generally as standard in 86 series machines.

As both MS-DOS and PC-DOS owed so much of their internal structure and organisation to CP/M, these two versions of DOS and DOS Plus have also been able largely to evolve in parallel, even as far as using similar version numbering. Which is the 'better' Operating System between MS-DOS and DOS Plus is, of course, a matter of opinion, but it must be acknowleged that, for any given version, DOS Plus can do all that the equivalent MS- or PC-DOS can do, while the reverse is not the case.

This is because the DOS functions provided by the emulator are similar to those of MS-DOS or PC-DOS, but DOS Plus can offer all the direct facilities of CP/M86 in addition, and CP/M86 has capabilities that DOS does not. The most glaring example is that the latest versions of MS-DOS (at the time of writing, up to about experimental version 4.3) may perhaps just be thinking about multi-user/multi-tasking, while CP/M86 has provided this capability since its inception.

Elements of DOS Plus

The basic design concepts of the original CP/M-80 and all succeeding versions of it (and DOS) are that the kernel of the Operating System is insulated from the outside world by a quite separate set of software interfaces. While the outward facing portions of these interfaces might alter for installation in different hardware, the inward connections to the DOS kernel, the BDOS (Basic Disc Operating System), and hence the applications software, do not.

The benefits of this approach are three-fold. First, within the limitations of memory size and range of peripherals, the way facilities are accessed by programs does not change, regardless of the type of machine. Secondly, from the point of view of a user, apart from physical differences, one DOS system should appear to be much like another. Finally, and equally important, the BDOS can be extended by adding to or altering its hardware interfaces (for example, for new storage media requiring new controls, like the read/write laser discs now beginning to appear commercially) without disturbing the kernel, the data it provides or uses, or the existing applications interfaces.

Although the main elements of DOS Plus in the 512 are similar to other systems, some differences are forced by the two-processor Acorn hardware configuration. The XIOS (eXtended Input Output System) is known in conventional systems as the BIOS (Basic Input Output System). The name change for the 512 is because the direct peripheral hardware interfaces are replaced by the indirect Tube protocols discussed previously. However, the concepts are the same and it is this very design philosophy which permits an eight bit BBC Micro host to run a 16-bit 80186-based DOS co-processor. A simplified schematic of this 'layered' approach is shown below in Figure 7.1.

In practice the divisions between the various layers are not so clear cut. For example, an application may replace the original Console Command Processor entirely with routines of its own. Alternatively, by means of INT 224, DOS Plus applications can call the BDOS directly, bypassing the CCP and the DOS emulator. However, these operations are legal and cause no problems because the BDOS and the XIOS still stand between the application and the hardware.

Finally, and as is known only too well by 512 users, some applications entirely ignore all standards and short-circuit the system by attempting direct access to the hardware peripheral controllers. To work, this would need to be able to by-pass the DOS emulator, the BDOS, the XIOS, the Tube and the host's MOS or filing system. Obviously such programs have no chance of success in the 512.

The BDOS

The core of the system, both figuratively and literally, is the BDOS. This should be functionally invariant for all versions of DOS Plus. Its functional responsibilities are completely hardware independent, comprising memory management, logical character input/output, logical file and record management and timer interrupt control.

Programs can access BDOS functions directly via interrupt 224, reserved by Intel for Digital Research Operating Systems. The technique involves loading specified processor registers with parameters and calling the BDOS by an INT 224 instruction. System calls are documented in Appendices A-D.

The DOS Emulator

The DOS emulator in DOS Plus 2.1 imitates PC-DOS 2.11. Specifically PC-DOS interrupts between 21h and 27h inclusive are emulated by being converted to CP/M functions, which are executed via calls to the BDOS.

It should be noted that PC-DOS 2.11 includes numerous other DOS interrupt calls than this restricted range, but these are not 'officially' supported in DOS Plus (although many actually are implemented) and hence may perform different functions to the PC calls. Note however that IBM have subverted many of these calls for their own purposes, and frequently these PC interrupts are not compatible with MS-DOS or the processor chip manufacturer's specifications.

In fact, IBM have used several interrupt numbers which were specifically reserved by Intel (the 86 series chip manufacturer) for future MS-DOS expansion, and even some reserved by Intel for themselves for future processor development. For example, In the IBM PC/AT, Interrupt 5 (specified by Intel as an 86 series hardware interrupt bounds error) actually precipitates a screen print. This example (and there are others) perhaps adequately underlines how compatible some 'compatibles' and their Operating Systems really are and how imprecise this subject is.

The Console Command Processor

The CCP consists of two parts. The first, the command loader is transparent to the user and is loaded with the BDOS and DOS emulator when the system is booted. It is responsible for allocating sufficient memory for COMMAND.COM which is the second part of the CCP to be loaded, and which is located immediately above DOS Plus in low memory. The command loader maintains a second copy of COMMAND.COM in high memory and, as one of its secondary functions, it ensures that the user's copy of COMMAND.COM is intact on program termination. This it achieves by comparing the high memory and low memory copies. If they are not the same one or other has been corrupted.

If COMMAND.COM has been corrupted the command loader will always replace both copies by loading a new image from disc automatically, since it cannot be sure which of the two was damaged. The user may become aware of the command loader when this situation occurs and COMMAND.COM is not available on the current drive. It is the command loader that generates the error message Cannot find COMMAND.COM, or Can't load COMMAND.COM, depending on the version of DOS Plus (1.2 or 2.1) in use.

The command loader is also responsible for processing CTRL-C aborts during program execution (since COMMAND.COM may no longer be resident) and tidy program closedown during abort or normal termination.

COMMAND.COM is the transient portion of the CCP that provides the user's interface to DOS. A maximum command line length of 127 characters is permitted. It is responsible for reading user input and translating it into a meaningful action in one of two ways.

It can be either by means of passing the command direct to DOS if the command is recognised as a permanent function, when it will be executed by calls to BDOS functions, or by loading the appropriate transient utility and passing the parameters to it if there is no such permanent command. In this latter case the commands may be carried out by calls to DOS interrupts or BDOS functions, depending how the code was written. Such transient file names are recognised by the command name supplied in the instruction and one of the allowable executable filename extensions detailed below. In this case, if no such file can be found in any current path, COMMAND.COM responds by outputting the Bad command or file name message.

The transient portion of the CCP is also responsible for opening and reading the file and performing a similar command translation function when a batch file is executed.

The XIOS

The XIOS (or BIOS in other systems) is responsible for communication between the BDOS and the computer hardware. It presents a fixed interface to the BDOS for the passing of peripheral commands as a result of program activity, but is customised by the computer manufacturer to provide the correct instructions to program the particular hardware device drivers and controllers being used in each machine.

In the 512 the task of the XIOS is precisely this, but instead of direct control of the hardware, the XIOS is responsible for translating BDOS commands into instructions which are passed through the Tube to the host, or receiving the replies, as documented in the preceding chapters on the Tube host code and 6502.SYS.

Because of the Tube interface, there is additional code in the XIOS that is directly responsible for initiating or receiving data transmission. While direct hardware triggered events and interrupts normally occur in a BIOS system, in the Tube these must be simulated by recognising the Tube protocols that generate IRQs and NMIs. However, in concept these are the equivalent of hardware interrupts and fulfil the same purpose.

The XIOS code itself is transparent, although special calls are provided so that applications can directly access the Tube software by means of the reserved function 50h within INT 224.

Executable Files

All versions of DOS recognise and reserve three file extensions for their own use, while DOS Plus includes two more. In all cases these extensions tell DOS that the file contains executable instructions in one form or another. 'COM', 'EXE' and 'BAT' extensions are common to all versions of MS-DOS, PC-DOS and DOS Plus. In addition, DOS Plus also recognises 'CMD' and 'RSX' as executable filename extensions.

Naturally, these filename extensions should not be used for any other type of file than those detailed below or the result of entering the filename as a command may, with the exception of 'EXE' files, be unpredictable and, in most cases, disastrous.

BAT Files

A file extension of .BAT (meaning a batch file) indicates that the file contains pure text which, line by line, can be processed by COMMAND.COM in a similar way to keyboard-entered instructions. That the instructions are automatically presented in a predefined sequence gives DOS a simple job control language. Batch files originated in CP/M-80.

BAT files are opened for input only during normal execution, ie you cannot update them or record data in them while they execute. Each text line up to the maximum command line length, or to the first occurrence of Dh (CHR$13), is treated as a single command, though each line may be conditioned and, by the use of labels, the file may effectively contain an alternative to the conditional command.

Unlike keyboard entry, where every command line is isolated, instructions in a BAT file have a logical position, or line number in the file. This permits a simple language structure by means of labels, the line number of which is remembered during execution. A GOTO command, therefore, instructs COMMAND.COM to reposition the file pointer to a given line number and resume execution from that point.

COM Files

A .COM file extension (in DOS, short for 'command') indicates that the file contains machine code (possibly with embedded data) which will occupy not more than 255 pages (ie one page less than a complete segment) and which should be loaded as a complete program in the first available free memory block large enough to contain it.

Note that there is no check implicit in the COM filename extension. That is to say, the file is not checked to ensure that it contains executable code, DOS simply loads the file and attempts to execute it immediately, which is why the extension should not be used for any other file type.

On initial load into RAM, a program segment is allocated to the file, the first page of which is automatically set up by DOS as the program segment prefix (PSP) at load time, that is, it is not stored as part of the COM file on disc. This area is initialised to contain certain system data in the first half, while the second half is reserved to hold the original command line parameters (the command tail) if any were issued with the original command that called the program.

The purpose of this technique is that the complete uncorrupted command line (excluding the program's own name, ie parameters only) remains available to the code throughout execution, regardless of what might happen to the contents of RAM elsewhere in the machine.

Since they have no header information (eg containing an execution address) initial entry to COM programs is pre-defined at address 100h, the first byte after the PSP when loaded, the first actual byte of the file as stored on disc. COM files must therefore, always contain an executable instruction as their first byte. Commonly, immediate program jumps transfer execution to another address within the code segment if it is required to set up tables etc at 100h, which can be subsequently overwritten. The first 128 bytes of the PSP should never be corrupted, though what the program does with the command line parameters during execution is its own affair.

On initial entry to the code, all segment registers point to the code segment and the stack pointer is initialised to FFFEh (the segment size minus two) or to the address of the top of available memory minus two if less than a complete segment is available. This defines the first available stack address, which therefore will always be at the top of the program area unless the stack pointer is repositioned within the code. Immediately after loading the program the first two bytes of the default stack are already used by DOS, which stores a zero word there. It is, therefore, also implicit in COM files that at least two bytes of stack will be available in the code segment.

COM files are designed to be simple to produce with a minimum of 'red tape', permitting the programmer to produce a fast, efficient program. COM files are, therefore, commonly used for small utilities required to perform a limited range of functions.

A map of the segment and PSP for a loaded COM file is shown below.

Spawning

The PSP terminate address in 000Ah to 000Dh usually points to the code in COMMAND.COM which handles tidy program closedown, but a program can change this if required.

The pointer in the PSP is set up before execution commences but may be temporarily saved (eg on the stack) then the PSP copy of it may be changed to point to a re-entry in its own code. This permits one program to call a second or subsequent program. As each subsequent program is loaded, its own terminate address is taken from the calling routine's PSP copy. If the caller has set up its own return address in its PSP terminate address, when the second (or nth) program terminates it automatically returns control to the caller, which in turn can lump back to its own caller, and so on until finally the last in the reverse chain (ie the first loaded) restores the original termination address and exits by jumping back to COMMAND.COM.

In essence, this is the DOS technique known as spawning. It may help to remember that all COM programs are actually spawned by COMMAND.COM.

The technique permits one, or a number of programs to be called from within any other, while each calling program remains resident and in control for the duration of its execution. This is why the terminate address is not 'fixed' externally by DOS, but is made available to user code. The only practical limits on how many programs may be spawned is the maximum memory available and good sense.

It should be noted that, although the terminate-handler address has been used here for illustration, employing the technique of spawning necessitates that the both the CTRL-C and the critical error handlers' addresses be manipulated in a similar fashion. Failure to do so will result in (some) undefined vectors if a spawned program terminates unexpectedly (see Chapter Eight).

EXE Files

A DOS .EXE file (meaning simply, executable) also contains program code, but each EXE file has a header which identifies the file completely, prior to execution. EXE programs do not necessarily commence execution at 0100h, nor are they limited to a single segment in size and can use memory up to the total available if required. For this reason the header must define the file as an EXE (and nothing else) and include additional information about where in memory the program is to be executed from, how much memory will be needed, if it is overlaid and so on.

For this reason an additional feature, a file checksum, is included. If the checksum is incorrect, DOS will report the fact and the program will not be executed, since the result could be catastrophic. Initially the file is brought into memory immediately above the PSP (which contains the same information as for COM files above) but the code may then be moved prior to execution.

The size and type of information contained in an EXE header depends on how big the program is and how much of it is to be automatically relocated at run tune, but the header size is always a multiple of 512 bytes. Another difference from COM files is that the processor registers have values pre-assigned to them, which will be set up before execution commences. This is because code, data and stack are presented to the loader as separate modules, and each might not be placed in the same segment. This is one reason why EXE files tend to take longer to load, even when fairly small. The information in the header table is shown below, as it appears in an EXE load module (ie a .EXE file).

	Byte Offset		Contains
	0000h		First part of EXE file signature (4Dh)
	0001h		Second part of EXE file signature (5Ah)
	0002h		Length of file MOD 512
	0004h		Size of file in 512 byte pages including header
	0006h		Number of relocation table items
	0008h		Size of header in paragraphs
	000Ah		Minimum number of paragraphs needed above program
	000Ch		Minimum number of paragraphs desired above program
	000Eh		Segment displacement of stack module §
	0010h		Contents of SP at entry
	0012h		Word checksum
	0014h		Contents of IP at entry
	0016h		Segment displacement of code module §§
	0018h		Offset of first relocation object in file
	001Ah		Overlay number (Zero for resident module)
	001Bh		Start of variable space for relocation table
			§ The stack segment is variable
			§§ Program and data segments are variable
	Figure 7.3 The EXE Load Module Layout

Before DOS transfers control to the loaded code, the header information is evaluated and, if the checksum is correct, the CS and IP register values are calculated from the entry point in the header (initial IP at 0014h) and the physical load address. The DS and ES registers are set to point to the PSP so that the program can readily access the environment pointer, the command line tail and so on. The SS and SP registers are likewise set to predefined values, indicated by a STACK declaration within the source code and decided by the programmer. The stack space can contain predefined data, or may be left indeterminate prior to execution. The program is then entered at the location pointed to by CS:IP.

The layout of an EXE file in memory is shown below in Figure 7.4, as it is just prior to execution. Note that the header has been discarded, as its purpose has been served. It does not form part of the memory resident program.

An EXE file is usually produced from a number of object modules, each of which has an .OBJ extension. OBJ files are essentially COM files with built in 'hooks' in a known format that allows them to be joined to other OBJ files. The normal production process involves writing and assembling or compiling several separate object modules, which are subsequently linked together (by a linker!) often with standard library routines added, to produce the final EXE file.

Many language compilers also produce OBJ modules that likewise require linking, though in some implementations this secondary process may be transparent. In practice, an EXE file may well be built from a mixture of assembled code, user library routines, compiled modules (perhaps from more than one language) and compiler supplied standard library routines. Library routines are ready made object modules that provide subroutines for common program functions, such as input/output or mathematical functions.

CMD Files

CMD files were the original CP/M predecessors to DOS's COM files, and likewise CMD is short for command. CP/M80 CMD files bequeathed most of their other characteristics to COM files too, including the one segment limit and the fact that they are not automatically relocatable. However, in CP/M86 extensions were made to the CP/M80 CMD definition, which allowed code and data to be separated so they could occupy different segments with automatic register initialisation, much like DOS EXE files.

The version of the CMD file produced depends on the way the code is written and the facilities required. In CP/M terminology generally, each separate area of the internals of a program is known as a 'group', thus the program code forms the code group, regardless of its size. The data for a program is the data group, the stack segment, if in a different segment is the stack group and so on.

In CP/M86 four categories of CMD file exist:

• The 8080 model
• The small memory model
• The compact model
• The large memory model

In the 8080 model (the original from CP/M80) the code and data groups are mixed, much as in a DOS COM file. However, segment registers can be manipulated within the code so as to access other segments, therefore the program is not, of necessity, limited to 64K overall, though there is no automatic distinction between code and data during initial program load.

The small model separates the code group and data group into different, though not necessarily single, segments, which can be placed separately in memory with automatic CS and DS initialisation on loading. Again, any additional segments in each group must be managed within the program code.

The compact model is used when an extra segment (ES) or a stack segment (SS) is also required. In this case CS, DS, ES and SS are automatically initialised. In effect, it provides the capability for a single code group but multiple data groups. As before, within each group, multiple segments can be managed by the program.

The large memory model permits programs with multiple groups for both code and data with, for all practical purposes, no limit on program size. All appropriate segment registers are initialised on program load. Memory permitting, each code group and each data group can be up to one megabyte in size.

The major difference between a large memory CMD file and an EXE file is that DOS assumes all code and all data segments occupy a single contiguous block of memory, while CP/M permits its various groups to be located anywhere in memory. This allows multi-user applications, when one or more groups of code can each have several, completely separate groups of data. In this case several users can each have several (usually up to four) of their own independent applications, each with separate data, while CP/M86 requires only one copy of each code group to run them all. In other words the CP/M86 large memory model is, by design, a multi-user, and multi-tasking system.

For all types of CMD file, the system initialises a 96-byte stack, with the far return (termination jump) already placed on it. In addition, the base page (00h to FFh) of the loaded program is initialised in a way which depends on the memory model indicated in the file header.

The following list, Figure 7.5, shows how the base page is set up on program load.

Byte Offset		Name		Contains
0000h‑0002h		CL		Code length (the size of the code group)
0003h‑0004h		CB		The base paragraph address of the code group
0005h		M80		A flag = 1 for the 8080 model, 0 otherwise
0006h‑0008h		DL		Data length (the site of data group)
0009h‑000Ah		DB		The base paragraph of the data group
000Bh				Reserved
000Ch‑000Ah		EL		Extra data length (the size of the extra group)
000Fh‑0010h		EB		The base paragraph of the extra group
0011h				Reserved
0012h‑0014h		SL		Stack length (the size of the stack group)
0015h‑0016h		SB		The base paragraph of the stack group
0017h				Reserved
0018‑0029h		AUX		The area containing the four optional independent groups for programs that execute using the compact memory model. Each is stored as a 3 byte length plus a two byte base paragraph address.
0030h‑003Fh				Reserved
0050h		DR		The drive from while the program was loaded, 0 for the default drive, 1 - 16 for drives A through P
0051h‑0052h		PWA1		The DS offset of the password field of the first command operand in the DMA buffer (see 0080h)
0053h		PWL1		The length of the first password field
0054h‑0055h		PWA2		The DS offset of the password field of the second command operand in the DMA buffer (See 0080h)
0056h		PWL2		The length of the second password field
0057h‑005Bh				Reserved
005Ch‑006Bh		FCB1		The default file control block (FCB1) for the first command operand (if there is one)
006Ch‑007Bh		FCB2		The default file control block (FCB2) for the second command operand (if there is one)
007Ch		CR		The current record position for FCB1
007Dh‑007Fh		RRN1		The optional random record position for FCB1
0080h‑00FFh		DMA		The DMA buffer. Initially this holds the complete command tail
Fig. 7.5 Base Page Command Allocation for a Specimen CMD File.

RSX Files

Resident system-extension files have an .RSX filename extension. These are programs which, when executed, will automatically attach themselves to the Operating System, and can extend the function of the system by intercepting BDOS calls. The RSX can then either process the calls itself, thus modifying the BDOS function, or pass the call to the BDOS unchanged. More than one RSX can be in operation at any time, and a normal external program can also make direct calls to RSXs for special functions without issuing calls through the BDOS intercept.

RSX routines should not be confused with background programs, (eg PRINT.CMD and ALARM.CMD) nor with DOS Plus 'sticky memory' programs which are, or can be, the equivalent to MS-DOS 'Terminate and Stay Resident' (TSR) programs, but which need not necessarily have anything to do with BDOS calls. RSX programs may be called by CMD programs and they may use sticky memory calls, but the programs issuing such calls are not RSXs, and programs using sticky memory may be, but are not necessarily RSXs.

Apart from the programming techniques employed, RSX programs are prepared in a different way to normal CMD files. The program is first assembled or compiled as a CMD file, then a special utility, GENRSX is required to correctly set up the RSX prefix. The RSX prefix, therefore, permanently precedes the program image in the resulting disc file. The data format of an RSX file prefix is shown below (Figure 7.6).

Byte Offset		Contains
0000h‑0002h		Jump to the start of the RSX program code
0003h		The terminate flag - if not zero the RSX terminates when the calling program terminates. RSXs belonging to background programs are always removed when the background program terminates
0004h‑0007h		The address of the next RSX in the chain
0008h‑000Fh		The name of the RSX
0010h‑0011h		The base page segment for the RSX
0012hv001Fh		Reserved
0020h on...		The RSX code
Figure 7.6 Data Format of an RSX Pile Prefix

Sticky Memory

Sticky memory describes the BDOS ability to allow a program to allocate memory permanently and exclusively for its own use. For the time it remains active only the program itself can free the sticky memory. By varying the memory allocation call type the program can define that the memory should be released on termination but, if it does not do so, the memory allocation remains unavailable to other programs when the sticky memory program terminates. When terminated, a program's sticky memory can be de-allocated by another program, but only if the precise start address and size of the sticky memory area is known.

The purpose of sticky memory is to allow a program to claim and reserve more memory than its immediate code and data needs justify. This is required when, for example, a program will dynamically build tables which may be small or non-existent initially, but for which expansion must be possible, as and when required. If memory could not be reserved in this way, loading a second program would allocate the area immediately following the top of the first program's initial memory allocation, which would then prevent such expansion. By allocating sticky memory, the reserved space cannot be used by a subsequently loaded program.

A common use of sticky memory is for interrupt driven routines which need to remain in memory (ie like MS-DOS TSR pop-ups) and operate from time to time dependent on certain conditions. This facility is also used by the manual ADDMEM and COMSIZE commands.

Background Tasks

Some programs may need to carry out functions over a period of time, which would prevent any other program running if they were to remain as a normal external foreground routine. Two examples are provided with the 512, ALARM and PRINT, both of which clearly would be pointless if they prevented other foreground programs from running simultaneously. DOS Plus permits up to three such programs to enter the background environment at anyone time.

Programs can enter the background by detaching from the console device by a call to INT 224 with a value of 147 in CL. After this call console I/O is impossible, but the program will continue to execute. Only CMD programs can enter the background and, once this is done, only direct BDOS calls are supported and DOS interrupts are no longer available.

If coded suitably, communication is possible with background programs from another program, so they can be terminated or otherwise commanded, but this is not possible directly from the console. Alternatively, like PRINT and ALARM, they can automatically terminate themselves when their function is complete, freeing their memory again for other programs.

Notes

Quite often, as in the PRINT utility, several of these techniques may be used in conjunction to provide a user service. There is (or was) a PRINT.RSX which is now transparent to the user, since it loads by default. In its idle state it requires no additional memory other than a small amount for its permanent code, which is effectively hidden within DOS Plus. When some print action is to take place, the user communicates with the RSX by indirect means, using the external program PRINT.CMD as an intermediary. In this case, PRINT.CMD passes on the user instructions to the RSX, then terminates. The print RSX then allocates the required sticky memory, opens the file and outputs it to the printer. On completion, the extra memory is freed and the system returns to its 'at rest' condition.

It is easy to demonstrate that the initial PRINT.CMD program actually does terminate, leaving the RSX to carry out the required functions, simply by issuing a command to query the progress of a user print instruction by means of the command PRINT. It will be observed that the immediate effect is that PRINT.CMD must be freshly loaded from disc to deal with the user's console communication. PRINT.CMD then interrogates the RSX, displays the state of the print queue (since RSXs cannot produce console output either) and once again terminates.

Except as mentioned above for RSXs and background tasks, all types of executable program except batch files, that is COM, CMD and EXE files, can issue all varieties of Operating System or hardware calls by means of DOS interrupts, BDOS calls or calls to the XIOS.

In general, direct XIOS calls are more efficient than BDOS calls, which in turn are more efficient than DOS interrupts since the overhead of the DOS emulator is avoided by both, while direct MOS calls also avoid the BDOS. On the other hand, many DOS interrupts are easier to code, since BDOS and XIOS calls, by definition, operate at succeedingly lower levels. In practical terms however, there will rarely be any discernible difference in execution time even for compiled code, much less for hand-coded assembler, regardless of the method chosen for calling Operating System functions.

< Previous  |  Contents  |  Next >

About the Master 512 | Bibliography