Feature MS-DOS 3.1 makes it easy to use IBM PCs on a network
No longer do software developers have to fashion their multi-user programs to the vagaries of each network. As a result, users will have a great deal more choice.
By Mike Hurwicz, Telco Research Inc., Nashville, Tenn.
Data Communications
November 1, 1985
About a year ago, Microsoft announced its latest upgrade to the standard operating system of the IBM Personal Computer. The importance of this operating system--MS-DOS version 3.1--is often underestimated, although many astute observers of the communications industry realize that it may have tremendous long-run significance.
For the first time, a programmer can write a multi-user application that will run on all local area networks (LANs) compatible with the latest version of MS-DOS. Some even say that developers of MS-DOS-compatible multi-user applications may find it nearly impossible to market a program that does not run on all the major LANs compatible with MS-DOS 3.1. This is a dramatic change from the recent past, when a multi-user program needed a tailor-made version for almost every LAN.
At the root of this revolution is the fact that the new version of MS-DOS now provides solutions to some of the most basic problems of multi-user programming. In fact, it not only provides them, once they are invoked, it enforces their use until the computer is rebooted. Thus, MS-DOS 3.1 multi-user programming tools are forcing the standardization of applications running on LANs that accommodate MS-DOS-compatible computers. To remain truly MS-DOS-compatible (and therefore able to survive) these LANs must implement the MS-DOS 3.1 solutions.
The MS-DOS 3.1 standard has several implications:
As of July 1985, there were three network operating systems (NOSs) conforming to the MS-DOS 3.1 standard on the U. S. retail market:
Some of the network operating systems have developed a following of their own. For example, at least 25 LANs are compatible with Novell's Netware, which means that 25 network manufacturers are conforming to the MS-DOS 3.1 standard. Numerous manufacturers are preparing to conform as well.
LANs that are believed to have leased MS-NET and are expected to conform to the standard include 3Com's EtherLink (perhaps the number one LAN in terms of installed bases), Ungermann/Bass's Net/ One, Corvus's Omninet, and Orchid Technology's PCnet. Indeed, no vendor of an MS-DOS-compatible LAN can afford to ignore MS-DOS 3.1 because of the fact that old operating systems will be incapable of running the new multi-user applications being written for the new operating system.
Unless they are massively revised, multi-user applications running under old operating systems will not run under the new operating system. Thus, LAN vendors may wait until new or revised software is at least equal to software presently available before they make the changeover. For many LANs, this may occur sometime in 1986. (For a discussion of whether MS-DOS 3.1 is compatible with previous versions of MS-DOS, see ''MS-DOS 3.1 compatibility.'')
To understand the importance of the MS-DOS 3.1 standard, it is important to understand how it relates to the other emerging major LAN standard, IBM's Netbios (Network Basic Input/Output System), which is positioned to become the most widespread standard in local area networking (DATA COMMUNICATIONS, ''IBM provides industry with a versatile local network standard,'' June, p. 195). While Netbios allows different operating systems to interface with any Netbios-compatible LAN regardless of the hardware used, it is MS-DOS 3.1 that plays the largest role in allowing a programmer to write one multi-user program that will run on all MS-DOS 3.1-compatible LANs.
The relationship between MS-DOS 3.1 and Netbios can be most easily summarized by referring to the International Organization for Standardization (ISO) seven-layer Open Systems Interconnection (OSI) model for network architecture (Fig. 1). Information starts at the application layer at one computer on the LAN. It is passed down the seven layers until it reaches the physical layer, which includes the physical cable. At the receiving computer, it is passed upward through the seven layers until it reaches the application layer, which is the only layer that users handle.
Netbios is positioned just above the session layer, between the session and presentation layers. Netbios is an interface that offers the capabilities of the five lower layers to the two upper layers in the form of 17 commands, such as SEND DATA and RECEIVE DATA. These commands are designed to be generic so that nearly all LANs will be able to support them.
MS-DOS 3.1, in turn, operates at the presentation level and provides an interface between Netbios and application programs. Although applications can access Netbios directly, the MS-DOS interface is much more convenient for most purposes. Some estimates indicate that only about 5 percent of the MS-DOS-compatible multi-user programs presently being developed--mostly those for communications gateways--will go directly to Netbios rather than going through MS-DOS. (Single-user programs do not go to Netbios, either directly or through MS-DOS.) Thus, for most multi-user applications, the characteristics of MS-DOS 3.1 are all-important, for Netbios remains hidden behind MS-DOS.
Working hand-in-hand with MS-DOS is its ''Redirector'' program. When an application requests service from a local device (such as a disk), the Redirector can reroute the request over the network to a device at another computer. The Redirector (discussed more fully below) may, in general, be considered a part of the MS-DOS standard. It is also a service of the presentation layer.
In the past, a single-user program that ran under MS-DOS on a standalone computer would probably execute correctly when the computer was networked, regardless of the particular type of network being used. (This has remained generally true even though incompatibilities between a particular application and a particular network are possible.) A multi-user program, on the other hand, had a very slim chance of running on more than one network. Today, the status of the single-user program has not changed, but the status of the multi-user program has changed dramatically.
New tools Today, MS-DOS 3.1 provides tools for multi-user programmers, and in order to run under the standard, the program must use the standard multi-user programming tools incorporated into MS-DOS 3.1.
The most important of these tools is the SHARE program, which implements the file-sharing facility. In the past, when opening a file, a user specified only an ''access mode,'' which told MS-DOS of the desired operations on the file: ''read only,'' ''write only,'' or ''read and write,'' for example.
With the SHARE program operating, however, the user can now also specify a ''sharing mode.'' The sharing mode determines permissible access modes for subsequent users opening the same file. For example, an operator can open a file for read and write access, while specifying that subsequent users will only be able to read the file; this is called ''read/write'' access and ''deny write'' sharing mode. Such a file-sharing mechanism is obviously indispensable for a multi-user application. Each NOS designer need no longer invent a new file-sharing scheme.
Moreover, the SHARE facility cannot for practical purposes be ignored because there is no un-SHARE command. The standard way to deactivate SHARE after it has been loaded is to reboot (reinitialize the computer). Rebooting is generally avoided as much as possible on a network, since it cuts off communications with all other computers. Therefore, if one program runs with SHARE loaded, all programs on that computer must be able to run with SHARE loaded. This means that every time the user opens a file, MS-DOS is going to: (1) check its ''sharing table'' and, if the file is already open, determine the user's access according to the ''sharing mode'' specified by the person who opened the file, or (2) check the sharing mode specified by the user who is the first to open the file.
Of course, most programs today do not specify a sharing mode, since they were written before SHARE was available. When SHARE is loaded, files opened by pre-SHARE programs are automatically assigned ''compatibility'' sharing mode, which means that only one user can access them at a time. Thus, programmers who fail to take SHARE into account automatically write single-user applications. Once SHARE is loaded, these applications are unable to share files.
There is one exception to this rule: If the program only needs to read a file (and does not need to write to it), the ATTRIB command can be used to assign a ''read-only'' attribute to the file. Then, when a pre-SHARE program opens the file, MS-DOS will automatically assign a sharing mode of ''deny write'' (rather than ''compatibility'') so that other users can also read the file. This allows pre-SHARE programs a limited file-sharing capability. The ATTRIB command is used extensively in adapting older programs to the MS-DOS 3.1 networking environment, but its applicability is limited to programs that need to read shared files but do not need to write to them.
Loaded simultaneously with SHARE is the ''byte-locking'' function, which is required when two or more users have simultaneous read and write access to a single file. This function allows a user to exclude all other users from accessing a particular range of bytes while the range is being updated by the original user. The standard procedure is to lock a range of bytes, read them, change them, and then unlock them. Without such a mechanism, two users attempting to update a file would be like two painters trying to paint on a single canvas, without being able to see all of each other's brush strokes. In the past, NOSs running under MS-DOS had to invent their own byte-locking methods, and naturally they tended to be incompatible with one another. Now, any program ignoring the standard MS-DOS 3.1 method is a renegade and unwelcome in the society of well-behaved applications.
In fact, the renegade might suffer more than the law-abiding citizens because not only would the renegade not be able to break their locks, but it might also be unprotected while it was updating. Suppose, for example, that the application ''Renegade'' opens a file with read/write ''sharing mode.'' (Other users can read from and write to the file while Renegade is using it.) Locking bytes by using its own private method--a method other than the MS-DOS standard--Renegade updates the file.
When another user requests to write to the file, MS-DOS will check to see if a lock is active for the requested bytes. But MS-DOS will only check its own lock table, not Renegade's lock table. Therefore, MS-DOS--finding no locks in its table--will assume there is no reason not to change those bytes.
Suppose now that another user places a standard MS-DOS lock on a range of bytes, and Renegade tries to write to that area of the file. Normally, Renegade will go through MS-DOS to accomplish the write; MS-DOS, however, will check its lock table and will prevent Renegade from writing. Unless it goes around MS-DOS, Renegade cannot break the lock.
It is important to note that additional methods of coordinating access to files or records are not precluded by conformance to the MS-DOS 3.1 standards. Any program or operating system is free to impose additional access restrictions. Netware, for example, provides a whole set of locking mechanisms and semaphores that can be used in addition to those provided by MS-DOS. Tapestry provides several extra security features as well.
It is clear that MS-DOS now provides solutions to some of the most basic problems of constructing a multi-user application. (See ''Network-related MS-DOS commands, interrupts, and functions.'')
These ''high-level network primitives,'' as they are called, will encourage the adaptation of popular single-user programs for network use, the adaptation of multi-user minicomputer programs for use on microcomputer networks, and the design of new network applications.
MS-DOS also allows the programmer to use the ''Redirector'' program, which reroutes requests away from local devices and sends them instead to remote devices.
Forces use of file server MS-NET essentially consists of the Redirector, MS-DOS 3.1, and a file server. The MS-NET file server is fully compatible with the new standard, but it is not an integral part of it. IBM, for example, created a proprietary file server for the PC Network, as did Torus for Tapestry. Novell adapted Netware's existing file server. All are fully compatible with MS-DOS 3.1.
The inclusion of the Redirector forces LAN manufacturers to use a file server rather than a disk server, although the Redirector does not mandate the use of any particular file server. This distinction is very important and bears some explanation.
Disk-server software fools a computer into seeing a remote disk as a local disk. Each computer continues to believe it is the only one using that disk, and the disk-server software must coordinate requests from multi-users essentially without cooperation from them. Unexpected problems can result, the most serious being inconsistencies in the various computers' File Allocation Tables (FATs).
Each computer maintains a FAT to keep track of which areas of the disk have been used and which ones are still available. When numerous FATs are maintained--as is the case with a disk-server network--there must be a mechanism for constantly updating all the FATs, so that every computer can know which areas of the disk have been used by the other computers. If an error occurs in the updating procedure--an all too common occurrence--it is possible for computer A to be unaware that computer B has written to a particular area of the disk. Computer A may then overwrite areas of the disk that have already been used by B, thus corrupting B's files.
With a file server under MS-DOS 3.1, the Redirector determines when a request should be redirected to the file server and handles the exchange of information. When using a file server, the computer cannot perform remote disk storage and retrieval operations directly. For example, each computer does not maintain its own FAT. All the individual computer can do is send messages, via the Redirector, to the file server, which then performs the disk access operations, taking into account all other active or pending requests. Only one FAT is maintained by the file server. Compared with a disk server, the operation is more orderly and controlled, and it is less prone to failure.
File servers also make it easier to internetwork or use multiple operating systems on a single network. This is because file servers are more likely than disk servers to support ''high level'' requests, which tend to be generic (common across most operating systems). For example, the Redirector communicates with the file server using blocks of information called Server Message Blocks (SMBs). To update a file, the following SMBs might be sent: ''start connection,'' ''open file,'' ''read byte block,'' ''write byte block,'' ''close file,'' and ''end connection.'' Such commands are not operating-system dependent. This makes it much easier to create an interface between a non-MS-DOS computer and an MS-DOS file server. In theory, there is nothing to keep any machine, be it mainframe, mini-, or microcomputer, from sending and receiving these message blocks. And the message can be sent or received through a gateway to another network. (The server on the Appletalk network for Macintoshes, although it does not run MS-DOS, accepts requests from the PC Network, probably by translating SMBs into Appletalk commands.)
By way of contrast, note that disk servers frequently use direct or ''absolute'' disk input/output operations that address physical sectors of the disk and are operating-system dependent. Thus, disk servers wishing to service multiple operating systems have to partition the shared disk and allow each operating system to access only one partition. This is required because different operating systems format disks differently and cannot read one another's formats directly.
File servers have been standard equipment for many years in the mainframe and minicomputer environment. However, perhaps because a file server is harder to create than a disk server, they have been slow to catch on in the microcomputer LAN environment.
Netbios The Redirector, a presentation layer service, talks to the session layer through Netbios. Although it is not necessary to have a general discussion of Netbios, there are some aspects of it that have particular importance to MS-DOS-compatible LANs.
IBM has made it clear that Netbios will be used in all its forthcoming networks, and that it intends for Netbios to become a standard; thus, vendors must take Netbios into account for future compatibility requirements. For most multi-user programs running on an MS-DOS-compatible LAN today, Netbios' significance lies in the role it plays in ''extending'' network protocols, adding basic multi-user functions that do not presently exist in MS-DOS. Suppose a programmer wants to allow a station to set its time-of-day clock to correspond with the time at a file server. If the programmer wants to maintain compatibility with MS-DOS and Netbios, a new SMB can be added to those that already exist (a ''get time'' SMB), the SMB can be defined at the server, and the SMB can be sent to the server when the function is desired. This procedure, which IBM has fully documented, allows the programmer to make a network function out of literally any operation available on the IBM PC. To use this powerful method, however, one must be able to send and receive SMBs; the standard way to do this is through Netbios. MS-DOS permits a programmer to access peripherals, such as disks and printers at a remote computer, but it makes no provision for sending a specified string of bytes over the cable. Netbios, on the other hand, has just such a ''send data'' command. (Note: SMBs are used with the Redirector, so NOSs that provide their own redirecting function provide some mechanism parallel to SMBs as well.)
The inclusion of Netbios in the MS-DOS 3.1 standard has far-reaching--and perhaps troublesome--implications, particularly in the area of internetworking. Netbios assumes that each station will maintain a ''local name table'' of up to 16 names. When a connection or ''session'' is established between two computers on the network, Netbios sees it as a connection between the two names. Because IBM designed the PC Network to operate in a ''peer-to-peer'' fashion, there is no central controller that knows all the names on the network. If an entity called ''John'' on computer A wishes to establish a connection with ''Mary'' on computer B, computer A will send out a Netbios ''call'' for Mary. This causes computer A's adapter card to broadcast a series of ''name query packets'' to all stations asking, in effect: ''Is Mary out there anywhere?'' If Mary resides on the network, Mary and John exchange packets in a prescribed order, and the connection is established (Fig. 2a).
If John and Mary are on two different networks connected by some type of internetworking device, a number of different approaches may be taken to establish the connection. In one approach, termed ''Discovery'' by Sytek Inc., the makers of the PC Network, the internetworking device receives the ''name query packet'' from John and rebroadcasts it onto Mary's network. The device continues to forward packets from Mary to John and from John to Mary (Fig. 2b). The process is transparent to John and Mary, who proceed as if they were on the same network.
Today, there are no MS-DOS-compatible devices that use ''Discovery.'' The Discovery protocols are proprietary to Sytek (Mountain View, Calif.), although the company has announced its intention of making these protocols available on a leased basis. Thus, network manufacturers will find it relatively easy to become compatible at the MS-DOS, Redirector, file server, and Netbios levels, because all these items can be currently purchased ''off the shelf'' (the first two from Microsoft, the third from Microsoft or Novell, and Netbios emulation from Novell). Still, it remains practically impossible to become compatible with the PC Network at the packet level, which is what would be required to integrate with Discovery.
Even if the Discovery protocols become available at a reasonable price, they will probably be used only for linking IBM PC Networks or networks based on the same protocols (such as Sytek's LocalNet). The Discovery method assumes that: (1) the internetworking device can broadcast a packet on Mary's network, and (2) Mary can respond to John's ''call'' before John times out. These are not safe assumptions except when two IBM PC Networks are communicating (or an IBM PC Network and a network with very similar protocols). One reason for this limitation is that some networks do not support the broadcast mode of transmission; Corvus' Omninet is a prominent example. (A broadcast facility is, however, a part of the Netbios standard and will probably be incorporated in most LANs in the future.) Also, on the PC Network, timeouts and retries for the ''call'' are fixed and cannot be changed by the user; it is therefore likely that the PC Network timeout period and/or retry count will be inappropriate for some networks.
Nevertheless, internetworking is still possible with the PC Network. Novell, for example, uses a ''clearinghouse'' approach. In this scheme, an internet ''name server,'' known to all stations, maintains a name-to-internet address map for every name on the internet. The name server handles the packet exchanges for setting up a connection. Since every station knows the address of the name server, broadcasts are not required. Furthermore, all names can be verified with equal speed, without reference to the performance of the network where the name is in use; the performance of Mary's network does not affect how quickly John receives the ''name query response packet,'' because John actually receives it from the name server on his own network. Furthermore, the name server, in setting up the connection with Mary, is free to use any appropriate protocol; it does not have to use PC Network-type packets.
The clearinghouse approach becomes less efficient as the number of names in use rises, while Discovery is equally efficient with any number of names. In selecting the Discovery approach, IBM may have been looking forward to the day when the PC Network would be used in very large networks that might do major internetworking. In such a situation, all the networks involved might have to be standardized at the MS-DOS, Redirector, Netbios, and packet levels.
How the pieces fit Figure 3 shows how the various elements of the MS-DOS 3.1 standard work together on the PC Network. On the left is a workstation. On the right is a file/print server, which can also be used as a workstation. At the workstation, an application will normally talk to MS-DOS, which will, in turn, talk either to the local computer hardware through the BIOS (Basic Input/Output System) or to the network through the Redirector. At the server, an application has three additional options: talking directly to the file server, talking to the file server through MS-DOS and the Redirector, and going through the SHARE or PSPrint programs to reach BIOS and the local computer hardware. (PSP, the ''Print Spool Print'' program, is the basis for printer sharing on the PC Network, just as SHARE is the basis for disk sharing.) Architectures incorporating the MS-NET file server are similar, except that no application can run at the MS-NET file server, which must be dedicated to printing and managing files.
There are other ways to put the pieces together. Figure 4, for example, shows how Novell uses a proprietary ''Interface Shell'' as a Redirector. At a workstation, the Interface Shell routes requests either to MS-DOS or to the network. At a server, requests are routed either to MS-DOS (for local workstation functions) or to the file/print server, which can then communicate with the network. The Interface Shell has direct access to network resources, without the intervention of MS-DOS. The elimination of MS-DOS as a middleman significantly increases efficiency.
LAN vendors have essentially three choices in constructing a standard network operating system:
1. They can use both MS-DOS 3.1 and the Redirector and create the rest of the network operating system themselves, either from scratch or by adapting present software. This approach requires a large investment of expensive programming resources, but some vendors may be pursuing it nonetheless. Torus is already pursuing this course, and 3Com may do so as well.
2. They can use MS-DOS 3.1, the MS-NET file server, and the MS-NET Redirector. MS-NET supports a somewhat limited number of commands and functions, so to this basic package vendors will be likely to add features that will distinguish them from other LANs following the same strategy. Perhaps the biggest weakness of such configurations is the dedicated MS-NET file server. Most LANs are small (a dozen stations or less), and dedicating a station to act as a file server raises the cost per connection significantly. Another weakness of MS-NET is in recovering from ''orphan locks'' that occur when a station locks a record and then, because of some type of malfunction (perhaps as simple as the station's cord getting unplugged), fails to unlock the record. On MS-NET, the malfunctioning station itself must unlock the record. Obviously, it would be preferable for the server to be able to clear the orphan lock, too, as is the case on IBM's and Novell's networks. However, it must be remembered that NOSs based on MS-NET have not yet appeared on the retail market, so no definitive statements can be made about their performance.
3. They can use MS-DOS 3.1 and the Novell Interface Shell and file server. Such a configuration will support concurrent workstation/server operation and recovery from orphan locks by the server. It will allow a greater number of commands and functions than either the PC Network or MS-NET. MS-DOS 3.1 compatibility MS-DOS 3.1 is not always incompatible with previous MS-DOS versions, but it is usually incompatible with the other versions in a multi-user environment. Problems arise only for multi-user programs, and then only when the SHARE program is loaded.
In the standard network environment, the SHARE program will be loaded. Previous muti-user software is compatible with MS-DOS 3.1 only if SHARE is not loaded. Thus, previous multi-user software is not MS-DOS 3.1 compatible in the standard network environment. Each network has essentially two alternatives: It can run new standard applications and not load SHARE. This allows it to use any version of MS-DOS, including MS-DOS 3.1, without SHARE and to run previous multi-user applications. Or, the network can run new standard applications and load SHARE, which wreaks havoc with multi-user programs written for previous versions of MS-DOS. In the long run, almost without exception, networks will standardize, load the SHARE program as part of regular operations, and revise or abandon previous multi-user software. Network-related MS-DOS commands, interrupts, and functions MS-DOS commands ATTRIB allows the user to designate certain files as ''read-only'' files. In a multi-user environment, any number of users can open such a file in order to read it. In a standalone or multi-user environment, ATTRIB can be used to protect files, because a read-only file cannot be deleted or copied over.
SHARE is useful only in a multi-user, or at least multitasking, environment. It allows a single file to be opened by more than one user (or process). SHARE also loads the byte-locking function that allows one user to exclude all other users from a particular range of bytes within a file.
MS-DOS function calls The following functions are called when an INT 21H interrupt occurs. (The ''H'' means hexadecimal.) 1. Open a file (function call number 3DH). Called the ''extended'' file open, this function allows the programmer to declare both an ''access'' and a ''sharing mode.'' The ''access'' determines the tasks available to the user (or process) that opens the file. The ''sharing mode'' determines what subsequent users can do with the file. 2. Input/output control for devices (function call number 44H). This function, chiefly used for controlling disk drives, allows the programmer to send and receive control information. For example, this function call allows the programmer to change (a) the number of times MS-DOS will retry when it detects a sharing conflict before it sends a critical error message to the application, and (b) the length of time MS-DOS will wait between retries.
This function can also be used to get information about the channel over which the data passes. For example, the programmer can determine if a particular disk drive is local or remote. 3. Load or execute a program (function call number 4BH). This function call is equally useful in standalone or networking environments. It allows the programmer to execute a program, MS-DOS command, or network operating system command from within an application. 4. Get extended error (function call number 59H). Extended error reporting returns an error code, an error class, a suggested action, or an error locus. There is network-specific information in all categories, except ''suggested action.'' For example, one locus (site of error occurrence) is ''Net: Related to the network.'' 5. Create temporary file (function call number 5AH). Many applications use temporary ''work files.'' Normally, these are not multi-user shared files. The ''create temporary file'' function helps ensure that each temporary file will be used by only one user. A closer look at the ''create file'' function will illustrate the usefulness of ''create temporary file.''
To use the old MS-DOS function for creating a file (function call 3CH), the programmer supplies a file name. MS-DOS will create a new file if no file presently exists with the specified name. If a file already exists by that name, MS-DOS truncates that file to zero, completely wiping out its contents.
In a multi-user environment, this type of file creation is extremely dangerous. In particular, if two users are using the same program in the same directory at the same time, they run a serious risk of truncating one another's temporary files if they use the old ''create'' function. For example, suppose the multi-user program creates a temporary file named ''TEMP.FIL.'' First, user A creates a file by this name and stores some information in it. Next, user B creates a file by this name, wiping out all the information A just put in it, and stores different information. When A comes back to the file looking for his information, he gets a big surprise. Clearly, this is unsatisfactory.
A multi-user program that creates a temporary file needs to ensure that each user will use a different file name. The ''create temporary file'' does just that: It produces an arbitrary file name and attempts to create a file with that name. If a file already exists with that name, that file is left alone; it is not truncated or affected in any way. Then, a second arbitrary name is checked to see if there is an existing file by that name. This continues until a name is found that is not in use. A file is then created with that unique name. 6. Create new file (function call number 5BH). Many applications check for the existence of a particular file and, if it does not exist, create it. A problem can arise in a multi-user environment when user A checks for the existence of a file, but before he can create it, user B creates a file by that name. When user A finally does create his file, he destroys the one user B created. This function call checks for the existence of a file and performs file creation all in one step, eliminating such problems.
This function is very similar to the preceding one, except that here the programmer supplies the file name, and the file will not be created if a file with the same name is found. Again, the existing file is left undisturbed.
Thus, ''create temporary file'' creates a unique file no matter what--but the programmer has no control over the file name. ''Create new file'' creates a unique file or no file at all--and the programmer determines what file name, if any, will be used. 7. Lock/unlock file access (function call number 5CH). This is the standard MS-DOS ''byte-locking'' function that all MS-DOS 3.1-compatible multi-user applications will now be using. 8. Get machine name (function call number 5E00H). Netbios requires that a user communicate over the network using names that consist of 16 characters. The PC Network program considers one of these names to be the ''computer name'' that uniquely identifies each computer. Function call 5E00H sticks the machine name into a memory location defined by a user program. 9. Printer setup (function call number 5E02H). Allows a program to specify up to 64 bytes that will be sent to a network printer immediately before any file is sent to that printer. This is normally used to reset various printer controls to standard default values that a previous print job may have changed. 10. Get redirection list entry (function call number 5F02H). Returns the name of one redirected device. Each time the function is used, it returns the name of another device. 11. Redirect device (function call number 5F03H). This command intercepts operations intended for a local device and reroutes them so that they are actually performed on a remote device. The local device does not really have to exist. For example, users could redirect drive N, even if they do not have a physical drive N. The only requirement is that ''N'' be a legal drive specifier. All calls to drive N will then be redirected to the remote device. 12. Cancel redirection (function call number 5F04H). Undoes the work of the previous function. Calls to the local device will access the local device once again.
MS-NET network call (interrupt 5BH) This interrupt is used by MS-NET for executing network commands.
IBM PC Network Netbios call (interrupt 5CH) Used to execute Netbios commands, this interrupt goes directly to the IBM PC Network adapter.
Hardware-independent network call (interrupt 2AH) 1. Check installation (function call number 00H). Checks whether the interrupt 2AH interface is installed. 2. Check direct input/output (function call number 0300H). Ensures that ''absolute disk access'' is allowed to the device. If this is allowed, the physical sectors of the disk are addressed instead of particular files. ''Absolute disk access'' is forbidden with all shared network devices. 3. Execute Netbios with error retry (function call number 0400H). Currently, this function simply translates the request into an interrupt 5BH or 5CH, depending on the network operating system being used. This version also retries network commands upon receipt of certain error messages. For example, if the network is busy, the program can retry the request a number of times to ensure that it is not just a temporary condition. This function can also be used by programmers to add commands to Netbios. 4. Execute Netbios without error retry (function call number 0401H). Similar to the previous function, but with no error retry. 5. Get network resource information (function call number 0500H). Checks how many network names, network commands, and network sessions are available to an application. This operation is used by the application after the network operating system (NOS) is loaded in order to determine the remaining network resources.
Multiplex interrupt (interrupt 2FH) 1. Get installed state (function call number 00H). Checks whether the multiplex interrupt interface is installed. 2. Print queue interface (function calls 01H through 05H). These functions support the print queue by submitting or canceling print jobs, or reporting status. 3. ''Append'' installation check (function call number B700H). Checks to see whether the MS-DOS APPEND command is active. 4. PC Network program installation check (function call number B800H). Checks whether the PC Network program is installed. This function can also be used by other network operating systems to check for installation. It also provides information about which features are configured. 5. Get current post address (function call number B803H). After a ''network event,'' instructions will be executed beginning at a particular address in memory referred to as the ''post address'' because the instructions at that address are executed ''post-event'' (after the network event). The instructions at this post address are called a ''network event handler.'' Two network events are defined: a) message received and b) critical network error. This function allows the programmer to determine the current post address. 6. Set new post address (function call number B804H). Used with the previous function, this allows the programmer to ''hook into'' network events. For example, an application doing distributed processing may need to send messages back and forth between workstations, without user intervention. The application gets the current post address. Then the application sets the new post address to the address of the application's network event handler. Every time a message is received, the instructions in the application's event handler are executed. The application's event handler checks the message to see whether it belongs to the application and routes it accordingly. If the message belongs to another program, it is routed back to the event handler at the original post address. If it belongs to the application, then it is routed accordingly.
Multitasking interrupt (interrupt 15H) Whenever Netbios encounters a busy condition or is about to enter a wait loop, it issues interrupt number 15H. Other programs can watch for this interrupt and use this ''idle'' time to accomplish their tasks.
-- Mike Hurwicz has been a technical documentation liaison and consultant at Telco Research Inc. for one and a half years.
Table: Spanning layers. Netbios functions between the session and presentation layers, while MS-DOS 3.1 and the Redirector operate at the presentation layer. Chart: Connections. A similar sequence of events occurs when John and Mary establish a connection over one network (a) and through an intervening network (b). Chart: PC Network. When an application needs an operating system service, an INT 21h interrupt is issued to the operating system. If a network resource is needed, the Redirector routes the request to the proper place. The SHARE and PSPrint utilities are also available to route network requests correctly from the file server. Chart: No middleman. In Novell's implementation, an interface shell at each workstation serves as the Redirector, routing requests to MS-DOS or to remote servers.
Copyright 1985 McGraw-Hill, Inc.