- Email: [email protected]
16-bit operating systems standards and MS-DOS
ll6-bit operating systems standards and MS-DOS Operating system vendors are trying to do for 16-bit operation what C P / M - 8 0 did for 8-bit. Carl Phillips presents the case for MS-DOS
The design philosophy behind the 16-bit operating system, MS-DOS 2.0, supplied by Microsoft, is outlined. MS-DOS has grown in strength since it was launched on the market in 1981, to the point where it is now possibly the most widely used 8086-based operating system in the world. The reasons behind its success, and the facilities it can offer the applications developer are also covered in this article. microsystems OPERATING
operating systems SYSTEM
MS-DOS
STANDARDS
The concept of a standard operating system is still relatively new to the computing community. Mainframes and minis almost exclusively run proprietary operating systems. The micro, however, owes its phenomenal growth, in part at least, to the presence of a standard 8-bit operating system, CP/M-80, which runs on many machines from different manufacturers. The advantages of such standardization are great. CP/M-80 users enjoy the benefits of a large software base andexcellent technical support, be it from software vendors or independent user groups. Porting of applications programs from one system to another presents no difficulties as all implementations of CP/M-80 are now standard. The program runs under the operating system and not the machine. With the emergence of the 16-bit microprocessor, attempts to establish a standard 16-bit operating system began. There is no doubt that a standard is desirable users will not be content with the Babel of language, operating system and machine combinations available. Strong attempts at standardization in many areas are being made by the industry as a whole. A standard may be achieved in a number of ways. A major step forward is mass user acceptance of a product. It is then likely that the national standards committees, such as ANSI, IEEE, and ISO will formalize a standard which has been derived from the user community's present implementation of a product. Alternatively, these standards committees may lay down guidelines which the industry then implements. In recognition of such a standard, the industry will invest in extensive support and development. Standards are now evolving rapidly in the 16-bit world. There are many system manufacturers who endorse MS-DOS 2.0: IBM, Wang, Victor/Sirius, DEC, Hitachi, Microsoft Ltd, Piper House, Hatch Lane, Windsor, Berks, UK. MS-DOS and XENIX are trademarks of Microsoft Corporation. UNIX is a trademark of Bell Laboratories. CP/M is a trademark of Digital Research.
vol 7 no 8 oct 1983
Carl Phillips left school at 16. In Liverpool, UK, he worked for Microdigital for 1½ years before joining Stack Computers where he was involved in technical support program: ruing. He then spent about ~:!~ 1 year as a consultant in the same area o f programming. He has been Technical Sup. . . . . port Manager for Microsoft (UK) for about I year, providing OEM support on MS-DOS porting and implementation.
ACT, Tycom and NEC, for example. A fuller list of manufacturers who support MS-DOS is given in Table 1. The concept of upward compatibility was crucial in the design aims of MS-DOS. Each new version, although incorporating major enhancements, will still be compatible with its predecessors. The environment at which MS-DOS is aimed is the low-end of 16-bit machines - the single-user system. The system which is dominating the multiuser, multitasking microsystems area is Xenix. Xenix is Unix adjusted for a 16-bit microprocessor environment. As an operating system, it is unparalleled in its power and flexibility, and already has a strong following because of the support that universities in particular have given Unix over the years. As a result there are already a large number of Table 1. Manufacturers who support MS-DOS 2.0
ACT Advance Products Almarc Data S y s t e m s Altos Anderson-J acobson Burroughs Columbia Compaq Compass Compu Systems Computer Ancillaries Computer Devices DEC Durango Equinox Fujitsu Future Gavilan
Hitachi Honeywell IBM Lambart Logica Matshushita Misubishi NCR Olivetti Sirius Systime Texas Instruments Toshiba Tycom Vector Victor Wang Zenith
0141--9331/83/080369--05 $03.00 © 1983 Butterworth & Co (Publishers) Ltd
369
users whose first contact with an operating system was Unix. High-end systems are already in the process of standardising implementations of Xenix and Unix. Traditionally, the domains of low-end and high-end systems have been regarded as separate entities. Now, with the latest versions of MS-DOS and Xenix, this is no longer the case. MS-DOS 2.0 incorporates features which allow access to facilities offered on high-end systems, and in return, Xenix Version 3, offers support for the MS-DOS environment. There is a gradual merging of the high-end and low-end capabilities.
Root
Sysdoc
The first commercial version of MS-DOS was version 1.23, produced in response to I BM's need for an operating system for its new Personal Computer. The initial design goals in version 1.23 were to maintain the appearance and principal functionality of CP/M-80, but incorporate features which exploited the 16-bit architecture. Continuity from the 8-bit to 16-bit environment was maintained, so that users could feel 'comfortable' with the new operating system, and MS-DOS 1.23 was fully compatible with CP/M-80. MS-DOS 2.0 included the same design goals as its predecessor, but with several improvements. MS-DOS 2.0 was to be the 'bridge to Xenix'. Just as MS-DOS 1.23 was the bridge from 8-bit to 16-bit operating systems, then the aim of MS-DOS 2.0 was to provide the link between low-end and high-end 16-bit operating systems. MS-DOS was to be the natural upgrade path for operating systems. Towards this end, many of the unique design structures of Xenix are to be seen in version 2.0, such as the hierarchical file organization and the I/O redirection capabilities, and Xenix system calls are available from the MS-DOS environment (see Table 2). However, the kernel of MS-DOS 1.23 is still present, so all version 1.23 applications will run under version 2.0. In recognition of the importance of Xenix, MS-DOS 2.0 provides a natural stepping stone from the low-end of the 16-bit market, to the facilities offered by the highest level 16-bit machines. The upgrade path to a multi-user, multi-tasking system is eased.
FEATURES OF MS-DOS 2.0 The major new feature of MS-DOS 2.0 is the addition of the hierarchical or tree structure of files as found in Xenix.
Table 2. Xenix systemcalls supported under MS-DOS 2.0 Change Attributes Change the Current Directory Create a File Create a Sub-directory Delete a Directory Entry Duplicate a File Handle Force a Duplicate of a File Handle I/O Control for Devices Load and Execute a Program Move a File Pointer Open a File Read From a File/Device Remove a Directory Entry Retrieve Return Code of a Child Terminate a Process Write to a File/Device
370
Memo
\ Printer
Help
Msinfo
THE EVOLUTION OF MS-DOS
Basic
Games
Editor
Figure 1. Hierarchical structure of MS-DOS 2.0 This allows a user to group files together in directories, each directory consisting of files containing related information. This gives rise to the concept of the working directory. The user need only have files on hand which are relevant to a particular set of tasks. The directories become logical and manageable. Each directory could be considered an environment, for example, a c language environment could be set up by creating a directory containing c programs, compilers, linkers, libraries etc. Consider, as an example, all the system documentation stored in a directory named 'sysdoc', all the BASIC files in a directory named 'basic' and so on. The file structure may be viewed as an inverted tree with the 'root' directory as the highest level of the tree. All other files and directories are 'branches' or 'sub-trees' of this root node. When the operating system is first booted, the root director is the first working directory the user will see. A representation of the hierarchical structure is shown in Figure 1. Creation of these directories is simple. The user gives the following command mkdir (directory name) The named directory is then automatically appended ctirectly below the working directory. Other than disc capacity, there is no limitation on the number of subtrees allowed under MS-DOS. Once the user has established a file organization, MS-DOS provides the means to traverse the file tree to carry out standard file operations. To move from one working directory to another, the user specifies the path that the operating system will have to take. If, for the example file organization given above, the user wished to move from 'root' to the 'help' directory, the following path would be specified cd ~sysdoc\help The 'cd' command means 'change direction'. After execution of this command, the working directory becomes 'help' and the user will only see the files 'msinfo' and 'editor'. File manipulation commands that delete, list~ copy etc., will only affect the files in the working directory. Should the user wish to list the contents of the file 'memo' while in the 'help' directory, then the following command line is given type \memo MS-DOS will then look for the file as given by the path, and list it on the user's terminal. In this case, the working directory is unchanged. A system may be structured so that an inexperienced
microprocessors and microsystems
user will only see the files needed for the immediate applications area, and an experienced user will have tidy files.
Batch file MS-DOS provides a means of grouping frequently used commands, so that they may be executed by typing a single' command word. In MS-DOS the commands are stored in a batch file, identified by the file extension '.bat'. Once a batch file has been created, typing the batch file name alone will invoke the string of commands. Unix/Xenix programmers will be familiar with the powerful shell command processor. The shell is, in effect, a programming language of its own. Under MS-DOS 2.0, the batch file offers essentially the same function as the shell. If a user working in a complex tree structure often has to type a file given as type \sysdoc\help\msdos\manual\check then it is apparent that the user wastes a good deal of time merely typing this command. If the user were to create a file named 'getfile.bat', for example, containing the above command line, then simply typing 'getfile' would retrieve the required file and list it on the user's terminal. More complex tasks are possible using batch files. While developing a program, the sequence of compiling a set of programs, linking the object code and executing the entire package may also be carried out by creating a batch file and typing that file's name. Batch files may be seen as an extension of the operating system environment. The batch file is, in effect, a programming environment of its own. There are statements available within the batch file which allow conditional evaluation of variables, looping, printing of character strings, and unconditional branching, all at command level. These may be used to shield the novice user from the operating system still further. For example, the simple case of checking whether or not a file exists is made possible. A user is not left baffled by an operating system message, and may be helped by a programmer-originated error message. The batch file facility allows an applications program developer to customise MS-DOS 2.0 to the needs of the development task on hand. Consider the following example. A new subdirectory is to be created and a set of files are to be copied to the new directory. The working directory is then to be changed to the new directory. If it is BASIC files that are to be copied, then the commands necessary will look like this mkdir (directory name) copy *.bas (directory name) cd (directory name) On execution of these commands, a sub-directory will have been created and all the files with the '.bas' extension copied to it. The working directory will be the new subdirectory. It would be more convenient if the batch file were more flexible, in that the directory name could vary and files of any extension could be copied. Batch files allow parameters to be specified when the file is called, much in the same way as the operating system commands accept arguments. As an example, a file named 'copydir.bat' containing the following commands demonstrates this mkdir %1 copy *.%2 %1 cd %1
vol 7 no 8 oct 1983
In this case, there are two variables specified: %1 and %2. A typical call to this file would be copydir basic bas 'basic' is substitute for the variable %1 and 'bas' is substituted for %2. Up to ten parameter definitions are allowed in a batch file, more may be used in practice with use of the MS-DOS command 'shift'. A special type of batch file is available named 'autoexec.bat'. The commands in this file are executed whenever the operating system is booted. This allows the applications package designer to develop turnkey systems. A package may be run automatically on system startup, so MS-DOS becomes invisible to the user, and the applications package is all the user will see.
Pipes, Filters and I/0 Redirection The standard I/O medium of most systems is the user console (keyboard and VDU). This may be adequate for most applications, but if data has to be directed to another I/O device, then most operating systems provide obstacles to the switching of the I/O stream. MS-DOS provides a set of I/O redirection features which are not device dependent. For example, the output of a program could be sent to a printer, or just as easily be sent to a serial communications port, a file, the screen or some other device. The pipe symbol, represented ' I' in a command line, links the output of one program to the input of another. The output stream is 'piped' into a program and emerges at the user's console only when processing is complete. Other redirection symbols are: ')', '))', and '('. The first of these directs the output of a process to a file, the second concatenates files and the last indicates that a file is to be used as an input source for a process. Often, there are tasks presented to the operating system user which are at best a drudge, and more commonly an irritant. File sorting, string searches, file comparisons etc. are relatively simple to program but would be inconvenient to use at command level. MS-DOS provides these functions as a set of programs known as 'filters'. These are used with the pipe and I/O redirection symbols. An example of the use of both filters and redirection symbols is the simple sorting of a directory into alphabetic order. The output of the 'list directory' command, 'dir', is piped into the filter 'sort' and then into a fiter 'more' which sends the output 24 lines at a time to the screen. The command line appears like this dir Isort i more Should the user wish to direct the output to a file named 'dirlist', then the following command would be given
dir I sort ) dirlist The file 'dirlist' is created automatically if it does not already exist. If it is already present in the directory, then its contents will be overwritten. The procedure for sorting one file and directing the output to another could be sort ( file1 ) file2 In this example, the 'sort' program receives input from 'file1' and directs the sorted output to 'file2'. The major advantage of I/O redirection is that it operates independently of the system devices. In the examples discussed so far, the output could have been directed to any system device. For example, a program
371
which handled an accounting problem could be made to direct a balance sheet to a file, which in turn could be piped to a printer. MS-DOS has the Xenix/Unix convention that any named article in the operating system environment is assumed to be a file, and it is possible to manipulate them in the manner of standard files. Thus, the printer, the screen, and all other I/O devices, directories etc, are to be thought of as files, the only difference being that they contain some special information to identify themselves to MS-DOS. Use of the batch file and I/O redirection capabilities of MS-DOS 2.0 gives the applications package designer a simple, and powerful set of commands, which ease the creation of user-friendly interfaces. It is the application which is the most important consideration for the designer. MS-DOS succeeds in putting the operating system in the background where it belongs.
MS-DOS BIOS MS-DOS 2.0 embodies a design philosophy termed 'software insulation': the operating system remains fundamentally unchanged when new peripheral devices are added, and is virtually independent of the machine it services. When moving from one machine to another, it is only the most machine-specific codes, the Bios, that need be rewritten. The Bios in MS-DOS 2.0 is radically different to those present in other 16-bit operating systems. It supports blocks of code known as installable device drivers - relocatable memory images containing all the information needed to support a named device. The format of the device driver is shown in Figure 2. At boot time, MS-DOS reconfigures its list of devices, and loads the drivers required to support them. System expansion is simple: should the user wish to DWORD pointer to next device (Must be set to -1 ) WORD attributes Bit 15 = 1 if char device : 0 i f b l k if bit 15 is 1 Bit 0 = 1 if current sti device Bit 1 = 1 if current sto output Bit 2 = 1 if current NUL device Bit 3 = 1 if current CLOCK dev Bit 4 = 1 if special Bits 5-12 Reserved; must be set to 0 Bit 14 is the IOCTL bit Bit 13 is the NON IBM FORMAT bit WORD pointer to device strategy entry point WORD pointer to device interrupt entry point 8-BYTE character device name field. Character devices set a device name. For block devices the first byte is the number of units.
Figure 2. Sample device header for the MS-DOS device driver
372
add a new disc drive, for example, then all that is required is to supply a driver module and append the named device to the Bios device list. There are two types or device supported: the character and the block device. The former is made up of the serial data transfer devices, such as a printer or a standard console; the latter is primarily the disc drives, which are able to pass data a block at a time. Each device driver consists of two entry points - the strategy and the interrupt routines. The strategy routine queues an I/O request and the interrupt routine executes the request and flags that it has been dealt with. Xenix handles its I/O requests in this way. This basic design anticipates future versions of MS-DOS: the dual entry points permit a multitasking environment. In practice, a single-user system will only have one I/O request outstanding at a time, so in Version 2.0 the strategy routine is called first and is followed immediately by a call to the interrupt routine. THE BRIDGE TO XENIX Unix, and its many commercial versions such as Xenix, share a dominance as the standard operating systems for multiuser systems. The Motorola 68000 has proved the ideal host processor for Unix/Xenix systems. A glance at this situation will reveal what appears to be a polarization of the market into single-user and multiuser systems with little in between - 8086 systems are predominantly single-user and 68000 systems are predominantly multiuser. Two recent hardware and software developments, however, show this polarization to derive from market immaturity rather than physical constraints. First, the hardware. Apple and Tandy are two major microcomputer manufacturers who have recently announced that their latest machines, Lisa and the Model 16 respectively, would run under Xenix. Both are sing!e-user, 68000-based machines, with networking capabilities. UK manufacturers Tycom and ACT have both announced Xenix for their machines, the Microframe and Apricot. Companies like Altos, Acorn, Convergent Technology and Intel also offer multiuser 8086-based systems running under Xenix. The second development is much more significant to the industry as a whole. It concerns the convergence of Xenix and MS-DOS. MS-DOS 2.0 already incorporates many Xenix functions, and a Xenix/Unix programmer can expect to feel reasonably at ease with MS-DOS after only a short time. What concerns the market most is the portability of programs from one environment to another and even now, with MS-DOS 2.0 and Xenix, this is possible. The Xenix system calls within MS-DOS 2.0 allow programs to be ported easily between the two. Even more significantly, the powerful Unix/Xenix development environment can be used to develop programs which will run under MS-DOS. Using Xenix as the development environment cuts development time and cost and improves efficiency. The next version of MS-DOS (MS-DOS 3.0), due for announcement in autumn 1983, and Xenix 3.0, announced in the summer, show more similarities. The design goals of MS-DOS 3.0 include network support, installable network devices, greater emphasis on system calls as the major means of Dos/Bios communication, and multitasking. The most important consideration, however, is that MS-DOS 3.0 provides a consistent upgrade path for users and developers from Versions 1.2.5 and 2.0.
microprocessors and microsystems
A closer look at these features indicates that MS-DOS 3.0 is a further step towards Xenix (multitasking operation, file locking, interprocess communication), with the addition of network facilities. Though Xenix and Unix cannot, as yet, boast a generally accepted mode of networking, it is clear that recent developments in this area are being closely paralleled by MS-DOS. Xenix Version 3, announced this summer, includes many features common to users of MS-DOS - a visual shell, support for mouse devices, and the facility to read and write MS-DOS files and directories. With these developments, the picture of the future begins to clear. Networking is now emerging as the step forward for microcomputing. There are thousands of single-user 16-bit systems already in use and the trend is for smaller and more powerful systems in the future. Such an installed base will not easily be overturned by multiuser
vol 7 no 8 oct 1983
systems. Rather, the advent of the low-cost network interface device will make networking the logical step forward. With future versions of MS-DOS, existing machines will have network software fully compatible with existing programs. With device I[O already performed in a standard manner under MS-DOS 2.0, it clearly takes little imagination to see applications developed under MS-DOS 2.0 porting onto networked systems with relative ease. The technical merits and demerits of various operating systems become less significant when competing in the open market. Market demands and the interests of the user are all important when marketing operating systems, and unless the question of software portability, while opening up new capabilities, is the prime motivation in operating system design, an operating system will never become globally successful.
373
The design philosophy behind the 16-bit operating system, MS-DOS 2.0, supplied by Microsoft, is outlined. MS-DOS has grown in strength since it was launched on the market in 1981, to the point where it is now possibly the most widely used 8086-based operating system in the world. The reasons behind its success, and the facilities it can offer the applications developer are also covered in this article. microsystems OPERATING
operating systems SYSTEM
MS-DOS
STANDARDS
The concept of a standard operating system is still relatively new to the computing community. Mainframes and minis almost exclusively run proprietary operating systems. The micro, however, owes its phenomenal growth, in part at least, to the presence of a standard 8-bit operating system, CP/M-80, which runs on many machines from different manufacturers. The advantages of such standardization are great. CP/M-80 users enjoy the benefits of a large software base andexcellent technical support, be it from software vendors or independent user groups. Porting of applications programs from one system to another presents no difficulties as all implementations of CP/M-80 are now standard. The program runs under the operating system and not the machine. With the emergence of the 16-bit microprocessor, attempts to establish a standard 16-bit operating system began. There is no doubt that a standard is desirable users will not be content with the Babel of language, operating system and machine combinations available. Strong attempts at standardization in many areas are being made by the industry as a whole. A standard may be achieved in a number of ways. A major step forward is mass user acceptance of a product. It is then likely that the national standards committees, such as ANSI, IEEE, and ISO will formalize a standard which has been derived from the user community's present implementation of a product. Alternatively, these standards committees may lay down guidelines which the industry then implements. In recognition of such a standard, the industry will invest in extensive support and development. Standards are now evolving rapidly in the 16-bit world. There are many system manufacturers who endorse MS-DOS 2.0: IBM, Wang, Victor/Sirius, DEC, Hitachi, Microsoft Ltd, Piper House, Hatch Lane, Windsor, Berks, UK. MS-DOS and XENIX are trademarks of Microsoft Corporation. UNIX is a trademark of Bell Laboratories. CP/M is a trademark of Digital Research.
vol 7 no 8 oct 1983
Carl Phillips left school at 16. In Liverpool, UK, he worked for Microdigital for 1½ years before joining Stack Computers where he was involved in technical support program: ruing. He then spent about ~:!~ 1 year as a consultant in the same area o f programming. He has been Technical Sup. . . . . port Manager for Microsoft (UK) for about I year, providing OEM support on MS-DOS porting and implementation.
ACT, Tycom and NEC, for example. A fuller list of manufacturers who support MS-DOS is given in Table 1. The concept of upward compatibility was crucial in the design aims of MS-DOS. Each new version, although incorporating major enhancements, will still be compatible with its predecessors. The environment at which MS-DOS is aimed is the low-end of 16-bit machines - the single-user system. The system which is dominating the multiuser, multitasking microsystems area is Xenix. Xenix is Unix adjusted for a 16-bit microprocessor environment. As an operating system, it is unparalleled in its power and flexibility, and already has a strong following because of the support that universities in particular have given Unix over the years. As a result there are already a large number of Table 1. Manufacturers who support MS-DOS 2.0
ACT Advance Products Almarc Data S y s t e m s Altos Anderson-J acobson Burroughs Columbia Compaq Compass Compu Systems Computer Ancillaries Computer Devices DEC Durango Equinox Fujitsu Future Gavilan
Hitachi Honeywell IBM Lambart Logica Matshushita Misubishi NCR Olivetti Sirius Systime Texas Instruments Toshiba Tycom Vector Victor Wang Zenith
0141--9331/83/080369--05 $03.00 © 1983 Butterworth & Co (Publishers) Ltd
369
users whose first contact with an operating system was Unix. High-end systems are already in the process of standardising implementations of Xenix and Unix. Traditionally, the domains of low-end and high-end systems have been regarded as separate entities. Now, with the latest versions of MS-DOS and Xenix, this is no longer the case. MS-DOS 2.0 incorporates features which allow access to facilities offered on high-end systems, and in return, Xenix Version 3, offers support for the MS-DOS environment. There is a gradual merging of the high-end and low-end capabilities.
Root
Sysdoc
The first commercial version of MS-DOS was version 1.23, produced in response to I BM's need for an operating system for its new Personal Computer. The initial design goals in version 1.23 were to maintain the appearance and principal functionality of CP/M-80, but incorporate features which exploited the 16-bit architecture. Continuity from the 8-bit to 16-bit environment was maintained, so that users could feel 'comfortable' with the new operating system, and MS-DOS 1.23 was fully compatible with CP/M-80. MS-DOS 2.0 included the same design goals as its predecessor, but with several improvements. MS-DOS 2.0 was to be the 'bridge to Xenix'. Just as MS-DOS 1.23 was the bridge from 8-bit to 16-bit operating systems, then the aim of MS-DOS 2.0 was to provide the link between low-end and high-end 16-bit operating systems. MS-DOS was to be the natural upgrade path for operating systems. Towards this end, many of the unique design structures of Xenix are to be seen in version 2.0, such as the hierarchical file organization and the I/O redirection capabilities, and Xenix system calls are available from the MS-DOS environment (see Table 2). However, the kernel of MS-DOS 1.23 is still present, so all version 1.23 applications will run under version 2.0. In recognition of the importance of Xenix, MS-DOS 2.0 provides a natural stepping stone from the low-end of the 16-bit market, to the facilities offered by the highest level 16-bit machines. The upgrade path to a multi-user, multi-tasking system is eased.
FEATURES OF MS-DOS 2.0 The major new feature of MS-DOS 2.0 is the addition of the hierarchical or tree structure of files as found in Xenix.
Table 2. Xenix systemcalls supported under MS-DOS 2.0 Change Attributes Change the Current Directory Create a File Create a Sub-directory Delete a Directory Entry Duplicate a File Handle Force a Duplicate of a File Handle I/O Control for Devices Load and Execute a Program Move a File Pointer Open a File Read From a File/Device Remove a Directory Entry Retrieve Return Code of a Child Terminate a Process Write to a File/Device
370
Memo
\ Printer
Help
Msinfo
THE EVOLUTION OF MS-DOS
Basic
Games
Editor
Figure 1. Hierarchical structure of MS-DOS 2.0 This allows a user to group files together in directories, each directory consisting of files containing related information. This gives rise to the concept of the working directory. The user need only have files on hand which are relevant to a particular set of tasks. The directories become logical and manageable. Each directory could be considered an environment, for example, a c language environment could be set up by creating a directory containing c programs, compilers, linkers, libraries etc. Consider, as an example, all the system documentation stored in a directory named 'sysdoc', all the BASIC files in a directory named 'basic' and so on. The file structure may be viewed as an inverted tree with the 'root' directory as the highest level of the tree. All other files and directories are 'branches' or 'sub-trees' of this root node. When the operating system is first booted, the root director is the first working directory the user will see. A representation of the hierarchical structure is shown in Figure 1. Creation of these directories is simple. The user gives the following command mkdir (directory name) The named directory is then automatically appended ctirectly below the working directory. Other than disc capacity, there is no limitation on the number of subtrees allowed under MS-DOS. Once the user has established a file organization, MS-DOS provides the means to traverse the file tree to carry out standard file operations. To move from one working directory to another, the user specifies the path that the operating system will have to take. If, for the example file organization given above, the user wished to move from 'root' to the 'help' directory, the following path would be specified cd ~sysdoc\help The 'cd' command means 'change direction'. After execution of this command, the working directory becomes 'help' and the user will only see the files 'msinfo' and 'editor'. File manipulation commands that delete, list~ copy etc., will only affect the files in the working directory. Should the user wish to list the contents of the file 'memo' while in the 'help' directory, then the following command line is given type \memo MS-DOS will then look for the file as given by the path, and list it on the user's terminal. In this case, the working directory is unchanged. A system may be structured so that an inexperienced
microprocessors and microsystems
user will only see the files needed for the immediate applications area, and an experienced user will have tidy files.
Batch file MS-DOS provides a means of grouping frequently used commands, so that they may be executed by typing a single' command word. In MS-DOS the commands are stored in a batch file, identified by the file extension '.bat'. Once a batch file has been created, typing the batch file name alone will invoke the string of commands. Unix/Xenix programmers will be familiar with the powerful shell command processor. The shell is, in effect, a programming language of its own. Under MS-DOS 2.0, the batch file offers essentially the same function as the shell. If a user working in a complex tree structure often has to type a file given as type \sysdoc\help\msdos\manual\check then it is apparent that the user wastes a good deal of time merely typing this command. If the user were to create a file named 'getfile.bat', for example, containing the above command line, then simply typing 'getfile' would retrieve the required file and list it on the user's terminal. More complex tasks are possible using batch files. While developing a program, the sequence of compiling a set of programs, linking the object code and executing the entire package may also be carried out by creating a batch file and typing that file's name. Batch files may be seen as an extension of the operating system environment. The batch file is, in effect, a programming environment of its own. There are statements available within the batch file which allow conditional evaluation of variables, looping, printing of character strings, and unconditional branching, all at command level. These may be used to shield the novice user from the operating system still further. For example, the simple case of checking whether or not a file exists is made possible. A user is not left baffled by an operating system message, and may be helped by a programmer-originated error message. The batch file facility allows an applications program developer to customise MS-DOS 2.0 to the needs of the development task on hand. Consider the following example. A new subdirectory is to be created and a set of files are to be copied to the new directory. The working directory is then to be changed to the new directory. If it is BASIC files that are to be copied, then the commands necessary will look like this mkdir (directory name) copy *.bas (directory name) cd (directory name) On execution of these commands, a sub-directory will have been created and all the files with the '.bas' extension copied to it. The working directory will be the new subdirectory. It would be more convenient if the batch file were more flexible, in that the directory name could vary and files of any extension could be copied. Batch files allow parameters to be specified when the file is called, much in the same way as the operating system commands accept arguments. As an example, a file named 'copydir.bat' containing the following commands demonstrates this mkdir %1 copy *.%2 %1 cd %1
vol 7 no 8 oct 1983
In this case, there are two variables specified: %1 and %2. A typical call to this file would be copydir basic bas 'basic' is substitute for the variable %1 and 'bas' is substituted for %2. Up to ten parameter definitions are allowed in a batch file, more may be used in practice with use of the MS-DOS command 'shift'. A special type of batch file is available named 'autoexec.bat'. The commands in this file are executed whenever the operating system is booted. This allows the applications package designer to develop turnkey systems. A package may be run automatically on system startup, so MS-DOS becomes invisible to the user, and the applications package is all the user will see.
Pipes, Filters and I/0 Redirection The standard I/O medium of most systems is the user console (keyboard and VDU). This may be adequate for most applications, but if data has to be directed to another I/O device, then most operating systems provide obstacles to the switching of the I/O stream. MS-DOS provides a set of I/O redirection features which are not device dependent. For example, the output of a program could be sent to a printer, or just as easily be sent to a serial communications port, a file, the screen or some other device. The pipe symbol, represented ' I' in a command line, links the output of one program to the input of another. The output stream is 'piped' into a program and emerges at the user's console only when processing is complete. Other redirection symbols are: ')', '))', and '('. The first of these directs the output of a process to a file, the second concatenates files and the last indicates that a file is to be used as an input source for a process. Often, there are tasks presented to the operating system user which are at best a drudge, and more commonly an irritant. File sorting, string searches, file comparisons etc. are relatively simple to program but would be inconvenient to use at command level. MS-DOS provides these functions as a set of programs known as 'filters'. These are used with the pipe and I/O redirection symbols. An example of the use of both filters and redirection symbols is the simple sorting of a directory into alphabetic order. The output of the 'list directory' command, 'dir', is piped into the filter 'sort' and then into a fiter 'more' which sends the output 24 lines at a time to the screen. The command line appears like this dir Isort i more Should the user wish to direct the output to a file named 'dirlist', then the following command would be given
dir I sort ) dirlist The file 'dirlist' is created automatically if it does not already exist. If it is already present in the directory, then its contents will be overwritten. The procedure for sorting one file and directing the output to another could be sort ( file1 ) file2 In this example, the 'sort' program receives input from 'file1' and directs the sorted output to 'file2'. The major advantage of I/O redirection is that it operates independently of the system devices. In the examples discussed so far, the output could have been directed to any system device. For example, a program
371
which handled an accounting problem could be made to direct a balance sheet to a file, which in turn could be piped to a printer. MS-DOS has the Xenix/Unix convention that any named article in the operating system environment is assumed to be a file, and it is possible to manipulate them in the manner of standard files. Thus, the printer, the screen, and all other I/O devices, directories etc, are to be thought of as files, the only difference being that they contain some special information to identify themselves to MS-DOS. Use of the batch file and I/O redirection capabilities of MS-DOS 2.0 gives the applications package designer a simple, and powerful set of commands, which ease the creation of user-friendly interfaces. It is the application which is the most important consideration for the designer. MS-DOS succeeds in putting the operating system in the background where it belongs.
MS-DOS BIOS MS-DOS 2.0 embodies a design philosophy termed 'software insulation': the operating system remains fundamentally unchanged when new peripheral devices are added, and is virtually independent of the machine it services. When moving from one machine to another, it is only the most machine-specific codes, the Bios, that need be rewritten. The Bios in MS-DOS 2.0 is radically different to those present in other 16-bit operating systems. It supports blocks of code known as installable device drivers - relocatable memory images containing all the information needed to support a named device. The format of the device driver is shown in Figure 2. At boot time, MS-DOS reconfigures its list of devices, and loads the drivers required to support them. System expansion is simple: should the user wish to DWORD pointer to next device (Must be set to -1 ) WORD attributes Bit 15 = 1 if char device : 0 i f b l k if bit 15 is 1 Bit 0 = 1 if current sti device Bit 1 = 1 if current sto output Bit 2 = 1 if current NUL device Bit 3 = 1 if current CLOCK dev Bit 4 = 1 if special Bits 5-12 Reserved; must be set to 0 Bit 14 is the IOCTL bit Bit 13 is the NON IBM FORMAT bit WORD pointer to device strategy entry point WORD pointer to device interrupt entry point 8-BYTE character device name field. Character devices set a device name. For block devices the first byte is the number of units.
Figure 2. Sample device header for the MS-DOS device driver
372
add a new disc drive, for example, then all that is required is to supply a driver module and append the named device to the Bios device list. There are two types or device supported: the character and the block device. The former is made up of the serial data transfer devices, such as a printer or a standard console; the latter is primarily the disc drives, which are able to pass data a block at a time. Each device driver consists of two entry points - the strategy and the interrupt routines. The strategy routine queues an I/O request and the interrupt routine executes the request and flags that it has been dealt with. Xenix handles its I/O requests in this way. This basic design anticipates future versions of MS-DOS: the dual entry points permit a multitasking environment. In practice, a single-user system will only have one I/O request outstanding at a time, so in Version 2.0 the strategy routine is called first and is followed immediately by a call to the interrupt routine. THE BRIDGE TO XENIX Unix, and its many commercial versions such as Xenix, share a dominance as the standard operating systems for multiuser systems. The Motorola 68000 has proved the ideal host processor for Unix/Xenix systems. A glance at this situation will reveal what appears to be a polarization of the market into single-user and multiuser systems with little in between - 8086 systems are predominantly single-user and 68000 systems are predominantly multiuser. Two recent hardware and software developments, however, show this polarization to derive from market immaturity rather than physical constraints. First, the hardware. Apple and Tandy are two major microcomputer manufacturers who have recently announced that their latest machines, Lisa and the Model 16 respectively, would run under Xenix. Both are sing!e-user, 68000-based machines, with networking capabilities. UK manufacturers Tycom and ACT have both announced Xenix for their machines, the Microframe and Apricot. Companies like Altos, Acorn, Convergent Technology and Intel also offer multiuser 8086-based systems running under Xenix. The second development is much more significant to the industry as a whole. It concerns the convergence of Xenix and MS-DOS. MS-DOS 2.0 already incorporates many Xenix functions, and a Xenix/Unix programmer can expect to feel reasonably at ease with MS-DOS after only a short time. What concerns the market most is the portability of programs from one environment to another and even now, with MS-DOS 2.0 and Xenix, this is possible. The Xenix system calls within MS-DOS 2.0 allow programs to be ported easily between the two. Even more significantly, the powerful Unix/Xenix development environment can be used to develop programs which will run under MS-DOS. Using Xenix as the development environment cuts development time and cost and improves efficiency. The next version of MS-DOS (MS-DOS 3.0), due for announcement in autumn 1983, and Xenix 3.0, announced in the summer, show more similarities. The design goals of MS-DOS 3.0 include network support, installable network devices, greater emphasis on system calls as the major means of Dos/Bios communication, and multitasking. The most important consideration, however, is that MS-DOS 3.0 provides a consistent upgrade path for users and developers from Versions 1.2.5 and 2.0.
microprocessors and microsystems
A closer look at these features indicates that MS-DOS 3.0 is a further step towards Xenix (multitasking operation, file locking, interprocess communication), with the addition of network facilities. Though Xenix and Unix cannot, as yet, boast a generally accepted mode of networking, it is clear that recent developments in this area are being closely paralleled by MS-DOS. Xenix Version 3, announced this summer, includes many features common to users of MS-DOS - a visual shell, support for mouse devices, and the facility to read and write MS-DOS files and directories. With these developments, the picture of the future begins to clear. Networking is now emerging as the step forward for microcomputing. There are thousands of single-user 16-bit systems already in use and the trend is for smaller and more powerful systems in the future. Such an installed base will not easily be overturned by multiuser
vol 7 no 8 oct 1983
systems. Rather, the advent of the low-cost network interface device will make networking the logical step forward. With future versions of MS-DOS, existing machines will have network software fully compatible with existing programs. With device I[O already performed in a standard manner under MS-DOS 2.0, it clearly takes little imagination to see applications developed under MS-DOS 2.0 porting onto networked systems with relative ease. The technical merits and demerits of various operating systems become less significant when competing in the open market. Market demands and the interests of the user are all important when marketing operating systems, and unless the question of software portability, while opening up new capabilities, is the prime motivation in operating system design, an operating system will never become globally successful.
373