WO1991004537A1 - Virtual network architecture and loader - Google Patents

Virtual network architecture and loader Download PDF

Info

Publication number
WO1991004537A1
WO1991004537A1 PCT/US1990/005118 US9005118W WO9104537A1 WO 1991004537 A1 WO1991004537 A1 WO 1991004537A1 US 9005118 W US9005118 W US 9005118W WO 9104537 A1 WO9104537 A1 WO 9104537A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
message
function
rom
error
Prior art date
Application number
PCT/US1990/005118
Other languages
French (fr)
Inventor
Brent B. Powers
Bruce K. Skidmore
Ian H. S. Cullimore
Lance C. Mock
Original Assignee
Poqet Computer Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Poqet Computer Corporation filed Critical Poqet Computer Corporation
Publication of WO1991004537A1 publication Critical patent/WO1991004537A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/177—Initialisation or configuration control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake

Definitions

  • This invention relates generally to computer systems and more specifically to a computer system including at least two computers which are interconnected by a virtual network and function as either a single virtual computer or two interconnected computers for sending and receiving information over the virtual network.
  • the fundamental components of a computer 20 include a central processing unit 10 (CPU) which is connected through an input bus 11 to an input module 12 and through an output bus 13 to an output module 14.
  • CPU 10 is also connected through data buses 15, 16 to a memory unit 17.
  • CPU 10 provides control and computing functions.
  • Input and output modules 12, 14 are used to communicate between the computer user and CPU 10.
  • Input module 12 supplies information to CPU 10.
  • Typical input devices are a keyboard and a mouse.
  • Output module 14 displays information from central processing unit 10.
  • Typical output modules include a video display monitor, a printer and other visual display means such as plotters.
  • Input unit 12 and output unit 14 are frequently referred to as input/output (I/0) units.
  • Memory unit 17 typically contains two general types of information, instructions and data.
  • a computer program is a sequence of instructions that are executed by the computer to perform a specific function.
  • Data in memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is executing in CPU 10.
  • Memory unit 17 typically includes mass memory 17A, sometimes called secondary memory, and main memory 17B.
  • Main memory 17B is a relatively fast memory, i.e. a typical access time is in the range from 20 to approximately 400 nanoseconds. Access time is the time interval between when CPU 10 requests data from memory 17 and when memory 17 makes the requested data available to CPU 10.
  • Main memory 17B is usually used to store at least a portion of the program currently being executed by CPU 10 and data required by this program.
  • Mass memory 17A such as disks and tapes, is used to store programs, data, or portions of either programs and data which are not needed immediately by CPU 10 or which cannot be accommodated in main memory 17B because of size limitations of main memory 17B. Since programs and/or data are transferred in and out of mass memory 17A at the direction of CPU 10, mass memory units are typically included in the generic term "I/O units.” Mass memory 17A, is significantly slower than main memory 17B. Access time for mass memory is typically on the order of tens of milliseconds. A computer operating system is typically used to control the operation of CPU 10 (Fig.
  • main memory 17B and I/O modules 12, 14, 17A the operating system provides an interface between computer user applications and the hardware.
  • hardware refers to the physical components of a computer system.
  • the operating system of a computer typically includes a kernel which (i) creates user processes, as described below, (ii) schedules execution of user processes, (iii) provides user processes with system services, and (iv) services hardware interrupts and exceptions.
  • the computer operating system is usually loaded into main memory 17B when the computer is booted.
  • booted refers to the sequence of operations that are performed when either power is first applied to the computer or the computer is reset.
  • a "user process” requires an understanding of the sequence of steps by which user source code, i.e., a computer program, is transformed into a series of instructions for CPU 10.
  • User source code for an application program which is to be run on a computer using a particular operating system, is typically compiled and linked into a binary file which is known as an executable image.
  • a "user process” is execution of the executable image by the kernel of the operating system.
  • MS-DOS MS-DOS operating system
  • ROM read-only memory
  • BIOS basic input/output system
  • the BIOS is designed to drive specific hardware based upon instructions, sometimes called commands, from the operating system.
  • the MS-DOS operating system interfaces with the BIOS thorough a series of commands called interrupts.
  • the interrupts are usually initiated by software executing in CPU 10.
  • CPU 10 obtains an address of the interrupt service routine from an interrupt vector table stored in main memory 17B.
  • main memory 17B typically contains user processes, an operating system, and information to interface the operating system with the hardware coupled to CPU 10.
  • the information in computer 20-1 may be copied onto a disk or a tape (disk/tape) 25 for example and the disk/tape 25 transported to computer 20-2 where the information is copied from disk/tape 25 into computer 20-2.
  • disk/tape 25 for computer 20-1 may not be compatible with computer 20-2.
  • computer 20-1 accepts only 5 1/4" floppy disks while computer 20-2 accepts only 3 1/2" floppy disks.
  • computers 20-1, 20-2 are often linked over telephone lines using modems 26, 27 (Fig. 2B) .
  • Computer 20-1 is connected to modem 26 through a serial port of computer 20-1.
  • Most microcomputers have at least one serial port.
  • Computer 20-2 and modem 27 are similarly coupled.
  • Modems 26, 27 are connected typically over telephone lines 28.
  • a modem converts the digital signals supplied by the computer serial port to analog signals, which are subsequently passed over telephone lines to another modem.
  • the second modem converts the analog signals received on the telephone lines to digital signals which are in turn supplied to the computer through the serial port.
  • Modems typically transfer data at 9,600 baud or less.
  • the transmission rate is limited by the quality of the line connecting the modems.
  • the data transmission rate between the modems is established at connect time based upon the quality of transmission and does not change thereafter. Accordingly, if data is initially transferred at a high rate and subsequently interference on the line produces errors in the data transmission, the transfer continues at the same high rate irrespective of the quality of the transmission. Similarly, if initially the quality of the line is low and a low transmission rate is established, this rate is not subsequently altered.
  • the error checking of transmitted information assumes that the information sent is the same as the information received.
  • an error code is calculated and transmitted as a part of the data block by the sending computer.
  • the receiving computer calculates the error code for the block of data and then compares the calculated error code with the transmitted error code. If the error codes are not identical, the receiving computer transmits an error message to the sending computer and the block of data is transmitted again.
  • computer 20-1 is hardwired to computer 20-2 by a cable 29 (Fig. 2C) and a software program executing in computer 20-1 and the same software program executing in computer 20-2 establish a data link over cable 29.
  • the coupled system i.e., computers 20-1, 20-2, cable 29 and the two executing software programs
  • the input/output devices such as the keyboard on each computer 20-1, 20-2 are both functional, as are the computer video displays.
  • the data transfer between two directly linked computers 20-1, 20-2 is being performed by a single user. Therefore, the keyboard and video display operation of one of the computers is redundant and unneeded. Nevertheless, the present techniques for connecting two computers provide such capability.
  • the configuration of computers 20-1, 20-2 is limited to executing operations for the specific software programs that establish the link between computers 20-1, 20-2. The link between the computers cannot be accessed by any other user application.
  • Networks of computers are formed, as shown in Fig. 3, with several computers 20-1 to 20-n, usually similar to computer 20 illustrated in Fig. 1, coupled to a common computer 21 usually referred to as the server.
  • Server 21 is accessed through network 22.
  • Network 22 permits common usage of data files as well as I/O devices which are connected to server 21.
  • An operating system for a network includes not only the operating system as described above for a single computer, but also additional software that coordinates the operation of computers 20-1 through 20-n and the server with respect to shared resources.
  • a MS-DOS executable program image is read off of disk, and loaded into memory by the MS-DOS operating system in response to the user providing the file name of the executable program image.
  • executable program image files usually have a file extension of ".EXE” and such a file is referred to as "a .EXE file”.
  • An alternative to a .EXE file is an executable program image file with a file extension of ".COM”.
  • .COM files and .EXE files are known to those skilled in the art.
  • the process of loading an executable program image, stored as a .EXE file includes allocating data and stack space in RAM for the program, setting up the program suffix prefix (PSP) for the program, reading the program from disk.
  • the executable program image stored as an .EXE file includes a "Relocation" process that is performed upon loading and execution of the executable program image.
  • the MS-DOS EXEC function using the relocation table at the start of the executable file, adjusts various values, primarily segment addresses, to the correct value.
  • _Data an assembler code word meaning the segment value of the default data segment
  • EXEC the MS-DOS operating system function
  • the EXEC function is intended to work with RAM and the executable program image upon loading into RAM may be changed.
  • the EXEC function, or any other function that performs a relocation fails to function properly because the function can not change the executable program image in ROM. Therefore, a relocation process is not possible for ROM-based executable program images.
  • any operating system that modifies executable program images cannot execute a program directly in ROM. This shortcoming limits the operation of portable computers, for example, which use ROM cards instead of floppy disks.
  • the virtual network executive of this invention overcomes the limitations of the prior art systems for coupling computer systems and provides a new capability for communications between computers coupled by a datalink. Moreover, the virtual network executive is accessed through a set of commands, e.g. interrupts in one embodiment, so that any user application, through these commands, can access and use the virtual network controlled by the virtual network executive. Not only can any user application access the virtual network executive, but also any user application is provided two distinct sets of capabilities by the virtual network executive.
  • commands e.g. interrupts in one embodiment
  • the virtual network executive is installed in each computer.
  • the virtual network executive in a first mode of operation is used to send and receive information between computers in the system.
  • a user application in a first computer can send a message through the virtual network executive to a second computer and a user application in the second computer can receive the message through the virtual network executive and send a reply message back to the first computer.
  • the virtual network executive in all the computers in the system except one are configured to service requests from the one computer.
  • a user application executing in the one computer has access to the resources in all the server computers, e.g., the information and attached peripheral equipment, through the virtual network executive.
  • This configuration of one computer in a system of computers controlling and using the other computers is referred to as a virtual computer.
  • the virtual computer is fundamentally different from the typical arrangement wherein a server computer through a network services requests from computers attached to the server computer.
  • the multifunction capability of the virtual network executive provides flexibility and communication means previously unavailable to user applications executing in a computer system.
  • the virtual network executive includes novel means for sending and receiving information over a communication link between computers.
  • the virtual network executive includes a first means, an application layer, for receiving, sending and generating messages.
  • the application layer receives the command from a user application and generates a first message structure that is sent to a second means, a transport layer, for receiving, sending, and generating messages.
  • the transport layer Upon receiving the message from the application layer, the transport layer generates a second message structure, called a packet.
  • the transport layer may construct one or more packets for each message received from the application layer. After construction of each packet, the transport layer sends the packet to a third means, a datalink layer, for sending and receiving information.
  • the datalink layer sends the packet over the communication link to another datalink layer in a remote computer using predetermined transmission parameters.
  • the datalink layers only send and receive information so that upon the datalink layer in the remote computer receiving the packet, the packet is sent to the transport layer in that computer.
  • the transport layers in the two computers control the predetermined transmission parameters, e.g., the speed of the transmission and the size of the packet sent over the communication link.
  • the sending transport layer generates an error code for the information in the packet and attaches the error code to the packet.
  • the receiving transport layer generates an error code for the information in the received packet and compares the error code for the received packet with the error code in the packet. If the error codes are not the same, the receiving transport layer, sends an error message to the sending transport layer and the packet is resent. After a predetermined number of transmission errors occur in sending a packet, the sending transport layer adjusts the packet size, the transmission speed or both.
  • the virtual network executive adjusts the transmission parameters, packet size and transmission speed, anytime a predetermined number of transmission errors are encountered and not just at connect time.
  • the designation of sending and receiving computers is chosen by the user.
  • the virtual network executive has the ability to perform either function in each computer in which it is installed.
  • the first message structure which is generated by the application layer, includes a header and a data region for storing information to be transferred between the computers.
  • the header includes (i) a field to identify the virtual network executive that generated the message, (ii) a field to identify the operation to be performed by the computer receiving the message, i.e., a field corresponding to the command from a user application, (iii) a field to indicate the direction of the message, i.e., whether the message is an operation request message or a reply message, and (iv) a field that identifies the remote computer to receive the message and the message itself.
  • the application layer builds a unique message structure for each remote operation that the application layer supports.
  • the second message structure which is generated by the transport layer, includes a header, which is different from the application layer header, at least a portion of the information in the first message structure, and an error code.
  • the application layer can compress and decompress the information passed over the communication link.
  • the information is transmitted and received over the datalink using predetermined parameters, i.e., a predetermined transmission rate and a predetermined blocksize, for the information transmitted and received.
  • predetermined parameters i.e., a predetermined transmission rate and a predetermined blocksize
  • the predetermined parameters are initially established at the time of the initial connection over the datalink.
  • the predetermined parameters are selected to permit transmitting and receiving the largest blocksize at the highest speed.
  • An iterative process is used to establish the predetermined transmission parameters.
  • the blocksize is reduced, and the transmission attempted again. If the transmission is successful, the new blocksize and the same transmission speed are used. If the transmission is not successful, the blocksize is reduced again. This procedure continues until either the transmission is successful or the blocksize reaches a minimum size. When the blocksize reaches the minimum and the transmission is still not successful, the transmission speed is reduced and the blocksize increased to the maximum blocksize. Again, the blocksize is successively reduced until a successful transmission is achieved. If both the transmission speed and the blocksize reach a minimum without a successful transmission, the transmission is aborted. If the transmission rate is fixed for some reason, then only the blocksize is varied upon detection of a predetermined number of errors.
  • a novel loader and a method are also provided for configuring a computer system for execution of a executable program image directly from a read-only memory (ROM) , in particular, the executable program image for the virtual network architecture.
  • ROM read-only memory
  • the loader of this invention is loaded into random access memory (RAM) by the computer system. Once the loader is in RAM, the loader sets up the conditions required for execution of the ROM-based executable program image directly from ROM.
  • an initialization means initializes computer system for execution of the ROM-based executable program image directly from ROM. The initialization includes configuring a data area in RAM for the ROM-based executable program image.
  • the loader preferably removes itself from RAM using a means for releasing RAM.
  • the ROM-based executable program image is, thus, configured to execute directly from ROM using the data area created in RAM by the loader.
  • the loader in one embodiment, includes a (i) a means for initializing computer system for execution of ROM-based executable program image directly from ROM and (ii) means for releasing RAM.
  • the loader includes means for releasing the random access memory used by the loader itself, the loader of this invention would function properly without releasing the RAM utilized by the loader.
  • such an embodiment would obviously result in somewhat diminished efficiency in utilization of the RAM because the loader would occupy RAM when the loader was no longer needed.
  • the loader includes a data area initialization means, an application existence verification means, and setup means.
  • the data area initialization means includes (i) a means for creating a working data area in RAM for the ROM-based executable program image and (ii) a means for data initialization which initializes, within the data area, the necessary variables for execution of the ROM-based executable program image directly from ROM. If the operating system creates a working data area of the appropriate size, the working data area creation means is unnecessary.
  • the application existence verification means ensures that the ROM-based executable program image is physically present on a ROM in the computer system. If application existence verification means finds the ROM-based executable program image, the loader continues operation with the setup means. However, if the ROM-based executable image is not on a ROM within the computer system, an error message is sent to the user by an error message means, and the loader terminates through a terminate means.
  • the application existence verification means may also include means for checking whether the ROM-based executable program image is already loaded in the computer system.
  • the setup means sets the data segment register as well as any other registers and/or vectors that are required by the ROM-based executable program image.
  • the operation of the setup means depends upon the nature of the ROM-based executable program image, as described more completely below.
  • the setup means at least releases the RAM required by the loader itself, and turns control of the computer system over to the ROM-based executable program image.
  • the setup means may include means for configuring the ROM-based executable programs image as a terminate-and-stay-resident program.
  • the execution of the ROM-based executable program image depends upon the nature of the ROM-based executable program image.
  • the executable program images may be divided into (i) TSR applications and (ii) non-TSR applications.
  • control is turned over to the ROM-based executable program image after the initialization, and the ROM-based executable program image is executed.
  • the ROM-based executable program image exits normally to the MS-DOS operating system.
  • the setup means as described above, may configure the ROM-based executable program image as a TSR program.
  • the ROM-based executable program image may (i) setup the necessary interrupt vectors, (ii) execute ROM-based code that configures the application as a TSR program and (iii) terminate-and-stay-resident releasing unnecessary code/data.
  • the ROM-based executable program image functions as a TSR program and so may not execute directly after the initialization.
  • the loader contains the structure necessary to perform the operations that are required for execution of the ROM-based executable program image directly from the ROM.
  • a method for configuring a computer system for execution of a ROM-based executable program image directly from a ROM.
  • the method includes the steps of creating a working data area in RAM for the executable program image and initializing, within the RAM data area, the variables needed for execution of the ROM-based executable program image.
  • the RAM used in the initialization is released.
  • Figure 1 illustrates a prior art computer system
  • Figure 2A illustrates information transfer between two uncoupled prior art computer systems as in Figure 1.
  • Figure 2B illustrates information transfer between two prior art computer systems as in Figure 1 that are coupled by modems.
  • Figure 2C illustrates information transfer between _- prior art computer systems as in Figure 1 that are coupled by a direct link.
  • Figure 3 illustrates a network of prior art computer systems as in Figure 1.
  • Figure 4 illustrates a general block diagram of the virtual network architecture of this invention.
  • Figure 5 is a more detailed block diagram of the virtual network architecture of this invention.
  • Figure 6 illustrates the general message structure including a header and a data region according to the principle of this invention.
  • Figure 7A is the message structure for the function O h CONNECT service.
  • Figure 7B is the message structure for the function OAh LISTEN service.
  • Figure 8 is the message structure for the function OAh DISCONNECT service.
  • Figure 9A is the message structure for the function OAh SEND service.
  • Figure 9B is the message structure for the function OAh RECEIVE service.
  • Figure 10A is the message structure for the function OAh MAP service.
  • Figure 10B is the reply message structure for the function OAh MAP service.
  • Figure 11A is the message structure for the function 09h SELECT DISK service OEh.
  • Figure 11B is the reply message structure for the function 09h SELECT DISK service OEh.
  • Figure 12A is the message structure for the function 09h GET FREE DISK SPACE service 36h.
  • Figure 12B is the reply message structure for the function 09h GET FREE DISK SPACE service 36h.
  • Figure 13A is the message structure for the function 09h MAKE DIRECTORY service 36h.
  • Figure 13B is the reply message structure for the function 09h MAKE DIRECTORY service 39h.
  • Figure 14A is the message structure for the function 09h REMOVE DIRECTORY service 3Ah.
  • Figure 14B is the reply message structure for the function 09h REMOVE DIRECTORY service 3Ah.
  • Figure 15A is the message structure for the function 09h CHANGE DIRECTORY service 3Bh.
  • Figure 15B is the reply message structure for the function 09h CHANGE DIRECTORY service 3Bh.
  • Figure 16A is the message structure for the function 09h DELETE FILE service 41h.
  • Figure 16B is the reply message structure for the function 09h DELETE FILE service 1h.
  • Figure 17A is the message structure for the function 09h CREATE FILE service 3Ch.
  • Figure 17B is the reply message structure for the function 09h CREATE FILE service 3Ch.
  • Figure 18A is the message structure for the function 09h OPEN FILE service 3Dh.
  • Figure 18B is the reply message structure for the function 09h OPEN FILE service 3Dh.
  • Figure 19A is the message structure for the function 09h CLOSE FILE service 3Eh.
  • Figure 19B is the reply message structure for the function 09h CLOSE FILE service 3Eh.
  • Figure 20A is the message structure for the function 09h WRITE FILE service 4Oh.
  • Figure 2OB is the reply message structure for the function 09h SELECT DISK service 4Oh.
  • Figure 21A is the message structure for the function 09h READ FILE service 3Fh READ FILE.
  • Figure 2IB is the reply message structure for the function 09h READ DISK service 3Fh.
  • Figure 22A is the message structure for the function 09h LSEEK service 42h.
  • Figure 22B is the reply message structure for the function 09h LSEEK service 42h.
  • Figure 23A is the message structure for the function 09h CHMOD service 43h.
  • Figure 23B is the reply message structure for the function 09h CHMOD service 43h.
  • Figure 24A is the message structure for the function 09h GET DIRECTORY service 47h.
  • Figure 24B is the reply message structure for the function 9Oh GET DIRECTORY service 47h.
  • Figure 25A is the message structure for the function 09h FIND FIRST service 4Eh.
  • Figure 25B is the reply message structure for the function 09h FIND FIRST service 4Eh.
  • Figure 26A is the message structure for the function 09h FIND NEXT service 4Fh.
  • Figure 26B is the reply message structure for the function 09h FIND NEXT service 4Fh.
  • Figure 27A is the message structure for the function 09h RENAME service 56h.
  • Figure 27B is the reply message structure for the function 09h RENAME service 56h.
  • Figure 28A is the message structure for the function 09h GET/SET TIME/DATE service 57h.
  • Figure 28B is the reply message structure for the function 09h GET/SET TIME/DATE service 57h.
  • Figure 29 is the status structure according to the principles of this invention.
  • Figure 30 is the call out structure for the serve function of this invention.
  • Figure 31 is the status event handler structure which is pointed to by the status event address in Figure 30.
  • Figure 32 is a block diagram of the transport layer function TSEND.
  • Figure 33 is the packet structure according to the principles of this invention that is generated by transport layer function TSEND.
  • Figure 34 is the block diagram for the operation send packet 170S12 in Figure 32.
  • Figure 35 is a flow diagram for transport layer function TRECEIVE.
  • Figure 36 is a flow diagram for receive packet 170- R6 in Figure 35.
  • Figure 37 is a flow diagram for operation send reply 170-R13 in Figure 35.
  • Figure 38 is a flow diagram for data link function DRESET.
  • Figure 39A and 39B are a flow diagram for function SET CONNECTION SPEED according to the principles of this invention.
  • Figure 40 is a flow diagram for function RECEIVE CHARACTER STATUS according to the principles of this invention.
  • Figure 41 is a flow diagram for function RECEIVE CHARACTER according to the principles of this invention.
  • Figure 42 is a flow diagram for SPEED RESYCHRONIZATON according to the principles of this invention.
  • Figure 43 is a flow diagram for function SET LISTEN SPEED according to the principles of this invention.
  • Figure 44 is a flow diagram for datalink function DSEND according to the principles of this invention.
  • Figure 45 is a flow diagram for function SEND PACKET SIZE according to the principles of this invention.
  • Figure 46 is a flow diagram for function GET PACKET SIZE according to the principles of this invention.
  • Figure 47 is a flow diagram for datalink function DRECEIVE.
  • Figure 48 is a flow diagram for interrupt service routine 180-INT according to the principles of this invention.
  • Figure 49 is a flow diagram of interrupt service routine 180-RECV according to the principles of this invention.
  • Figure 50 is a flow diagram for datalink function DCONNECT according to the principles of this invention.
  • Figure 51 is a flow diagram for a function MAIN INITIALIZATION according to the principles of this invention.
  • Figure 52 is a flow diagram for a function CONNECT/LISTEN INITIALIZATION according to the principles of this invention.
  • Figure 53 is a flow diagram for a function CHECK LINE SPEED according to the principles of this invention.
  • Figure 54 is a flow diagram from datalink function DLISTEN according to the principles of this invention.
  • Figure 55A is a block diagram of a computer system including the loader of this invention for a ROM-based executable program image.
  • Figure 55B is a block diagram of one embodiment of the loader of this invention.
  • Figures 56A and 56B are flow diagrams for one embodiment of the loader of this invention.
  • FIGS 57A through 57C are block diagrams of alternative RAM memory allocations associated with the loader of this invention.
  • FIGS 58A through 58C are a flow diagram for one embodiment of a loader, according to the principles of this invention, for a library of ROM-based functions.
  • Figures 59A through 59D are a flow diagram for one embodiment of the loader of this invention for a ROM- based application which operates under the library of functions loaded by the loader of Figures 58A through 58C and which is configured as a terminate-and-stay-resident program.
  • a new computer architecture for configuring at least two computers as a single virtual computer system.
  • a virtual network architecture is added to each computer in the system.
  • the novel virtual network architecture permits a first computer to function in a normal manner while the second computer and other computers function only to service requests from the first computer and so are referred to as server computers.
  • This configuration of computers is referred to as a virtual computer.
  • the first computer has not only the main memory and the secondary memory of that computer available, but also the first computer can directly access the main memory the mass memory, and other peripheral equipment of the other computers as well through the virtual network architecture, sometimes referred to as the virtual network.
  • the first computer has access to all the resources of the server computers.
  • the secondary memory of a server computer appears to the first computer as slow secondary memory.
  • slow refers relatively to the access time of information in the server computer relative to the access time for equivalent information in the first computer.
  • the access time for the information in a server computer is the normal access time plus the time required to receive the request for information and to transmit the information back to the first computer.
  • the access time for information in the server computer is greater than normal access time in the first computer so that the resources in the server computer are slow relative to the resources in the first computer.
  • the transfer of information is more flexible than the prior art transfer methods, but more importantly, the virtual network architecture provides a new virtual computer system capability for computer applications.
  • the virtual network architecture of this invention is interposed between user applications and the computer operating system.
  • the virtual network is included on a read-only memory in the computer and is loaded as part of the ROM BIOS, as described more completely below.
  • the virtual network would be loaded as a terminate and stay resident program.
  • the virtual network architecture provides two basic functions to user applications.
  • the first function in one embodiment, permits a user application to form a virtual network between two computers and establish one of the computers as the first computer and other computer as the server.
  • the first function includes not only the ability to establish a connection with another computer, but also the ability to send and receive messages, to obtain the virtual network system status, and to initialize the virtual network system.
  • the second function provided by the virtual network architecture to user applications is the ability to perform operating system commands utilizing the resources of the server computers while the user application is executing in the first computer.
  • FIG. 4 One embodiment of this invention is illustrated in Fig. 4.
  • a user application 101 In first computer 100, a user application 101, a virtual network executive 102, and an operating system 103 are included in main memory 117.
  • memory 217 of a second computer 200 In memory 217 of a second computer 200, a user application 201, a virtual network executive 202 and an operating system 203 are present.
  • user applications 101, 201 are functionally identical; virtual network executives 102, 202 are functionally identical; and operating systems 103, 203 are functionally identical.
  • Computers 100, 200 also include secondary memory 118, 218 and CPUs 110 and 210 as well as video display, input/output devices and other components and parts typically found in micro- and mini-computers. These features are known to those skilled in the art and are not included in Figure 4 for clarity. (See P. Norton and R. Wilton, The New Peter Norton Programmer's Guide to The IBM PC & PS/2. Microsoft Press, (1988).)
  • serial line 150 is connected to a serial port(not shown) of each computer 100, 200.
  • Each serial port is coupled to the CPU of the computer according to principles known to those skilled to the art, and the coupling, i.e., the hardware components in the computer interfacing the serial port with the CPU, do not form a part of this invention. Rather, this invention provides the user a new capability for communication between computers using a serial connection or any other datalink. While a serial connection is used in this embodiment, in view of the following description, those skilled in the art could use the principles of this invention to couple computers 100, 200 through any number of physical or electronic connections.
  • User applications 101, 201 and operating systems 103, 203 are loaded in computers 100, 200 respectively using standard techniques known to those skilled in the art.
  • User applications 101, 201 include a series of commands which interact with virtual network executives 102, 202 to: (i) determine that virtual network executive 102,
  • 202 is installed on computers 100, 200; (ii) activate virtual network executive 102, 202; (iii) configure computers 100, 200 as virtual computer 300; (iv) perform user specified operations on virtual computer 300; and
  • (v) send and receive information between user applications 101, 201.
  • the user must interact with user applications 101, 201 to establish virtual computer 300 because either computer 100 or computer 200 can be selected as the first computer.
  • the other computer becomes by definition the server in virtual computer 300.
  • the server computer is under the control of the first computer and does not support user input from the server computer.
  • user application 201 After virtual computer 300 is established with computer 100 as the first computer and computer 200 as the server, user application 201 only supports exchange of information with computer 100 as needed, and user application 101 is in control of virtual computer 300.
  • the user interacts with virtual computer 300 through user application 101 in computer 100.
  • application 101 has the resources of both computers 100, 200 available.
  • virtual network executive 102 When user application 101 sends a command to virtual network executive 102, virtual network executive 102 processes the command. As explained more completely below, virtual network executive 102 has a set of commands, sometimes called instructions, that control operation of vitural network executive 102. Therefore, the user application issues a command that is one of the set of commands. Moreover, any user application can use this set of commands to access the virtual network executive 102. Accordingly, unlike prior art systems, any user application can use the features of the virtual network architecture of this invention.
  • virtual network executive 102 passes the command to virtual network executive 202 which in turn performs the requested operation in conjunction with the operating system 203 (and user application 201 in some cases) using the resources of computer 200.
  • virtual network 202 Upon completion of the requested operation, virtual network 202 sends the requested information and/or a message that the requested operation was completed to virtual network executive 102 which in turn passes the results to user application 101.
  • virtual network executive 102 in conjunction with operating system 103, if required, processes the command. In either case, user application
  • Virtual network executive 101 is unaware that the command was processed by virtual network executives 102, 202. User application 101 does not provide information which is suitable for direct transmission to computer 200 over serial line 150. Thus, user application 101 issues a command that directs virtual network executive 102 to perform a specific operation. Generally, the command specifies an operation with certain information and user application 101 provides a pointer to a buffer that is to be used for that information.
  • Virtual network executive
  • virtual network executive 202 converts the packets of information into a message and subsequently the message into a buffer and a command.
  • virtual network executive 202 After construction of the buffer of information from the transmitted packets, virtual network executive 202 performs the specified command using the information in the buffer as required. After the operation is complete, virtual network executive 202 converts the buffer into a reply message and then the reply message into packets which are transmitted to virtual network executive 102. Virtual network executive 102 then converts the received packets into a reply message and the reply message into a buffer and provides the buffer to user application 101.
  • the previous description assumed that user application 101 accessed or used information in computer 200, but, as described more completely below, virtual network executive 102 also processes commands for information within computer 100.
  • virtual network executives 102, 202 support two different functions 120, 130(Fig. 5).
  • First function 120, 220 includes means for establishing virtual computer 300 from computers 100, 200 and means for passing information between computers 100 and 200.
  • Second function 130, 230 supports selected operating system commands both locally and over the virtual network coupling computers 100 and 200.
  • virtual network executives 102, 202 operate in two modes.
  • user applications 101, 201 use first function 120, 220 in virtual network executive 102, 202 to send and receive information between computers 100, 200.
  • computers 100, 200 are configured as a virtual computer, i.e., one of the computers is placed in a server mode, and then first function 120, 220 and second function 130 are used by a user application on the other computer to access resources in both computers.
  • the operation of virtual computer 300 using the virtual network established over serial line 150 is illustrated in Fig. 5.
  • Virtual network executive 102, 202 includes an application layer 160, 260 which in turn includes a first function 120, 220 and a second function 130, 230, a transport layer 170, 180 and a datalink layer 180, 280.
  • Each function typically includes several services.
  • Each layer in virtual network executive 102, 202 communicates only with an adjacent layer.
  • application layer 160, 260 communicates with user application 101, 201 and transport layer 170, 270.
  • serial line 150 is shown coupled with datalink layers 180, 280 so that datalink layers 180, 280 communicate with each other.
  • Serial line 150 is only one example of a datalink coupling computers 100, 200.
  • Datalink layer 180, 280 of the virtual network executive must be selected to communicate with the electronic datalink and transport layer 170, 270.
  • the user first instructs application 101 to activate virtual network executive 102.
  • application 101 sends a command to first function 120 to reset virtual network executive 102. Since this command is for a local operation, function 120 activates virtual network executive 102 in computer 100. The user repeats this process on computer 200 to activate virtual network executive 202.
  • virtual network executives 102, 202 are activated, the user through user applications 101, 201 establishes the virtual network so that computer 100, 200 function as virtual computer 300.
  • the user instructs user application 201 to configure computer 200 as the server.
  • Function 220 in response to the command from user application 201, configures virtual network executive 202 as a server so that virtual network executive 202 listens for a connect command on serial line 150.
  • virtual network executive 202 receives a connect command, as described below, computer 200, sometimes referred to as a node, services commands directed over virtual network 150 by user application 101.
  • the user instructs user application 101 to establish a connection between computer 100 and computer 200.
  • User application 101 in response to the user, sends a connect command to function 120 in application layer 160.
  • Connect is one of the services supported by function 120.
  • Application layer 160 generates a connect message and calls transport layer
  • the application layer generates a unique message for each service supported by a function.
  • the set of application layer messages all have a common structure that includes a message header and a data region following the header.
  • the message structure is described below for each of the services in first and second functions 120, 130.
  • the data region of a message is sometimes compressed to minimize the information that must be transmitted to the remote node.
  • Transport layer 170 which is responsible for correct delivery of the information to the server computer, breaks the connect message generated by application layer 160 into packets.
  • Transport layer 170 processes each packet sequentially. Specifically, transport layer 170 adds a header and an error code, e.g., a CRC-16 checksum, to each packet and then calls datalink layer 180 to transmit the packet to computer 200.
  • error code e.g., a CRC-16 checksum
  • Transport layer 170 then waits for a reply from transport layer 270 that the packet was received.
  • datalink 280 receives a packet
  • the packet is passed to transport layer 270, which checks the transmitted packet for errors and sends a reply through datalink 280 to datalink 180 and consequently to transport layer 170. If the packet was transmitted without error, the next packet is sent by transport layer 170. However, if an error occurs in transmission, transport layer 170 resends the packet. This continues until either transport layer 170 successfully transmits the packet or transport layer 170 determines that the packet cannot be transmitted with the present transmission speed and blocksize.
  • blocksize refers to the size of the packet in bytes.
  • the maximum transmission rate is 115,200 bits per second and the maximum blocksize is 4 Kbytes.
  • the UART is the interface between software and hardware in the computer.
  • the UART defines the maximum transmission rate.
  • the specification for the typical UART is 19.2 Kbits per second, because the minimum baud rate divisor is specified as 6.
  • the baud rate divisor for the UART is 1. If transport layer 170 determines that the information cannot be passed in large blocks without error, transport layer 170 decomposes the packet into a sequence of packets with a blocksize one half the prior blocksize.
  • transport layer 170 attempts to reduce the errors by again halving the blocksize of a packet.
  • the size of the transmitted packet is continually halved until either the packet is either successfully transmitted or until the blocksize reaches the minimum 256 bytes.
  • transport layer 170 directs datalink layer 180 to decrease the transfer speed and then the packet blocksize is increased to the maximum and the error reduction procedure is repeated.
  • the transmission parameters i.e., the packet size and/or the transmission speed, are adjusted any time a predetermined number of transmission errors are encountered while sending a packet.
  • virtual network executive of this invention is responsive to changes in transmission conditions.
  • transport layer 270 After the packets are successfully received by datalink layer 280 and transport layer 270, transport layer 270 passes the message to application layer 260, application layer 260 processes the message provided by transport layer 270 and determines that a connect command was received. Accordingly, application layer 260 configures virtual network executive 202 in the server mode to receive information from virtual network executive 102.
  • application layer 260 After application layer 260 completes the operations specified in the received message, application layer 260 constructs a reply message and passes the reply message to transport layer 270.
  • Transport layer 270 performs the same operations as previously described for transport layer 170 in sending the reply message to transport layer 170. As transport layer 170 receives each packet from transport layer 270 the reply message is constructed and upon completion passed to application layer 160 which in turn parses the reply message and provides the returned information to user application 101.
  • the user identifies the remote drives that are available to user application 101.
  • the remote drives i. e. , the drives in computer 200
  • the remote drives are aliased as drives in computer 100.
  • computer 100 may have drives identified by letters A through E.
  • the remote drives are typically aliased as local drives F, G, ....
  • virtual network executive 102 when user application specifies an operation with one of drives F, G, ... , virtual network executive 102, as explained more completely below, sends the request over the virtual network.
  • Virtual computer 300 in now established with computer 200 configured to service requests from user application 101 executing in computer 100.
  • server computer 200 processes services associated with both first function 120 and second function 130.
  • user application 201 is not instructed to place computer 200 in the server mode using the server service of first function 220. Rather, user application 201 sends and receives messages through first function 220. In this mode of operation, user application 201, rather than the server service of first function 220, processes the commands from user application 101.
  • virtual network executive 202 provides the user with the capability to either process commands automatically through the server service of first function 220 or provide specific services that are unique to the user by providing a user application that processes and sends messages through first function 220 of virtual network executive 202.
  • virtual network executive 102, 202 services are invoked using interrupt 66h.
  • First function 120 is invoked by user application 101, 201 issuing an interrupt 66h
  • function OAh is invoked by user application 101, 201 issuing an interrupt 66h, function 09h.
  • the selection of a particular interrupt and particular functions are illustrative only and are not intended to limit the invention to the specific embodiments described herein. In view of this disclosure, those skilled in the art could implement this invention using other operating systems either by using other strategies to define entry points to the functions of this invention, or by implementing these services on the native operating system.
  • user applications 101, 201 invoke virtual network executives 102, 202 by issuing an interrupt 66h that specifies either function 09h or function OAh and a service for the specified function.
  • interrupt 66h specifies either function 09h or function OAh and a service for the specified function.
  • register names e.g., AX (sometimes used as two registers called AH and AL) , BX (sometimes used as two registers called BH and BL) , CX (sometimes used as two registers called CH and CL) , DX (sometimes used as two registers called DH and DL) , SP, BP, SI, DI, CS, DS, SS, and ES, are those associated with the Intel Corporation of Santa Clara, CA, iAPX86, 88 and iAPX186, 188, 286, 386 and 486 family of micro-processor systems.
  • these examples are illustrative only of the principles of the invention and are not intended to limit the scope of the invention to the specific embodiment described. In view of this disclosure, those skilled in the art can use the virtual network executive of this invention with other microprocessors and other operating systems.
  • the services within function 120, 220 of application layer 160, 260 are invoked, as described above, by user application 101, 201 issuing an interrupt 66h, function OAh, and a service.
  • Table 1 lists the nine application layer services for function OAh in this embodiment, i.e., the services of interrupt 66h, function OAh that must be provided by the user application to access application layer 160.
  • the register configuration that must be initialized by user application 101, 201, and the information in the registers that are returned to user application 101, 201 are also presented in Table 1.
  • the services described herein are illustrative only of the principles of this invention and are not intended to limit the invention to the specific embodiments described.
  • function OAh could include either only a subset of the services in Table 1 or additional services to support user specific needs.
  • AX Session identification (SID) or error code
  • Second function 130 is entered via the application program 101 issuing an interrupt 66h, function 09h call that includes a specific service.
  • a selected group of MS-DOS operating services are supported.
  • the selected group of services may be considered a nearly orthogonal set of services. Orthogonal means that these services can be used to accomplish the complete range of interrupt 21 services.
  • the selected set of services are listed in Table 3.
  • interrupt 66h function 09h services have the same service number as the MS-DOS interrupt 21h services.
  • the register values that must be supplied when an interrupt 66h service is called are the same as those defined by MS-DOS for the corresponding interrupt 21h service with the exception that the MS-DOS function code in register AH and the parameter AL are pushed on the stack by the user application prior to the interrupt 66h.
  • the global interrupt 66h handler removes the pushed AX parameter prior to returning to the calling program so that the user program is not required to adjust the stack after interrupt 66h function 09h invocations.
  • interrupt 66h function 09h generally uses interrupt 21h to ultimately perform the requested service.
  • a global interrupt 66h handler is entered when a user application issues an interrupt 66h.
  • the user application sets the parameters which are required by the interrupt function 66h function that is to be called.
  • register AH has been set to the function number and register AL has been set to the service number.
  • interrupt 66h function 09h the user application sets register AX to the appropriate value for the service and then pushes that value onto the stack. The user application then sets register AH to 9 and issues interrupt 66h.
  • the global interrupt 66h handler Upon receipt of interrupt 66h, the global interrupt 66h handler first increments the reentrancy level and if this entrance is not a reentrance switches stacks. The current CPU register values are saved and various parameters, e.g., the screen segment and related colors are determined. Global interrupt 66h handler then passes control to a main dispatcher which determines whether the interrupt 66h function is supported. In this embodiment, the main dispatcher determines whether the function number is less than or equal to OAh or is equal to 3Oh. If the function is not supported, subsequent operations depend upon the computer system in which the global interrupt 66h handler and the virtual network executive are loaded.
  • the main dispatcher in computers other than the low power portable computer, if the function passed to the global interrupt 66h handler is not supported, the main dispatcher returns an error message indicating a bad parameter to the global interrupt 66h handler which in turn decrements the reentrancy level, sets the carry flag, restores the stack to its original condition and returns the error code to the user application. If the function passed in the interrupt 66h call is supported, the main dispatcher determines whether the requested service is valid by comparing the service with a maximum service number for that function. If the service is valid, the dispatcher loads the address of the handling function and passes control to that handling function.
  • the main dispatcher Upon return from the function, the main dispatcher returns control to the global interrupt 66h handler, which as described above, decrements the reentrancy level, sets the carry flag based upon the return code, resets the stack and returns to the calling user application.
  • This is the sequence of operations in which function OAh of the virtual network executive are processed.
  • the interrupt 66h function 09h services are processed in a somewhat different manner.
  • the maximum service number for function 09h is 1. Accordingly, if function 09h is called with a service 0, the main dispatcher loads the VNA dispatcher which is described more completely below. If function 09h is called with any number other than 0 the service is not supported but since the function is 09h, control passes to the VNA dispatcher.
  • the VNA dispatcher removes the saved registers from the stack, restores the stack to its state upon entry to the global interrupt 66h handler and returns to the user application. If the service is not supported and the function is not 09h, the processing is the same as that described above when the specified function was not supported.
  • the application layer functions are written primarily in the "C" programming language and the interrupt handler and dispatchers are written in assembly language, there is of necessity a set of interface routines, written in assembly language, between the VNA dispatcher and the function 09h services and between the main dispatcher and the application layer function OAh services. These interface routines adjust the parameters from the register-based assembly conventions to the stack-based
  • the VNA dispatcher receives control when the main dispatcher determines that an interrupt 66h has been issued with a requested function number of 09h.
  • the VNA dispatcher first determines if the virtual network executive is active. If the virtual network executive is not active, then the VNA dispatcher executes the function locally. Specifically, if the requested service is the MS-DOS terminate function, then the virtual network executive reentrancy level is reset to 0, and the flag indicating whether VNA is active is set to indicate that VNA is inactive.
  • the registers are then reset to the state that they were in prior to entering interrupt 66h and the value of register AX is popped off the stack and at this time, an interrupt 21h is executed.
  • the VNA dispatcher examines the requested service number to determine if the service number is listed in the table of those service numbers that the virtual network executive directly supports under function 09h. If the service is not in the table, the service is executed locally in the same manner as when the virtual network executive was not active. Conversely, if the service is in the table, an interface function is called via the look-up table. The interface function parses parameters and places them on the stack and then passes control to the actual handling function.
  • Each of the handling functions parses the parameters passed by the user application to determine the path, handle, or other identifier that specifies the location of the desired operation. Based upon that information, the handling function either sets a flag to indicate that the functions should be executed locally and returns to the VNA dispatcher, or increments the VNA reentrancy level, performs the specified operation, as more completely described below, clears the flag to indicate that the function should not be executed locally, and returns to the VNA dispatcher.
  • the flag is examined to determine if the function has requested that the VNA dispatcher execute the function locally. If the flag is set, the function is executed as described above when VNA was inactive. If the flag is not set, the VNA dispatcher decrements the reentrancy level and returns to the main dispatcher as described above.
  • the operation of each application layer service for functions 09h and OAh are presented. Some of the services are performed locally and others remotely. As used herein, local refers to the computer that is executing the particular operation and remote refers to other computers that are accessed as a result of the local operation.
  • the application layer function constructs a message that is in turn supplied to the transport layer through a transport function call.
  • the calls to the transport layer are described.
  • the application layer provides the information given in Table 4 and receives the information indicated in Table 4 from the transport layer function.
  • the transport layer functions called are described more completely below after the description of the application layer functions.
  • the transport layer functions in turn call datalink functions that are described after the transport layer functions.
  • the application layer message structure (Fig. 6) is identical for both function OAh and function 09h services.
  • Fig. 6 through Fig. 28B the first byte in each row of a message is identified at the left of the row. Also, either the value or a descriptor of the value or values is given in each byte of these Figures.
  • Each message 160-M consists of an eight byte header 160-MH and a data region 160-MD. The portion of the message after the header is collectively the data region, but in most case the data region contains several bytes of information that characterize the data and then the actual data. Thus, the data region is a storage area in the message for information that is transmitted over the virtual network.
  • the message may include up to 64 KBytes of information including the eight byte header.
  • the eight byte header of the message constructed by application layer 160, 260 has a fixed structure.
  • the first three bytes, bytes OOh to 02h, of the application layer header are used identify the source of the message.
  • "VNA" indicates that the message was generated by application layer 160 (Fig. 5) of virtual network executive 102.
  • the fourth byte is a space, which may be considered part of the source identification.
  • the space is represented by the ASCII code for a space, "20h”.
  • the fifth byte is used to indicate whether the message packet is an operation message packet or a reply message packet, i.e., the direction of the transmission. If the fifth byte is OOh, the message packet is an operation message packet.
  • the message packet is a reply message packet.
  • the sixth byte is used to identify the service generating the message.
  • the sixth byte represents the command specified by the user application. For example, for function 09h services, the sixth byte corresponds to the hexadecimal representation of the service given in Table 3.
  • the seventh and eighth bytes of the message packet are the session identification (SID) , which is described more completely below.
  • the remainder of the message provides information that is specific to the function being processed. Generally, in the operation packet the remainder of the information contains data provided by the user application. In the reply packet, the remainder of the message corresponds to the information and/or operations specified in the transmission message, and is usually provided by the application layer to the user application.
  • Function OAh service CONNECT attempts to establish a session with the remote node specified in register BX.
  • a node refers to one of the individual computers connected to the virtual network.
  • application layer 160, 260 and transport layer 170, 270 support multiple server computers so that virtual computer 300 would include first computer 100 and a plurality of server computers.
  • LISTEN in response to a CONNECT, returns a session identification (SID) .
  • CONNECT message 160-C supplied to transport layer 170, 270 by application layer 160, 260 is illustrated in Fig. 7A.
  • the node identification and the session identification are identical.
  • a node identification is used to uniquely identify each computer in a single virtual computer.
  • the SID is used to identify tasks that are performed over the virtual network so as to prevent contentions or confusion between tasks.
  • a user application could request information from a server computer and this request would have a SID of 1. Subsequently, the user application could request other information before the information associated with SID 1 is provided by the server computer. Thus, the second information request is SID 2.
  • the user application can identify the information being provided by the server computer through the SID.
  • a SID could be associated with each task.
  • the use of multiple SIDS requires further development of the datalink layer described below.
  • CONNECT message 160-C (Fig. 7A) illustrates the general message architecture according to the principles of this invention.
  • the fifth byte is set to "FFh”. Since the SID is generated by LISTEN in response to CONNECT, the seventh and eighth bytes in CONNECT message 160-C are OOh to show that an SID is not yet established.
  • CONNECT message 160-C is 16 bytes in length.
  • the ninth and tenth bytes contain the maximum working buffer size for data transmission.
  • the eleventh and twelfth bytes are used as a first identification field and the thirteenth and fourteenth bytes as a second identification field.
  • the virtual network architecture is included in a low power portable computer which includes a global interrupt 66h handler that processes all interrupt 66h calls and subsequently passes the interrupt 66h calls to the appropriate handlers such as virtual network executive 102 (Fig. 5) .
  • the first identification field is used to identify the version of the global interrupt 66h handler
  • the second identification field is used to identify the version of virtual network executive 102.
  • the fifteenth and sixteenth bytes in CONNECT message 160-C (Fig 7A) contain the message dialect.
  • the message dialect is a version number for the message structure used in the application layer messages.
  • the set of message structures illustrated in Figs. 7A to 28B are considered message dialect 0.
  • the message dialect for the new set of message structures would be, for example, 1.
  • user application 101 passes application layer CONNECT service (i) the node ID for the computer to which the connection is to be made; (ii) the transmission speed; (iii) a timeout value which is the time period, typically one second, to wait for a response from the remote node; and (iv) the serial port for the connection.
  • the handling function for service CONNECT calls application layer function VCONNECT and passes this information to function VCONNECT.
  • function VCONNECT Upon entry, function VCONNECT first determines whether virtual network executive is active. An error is returned to the user application if virtual network executive is not active.
  • function VCONNECT calls transport layer function TCONNECT, described more completely below.
  • Function VCONNECT passes the node ID, speed, timeout and port information received from the user application to function TCONNECT. If function TCONNECT operates successfully, function VCONNECT receives as a return value the SID. In this embodiment, for the SID to be valid the SID must be greater than zero and must be less than a predetermined maximum value. The actual return values used are arbitrary. The important aspect is that successful return values are differentiated from error return values.
  • function VCONNECT builds the message header, described above, in the local message buffer that was passed to function VRESET, which is described more completely below.
  • the function when a function builds the message header, the function also initializes the data region of the message in the local buffer.
  • the buffer size in the message (bytes 08h and 09h in Fig. 7A) is set to the local message buffer size which is defined by function VRESET, described more completely below.
  • the identification bytes are set to the local version identifiers where local means the versions being used in the computer initiating the CONNECT.
  • function VCONNECT calls the transport layer function TSEND to send the message. Function TSEND is described more completely below with respect to Fig. 32.
  • function VCONNECT calls function TDISCONNECT in the transport layer which in turn disconnects the local machine from the remote machine. Function VCONNECT returns the return value from function TSEND to application program 101. Conversely, when function TSEND is successful, function VCONNECT calls transport layer function TRECEIVE with the current SID, the length of the receive buffer, a pointer to the receive buffer and a timeout value. If TRECEIVE returns an error, function VCONNECT calls function TDISCONNECT and then returns the error to application program 101.
  • function VCONNECT selects the lesser of the local buffer size and the remote buffer size and sets the work buffer size to the selected value.
  • references to the local message buffer refer to the region in the work buffer that is used to construction the application layer messages.
  • Function VCONNECT also parses message 160-L, described more completely below and saves the information in the remainder of the reply message. Function VCONNECT returns the SID and the total number of remote drives to user application 101.
  • LISTEN waits for a CONNECT request to arrive signaling the start of a virtual computer session.
  • a SID(bytes 06h and 07h in Fig. 7B) and a disk drive count(bytes OAh and OBh) are returned by LISTEN for the node which responds to CONNECT.
  • the drive count indicates which local drives are available for use by the remote node issuing the CONNECT.
  • the disk drive count identifies the number of information storage drives which may be accessed using operating system disk drive services.
  • RECEIVE which is described below.
  • the SID is used in all subsequent operations to identify the session.
  • Message 160-L which is generated by LISTEN in response to a CONNECT is illustrated in Fig. 7B.
  • the first eight bytes are identical to the CONNECT message in Fig. 7A except the fifth byte is changed to Olh to indicate that the message is a reply message.
  • Bytes 08h and 09h are the local message buffer size.
  • Bytes OCh and ODh are the two identifiers for the local global interrupt 66h handler and the virtual network executive.
  • Bytes lOh and llh are the server type.
  • a first server type is associated with LISTEN and a second server type is associated with SERVE, which is described more completely below. The server type corresponds to the two possible modes of operation described previously.
  • Bytes 12h and 13h represent the message dialect of the local virtual network executive.
  • function VLISTEN When the user application calls service LISTEN, the handling function for LISTEN in turn calls function VLISTEN. The communication speed, the timeout value, and the port are passed to function VLISTEN.
  • function VLISTEN Upon entry, function VLISTEN first determines whether the virtual network executive is active. An error is returned to the user application if the network executive is not active. If the network executive is active, function VLISTEN calls transport layer function TLISTEN, described more completely below, to wait for a connect request. If function TLISTEN returns an error, the error is returned to the user application.
  • the SID is set to the SID value that is returned to the remote node.
  • the receive message buffer is set to point to the local message buffer and transport function TRECEIVE is called to receive the incoming connect message. If the length of the received message is zero or byte six of the message is not set to -1, function TDISCONNECT is called and the length of the received message is returned to the calling user application.
  • the work buffer size is set to the buffer size in the received message. Otherwise, the work buffer size is set to the local buffer size.
  • the selected buffer size in placed in the reply message.
  • the global interrupt 66h handler and the virtual network executive identifiers are also placed in the local message, and the identifiers in the CONNECT message are saved.
  • the other information in reply message 160-L is placed in the local message buffer.
  • Transport layer function TSEND is called to send the reply message. If function TSEND returns an error, function TDISCONNECT is called and the result of TDISCONNECT returned to the user application.
  • DISCONNECT If function TSEND is successful, the SID is returned to the calling user application.
  • the handling function for service DISCONNECT calls function VDISCONNECT in response to a call from a user application.
  • Function VDISCONNECT may also be called another application layer service to close a session with a remote node.
  • An error code is returned indicating success or failure of the function.
  • Any aliased drives, as defined below in service MAP, are invalidated and services that reference a previously aliased drive return an invalid drive error.
  • DISCONNECT message 160-DC is illustrated in Fig. 8. The first eight bytes have the general structure described above with the sixth byte being set to "FEh" to indicate DISCONNECT.
  • the 08h and 09h bytes contain an arbitrary parameter that is not used at this time.
  • Function VDISCONNECT is passed the SID to be disconnected.
  • Function VDISCONNECT first determines whether the network executive is active. An error is returned to the user application if the network executive is not active.
  • each of the active files that the server has open are closed.
  • the DISCONNECT message is built in the local buffer and transport function TSEND called to send the message to the server.
  • the server status is set inactive and each drive associated with the SID being closed is removed from the drive mapping table by marking the drive with a minus one in this embodiment.
  • the drive mapping table is described more completely below with respect to service MAP.
  • the SID is reset to zero and transport function TDISCONNECT called.
  • the result from function TDISCONNECT is returned to the calling user application or the calling function.
  • OAh service SEND is used to send a user application specific message to the remote node where an outstanding receive is active. SEND returns zero to the user application indicating that the message was successfully sent. A negative error is returned if the message can not be sent. SEND generates the message structure 160-S (Fig. 9A) that is described more completely below. RECEIVE is used to wait for a message to be received. Upon receipt of a message RECEIVE returns the actual length of the message to the calling service.
  • SEND creates generic message 160-S illustrated in Fig. 9A and RECEIVE creates generic reply message 160-R illustrated in Fig. 9B.
  • Both messages use the general structure described above for the first eight bytes of the message with the sixth byte being set to "FCh" to indicate a generic message.
  • Bytes 08h and 09h indicate the length of the data region of the message that starts in byte OAh.
  • User application 101 calls service SEND and the handling function for SEND calls function VSEND with a SID, a message length and a pointer to a message buffer.
  • function VSEND first determines whether the network executive is active. An error is returned to the user application if the virtual network executive is not active.
  • function VSEND builds generic message 160-S, illustrated in Fig. 9A.
  • the maximum message size is the size of the local message buffer size minus the two bytes used for data length in the message and the eight byte header. If the passed message length supplied to SEND by user application 101 is greater than the local message buffer size, the message length is set to the local message buffer size and the length in bytes 08h and 09h is set to the local message buffer size also.
  • a user application also calls service RECEIVE and the handling function for RECEIVE calls function VRECEIVE with a SID, a message length a timeout value, and a pointer to a message buffer.
  • function VRECEIVE first determines whether the virtual network executive is active. An error is returned to the user application if the virtual network executive is not active.
  • function VSEND calls transport function TRECEIVE to receive a generic message in the local message buffer. If TRECEIVE receives a message having a length greater than zero in bytes 08h and 09h, the length in these bytes is saved. If the saved length is greater than the local buffer size, the saved length is set to the local buffer size. The message is copied from the local message buffer to the message buffer passed in the call to function
  • VRECEIVE Function VRECEIVE returns the length of the receive message to the calling user application.
  • STATUS is used to obtain information about the virtual network.
  • the status information is placed in a buffer supplied by the user application.
  • Structure 160- STATUS of the buffer is illustrated in Fig. 29.
  • the SID count field (Fig. 29 bytes 02h and 03h) indicates the number of sessions currently active and described in the supplied buffer. Following the SID count field is a 18h byte session status descripter which is repeated in the buffer SID count times. In one embodiment, SID count is always one.
  • the session status descripter includes SID (bytes 04h and 05h ) , remote node ID (bytes 06h and 07h) , bytes sent (bytes 08h to OBh) , bytes received (bytes OCh to OFh) , send errors (bytes lOh and llh) , receive errors (bytes 12h and 13h) , speed of transmission (bytes 14h and 15h) , and the identification information, (bytes 16h to 19h) which was described above with respect to CONNECT.
  • STATUS can be called from a hook, i.e., a section of software that is passed to SERVE by a pointer in the call to SERVE.
  • User application program 101 calls STATUS with the SID, the length of the status buffer, and a pointer to the status buffer. Subsequently, the STATUS handling function calls function VSTATUS which in turn calls transport layer function TSTATUS, which is described more completely below, with the parameters defined in Table 4. Function TSTATUS gets the virtual network status. If TSTATUS returns an error code, the error code is returned to the user application program. However, if an error code is not detected, the global interrupt 66h handler and the virtual network executive version numbers of each active session are set to the version number of the remote global interrupt 66h handler and the remote the network executive version numbers respectively. The message dialect is set to zero. Finally, a successful return code is supplied to the user application program 101.
  • Virtual network executive 102 is enabled by user application 101 passing service RESET a valid buffer pointer and a valid buffer length. Virtual network executive 102 is deactivated by calling service RESET with either a null pointer and/or an invalid buffer length (preferably zero) .
  • VRESET The length and the buffer pointer are passed to function VRESET. Initially, function VRESET sets the virtual network status, the server status, and the SID to zero.
  • the passed length and the buffer pointer are both zero, success is returned to the calling program if the virtual network termination offset and termination segment are zero. However, if the virtual network termination offset and segment are non-zero, the program segment prefix(PSP) address is obtained. If the PSP address is not zero, the PSP pointer in the passed buffer is set to the PSP termination address and the termination offset and segment are set to zero. Success is then returned to the user application. Success is also returned if the PSP address is zero.
  • a buffer length error is returned to the calling user application. If the passed buffer pointer is zero, and the passed buffer size is non-zero and greater than the predetermined minimum size, a buffer pointer error is returned.
  • the local buffer size and the beginning location of the local buffer are set.
  • the current drive, the default drive and the total number of locally available drives are obtained.
  • the drive mapping table is initialized.
  • the default disk transfer area(DTA) and the number of disks are obtained, and the current DTA is set to the default DTA.
  • the version numbers for the local global interrupt 66h handler and the virtual network executive are obtained.
  • Transport layer function TRESET is called to reset the transport layer.
  • function TRESET returns success, the PSP address is obtained. If the PSP address is non-zero, the PSP pointer in the passed buffer is set to point to the PSP terminate address. If the PSP pointer is not equal to the first PSP, the terminate offset and segment are reset to zero and the PSP pointer is set to the first PSP. Next, the virtual network executive status is set to active and the result from function TRESET is returned to the calling user application.
  • Function OAh service MAP is used to (i) alias a local drive to a remote drive once a session is activated by service RESET, (ii) disassociate a remote drive from its alias, or (iii) to interrogate the virtual network executive for the current mapping status. Once a drive is aliased, all references to the aliased drive are redirected over the virtual network, as described more completely below.
  • MAP service message 160-MAP is illustrated in Fig. 10A.
  • the first eight bytes have the general header structure described above with the sixth byte being set to "FDh" to indicate a MAP.
  • the 08h and 09h bytes indicate the remote drive that is aliased.
  • the reply message 160-RMAP is illustrated in Fig. 10B and is identical to MAP message except the fifth byte indicates a reply message and bytes 08h and 09h contain an error code.
  • the assignment of a local drive alias to a remote drive is arbitrary.
  • Service MAP maintains a drive mapping table.
  • the zeroth element in the drive mapping table is the entry associated with local drive A.
  • Information concerning virtual drive Q is entry 16 in the drive mapping table. Entry 16 would indicate the remote drive number that Q is aliased to, and the SID for that alias.
  • service MAP To alias a drive, user application 101 calls service MAP with a SID, local drive identifier, a remote drive identifier, and an alias parameter.
  • the twenty-six word array passed by the user application is returned as a user drive mapping table.
  • the user drive mapping table is a subset of the drive mapping table. Each element in the table has no SID value, and drives mapped by other sessions (as indicated by the SID) are shown as not mapped.
  • the MAP service handling function passes these parameters to function VMAP. Function VMAP first determines whether the network executive is active. An error is returned to the user application if the network executive is not active.
  • function VMAP determines whether the passed alias parameter is zero.
  • the drive identifier associated with the aliased local drive in the drive mapping table is set to a value, for example -1, that indicates that the aliased local drive has been removed.
  • a success condition is returned to user application 101.
  • map message header is constructed in the local message buffer.
  • Bytes 08h and 09h of the message are set to the remote drive identifier passed in the call to function VMAP.
  • function VMAP calls transport layer function TSEND to send the message.
  • function VMAP calls transport layer function TDISCONNECT to terminate the session. Otherwise, function VMAP calls transport function TRECEIVE to receive reply message 160- RMAP (Fig. 10B) that contains the mapped drive letter. If TRECEIVE does not return an error code and the returned drive does not indicate that the remote drive is unavailable, the aliased drive in the drive mapping table is set to the remote drive and the SID indicator to the SID. A success code is then returned to the user application.
  • function VMAP calls transport layer function TDISCONNECT to terminate the session.
  • Function OAh service SERVE is called by a user application to configure the computer (node) as a server.
  • Service SERVE is actually a higher level service than the other services described above because when service SERVE is successfully implemented in a node, the service responds to the application layer commands from the remote computer that controls the virtual computer. Thus, the basic features of service SERVE are described here and then after the description of the application layer function 09h services, service SERVE is described more completely.
  • Service SERVE calls function VLISTEN to wait for a CONNECT message 160-C (Fig. 7A) from a remote machine and calls function VDISCONNECT at the request of that remote machine.
  • User application 201 (Fig. 5) passes SERVE the address of a callout structure 160-CSTRUCT (Fig.
  • callout structure 160-CSTRUCT The format of callout structure 160-CSTRUCT is illustrated in Fig. 30.
  • the Generic Message Handler is called by the server whenever SERVE receives a generic message.
  • the Status Event Handler is called by the server when a request is received from a remote machine and again before a reply to the request is sent.
  • the Generic Message Handler is called, as described below, with the length of the message data in register CX, the size of the message data buffer in register BX and the address of the message data in register DX:AX.
  • the Generic Message Handler services the request, updates the message buffer with new data and returns the length of the updated message buffer or an error code in register AX. If register AX is zero, then no reply message is sent. If register AX is -1, the Server does not send a reply and calls function VDISCONNECT.
  • the Status Event Handler is called with address of the Status Event structure in register DX:AX.
  • Status Event structure 160-STATSTRUCT contains a current status structure (See Fig. 31) followed by the far address of the current message.
  • the Status Event Handler is called every time the server receives a message other than a generic send message (Fig. 9A) and again just prior to the server sending a reply message other than a generic reply message (Fig. 9B) .
  • the Generic Message Handler and the Status Event Handler are allowed to use the services of virtual network executive 202 as long as the request does not require communication with a remote node.
  • the User Terminate Handler is used by the user application program to signal the Server to terminate
  • the server calls the User Terminate Handler after a remote function request is serviced and at a predetermined time interval, e.g.. every 15 seconds, in one embodiment, while waiting to receive a remote function request.
  • the User Terminate Handler returns a zero in register AX indicating that the server should not terminate. A one returned in register AX signals the server to terminate.
  • the handling function for select disk service OEh of function 09h calls function SELDSK with the SID, the specified drive, and a pointer to the local message buffer. Initially, function SELDSK sets up the eight byte header for message 160-SDSK, as shown in Fig. 11A. Bytes 08h and 09h of the message are then set to the drive passed in the call to function SELDSK. Function SELDSK calls transport layer function TSEND to transport the message across the virtual network to the node indicated by the SID.
  • select disk message 160-SDSK (Fig. 11A) is transmitted successfully by function TSEND, function SELDSK calls transport layer function TRECEIVE to receive reply message 160-RSDSK.
  • the response to select disk message 160-SDSK is illustrated in Fig. 11B.
  • the generation of the select disk reply message is described below in the discussion of the server function operation.
  • function SELDSK gets the returned drive letter from bytes 08h and 09h of reply message 160-RSDSK. The returned drive letter is set in the register AX and processing returned to user application as described above.
  • function FREESPACE The handling function for get free disk space service 36h of function 09h calls function FREESPACE with the SID, the specified drive, and a pointer to the local message buffer.
  • the operation of function FREESPACE is nearly identical with that described above for function SELDSK.
  • Message 160-FS in Fig. 12A is constructed in the local message buffer and transport layer functions TSEND and TRECEIVE used as previously described.
  • Reply message 160-RFS (Fig. 12B) received by function TRECEIVE has the number of sectors per cluster in bytes 08h and
  • Function FREESPACE enters these four values in registers AX through DX respectively.
  • the error handling and return are as described in function SELDSK.
  • the handling functions for function 09h make directory service 39h, remove directory service 3Ah, change directory service 3Bh, and delete file service 41h all call function DIRFUNCS.
  • Each service provides function DIRFUNCS with the SID, the service identification, the drive, a pointer to the path for the service, and a pointer to the local message buffer.
  • the messages for service 39h. (Fig. 13A) , for service 3Ah (Fig. 14A) , for service 3Bh (Fig. 15A) , and for service delete file 41h (Fig. 16A) have the same basic structure. The only difference is the service identification in byte six. Similarly, the reply messages. Fig. 13B, Fig. 14B, Fig. 15B, and Fig. 16B respectively also have the same structure.
  • function DIRFUNCS first creates in the local message buffer the message header using the information passed to the function. After the message header is created, the path name prepended with a drive letter and a colon is copied into the local message buffer. The drive letter is determined by the drive identifier passed to function DIRFUNCS.
  • transport layer function TSEND is used to send the message over the virtual network and transport function TRECEIVE to receive the reply message from the server indicated by SID. If function TSEND and function TRECEIVE are successful, register AX is set to length of the reply message which is given by result in bytes OAh and OBh in the reply message. If the error code in bytes 08h and 09h of the reply message indicate an error, the carry flag is set. If function TSEND or function TRECEIVE generates an error, the carry flag is set and register AX set to operating system network error code. Processing returns to the user application as described above.
  • Messages 160-CF, 160-OF for service create file 3Ch and service open file 3Dh are given in Fig. 17A and Fig. 18A, respectively and associated reply messages 160-RCF, 160-ROF are given in Fig. 17B and Fig. 18B, respectively.
  • the structure of these messages are identical, and both services access function CROP.
  • the handling functions for these services pass the SID, the service identifier, the drive identifier, the access attribute of the file, a pointer to the path for the file and a pointer to the local message buffer to function CROP.
  • Function CROP opens or creates a file and provides the user application with a 16 bit integer, called a handle, that is subsequently used to identify the file.
  • function CROP opens a file in a remote node and the operating system in the local node is not aware of this operation. Therefore, the local operating system could create a handle for a local file that would be the same as the handle for a remote file.
  • each time function CROP is called the first operation is to generate another handle using the local operating system so that the local operating system handle count remains consistent with the number of files opened or created.
  • the first operation in function CROP is to use the operating system to locally duplicate the file handle "StdOut" (Standard Output) . This operation assures unique file handles.
  • Function CROP then sets register AX to the handle generated by duplication and checks to determine whether the handle was successfully generated.
  • function CROP If an error occurred, the carry flag is set and function CROP returns control to the user application as described above. After assuring unique handles, function CROP generates in the local message buffer the header for the service identified in the call to function CROP. After the message header is created, the path name prepended with a drive letter and a colon is copied into the local message buffer. The drive letter is determined by the drive identifier passed to function CROP. As previously described, transport layer function TSEND is used to send the message over the virtual network and function TRECEIVE is used to receive the reply message from the server indicated by SID. If function TRECEIVE transmission is successful and bytes 08h and 09h of the reply message do not inidicate an error, register AX is already set to the appropriate handle, as described above. Thus, the table of file handle structures is updated with the current SID and the handle set to the returned value in bytes OAH and OBh of the reply message. (See Figs. 17B and 18B.) Processing returns to the user application as described above
  • register AX is set to the value in bytes OAh and OBh of the reply message and the carry flag is set.
  • the locally duplicated file handle is closed so that the handles remain unique. Processing returns to the user application as described above. However, if function TRECEIVE or function TSEND returns an error code, register AX is set to operating system network error and the carry flag is set. Also, the locally duplicated file handle is closed so that the handles remain unique and processing is returned to the user application as described above.
  • Close file service 3Eh handling function calls function NETCLOSE to close a remote file.
  • Function NETCLOSE is passed a pointer to the local message buffer and the handle of the file to be closed.
  • Function NETCLOSE obtains the SID for the passed handle from the table of handles and then constructs message 160-CFI shown in Fig. 19A in the local message buffer.
  • transport layer function TSEND is used to send the message over the virtual network and function TRECEIVE to receive the reply message from the server indicated by SID.
  • register AX is set to the result received in bytes OAh and OBh of reply message 160-RCFI (Fig. 19B) . If the error code in bytes 08h and 09h of the reply message indicate an error, the carry flag is set and processing returns to the user application as described above. If the error code does not indicate an error, the local file handle in the table of file handle structures is closed. The file handle and the SID in the table of file handles are set to zero. Processing returns to the user application as described above.
  • NETWRITE Write file service 4Oh handling function calls function NETWRITE.
  • Function NETWRITE is passed a handle for the file to be written over, a pointer to the information to be written along with the length of the information, and a pointer to the local message buffer.
  • Message 160-W generated by function NETWRITE is illustrated in Fig. 20A and reply message 160-RW from the server in Fig. 2OB.
  • NETWRITE a compression scheme used in function NETWRITE is considered. Compression of the information written across the virtual network increases the performance of the network.
  • the function NETWRITE could also be used without compression or alternatively with compression schemes other than the one described herein.
  • the information in array of the other messages e.g., the generic send message described above, could also be processed with the following compression scheme.
  • the compressed buffer has the following form:
  • a stream of data with identical adjacent bytes generates a compressed object
  • a stream of data containing non-identical adjacent bytes generates an uncompressed object.
  • a buffer having the following data and assuming Intel byte ordering:
  • the compressed buffer contains:
  • the decompression (expansion) scheme consists of just the inverse operations of the compression scheme, i.e., reading the number of objects and then for each object performing the appropriate operation for the given flag.
  • the handle passed in the call to function NETWRITE is used as an index into the handle table to obtain the SID for the write operation.
  • a pointer called the buffer offset, is used track the portion of data in the information buffer that has been transmitted. Initially, the buffer offset is set to zero so that the pointer is aligned with the start of the data. After each transmission, the buffer offset is incremented by the length of the data region in the local message buffer, sometimes called the buffer length.
  • function NETWRITE compares the local message buffer length with the length of the data remaining to be written in the information buffer. If the length of the remaining data buffer is greater than the local message buffer, length is not changed, but if the length of the remaining data is less than the local message buffer length, length is set to the length of the remaining data.
  • the eight byte header for write message 160-W is generated in the local message buffer.
  • the file handle passed is placed in bytes 08h and 09h and then the data being transmitted is compressed, as described above.
  • the length of the compressed data is placed in bytes OAh and OBh of the message and the compressed data follows starting in byte OCh.
  • Transport function TSEND is used to transmit the message to the remote node, and if function TSEND is successful, transport function TRECEIVE is called.
  • register AX is set to the result in bytes OAh and OBh of the reply message. If bytes 08h and 09h of the reply message indicate an error occurred, the carry flag is set and processing returns to the user application as described above. If no error occurred, the value of the result is compared with the buffer length. If the result is less than the buffer length, the remote device is full because the operating system, when a full device is encountered, terminates writing, but does not generate an error message. When such an error occurs and the buffer length is greater than the result, the result is added to the current value of the buffer offset. The sum is placed in register AX and processing returned to the user application as described above.
  • the user application can compare the returned length with the length of the information to ascertain that an error occurred. If the buffer length and the result in the reply message are the same, the buffer offset is incremented by adding the buffer length to the buffer offset and the transmission process repeated until the buffer offset equals the information length. When the buffer offset equals the information length, the buffer offset is placed in register AX and processing returned to the user application as described above.
  • function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and the error code operating system network error is placed in register AX. Processing is returned to the user application as described above.
  • Read file service 3Fh handling function calls function NETREAD.
  • Function NETREAD which functions similarly to NETWRITE is passed a handle for the file to be read, a pointer to the buffer where the information read is to be placed along with the length of the buffer, and a pointer to the local message buffer.
  • Message 160-READ which is generated by NETREAD, is illustrated in Fig. 21A and reply message 160-RREAD from the server in Fig. 21B.
  • the handle passed in the call to function NETREAD is used as an index into the handle table to obtain the SID for the read operation.
  • a pointer called the buffer offset
  • the buffer offset is used track the portion of buffer for the read information that is filled. Initially, the buffer offset is set to zero so that the pointer is aligned with the start of the data. After each transmission, the buffer offset is incremented by the length of the data region in the local message buffer, sometimes called the buffer length.
  • the eight byte header for read message 160-READ is generated in the local message buffer.
  • the file handle passed is placed in bytes 08h and 09h and the length of the data to be read is placed in bytes OAh and OBh of the message.
  • Transport function TSEND is used to transmit the message to the remote node. A flag indicating that more data is to be read is set. If function TSEND is successful, transport function TRECEIVE is called.
  • function TRECEIVE successfully receives the reply message shown in Fig. 2IB, and if bytes 08h and 09h of the reply message do not indicate that an error occurred, the data in the reply message is decompressed into the information buffer. Subsequently, the buffer offset is set to the length of the decompressed data. The more flag in bytes OCh and ODh of the reply message are next examined to ascertain whether more data will be sent from the remote node. If the more flag is set, processing branches back to the call to transport function TRECEIVE. If the more flag is not set, all the data has been received and register AX is set to the buffer offset which is the length of the data read. Processing is returned to the user application as previously described.
  • function TRECEIVE If function TRECEIVE generates an error, the receive is retried. However, if an error occurred as indicated in the reply message, register AX is set to the length received as indicated in bytes OAh and OBh of the reply message, which in this case is an error code generated by the operating system in the remote node. The carry flag is set and processing returned to the user application as previously described. Similarly, if function TSEND fails to successfully send the message, the carry flag is set and the error code operating system network error is placed in register AX. Processing is returned to the user application as described above.
  • Lseek service 42h handling function calls function NETLSEEK.
  • Function NETLSEEK is passed the handle of the file being accessed, an offset value, a relation indicator that represents the seek mode, and a pointer to the local message buffer.
  • the handle passed in the call to function NETLSEEK is used as an index into the handle table to obtain the SID for the seek operation.
  • the eight byte message header for message 160-SEEK (Fig. 22A) is created in the local message buffer.
  • the passed handle is placed in bytes 08h and 09h of the message buffer, the passed file offset in bytes OAh through ODh, and the passed relation in bytes OEh and OFh.
  • message 160-SEEK as shown in Fig. 22A, has been created.
  • Transport function TSEND is called to transmit message 160-SEEK to the server node. If function TSEND is successful, transport function TRECEIVE is called to receive reply message 160-RSEEK (Fig. 22B) from the server node. If transport function TRECEIVE is successful and the error code in the reply message(bytes 08h and 09h) indicates an error, register AX is set to the extended error returned in bytes OAh and OBh of the reply message and the carry flag is set. Processing is returned to the user application as described above. However, if an error was not generated by the seek operation, register AX is set to bytes OCh and ODh of reply message 160-RSEEK and register DX is set to bytes OEh and OFh of the reply message.
  • NETCHMOD Service Chmod 43h is used to either set or get the attribute of a remote file.
  • function NETCHMOD is passed the SID, the attribute, a flag that indicates whether to get the file attribute or set the file attribute, a remote drive indicator, the path for the file and a pointer to the local message buffer.
  • function NETCHMOD builds message 160-CHMOD shown in Fig. 23A in the local message buffer.
  • the SID, the attribute, function code(the passed flag) , and the path length are place in bytes 08h and 09h, OAh and OBh, OCh and ODh respectively.
  • the path is copied to the local message buffer and prepended with a drive letter, based upon the passed drive indicator, and a colon.
  • Transport function TSEND is used to send the completed message to the remote server node. If function TSEND is successful, transport function TRECEIVE is called to receive reply message from the remote server node. If function TRECEIVE successfully received the reply message illustrated in Fig.
  • register AX is set to the value in bytes OAh and OBh of the reply message. If the operation in the remote node was successful, these bytes contain the attribute. Otherwise, the bytes contain an error code. If the error code bytes in the reply message, bytes 08h and 09h indicate an error, the carry flag is set and processing returns to the user application as described above. Conversely, if these bytes indicate no error, register CX is set to the value of register AX and processing returns to the user application as described above. If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
  • Get current directory service 47h of function 09h is used to obtain the current directory for a specified path on a remote drive.
  • current directory service handling function calls function NETGETDIR
  • the SID, the remote drive indicator, the path on the remote drive, and a pointer to the local message buffer are passed to function NETGETDIR.
  • function NETGETDIR uses the passed information, function NETGETDIR generates the header for message 160- GDIR, illustrated in Fig. 24A, in the local message buffer.
  • Bytes 08h and 09h in the message are set to the passed remote drive indicator.
  • the return pointer is initialized to the location OEh in the reply buffer.
  • Function NETGETDIR then calls transport layer function TSEND to transmit the message to the server node.
  • function NETGETDIR calls transport function TRECEIVE.
  • register AX is set to the extended error code in bytes OA and OBh. If the error code bytes in the reply message, bytes 08h and 09h indicate an error, the carry flag is se and processing returns to the user application as described above. Conversely, if these bytes indicate no error, the path name in the reply message is copied to th path name passed in the call to function NETGETDIR and processing returns to the user application as described above. If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
  • Terminate session service 4Ch is processed locally so that a message structure is not needed.
  • Terminate session service handling function calls function NETTERMINATE which in turn calls function VDISCONNECT, described above, if this is an active connection with a remote node.
  • the virtual network executive is identified as inactive and processing returned to the operating system.
  • Find first service 4Eh finds the first file matching a particular file specification. This service uses a structure defined by the operating system as the disk transfer area (DTA) . Therefore, to assure proper functioning of this service in all computers, prior to initiating the network executive for the first time, a local interrupt 21h find first service should be performed. This operation effectively initializes the DTA so that it is available.
  • DTA disk transfer area
  • the handling function for find first service calls function NETFINDFIRST.
  • SID a file attribute, a remote drive indicator, a path and a pointer to the local message buffer are passed to function NETFINDFIRST.
  • Function NETFINDFIRST builds the standard eight byte header in message 160-FF, as illustrated in Fig. 25A, for the find first service in a manner similar to that previously described for other function 09h services.
  • the path name prepended with a drive letter and a colon is copied into the local message buffer.
  • the drive letter is determined by the drive identifier passed to function NETFINDFIRST.
  • the file attribute passed to function NETFINDFIRST is placed in bytes 08h and 09h of the local message buffer and the path length in bytes OAh and OBh.
  • TSEND is used to send the message over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message
  • register AX is set to the extended error code in bytes OAh and OBh of reply message 160-RFF (Fig. 25B) . If the error code bytes in the reply message, bytes 08h and 09h, indicate an error, the carry flag is set and processing returns to the user application as described above. Conversely, if these bytes indicate no error, the 2Bh byte result in the reply message is copied to the current DTA, and processing returns to the user application as described above.
  • function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
  • Find next service 4Fh finds the next file matching a particular file specification. This service is typically used after find first service 4Eh. Thus, the search process has already been initialized. Consequently, when the handling function for find next service calls function NETFINDNEXT only the SID and a pointer to the local message buffer are passed the function. Function NETFINDNEXT also builds the standard eight byte header in message structure 160-FN, as illustrated in Fig. 26A, for the find next service in a manner similar to that previously described for other function 09h services. After the message header is created, a copy of the DTA that was returned by the find first service is copied into the data area of the message. The remaining operations after construction of the message are identical to those described above for function NETFINDFIRST after the generation of the message, which are incorporated herein by reference. Rename service 56h renames a file on a remote drive.
  • the handling function for rename service calls function NETRENAME.
  • SID a remote drive indentifier for the file to be renamed
  • path for the file to be renamed a remote drive indentifier for the renamed file
  • a pointer to the local message buffer are passed to function NETRENAME.
  • Function NETRENAME builds the standard eight byte header in message 160-REN, as illustrated in Fig. 27A, for the rename service in a manner similar to that previously described for other function 09h services.
  • the path name for the file to be renamed is prepended with a drive letter and a colon is copied into the local message buffer.
  • the path name is terminated with a zero.
  • the drive letter is determined by the drive identifier for the file to be renamed that is passed to function NETRENAME. The length of this path name is placed in bytes 08h and 09h of the local message buffer.
  • the path name for the renamed file is prepended with a drive letter and a colon is copied into the local message buffer after the first path.
  • the path name is terminated with a zero.
  • the drive letter is determined by the drive identifier for the renamed file that is passed to function NETRENAME. The length of this path name is placed in bytes OAh and OBh of the local message buffer.
  • function TSEND is used to send message 160-REN over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message 160-RREN (Fig. 27B) from the server node indicated by SID. If function TRECEIVE successfully receives message
  • register AX is set to the result in bytes OAh and OBh of reply message 160-RREN and processin returns to the user application as described above. If the error code bytes in the reply message, bytes 08h and 09h, indicate an error, register AX is set to the result in bytes OAh and OBh of the reply message (Fig. 27B) . Th carry flag is set and processing returns to the user application as described above.
  • function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
  • Function 09h get/set file's date and time 57h is used to either get the date and time for a remote file or set the date and time for a remote file.
  • the handling function for service 57h calls function NETDATETIME.
  • the file handle, a function indicator to distinguish between the get and the set operation, the date and the time for a set operation, and a pointer to the local message buffer are passed to function NETDATETIME by the handling function.
  • Function NETDATETIME builds the standard eight byte header of message 160-GT, as illustrated in Fig. 28A, for service 57h in a manner similar to that previously described for other function 09h services.
  • the SID is obtained from the file handle table using the passed handle.
  • the handle is placed in bytes 08h and 09h, the function indicator in bytes OAh and OBh, the time in bytes OCh and ODh, and the date in bytes OEh and OFh.
  • function TSEND is used to send the message over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message 160-RGT (Fig. 28B) from the server node indicated by SID.
  • register AX is set to zero.
  • Register DX is set to the date in bytes OCh and ODh of the reply message.
  • Register CX is set to the time in bytes OAh and OBh of the reply message and processing returns to the user application as described above.
  • register AX is set to the result in bytes OAh and OBh of the reply message (Fig.
  • the carry flag is set and processing returns to the user application as described above.
  • function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
  • OAh SERVE service handling function calls application layer function VSERVE.
  • the handling function passes a speed for communication with the server node, a timeout value that indicates the time interval to wait for a response from a remote node, a port to use in establishment of the virtual network, the data segment register value, the extra segment register value and a pointer to the callout structure, described above, that contains the addresses of the Generic Message Handler, the Status Event Handler, and the User Terminate Handle.
  • a byte map 160-CSTRUCT for the callout structure is given in Fig. 30.
  • Function VSERVE first ascertains whether the network executive is active. If the network executive is not active, a flag is returned to the user application indicating that the network executive is not active. After checking whether the network executive is active, the server status is set to active and function VLISTEN, described above, is called to poll for a connect request from a remote node. Upon receipt of a connect, function VLISTEN provides an SID and function VSERVE sets SID equal to the value provided by function VLISTEN. If the SID is not greater than zero, the server status is se to inactive and the SID is returned to the user application.
  • function VSERVE If the SID is greater than zero, function VSERVE first sets up a critical error handler intercept.
  • the critical error handler fails the function in manner known to those skilled in the art. For example, see R. Duncan (Editor) , The MS-DOS Encyclopedia. Microsoft Press, Redmond, Washington pp. 390-398, (1988).
  • function SERVERMAIN is the function dispatcher for the server, i.e., this function receives the message from the first computer, a remote node, performs the operation specified in the message locally, and constructs and dispatches a reply message to the remote node.
  • function SERVERMAIN generates each of the reply messages described above for function 09h and function OAh services when function VSERVE is called by user application 201.
  • the current DTA is obtained and associated with a variable, i.e., the variable is held with that address.
  • the callout table is defined and the callout table has a defined Status Event Handler, in this embodiment, a non-null entry, the event callout is set to the address of the Status Event Handler in the callout table.
  • the event callout register DS is set to the passed data segment register value and event callout register ES is set to the passed extra segment value.
  • the byte structure in one embodiment of the Status Event Handler is illustrated in Fig. 31.
  • Function SERVERMAIN next ascertains whether the User Terminate Handler in the callout table (Fig. 30) is defined. If the User Terminate Handler is defined, function SERVERMAIN calls the User Terminate Handler, which was described above. If the User Terminate Handler returns a zero, processing continues as described below. If a nonzero value is returned, a user termination flag is set and processing transfers to the server error exit. The server error exit performs the clean-up operations necessary to close the server and calls transport layer function TDISCONNECT. Upon completion of function TDISCONNECT, the error is returned to the user application.
  • function SERVERMAIN calls transport layer function TRECEIVE. If function TRECEIVE generates a timeout error, function SERVERMAIN returns processing to the step that determines if the User Terminate Handler is defined. If function TRECEIVE generates any other error, processing transfers to the server error exit described above. If function TRECEIVE successfully receives a message, the first four bytes of the message are checked to ascertain whether the identifier indicates that the message was sent by the virtual network executive. If the proper identifier is not detected, processing transfers back to the step that determines if the User Terminate Handler is defined. Otherwise, function SERVERMAIN calls application layer function VSTATUS, described above.
  • the stored message length is set to zero. If the Generic Message Handler is defined in the callout structure, function SERVERMAIN calls the Generic Message Handler providing the length of the message data in register CX, the size of the local message buffer in register BX and the address of the message data in register pair DX:AX. The Generic Message Handler services the request, updates the local message buffer with new data and returns the length of the updated message buffer or an error code in register AX.
  • the actual operation or operations performed by the Generic Message Handler are defined by the user application, because the user application must provide the Generic Message Handler. However, the Generic Message Handler must parse the message in Fig. 9A and generate information for the message in Fig. 9B.
  • the length returned by the Generic Message Handler is stored for further processing as described below. If the length is greater than zero, the eight byte generic reply message header (Fig. 9B) is constructed in the local message buffer and the length of the message is put in bytes 08h and 09h of the generic reply message. The stored length is updated to the length of the message.
  • function SERVERMAIN again calls the Status Event Handler, if the handler is defined.
  • transport layer function TSEND is called to send the reply message to the remote node. If function TSEND returns an error, processing transfers to the server exit error, described above.
  • Each of the function 09h functions (Table 3) has a counterpart that is called by SERVERMAIN.
  • each of these functions parses the message sent, uses the information in the message to set registers to the appropriate values, and issues an interrupt 21h to the local operating system.
  • the function uses the information supplied by interrupt 21h to generate the reply message for the function. Specifically, services select disk OEh, get free space 36h, make directory 39h, remove directory
  • 3Dh parse the incoming message and initiate the appropriate interrupt 21h service.
  • the result returned by the operating system is placed in bytes OAh and OBh of the reply message. If the operating system set the carry flag, the error code in bytes 08h and 09h of the reply message are set in this embodiment to one. If the carry flag is not set, an empty slot is found in the local file handle table. The SID for the empty slot is set to the SID in the incoming message and the slot to the result returned by the operating system, i.e., the handle. The size of the reply message is returned to function SERVERMAIN.
  • the server function for service close 3Eh is similar to the functions for create 3Ch and open 3Dh. The difference is that this function searches in the local file handle table for the handle corresponding to the SID in the incoming message. If the handle corresponding to the SID is the correct handle, both the SID and the handle are set to zero.
  • the server function for service read 3Fh is somewhat more complex because the length of the data to be read (bytes OAh and OBh in the incoming message (Fig. 21A) ) may be greater that the data region in the reply message. Thus, this function parses the incoming message to obtain the file handle and the length of the data to be read.
  • the read is broken into a series of reads such that all but possibly the last read fill the data region of the reply message.
  • the eight byte header for the reply message is created and then an interrupt 21h read is sent to the operating system where the length of the read is equal to the data region in the reply message.
  • the length of the read returned by the operating system is added to the length of the previous reads and saved so that comparison of the stored value and the read length from the incoming message shows that the read is complete.
  • the read data is compressed, as previously described, and put in the local message buffer. The length of the compressed data is placed in bytes OAh and OBh of the reply message.
  • a length of zero is returned to function SERVERMAIN.
  • the server function for service write 4Oh parses the incoming message (Fig. 20A) , decompresses the data, as described above, and initiates an interrupt 21h write.
  • the function then builds the eight byte header for the reply message (Fig. 2OB) in the local message buffer and sets the OAh and OBh bytes of the reply message to the result provided by the operating system. If the carry flag has been set by the operating system, the error code in the reply message is set to a nonzero value.
  • the length of the reply message is returned function SERVERMAIN.
  • the server function for service get directory 47h also parses the incoming message (Fig. 24A) and subsequently initiates an interrupt 21h get directory service.
  • the function then builds the eight byte header for the reply message (Fig. 24B) in the local message buffer and sets the OAh and OBh bytes of the reply message to the result provided by the operating system. If the carry flag was set by the operating system, the error cod in the reply message is set to one and the path length (bytes OCh and ODh) is set to two in this embodiment. If the carry flag was not set, the path is copied to the local message buffer and the path length is set appropriately. The length of the reply message is returned to function SERVERMAIN.
  • the server functions for find first 4Eh and find next 4Fh are similar to the server function for write 4Oh, described above, except the appropriate interrupt 21h is called for the service indicated in byte six of the incoming message (Figs. 25A and 26A) . Also, as previously described, the DTA is copied into the data region of the reply message (Figs. 25B and 26B) .
  • VDISCONNECT a VDISCONNECT message
  • the open files are checked against the SID in the message. If an open file has the SID, the file is closed. Subsequently, transport layer function TDISCONNECT is called and a zero length is returned to function SERVERMAIN.
  • VLISTEN and VSTATUS are not serviced by the server because a connection has been achieved and STATUS is only a local command and no message is sent over the network. VRESET simply resets and nothing is sent over the network so that server has no response.
  • Server function M&PDRV for service map FDh responds to incoming message 160-MAP (Fig. 10A) .
  • the requested drive may not physically exist in the remote node.
  • the operating system in the remote node may take action that would inhibit operation of the virtual network executive. For example, originally most IBM PC compatible microcomputers had only one floppy disk drive, but that drive could be addressed as either drive A or drive B. Drive B in this case did not physically exist. If drive A was being used, and then a command was given for drive B, the operating system would cue the user to insert a disk in drive B and press any key to continue. Obviously, such a response at the remote node would limit operation of the virtual computer.
  • server function MAPDRV Upon receiving incoming message 160-MAP (Fig. 10A) , server function MAPDRV builds the eight byte header for the reply message 160-RMAP (Fig. 10B) in the local message buffer and sets the 08h and 09h bytes of the reply message to invalid drive. Function MAPDRV next ascertains whether the drive specified in message 160-MAP is both physically present and not removable in the remote node. If both of these conditions are true, bytes 08h and 09h of the reply message are set to the requested drive. A similar action is taken if the drive is removable and the drive exists. The length of the reply message is returned to function SERVERMAIN.
  • Transport layer 170 (Fig. 5) is called by either a function 120, 130 in application layer 160, or a function in datalink layer 180.
  • a function that calls a transport layer function interfaces with the transport layer function via a 'C type stack frame with parameters pushed on the stack, from right to left.
  • 'C refers to the C programming language as described by B. Kernighan and D. Ritchie, The C Programming Lancrua ⁇ e. 1st Edition, Prentice Hall,
  • Transport layer 170 can process a message from application layer 160 having a size of 64 Kbytes or less. Transport layer 170 breaks the message from application layer 160 into a number of packets. Transport layer 170 assures the correct delivery of each packet to the remote node indicated by the session identification number (SID) by using a CRC-16 checksum, as explained more completely below. Specifically, the transport layer prepends a header to each packet, and appends a CRC-16 checksum. The packet is then handed to datalink layer 180 for delivery to the remote destination.
  • SID session identification number
  • Transport layer 170 is responsible for detecting errors in the communication link and for handling packet resends when necessary.
  • Transport layer 170 breaks a large message into a sequence of packets when necessary, i.e., when either a specified number errors occur in transmission of the packets or the message has a size greater than the maximum size that can be transmitted in a packet. In one embodiment, a message is divided into 4
  • transport layer 170 resends the packet a predetermined number of times. If the packet is not sent without error in the predetermined number of times, transport layer responds by halving the size of the packet. If the packet size is at the minimum 256 bytes in one embodiment, then datalink layer 180 is directed to reduce the line speed, and the packet size is increased to the maximum size, 4 KBytes in this embodiment. Further transmission errors cause this process to reoccur, until neither packet size nor speed can be reduced further, whereupon transport layer 170 aborts the transmission process, and returns an appropriate error code to the calling function. Transport layer 170, like the datalink and application layers, is capable, in design, of handling multiple sessions. However, one embodiment restricts the maximum number of sessions because datalink layer 180 would require further development to support multiple sessions.
  • transport layer 170 supports a set of seven functions called TLISTEN, TCONNECT, TDISCONNECT, TSTATUS, TRESET, TSEND, and TRECEIVE.
  • TLISTEN The input information that must be provided to each transport layer function by the calling function and the results returned to the calling function are shown in Table 4.
  • nodeid Remote node identification Speed: Line baud rate divided by 100 (0 to allow select best speed) .
  • timeout # of clock ticks to wait for data (0
  • An error code is returned indicating success or failure.
  • sid session identification length: length of supplied buffer statbuf: pointer to supplied buffer
  • Buffer supplied by the calling function is filled with the status information in the Virtual Network Data Structure and TSTATUS returns zero or an error code.
  • Virtual Network Data Structure local node id num. of active sessions array of SID data structures (one for each active session)
  • SID data structure session ID ID of remote node number of bytes sent number of bytes received number of send errors number of rev errors current baud rate SAI Version VNA Version Application Msg Dialect TRESET
  • sid session identification length! length of message message: pointer to message On return:
  • the length of message or an error code is returned.
  • Transport layer function errors are returned to the application as negative values. Successful completion of a transport layer function is indicated by a positive (generally zero) return value.
  • a positive (generally zero) return value is given in Table 5.
  • Transport layer functions TLISTEN, TCONNECT, TDISCONNECT, TSTATUS, and TRESET are virtually null operations and each of these functions simply acts as a conduit between application layer 160 and datalink layer 180.
  • the transport layer function in turn calls the corresponding datalink layer function.
  • each of the transport layer functions must support the information required by the application layer functions.
  • TSTATUS places status information about the network executive in the supplied buffer. The structure placed in the buffer is equivalent to the application layer status data structure 160-STATSRUCT (Fig. 29) previously described.
  • Transport layer functions TSEND (TSEND) 170-S, upon entry, first performs SID check 170-S1. SID check 170-S1 ascertains whether the SID passed in the call to TSEND 170-S is valid. A SID is valid if the SID is not equal to zero, is less than the maximum SID permitted, and is one of the SIDs associated with a session.
  • SID error return 170-S2 sets the error return code to a -9 and returns to the calling function in application layer 160 (Fig. 5) .
  • SID check 170-S1 (Fig. 32) determines that the SID is valid
  • pointer check 170-S5 examines the message pointer passed in the call to TSEND 170-S to ascertain whether the message pointer is defined, i.e., not null.
  • the message pointer identifies the start of the message generated by application layer 160 (Fig. 5) . Accordingly, the message pointer must be defined so that TSEND 170-S (Fig. 32) can locate and subsequently process the message.
  • pointer check 170-S5 determines that the message pointer is not defined, processing passes to pointer error return 170-S4 which, in one embodiment, sets the error return code to -8, invalid buffer address, and returns to the calling function in application layer 160 (Fig. 5).
  • pointer check 170-S5 determines that the message pointer is defined
  • processing transfers to reset counter 170-S6.
  • reset counter 170-S6 resets the bad message error counter to zero.
  • number of packets 170-S7 After the bad message error counter is reset, number of packets 170-S7 initially uses the message length as supplied in the call to TSEND 170-S to calculate the number of packets that must be transmitted to the remote node. Recall that in this embodiment a message from the application layer may be up to 64 Kbytes in length, but as previously defined, transmission layer 170 (Fig. 5) can send a packet having a maximum size of 4 Kbytes. Number of packets 170-S7 (Fig. 32) divides the message length by the current packet length and rounds the result to the next higher integer value. Thus, if the length of the message is 64 Kbytes and the current packet length is the maximum 4 Kbytes, number of packets 170-S7 calculates that 16 packets must be transmitted.
  • Buffer offset initialization 170-S8 sets the buffer offset to zero so that the processing starts at the beginning of the local message buffer. The buffer offset is adjusted so that the offset indicates the data in the local message buffer for the next packet.
  • packet available check 170-S9 determines whether another packet is available for transmission. If all the packets have been successfully sent, packet available check 170-S9 transfers processing to return 170-S10 which in turn transfers control to the calling function in application layer 160 (Fig. 5) with a return code indicating successful completion of TSEND 170-S (Fig. 32).
  • header 170-MH is 14 bytes in length.
  • the first two bytes are a rudimentary signature, for example, "VI”.
  • the third and fourth byte contain a message identification. Since transport layer transfers at least two blocks for every packet, (a send and a receive) the message identification is used to identify which packet the transferred block represents. In one embodiment, the message identification is simply increased sequentially as TSEND processes each packet.
  • the fifth and sixth bytes are the node identification for the source of the packet while the seventh and eighth bytes are the node identification for the destination of the packet.
  • the total number of packets comprising the message as calculated by number of packets 170-S7 is placed in the ninth and tenth bytes of the header while the number of the packet being transmitted is in the eleventh and twelfth bytes of the header.
  • the thirteenth and fourteenth bytes of the header are used to transmit the length of the data contained in this transmission packet.
  • the reverse CRC-16 generating function is used to obtain the CRC-16 checksum. See J. Campbell, C Programmer's Guide to Serial Communications. Chapt. 19, Howard W. Sams and Co., Indianapolis, In. pp 533-550 (1987) .
  • build packet 170-S11 has constructed a transport layer header, a data region consisting of a portion of the message provided by application layer 160 (Fig. 5) , and has appended a CRC-16 error code.
  • send packet 170-S12 Upon construction of the packet by build packet 170- Sll (Fig. 32) , the packet is provided to send packet 170- S12 which is described more completely below with respect to Fig. 34.
  • send packet 170-S12 calls datalink layer function DSEND, and provides the packet for transmission.
  • Datalink layer 180 either returns a successful completion code, or an error code to send packet 170-S12.
  • Error check 170-S13 determines whether an error code was returned or whether the transmission was successful. If the transmission was successful, error check 170-S13 transfers processing to packet available 170-S9 which then either sends the next packet or returns to application layer 160 (Fig. 5) . However, if error check 170-S13 (Fig. 32) detects an error, processing transfers to message bad check 170-S14.
  • count check 170-S15 determines whether the bad message count as represented by the bad message error counter is less than five. If the bad message error count is less than five, count check 170-S15 transfers control to number of packet 170-S7 which in turn starts the transmission process over.
  • count check 170-S15 determines that the bad message counter is equal to or greater than five, processing transfers to set packet number 170-S16 which i turn sets the packet number to one. This branch changes the transmission parameters prior to attempting a resend.
  • Both message bad check 170-S14, when the message is not bad, and set packet number 170-S16 transfer processing to hardware error check 170-S16. If either the connection was broken or a bad node ID was returned by send packet 170-S12, hardware error check 170-S16 transfers to error code return 170-S19. However, if neither the connection was broken nor a bad node ID was returned, processing transfers to blocksize check 170-S20.
  • block size 170-S20 transfers to change speed check 170-S21 which determines whether a reduction in the transmission speed if possible. If the virtual network is established through a modem or the speed is at a minimum, the transmission speed cannot be changed so that change speed check 170-S21 transfers to send/receive error return 170-S22 which returns a send error to the calling application layer function. If the speed can be reduced, change speed check 170-S21 calls reduce speed 170-S23 which in turn uses the datalink function DRESET, described more completely below, to reduce the speed of transmission.
  • DRESET datalink function
  • Resend 170-S25 resets the buffer offset to the location of the start of the packet where the error occurred and returns processing to build packet 170-S11. Accordingly, the transmission parameters have been changed and the transmission reinitiated at the point of the transmission error.
  • the ability to change the transmission parameters during the transmission of a message is not available in prior art systems. Rather the prior art systems determine the transmission parameters upon connection and use these parameters for all subsequent transmisssions.
  • Send packet 170-S12 (Fig. 32) is illustrated in more detail in Fig. 34.
  • Initialize error counter 170-SP1 first sets the send error counter and the datalink send error counter to a selected value, typically three.
  • Datalink send 170-SP2 transfers to datalink send error check 170-SP3 which ascertains whether a datalink send error occurred. If a datalink send error did not occur, processing transfers to datalink receive 170-SP9, but if an error was generated at datalink send 170-SP2, the send error counter is decremented by decrement send error counter 170-SP4.
  • Hardware error check 170-SP5 determines whether the datalink send error was a connection broken error or a bad node ID. If either of these errors occurred, processing transfers to error return 170-SP6 which returns to send 170-S12.
  • Count check 170-SP8 ascertains whether the error counter has a zero value. If count check 170-SP8 determines that the error count is zero, processing transfers to error return 170-SP6 which functions as described above. However, if the count check is greater than zero, processing transfer to datalink send 170-SP2 which resends the packet.
  • datalink send error check 170- SP3 transfers to datalink receive 170-SP9 which waits for a reply message from the remote node containing a header, return code and CRC-16 checksum.
  • error check 170-SP10 analyzes the return code to determine whether a a datalin receive error occurred.
  • error check 170-SP10 branches to error return 170-SP15 which in turn sets the error code, flushes the datalink, as described below, and transfers to decrement counters 170-SP19. However, if error check 170-SP10 does not detect an error, processing transfers to CRC sum chec 170-SP11.
  • CRC sum check 170-SP11 calculates a CRC-16 checksum for the header and compares the calculated checksum with the CRC-16 checksum received by datalink receive 170-SP9. If the CRC-16 checksums are not the same, processing transfers to return CRC error 170-SP16 which in turn calls datalink flush and sets the error code to a CRC error and subsequently transfers processing to decrement counters 170-SP19. If CRC sum check 170-SP11 does not detect an error, processing transfers to message ID check 170-SP12. If the message ID from datalink receive 170-SP12 does not match the message ID of the transmitted packet, processing transfers to return bad message 170-SP17 which sets the error code to bad message ID.
  • return code 170-SP13 checks the return code from datalink receive 170-SP70 and if it is less than zero, transfers processing to 170-SP18 which sets the return error code and passes processing to decrement counters 170-SP19. If error checks 170-SP10, 170-SP11, 170-SP12 and 170-SP13 fail to detect an error, processing transfers to return 170-SP14 which provides a successful return code to send 170-S. Decrement counters 170-SP19, upon receiving control, decrements the datalink error counter and the send error counter and passes control to count check 170-SP20. If the error count is greater than zero, processing transfers to datalink send 170-SP12 which repeats the send process.
  • process 170-SP9 through 170-SP18 are included in a separate function that is called by send packet 170-S12 after error check 170-SP3.
  • TSEND is responsive to a remote node TRECEIVE.
  • the TRECEIVE function is similar to the TSEND function and is illustrated in Fig. 35 through Fig. 37.
  • Function TRECEIVE of transport layer 170 as illustrated in Fig. 35, first performs SID check 170-R1 and pointer check 170-R5. The operation of these checks is equivalent to that described previously for the SID check 170-S1 and pointer check 170-S5 in send 170-S (Fig. 32) , which is incorporated herein by reference.
  • Pointer check 170-R5 transfers processing to receive packet 170-R6.
  • Receive packets 170-R6 provides the length of the received data, the header and the CRC-16 checksum as well as an error code if an error was detected.
  • Error check 170-R7 determines whether receive packet 170-R6 generated an error. If no error was detected, copy data 170-R12 copies the received data to the receive buffer and then transfers processing to send reply 170-R13.
  • Send reply 170-R13 is described more completely below with respect to Fig. 37. Briefly, send reply 170-R13 sends the packet of information to datalink receive 170- SP9 (Fig. 34) . If an error occurs in send reply 170-R13 (Fig. 35) , error check 170-R14 passes processing to receive packet 170-R6, which functions as previously described.
  • error check 170-R14 passes control to last packet check 170-R16 which in turn either passes processing to return 170-R18 if the last packet was processed, or passes processing to buffer full check 170-R17. If the receive buffer is full, processing passes to buffer error return 170-R19 which returns a buffer full error to the calling function in application layer 160. If the buffer is not full, buffer full check 170-R17 passes processing to receive packet 170-R6 to obtain the next packet from TSEND.
  • error check 170-R7 did not receive an error from receive packet 170-R6. If error check 170-R7 detects an error, processing transfers to increment counter 170-R8 which after incrementing the received error counter passes control to hardware error check 170-R9. If receive packet 170-R6 returned a bad node ID, connection broken, or time out error, hardware error 170-R9 transfers to return error code 170-R15.
  • hardware error 170-R9 transfers to message bad check 170-R10. If a bad message error was not generated by receive packet 170-R6, message bad check 170-R10 passes processing to receive packet 170-R6. However, if a bad message error was generated, message bad check 170-R10 passes control to set packet number 170-Rll which sets the packet number to one and then transfers control to receive packet 170-R6. TRECEIVE continues to loop from receive packet 170-R6 through the subsequent steps until last packet check 170-R16 returns to the calling program.
  • Receive packet 170-R6 (Fig. 35) is illustrated in more detail in Fig. 36.
  • datalink receive 170-RP1 calls datalink function DRECEIVE.
  • Function DRECEIVE receives the packet sent by DSEND, which was called by datalink send 170-SP2 (Fig. 34) .
  • the packet received has a header, a data region and a CRC-16 checksum.
  • Error check 170-RP2 (Fig. 36) checks to determine whether datalink receive 170-RP1, generated an error code. If an error code was generated by datalink receive 170-RP1 processing transfers to datalink flush 170-RP3 which calls the datalink function DFLUSH.
  • selected error check 170-RP4 determines whether the return error was a connection broke error, a time out error, or a bad node ID error. If the error was one of these three selected errors, processing transfers to return error code 170-RP7 which in turn returns to error check 170-R7 (Fig. 35) . If another error was generated, processing transfers to send reply 170-RP5, which is described more completely below. Send reply 170-RP5 generates an error packet and sends the packet to datalink send 170-SP2
  • Packet error compares the pocket number with the received packet number and if they are not the same, transfers processing to datalink flush 170-RP3 which calls datalink function DFLUSH, which is described more completely below.
  • Datalink flush 170-RP3 in turn passes processing to send reply 170-RP5, which is described more completely below, and finally to return bad message error 170-RP15. If the packet numbers are the same, packet error 170-RP12 transfers to data return 170- RP16 which returns the length of the received data, the header and a CRC-16 checksum to receive packet 170-R6.
  • Send reply 170-RP5 (Fig. 36) is illustrated in more detail in Fig. 37.
  • create reply packet 170-SRl Upon entry to send reply 170-RP5, create reply packet 170-SRl generates a packet containing the transport layer header, the passed return code and a CRC-16 checksum.
  • initialize counter 170-SR2 initializes an error counter to zero.
  • Datalink send 170-SR3 calls datalink layer function DSEND to transmit the packet created by create packet 170-SRl to the remote machine that sent the received packet.
  • Error 170-SR5 checks to determine whether an error was generated in datalink send 170-SR3. If no error was generated, processing transfers to return 170-SR6 and consequently control passes to the next operation in receive packet 170-R6.
  • error check 170-SR5 passes processing to counter check 170-SR7. If the error counter is less than 5, counter check 170-SR7 passes control to increment counter 170-SR4 which increments the error counter and passes processing back to datalink send 170-SR3. Conversely, if the counter error is greater than or equal to 5, counter check 170-SR7 passes control to datalink error 170-SR8 which returns to receive packet 170-R6 with a datalink error code.
  • transport layer functions TSEND and TRECEIVE call datalink layer function DFLUSH, DSEND and DRECEIVE.
  • datalink layer 180 also includes DLISTEN, DCONNECT, DDISCONNECT, DSTATUS and DRESET. As described above, each of these functions responds to the corresponding function in the transport layer. The possible return codes from the datalink functions are presented below in Table 6.
  • Datalink layer 180 is responsible for the delivery of a single packet across the network (i.e., physical layer), along with support services. No accuracy check is made by the datalink layer. In the event that transport layer 170 requests a speed change, datalink layer 180 arbitrates that change, if possible. Datalink layer 180 is low level, which means that the layer is hardware dependent. In the embodiment presented in Microfiche Appendix A and incorporated herein by reference, datalink layer 180 is compatible with IBM personal computers and IBM compatible personal computers. Through the proper use of datalink layer 180, however, transport layer 170 may effect hardware independence.
  • Datalink function DRESET (DRESET) is used to initialize or reinitialize the datalink driver.
  • Transport layer function TRESET or any other function calling DRESET passes a parameter to DRESET which indicates to perform either a normal reset or to alter the transmission speed.
  • Reset check 180-RST1 analyzes the parameter passed to function DRESET and passes processing to initialize 180-RST2 if a normal reset is indicated.
  • Initialize 180-RS2 sets variables used in the datalink functions to selected values. Specifically, datalink layer functions use an intercharacter timeout variable and another timeout variable to monitor the time period spent waiting for an action to occur. These variables are distinguished by referencing "the timeout variable” and "the intercharacter timeout variable.” Both of these variables are set to zero as is a flag used to indicate the connection status. A zero value for either timeout variable indicates that the variable is not being used for monitoring the elapsed time.
  • connection status flag is set to zero to indicate no connection or a successful connection; to a -1 to indicate a connection or listen being attempted; and to a -2 to indicate attempting speed arbitration.
  • initialize 180-RST2 sets the transmission delay variable to a predetermined value, e.g., one, and processing transfers to return 180-RST3 which returns a success to the calling function.
  • Reset check 180-RST1 passes processing to set parameters 180-RST4 when the parameter passed to function DRESET indicates a speed change.
  • Set parameters 180-RST4 first sets the timeout variable to 30 seconds and then calls set speed 180-SS (not shown) to set the transmission speed to 300 baud.
  • Set speed 180-SS is used to set the UART speed to the index passed to the function.
  • Set speed 180-SS first points to the table of UART baud rate divisors and then loads the divisor corresponding to the passed index. The UART status is monitored until any transmission operation is complete and then the UART baud rate divisor access is enabled. The loaded divisor is sent to the UART, the low byte being sent first and then the high byte. Subsequently, access to the UART baud rate divisor is disabled and processing returned to the calling routine, in this case, to set parameters 180-RST4. Subsequent references to set speed 180-SS refer to this sequence of operations.
  • set parameters 180-RST4 transfers processing to set connect speed 180-CS.
  • Set connect speed 180-CS establishes a transmission rate with a remote node.
  • the operations in set connect speed 180-CS are described more completely below with respect to Figures 39A and 39B. If the operation of set connect speed 180-CS is successful, no error flag is returned and error check 180-RST5 transfers processing to set delay count 180-DC.
  • Set delay count 180-DC first loads the baud rate index. A first variable, loop count, is used to indicate relative machine speed.
  • loop count is defined by function DCONNECT as the number of times that the register pair DX:AX can be incremented during the time interval between two ticks.
  • a tick in this embodiment, is 55 milliseconds. If the baud rate is greater than 19,200, the delay count is set equal to the loop count multiplied by eight and divided by the baud rate divisor.
  • delay count is set to zero. After delay count is set, set delay count 180-DC returns processing to the calling function. Subsequent references to set delay count 180-DC refer to this set of operations. Accordingly, after set delay count 180-DC completes processing, DRESET 180-RST returns through 180-RST3 to the calling function.
  • error check 180-RST5 transfers processing to error return 180-RST6 which sets the carry flag and returns processing to the calling function.
  • Set connect speed 180-CS is shown in more detail in Figures 39A and 39B.
  • a circle enclosing a letter represents a connection in that figure and a triangle containing a letter represents a connection to another figure.
  • elements with a similar label are equivalent and multiple references to the same element within a figure are indicated by the label followed by a capital letter.
  • the first operation in set connect speed 180-CS is set connection status 180-CS1 which sets the connection status flag to indicate that speed arbitration is being attempted.
  • transmit connect character 180-CS2 sends a character to the specified remote node.
  • the connect character is "ENQ".
  • transmit character means that a function is called to send the character over the virtual network. This function is passed the character to be transmitted and a delay factor. The character transmission function waits for the number of ticks specified by the delay factor and then tests the UART status until the transmission holding buffer is empty. The passed character is then sent and processing returns to the calling function.
  • a reference to "transmit character” refers to this sequence of operations.
  • timeout check 180-CS3 After transmit connect character 180-CS2, timeout check 180-CS3 waits two ticks and then checks the timeout variable described previously. If a timeout has occurred, processing transfers to timeout error return 180-CS4 which in turn sets the return value to a timeout error and the carry flag prior to returning to the calling function. If a timeout has not occurred, timeout check 180-CS3 transfers processing to receive character status 180-RCS. The operations of receive character status 180-CS are described more completely below with respect to Figure 40. Receive character status 180-RC either (i) receives the character sent by the remote node in response to transmit connect character 180-CS, (ii) generates an error code, or (iii) indicates that a character is not ready and then passes processing to character check 180-CS5.
  • character check 180-CS5 returns processing to transmit character 180-CS2.
  • an acknowledge or an acknowledge character refers to a character such as "ACK”. If the character is an acknowledge, processing transfers to set timeout 180-CS6 which sets the timeout variable to five seconds.
  • Receive character 180-RC either returns a character or an error to the calling function. Accordingly, error check 180-CS7 transfers control to error return 180-CS9 upon receipt of an error. Error return 180-CS9 sets the carry flag and returns processing to the calling function.
  • receive character 180-RC-B receives the next character transmitted from the remote node.
  • Error check 180-C7-B functions, as previously described, and if there is not an error passes control to end baud rate string check 180-CS14. If the received character does not indicate the end of the baud rate sequence, processing transfers to send/receive error return 180-CS10. However, if the character is the end of baud rate sequence, processing transfers to transmit baud rate 180-CS15 (Fig. 39B) .
  • Transmit baud rate 180-CS15 is a sequence of actions that sends the selected speed over the virtual network to the remote node.
  • transmit baud rate 180-CS15 waits eight ticks and then transmits a character that indicates a start of a baud rate change.
  • receive character (Fig. 41) is called. Again, receive character either returns a character or an error. If an error is returned, the carry flag is set, the return value is set to a timing error and processing transferred to the calling function. If no error is returned, the received character is checked to determine whether the character is an acknowledge. If the character is not an acknowledge, the carry flag is set, the return value is set to a send/ receive error, and processing return to the calling function.
  • receive character 180-RC-D is called and error check 180-CS16-A and acknowledge 180-CS17-B function as described previously. If the received character is an acknowledge, an end of session character is transmitted by transmit end of session 180-C19 and receive character 180-RC-D is used to receive the character from the remote node. If an error is detected, error check 180-CS16-B transfers processing to timeout error return 180-CS4. If the received character is an end of session character, processing is transferred by end of session check 180-CS20 to return 180-CS21, or otherwise to send/receive error 180-CS10.
  • Function receive character status 180-RCS is illustrated in Figure 40. This function receives one character into register AL, or alternatively sets the Z flag if a character is not ready. Initially, function receive character status 180-RCS performs start test 180-RCS1. Start test 180-RCS1 determines whether a connection is made and whether there is a framing error. A framing error normally occurs only when the two nodes are sending at different baud rates to one another. If there is a connection and a framing error, start test 180-RCS1 passes processing to speed resynchronization 180-SRE, which is described more completely below with respect to Figure 43. Speed resynchronization 180-SRE adjusts the connect speed so that both nodes are communicating at the same speed.
  • speed resynchronization 180-SRE returns an error
  • error check 180-RCS5 returns processing to return 180-RCS4 which clears the Z flag and returns to the calling function.
  • speed resynchronization 180-RCS5 does not return an error
  • error check 180-RCS5 transfers processing to set error code 180-RCS6 which in turn sets the error return value to a speed change error. Processing is then again transferred to return 180-RC4 which clears the Z flag and returns to the calling function.
  • start test check 180-RCS1 passes processing to character ready 180-RCS2. If a character is not ready, processing transfers to error return 180-RCS4, which sets the Z flag and returns. Conversely, if a character is ready, processing transfers to read character 180-RCS3, which reads the character from the UART and subsequently transfers processing to return 180-RCS4 which clears the Z flag and returns.
  • timeout check 180-RC1 determines whether the timeout variable is one. If the variable is one, processing transfers to error return 180-RC11 which sets the carry flag and returns a timeout error. Conversely, if the timeout variable is not one, UART status 180-RC2 reads the UART line status to ascertain whether there is a framing error.
  • Framing error 180-RC3 then ascertains whether there is a framing error or whether the connection status flag is zero. If there is no framing error or the connection status flag is zero, processing transfers to character ready check 180-RC4. If no character is ready, processing returns to timeout check 180-RC1. Conversely, if a character is ready, read character 180-RC6 obtains the character and transfers processing to return 180-RC7.
  • framing error 180-RC3 transfers processing to save timeout 180-RC5 which saves the current timeout value. Processing then transfers to speed resynchronization 180-SRE, which is described more completely below with respect to Fig. 42.
  • restore timeout 180-RC8 restores the same saved timeout value and transfers processing to speed change error 180-RC9. If an error is generated by speed resynchronization 180-SRE, speed change error 180-RC9 transfers processing to error return 180-RC11. Conversely, if no error was generated, processing transfers to return speed change 180-RC10 which sets the result of the function to indicate the speed change.
  • Speed resynchronization function 180-SRE which was called by receive character function 180-RC (Fig. 41) and receive character status 180-RCS (Fig. 40) is illustrated in Figure 42.
  • reset timeout 180-SRE1 first zeroes the timeout variable. Subsequently, clear
  • UART port 180-SRE2 reads the UART data port so as to clear the port.
  • Minimum speed check 180-SRE3 then ascertains whether the speed is set at 300 baud. If the speed is 300 baud, error return 180-SRE4 sets the carry flag and returns a value of speed error to the calling function.
  • minimum speed check 180-SRE3 transfers to set speed 180-SS, which functions as previously described. Specifically, set speed 180-SS sets the speed in the node to 300 baud and transfers processing to save baud rate 180-SRE5 which sets the baud rate index to correspond to the set baud rate.
  • set listen speed 180-LS is called to resynchronize the speed with the remote node. The operations in set listen speed 180-LS are described more completely below with respect to Figure 43.
  • set delay count 180-DC is called. The operation of set delay count 180-DC was described above and is incorporated herein by reference.
  • return 180-SRE6 Upon completion of set delay count 180-DC, return 180-SRE6 returns control to the calling function.
  • Function set listen speed 180-LS is illustrated in Figure 43.
  • the call to set listen speed passes the baud rate as a parameter.
  • Set connection status 180-LS1 saves and then sets the connection status flag to -2 to indicate that a speed arbitration is being attempted.
  • receive character 180-RC is used to receive either a character or return an error. If an error is returned, error check 180-LS2 transfers processing to error return 180-LS3 which restores the connection status flag and sets the carry flag prior to returning. If an error is not returned, end of listen check 180-LS9 ascertains whether the received character indicates the end of set listen speed and if so transfers processing to return 180-LS4.
  • Return 180-LS4 sends an acknowledgment that the end of set listen speed character was received; restores the connection status flag to the value upon entry; and returns to the calling function. Otherwise, connect character check 180-LS5 determines whether a connect character was received. If such a character was not received, processing returns to receive character 180-RC.
  • connect character check 180-LS5 receives a connect character
  • processing transfers to set timeout 180-LS6 which in turn sets the timeout variable for five seconds.
  • Processing then transfers to transmit baud rate 180-LS7.
  • transmit baud rate 180-LS7 includes a number of operations. Specifically, an acknowledge character is transmitted and then two ticks later a start baud rate sequence character is transmitted. The low byte of the speed and the high byte of the speed are followed by an end of baud rate sequence character and then processing transfers to save baud rate 180-LS8. Save baud rate 180-LS8 loads the baud rate index from the table based upon the speed and then sets the baud rate index to the loaded index.
  • Set speed 180-SS sets the speed in the local machine, as previously described.
  • An acknowledge character is then sent at the new speed and processing then transfers to receive character 180-RC.
  • Datalink layer function DSEND is used to send a packet to the remote node where an outstanding function DRECEIVE is active. DSEND returns zero indicating that the packet is successfully sent. A negative error is returned if the packet cannot be sent.
  • the function calling DSEND passes the node ID, the length of the message, and a pointer to the message buffer to function DSEND.
  • One embodiment of DSEND is illustrated in Figure 44.
  • Disable keyboard 180-S1 turns off the keyboard scanning and transfers processing to send packet size 180-SPS.
  • Send packet size 180-SPS sends to the remote node the size of the packet to be sent.
  • the operation of send packet size 180-SPS is illustrated in more detail in Figure 45. If send packet size 180-SPS returns an error, processing is transferred by error check 180-S3 to enable keyboard 180-S10 which restores keyboard scanning and passes control to return 180-S11 which in turn passes control to the calling function.
  • increment bytes sent 180-S4 adds the packet size to the variable that is used to count the number of bytes transmitted since the last reset.
  • byte available 180-S5 ascertains whether there are any additional bytes and then load byte 180-S12 loads the byte so that transmit character 180-S13 can send the byte across the virtual network.
  • byte available 180-S5 transfers control to get packet size 180-GPS.
  • Get packet size 180-GPS obtains the size of the received packet from the remote node. If an error is generated, processing transfers to enable keyboard 180-S10. However, if an error is not returned, packet size check 180-S7 ascertains whether the passed packet size matches the received packet size. If the packet sizes are different, set error 180-S9 - Ill - sets the return value to send/ receive error and transfers processing to enable keyboard 180-S10. Conversely, if the packet sizes are the same, set success 180-S8 sets the return value to success before passing control to enable keyboard 180-S10.
  • Function send packet size 180-SPS which was called by function DSEND, is illustrated in Figure 45.
  • Initialize 180-SPS1 first sets the receive active flag to one and then saves the transmission delay. The transmission delay is then set to delay count, which was described above.
  • the timeout variable is set to fifteen seconds.
  • Timeout 180-SPS2 checks the timeout variable to ascertain whether a timeout has occurred. If a timeout has occurred, set error 180-SPS3 sets the return value to send/ receive error and set flag 180-SPS4 sets the carry flag. Subsequently, restore 180-SPS5 restores the value of the transmission delay to the saved value and resets the receive active flag to zero before passing control to return 180-SPS6.
  • timeout check 180-SPS2 does not detect a timeout, initiate transmission 180-SPS7 transmits a start of transmission character to the remote node.
  • Receive character status 180-RCS then either receives a character, generates an error, or indicates that a character is not ready as described above. Accordingly, if character ready check 180-SPS9 ascertains that a character is not ready, processing returns to timeout check 180-SPS2. If a character is ready and an error was generated, error check 180-SPS10 returns processing to set flag 180-SPS4. If an error is not returned, acknowledge check 180-SPS11 ascertains whether the character returned by receive character status 180-RCS was an acknowledge character. If the character was not an acknowledge character, processing transfers to set error 180-SPS3.
  • transmit packet size 180-SPS12 sends to the remote node the size of the packet to be sent. Specifically, transmit package size 180-SPS12 transmits a character indicating the start of the transmission, the low byte of the packet size, the high byte of the packet size, and then a character to indicate end of the transmission. Receive character
  • 180-RC then receives a character as described previously with respect to Figure 41. If receive character 180-RC returns an error, error check 180-SPS10-A transfers processing to set flag 180-SPS4. If the character is an acknowledge, acknowledge test 180-SPS11-A transfers processing to restore 180-SPS5. Otherwise, acknowledge test 180-SPS11-A transfers processing to set error 180-SPS3.
  • Figure 46 Initialize 180-GPS1 sets the receive active flag to one and saves the transmission delay and timeout values. Subsequently the transmission delay is sent to delay count, which was described previously. Processing then transfers to receive character 180-RC-A.
  • error check 180-GPS2 transfers processing to speed change error 180-GPS3 which returns processing to receive character 180-RC-A if the error was set to a speed change error.
  • speed change error 180-GPS3 transfers to set flag 180-GPS4 which sets the carry flag and then transfers to restore 180-GPS5.
  • Restore 180-GPS5 returns the saved transmission delay and timeout values to the appropriate variables and sets the receive active flag to zero before transferring processing to return 180-GPS6.
  • error check 180-GPS2 transfers processing to initiate transmission check 180-GPS7. If the received character did not indicate an initiation of transmission, processing is returned to receive character 180-RC-A. If the received character indicates an initiation of transmission, transmit acknowledge 180-GPS8 sends an acknowledge character to the remote node and then passes processing to receive character 180-RC-B.
  • error check 180-GPS9 transfers processing to speed change error 180-GPS3 which proceeds as described above. If an error was not generated and a start of transmission character was not received, processing is returned to receive character 180-RC-B by start transmission 180-GPS10. Otherwise, start transmission 180-GPS10 passes processing to receive character 180-RC-C, which receives the low byte of the packet length. Similarly, receive character 180-RC-D receives the high byte of the packet length and receive character 180-RC-D receives the end of the transmission character. If any of these receives generates an error, processing is returned to speed change error 180-GPS2.
  • end of transmission check 180-GPS11 transfers to set error 180-GPS13 which in turn sets a send/receive error. If an end of transmission is received, transmit acknowledge sends an acknowledge signal to the remote node and clear flag 180-GPS12 clears the carry flag before transferring processing to restore 180-GPS5.
  • datalink layer 180 embodiment described herein represents a set of functions for use with an IBM PC compatible computer. However, in view of this disclosure, one skilled in the art can use the application layer functions and the transport layer functions with any datalink layer which provides the services described for those functions.
  • interrupt 08h is dependent upon the interrupt service routine that is pointed to by the interrupt 08h vector in the low memory of the computer.
  • a program can cause different functions to be executed at a 55 millisecond interval. As previously described, the 55 millisecond interval is referred to as a "tick".
  • the datalink layer of this invention uses two different interrupt service routines for interrupt 08h.
  • the first interrupt service routine, 180-INT is illustrated in Figure 48
  • the second, 180-RCV is illustrated in Figure 49.
  • the second interrupt service routine 180-RCV is used when the datalink is in a receive and the first interrupt service 180-INT is used at all other times when the virtual network is active.
  • interrupt service routine 180-RCV all interrupts other than interrupt 08h are disallowed and assumptions are made about the states of the registers upon entry into the interrupt service routines, as described more completely below.
  • Interrupt service 180-INT upon entry first accesses save registers 180-INTl which saves the necessary registers for the interrupt. Subsequently, increment delay count 180-INT2 increases the delay count. Operations 180-INT3 through 180-INT10 examines the two timeout variables, described previously, and if either variable represents a timeout, the timeout flag is set. Otherwise, the timeout variables are decremented.
  • receive active flag check 180-INT11 ascertains whether the receive active flag is set. If the flag is not set, chain to interrupt 08h 180-INT13 chains through to the old interrupt 08h and then passes processing to restore registers 180-INT14. Restore registers 180-INT14 resets the registers' values to those saved in save register 180-INTl and then return 180-INT15 returns processing to the calling function.
  • BIOS services 180-INT12 If the receive active flag is set, processing transfers to perform BIOS services 180-INT12. Other processes may be serving interrupt 08h and these processes may take an inordinate amount of time to complete. Therefore, to enhance speed, the function does not chain to the old interrupt 08h. Rather, perform BIOS services 180-INT12 provides the minimum set of services that are normally provided by the BIOS.
  • BIOS time count at address 0:46Ch is incremented. If the BIOS timer count equals 1800B0h (one day) , the BIOS timer count is set to zero and the BIOS timer overflow flag is set to one. Next, if the BIOS drive time counter at address 0:44Oh is greater than one, the BIOS drive timer is decremented. This completes the services in perform BIOS service 180-INT12.
  • the second interrupt 180-RCV1 (Fig. 49) has been optimized for the maximum speed.
  • an interrupt service routine saves the current registers before any other processing. However, this routine saves only register AX. The routine also uses only register AX. However, the routine does access memory so that a segment register pointing to the segment of memory to be accessed is required.
  • the normal interrupt service routine saves at least one segment register and then loads the segment register for the interrupt service routine.
  • all other interrupts are disabled and this interrupt is enabled only during a small section of the datalink function DRECEIVE, which already has a segment set to the datalink data segment. Since all other interrupts have been turned off, no other interrupt service routines can become active when this interrupt becomes active.
  • the operations in the interrupt service routine 180-RCV1 include save register 180-RCV1, increment the delay count 180-RCV2, and check the intercharacter timeout value 180-RCV3. If the intercharacter timeout value is greater than one, the timeout is incremented and processing returns to end of interrupt 180-RCV5. Otherwise intercharacter timeout check 180-RCV3 passes processing directly to end of interrupt 180-RCV5. End of interrupt 180-RCV5 signals the end of the interrupt to the interrupt controller and restores the register AX. Finally, return 180-RCV6 returns processing to the calling program.
  • Datalink function DRECEIVE is used by the transport layer to wait for a message to be received. On receipt of a message, function DRECEIVE returns the actual length of the message. DRECEIVE is passed the node ID, the length of the receive buffer, a pointer to the receive buffer, and a timeout value corresponding to the number of ticks to wait for data. Function DRECEIVE returns the length of the message or an error code.
  • FIG. 47 One embodiment of datalink function DRECEIVE 180-R is illustrated in Figure 47.
  • Initialize 180-R1 sets the timeout variable to the passed parameter and the timeout flag to zero.
  • Processing subsequently transfers to get packet size 180-GPS (Fig. 46) .
  • error check 180-R2 passes processing to initialize receive 180-R7 if an error was not generated.
  • error check 180-R2 passes through error check 180-R2 to set error 180-R3 which in turn sets the error code to the result of get packet size 180-GPS.
  • set timeout 180-R4 sets the timeout variable and the intercharacter timeout variable both to zero.
  • Timeout error check 180-R5 passes processing to error return 180-R6 if a timeout error is not detected. If timeout error check 180-R5 detects a timeout error, processing transfers to send packet size 180-SPS prior to returning to error return 180-R6. Send packet size 180-SPS functions as previously described (Fig. 45) .
  • Initialize receive 180-R7 upon receiving processing from error check 180-R2, first turns on the receive active flag and then sets the timeout variable to zero and the intercharacter timeout variable to six. Initialize receive 180-R7 then turns on interrupt service routine
  • Step 180-R11 ascertains whether the address is at 0:0h. If the address is not at 0:0h, the read character is not stored by store character 180-R12. Step 180-R11 could be removed from function 180-R and is used only to support the check line connection operation in function DCONNECT and the check line listen operation in function DLISTEN. As described more completely below, both these operations could be moved into the transport layer obviating the need for step 180-R11. After buffer address 180-R11, adjust variables
  • 180-R13 increments the character received count and sets the intercharacter timeout variable to three. More character test 180-R14 then ascertains whether there are more characters to receive. If more characters are remaining to be sent, processing transfers to UART status 180-R8 and processing proceeds as previously described. If there are no more characters available, update 180-R15 adds the number of characters received to the number of characters received since the last reset and sets the error code to the characters received. Restore interrupt 180-R24 turns off interrupt service routine 180-RCV and turns on interrupt service routine interrupt 180-INT. Processing then transfers to set timeout 180-R4.
  • framing error check 180-R18 passes processing to UART status 180-R8 upon detection of a framing error. Otherwise, processing transfers through to restore interrupt 180-R24-A which, as previously described, turns on interrupt service routine 180-INT and turns off interrupt service routine 180-RCV. Subsequently save timeout 180-R19 saves the timeout values for the timeout variable and the intercharacter timeout variable and then speed resync 180-R20 functions as previously described. Upon completion of speed resynchronization, restore timeout 180-R21 restores the timeout and intercharacter timeout values to the saved parameters. If speed resynchronization generated an error, error check 180-R22 passes processing to set timeout 180-R4.
  • restore 180-R23 restores all parameters to the values upon entry and transfers processing back to the start of function DRECEIVE 180-R.
  • Datalink function DCONNECT 180-C (Fig. 50) is called in response to transport layer function TCONNECT.
  • Function DCONNECT attempts to establish a connection with the specified remote node.
  • the calling function passes the nodeid, a speed parameter, the port for the connection and the number of ticks to wait for data.
  • the nodeid parameter is redundant.
  • the speed parameter passed to function DCONNECT if non-zero, is the desired baud rate divided by 100.
  • set connection status 180-Cl Upon entry to function DCONNECT 180-C (Fig. 50) , set connection status 180-Cl first sets the connection status flag to -1 to indicate a connection is being attempted. Subsequently, main initialization 180-MI, which is shown in more detail as steps 180-MI1 through 180-MI8 in Fig. 51, initializes the general conditions. Specifically, save interrupt 180-MI1 first gets the current interrupt 08h vector and saves it. Next, clear flag 180-MI2 clears the receive active flag, and set interrupt 180-MI3 sets interrupt 08h to interrupt service routine 180-INT. Initialize variables 180-MI4 initializes the other variables in DCONNECT and those used in other functions to the required values. Subsequently, call set speed 180-SS functions as previously indicated to set the speed for the transmission. Disable 180-MI5 disables all UART interrupts, while clear registers 180-MI6 reads the status and data from the UART to clear the registers.
  • calculate speed 180-MI7 counts the number of times the register pair DX:AX can be incremented during the timespan between two clock ticks and stores that value in a variable called loop count in this embodiment.
  • Return 180-MI8 returns processing to connect/ listen initialization 180-CLI in Figure 50.
  • set timeout 180-CLI1 sets the timeout variable to the parameter passed to function DCONNECT
  • Speed check 180-CLI2 passes processing to return parameter 180-CLI5 if the speed parameter was passed to DCONNECT. Return parameter 180-CLI5 returns the index of the passed parameter. Conversely, if a speed parameter was not given, i.e. zero was passed to function DCONNECT, set parameters 180-CLI3 sets the speed parameter to the maximum baud rate and return 180-CLI4 returns the index of 300 baud to set baud rate index 180-C2 (Fig. 50) .
  • Set baud rate index 180-C2 sets the baud rate index to the value return by connect/listen initialization 180-CLI. Subsequently, processing passes to speed valid check 180-C3 which ascertains whether the requested speed is valid.
  • Set error 180-C4 transfers processing to set connection status 180-C1-A which sets the connection status flag to zero and then passes processing to restore 180-C14.
  • Restore 180-C14 denies UART divisor access, disables UART interrupts, and then resets interrupt 08h to the old interrupt 08h vector that was stored. Processing then transfers to return 180-C15.
  • speed valid check 180-C3 transfers processing to set speed 180-SS, which functions as previously described to set the requested speed. Subsequently, speed arbitration 180-C5 ascertains whether a specified speed was set or speed arbitration requested.
  • timeout check 180-C12 ascertains whether a timeout has occurred. If a timeout has occurred, set error 180-C13 sets the return value to timeout error and transfers processing to set connection status 180-C1-A, which was previously described.
  • timeout check 180-C12 transfers to receive character status 180-RCS, which functions as previously described. If no character is ready, or the character received by receive character status 180-RCS is not an acknowledgment of the end of transmission, processing returns to transmit character 180-C11. However, if character test 180-C16 detects an acknowledgment of the end of connect, processing transfers to set delay count 180-DC-A which functions as previously described. Connection set 180-C1-B sets the connection status flag to zero and processing transfers to return
  • speed arbitration 180-C5 detects a zero value, processing transfers to set character 180-C6 which in turn sets the connection character to a first character. Subsequently, set connect speed 180-CS performs the functions previously described with respect to Figs. 39a and 39b.
  • Set connect character 180-C6-A sets a second connect character and passes processing to set connection status 180-C1-A.
  • Set connection status 180-C1-A sets the status connection flag to zero.
  • set delay count 180-DC functions as previously described and baud rate check 180-C7 passes processing to set delay count 180-DC-A, if the baud rate is less than or equal to 19,200.
  • baud rate check 180-C7 passes processing to check lines send 180-CLS which is described more completely below with respect to Fig. 53.
  • error check 180-C8 Upon the completion of check line send 180-CLS, error check 180-C8 ascertains whether an error was returned. If an error was returned error check 180-C8 transfers processing to set connection status 180-C1-A which functions as previously described. Conversely, if no error was returned, error check 180-C8 passes transfer to receive block 180-C9 which calls datalink function DRECEIVE to receive a block of data from the remote node with a 15 second timeout. If the block is received without error, error check 180-C10 passes processing to set connection status 180-C1-A. Otherwise 180-C10 passes processing to set delay count 180-DC-A. In connect 180-C, operations 180-CLS, 180-C8, 180-C9, and 180-C10 are used to verify the operation of the line connecting the computers. In another embodiment, these operations would be moved into the transport layer for improved efficiency.
  • Function check line send 180-CLS is shown in more detail in Fig. 53.
  • send block 180-CLS1 Upon entry send block 180-CLS1 first generates a block of data and then calls datalink function DSEND to send this block of data across the virtual network. If DSEND functions without error, error check 180-CLS2 passes processing to return 180-CLS3. However, if send block 180-CLS1 generates an error, processing is transferred by error check 180-CLS2 to drop speed 180-CLS4. Drop speed 180-CLS4 calls datalink function DRESET with the parameter indicating a change of speed. Accordingly, function DRESET operates as previously described. If DRESET returns an error, error check
  • 180-CLS5 transfers processing to error return 180-CLS6 which sets the carry flag and returns to the calling function. If an error is not returned from drop speed 180-CLS4, error check 180-CLS5 initiates the line check at the lower speed by again calling send block 180-CLS1.
  • the datalink function corresponding to function DCONNECT is function DLISTEN, which waits for a DCONNECT request to arrive, signaling the start of a session. DLISTEN also prepares to perform arbitration on the line speed to determine the optimum line speed. DLISTEN is passed the speed, a timeout value, and a port for the connection.
  • Fig, 54 One embodiment of function DLISTEN is illustrated in Fig, 54.
  • Operations 180-L1 through 180-L2 are equivalent to operation 180-Cl through 180-C2 described above for Figure 50, which are incorporated herein by reference.
  • Speed valid 180-L3 passes processing to set error 180-L4 if the requested speed is invalid.
  • Set error 180-L4 sets the return value to invalid line speed error and subsequently transfers processing to set connection status 180-CS, which sets the connection status flag to zero.
  • restore 180-L6 performs the same operations as previously described for restore 180-C14 (Fig. 50) , which are incorporated herein by reference.
  • speed valid check 180-L3 transfers processing to set speed 180-SS which functions as previously described.
  • set connect character 180-L9 establishes a first connection character and then set listen speed 180-LS functions as previously described.
  • set connect character 180-L10 sets a connection character different from that set by set character 180-L9. If set listen speed 180-LS generates an error, error check 180-L11 transfers processing to set connection status 180-L5 which functions as previously described.
  • error check 180-L11 transfers to speed arbitration 180-L12. If the passed speed parameter is not zero, speed arbitration 180-L12 passes control to set delay count 180-DC-A which functions as previously described.
  • speed arbitration 180-L12 transfers to set delay count 180-DC, again which functions as previously described.
  • Baud rate check 180-L13 returns through 180-L14 to the calling program if the current baud rate is less than 19,200. If the baud rate is greater than 19,200, baud rate check 180-L13 goes to set timeout 180-L15 which sets the timeout value to 15 seconds.
  • verify connection 180-L16 calls datalink function DRECEIVE to verify a connection. If the DRECEIVE generates an error, error check 180-L17 transfers to timeout 180-L18. Timeout 180-L18 checks for a timeout error. If a timeout error is detected, error return 180-L19 returns processing with a timeout error, otherwise timeout check transfers processing to set timeout 180-L15.
  • Function DSTATUS places the status information requested in the supplied buffer. Specifically, the nodeid is set to one. The variables used to track the number of bytes sent and received since the last reset are placed in the structure and the speed index is used to lookup the current speed which is subsequently placed in the buffer. The buffer is then returned to the transport layer.
  • Function DFLUSH in this embodiment is a null operation and so the function simply returns to the calling function.
  • any user application can be adapted to use the virtual network executive of this invention to transfer information between two computer systems.
  • the user application must simply provide the information and the commands previously described for the application layer.
  • Two user applications are described below for use with the virtual network executive of this invention.
  • One of the user applications called "PoqetLink”, is a user interface application for the MS-DOS operating system. PoqetLink allows any person with minimal knowledge of MS-DOS to manage disk files.
  • PoqetLink allows the user to manipulate files and directories with the capabilities to copy, delete, rename, print and view files as well as being able to view create, and remove directories.
  • PoqetLink allows the user to manipulate files and directories with the capabilities to copy, delete, rename, print and view files as well as being able to view create, and remove directories.
  • user application PoqetLink allows manipulation of the virtual network executive through attach, detach, connect, disconnect, serve and configure commands.
  • the PoqetLink program provides a user interface and converts user commands provided through that interface into the appropriate sequence of commands and information for the virtual network executive of this invention.
  • the virtual network architecture system must be loaded into the computer before executing PoqetLink.
  • the local and remote computers must be directly connected, i.e., have an RS232 connection, with a virtual network architecture and user application PoqetLink active on both computers.
  • PoqetLink commands the user, for example, highlights a file to act upon using the cursor control keys and then presses the menu key (function key F10) and uses the cursor control keys to highlight the appropriate item, for instance, "FILE.” The user then presses the return key and again uses the cursor control keys to select the appropriate option, "COPY" for example. Pressing the enter key then causes the option to execute and the user is prompted for any additional information needed.
  • the user first sets PoqetLink on one machine to server mode (this is the same as designating the machine to be a remote machine) .
  • the local machine the user instructs PoqetLink to establish a logical connection to the remote machine by performing the connect function.
  • the virtual network executive connection is established, all processes involving the remote disk drive(s) are redirected across the virtual network to the remote machine.
  • the PoqetLink connect request establishes the virtual network executive VCONNECT, as previously described. If the connection is successful, a list of available drives of the remote machine is retrieved via a generic send/receive exchange between the local machine and the server machine. Specifically, PoqetLink uses the generic send/receive messages, previously described, to obtain the list of available drives. The current drive of the server machine is then mapped to an available local drive. If there is more than one remote drive, the other remote drives are not mapped. The user must execute the PoqetLink attach option from the volume menu to map any other remote drives. After attachment, remote drives are treated as local drives.
  • the virtual network server processes out after a selected time period if a connect request is not received. If such a timeout occurs,
  • PoqetLink reinitiates the virtual network serve request. If the server receives a disconnect request, the disconnect performs a virtual network executive reset and then returns control to user application PoqetLink which displays the main PoqetLink screen.
  • PoqetLink permits file manipulation without direct knowledge of the MS-DOS operating system.
  • PoqetLink the user tags (or marks) one or more files of one or more directories and then executes the desired function.
  • tag is a function in PoqetLink that is used to indicate files that will be affected by the file copy and delete functions.
  • To tag a file the user moves the highlight bar to that file name and presses the tab key or alternatively uses the tag option of the tag menu. If a directory name is tagged and that directory is open, all the files within that directory are tagged.
  • Untag is a function in PoqetLink used to unmark files. To untag a file, the user moves the highlight bars to the file name and presses the shift and tab keys simultaneously or uses the untag option of the tag menu. If a directory name is untagged and that directory is open, all files within that directory are untagged. Clear tags is a tag menu option to untag all tagged files.
  • the user tags the files to be copied and executes the copy option from the file menu.
  • PoqetLink then asks for the copy destination.
  • the user may supply the full drive and directory path, or the path only. If no drive is given the files tagged are copied to the current drive.
  • the current drive may be changed by using the change volume command of the volume menu.
  • the highlight bar is positioned on the name of the file to be renamed and the rename option is executed from the file menu.
  • PoqetLink has a print command that is similar to the print command available with DOS except that this print command can print a file to a remote printer.
  • Remote printing requires that PoqetLink be connected to a PoqetLink server with a printer and that PoqetLink is configured to use the remote printer.
  • the files to be printed are tagged and then the print option on the file menu is selected. If no files are tagged, then the current highlighted file is printed.
  • Another PoqetLink function is view. View is like the type command in MS-DOS, but view provides more capability. To view a file, the user positions the highlight bar on the file name and then presses control enter, or executes the view option of the file menu.
  • PoqetLink accesses the specified information using the appropriate application layer commands described above, and when the information is retrieved by the virtual network executive, PoqetLink the provides the necessary coding to display the text on the screen.
  • PoqetLink To view directory information with PoqetLink, the user opens that directory.
  • PoqetLink initially opens the root directory and that directory remains open.
  • PoqetLin shows directory information in a list and when a directory in the middle of the list is open, PoqetLink inserts the directory information at that position in the list. The user can browse the list by scrolling up and down, paging up and down, going to the beginning or to the end of the list, or moving forward and backward to a directory name.
  • PoqetLink maintains a status of all directories in the list either as open or as closed.
  • the directory level is subindented, i.e., the root or parent directory occupies the first column and its subdirectories are indented, and subdirectories of subdirectories are further indented.
  • the user To view information of a subdirectory when its parent directory status is closed, the user must position the highlight bar in the parent directory and perform an open directory. Subsequently, the user must position the highlight bar on the subdirectory and perform an open directory.
  • To create a new subdirectory, ⁇ A ⁇ B the highlight bar is positioned on the A directory and the directory option is selected. If the directory A is not open, it is opened by pressing the insert key. The PoqetLink make directory selection is then executed. The user is prompted for the name of the new subdirectory, which is now created. Similarly, to remove a directory using PoqetLink the highlight bar is positioned on the name of the directory to be removed and then the remove directory option is selected.
  • the PoqetLink user application provides a series of menu selections wherein the user selects a file or a directory and then a second menu option to perform these operations upon the selected files or directory.
  • PoqetLink Upon the user selecting a command, PoqetLink then converts the user selection into a series of operations i.e., the application layer commands described previously to perform the operation requested by the user.
  • a second user application requires that the remote mode be placed in the server mode using PoqetLink.
  • the second user application is then loaded in the other machine and used to obtain disk directory information for the server.
  • the embodiment of this invention as described above, was designed for operation with IBM personal computers and IBM compatible personal computers. However, this embodiment was illustrative only of the principles of this invention and was not intended to limit the scope of the invention to the particular embodiment described. In view of this disclosure, those skilled in the art can now implement the novel virtual network executive of this invention in other computer architectures and in other computer programming languages.
  • the virtual network architecture of this invention is interposed between user applications and the computer operating system.
  • the virtual network is included on a read-only memory (ROM) in the computer and is loaded as part of the ROM BIOS.
  • the virtual network would be loaded as a terminate-and-stay-resident program. In either case, after loading the virtual network functions as a terminate-and-stay-resident program.
  • the executable code and data were separated into a memory resident portion and a transient portion, which were both loaded in random access memory (RAM) (i.e., main memory 17B (Fig. 1)) .
  • RAM random access memory
  • the memory resident portion contained executable application code and data.
  • the transient portion installed the executable application code.
  • the prior art transient portion of the terminate-and-stay-resident (TSR) program initialized data and interrupt handlers contained in the memory resident portion and executed an MS-DOS function that left the RAM resident portion in RAM and freed the memory used by the transient portion.
  • the executable application code for virtual network architec ⁇ ture is ran directly from ROM and not RAM as in prior art TSR programs. Since relocation cannot be performed on a ROM-based executable program image, a novel "loader” is used to configure the computer system for execution of the ROM-based executable program image.
  • an executable program image is the same as the "executable image” described above.
  • the loader of this invention is not limited to ROM-based TSR applications. In general, the loader of this invention configures a computer system for execution of any executable program image from ROM including both memory card ROMs and permanently installed ROM within a computer such as the ROM BIOS.
  • FIG. 55A One embodiment of a computer system 1220 including loader 1100 of this invention is illustrated in Figure 55A.
  • Computer system 1220 (Fig. 55A) includes an input module and an output module similar to those described previously for prior art system 20 (Fig. 1) . However, for clarity, only the key components associated with loader 1100 are illustrated in computer system 1220 (Fig. 55A) .
  • loader 1100 is stored on secondary memory 1217A of computer system 1220 as either a .EXE file or a .COM file.
  • Read-only memory ROM 1230 contains executable program image 1250 associated with loader 1100.
  • Random access memory 1217B contains operating system 1203.
  • CPU 210 communicates with ROM 1230, RAM 1217B and secondary memory 1217A over paths 1240, 1241, and 1242 respectively.
  • path 1243 connects secondary memory 1217A and 1217B and is used to illustrate that CPU 1210 may move a file such as loader 1100 directly into RAM 1217B using operating system 1203.
  • the operation and architecture of computer system 1220 are equivalent to prior art system 20 (Fig. l) and therefore are known to those skilled in the art.
  • Loader 1100 (Fig. 55A) of this invention is loaded into RAM 1217B by operating system 1203. For example, loader 1100 is placed into the portion of RAM 1217B between addresses XXX and YYY by operating system 1203 in the conventional method described above in response to a user's instruction to execute loader 1100 for a particular ROM-based executable program image 1250. Once loader 1100 is in RAM 1217B, loader 1100 sets up the conditions required for execution of ROM-based executable program image 1250 directly from ROM 1230. Specifically, initialization means 1100-1 (Fig. 55B) initializes computer system 1220 (Fig. 55A) for execution of ROM-based executable program image 1250. Initialization means 1100-1 configures a data area in RAM 1217B for ROM-based executable program image 1250.
  • loader 1100 After the necessary conditions for direct execution of the ROM-based executable program image 1250 are established, loader 1100 preferably removes itself from RAM 1217B using means for releasing RAM 1100-2 (Fig. 55B) . After loader 1100 removes itself from RAM 1217B, the data area for ROM-based executable program image 1250 is left in memory. ROM-based executable program image 1250 (Fig. 55A) is, thus, configured to execute directly from ROM 1230.
  • loader 1100 in one embodiment, includes a means for initializing computer system 1220 for execution of ROM- based executable program image 1250 directly from ROM 123 and means for releasing RAM.
  • loader 1100 includes means for releasing the random access memory used by the loader itself, the loade of this invention would function properly without releasing the RAM utilized by the loader. However, such an embodiment would obviously result in somewhat diminished efficiency in utilization of RAM 1217B because loader 1100 would occupy RAM when loader 1100 was no longer needed.
  • loader 1100 makes it possible to operate portable computers using executable program images on either ROM cards or any other ROM in the computer.
  • loader 1100 depends on both ROM-based executable program image 1250 and the steps used to generate loader 1100. In each case, loader 1100 performs the steps necessary to insure proper execution of the ROM-based application.
  • Loader 1100 of this invention is illustrated in more detail Figure 56A.
  • loader 1100 includes data area initialization means 1110, application existence verification means 1120, and setup means 1130.
  • Data area initialization means 1110 configures a data area in RAM for the ROM-based executable program image.
  • Data area initialization means 1110 includes (i) means for creating a working data area 1110-1 (Fig. 56B) for the ROM-based executable program image in RAM and (ii) means for data initialization 1110-2, which initializes within the data area the necessary variables for execution of the ROM-based executable program image directly from ROM.
  • Application existence verification means 1120 ensures that the ROM-based executable program image is physically present on a ROM in the computer system. If application existence verification means 1120 finds the ROM-based executable program image, loader 1100 continues operation with setup means 1130. However, if the ROM-based executable image is not on a ROM within the computer system, an error message is sent to the user by error message means 1150, and loader 1100 terminates through terminate means 1140.
  • Setup means 1130 sets the data segment register as well as any other registers and/or vectors that are required by the ROM-based executable program image.
  • the operation of setup means 1130 depends upon the nature of the ROM-based executable program image, as described more completely below.
  • setup means 1130 at least releases the RAM required by loader 1100 itself, and turns control of the computer system over to the ROM-based executable program image. After loader 1100 releases the RAM it required, the data area for the ROM-based executable program image remains in RAM.
  • the execution of the ROM-based executable program image depends upon the nature of the ROM-based executable program image.
  • the executable program images may be divided into (i) TSR applications and (ii) non-TSR applications. For non-TSR applications, control is turned over to the ROM-based executable program image, and the
  • ROM-based executable program image is executed directly after the initialization of the RAM data area. Upon completion of the execution, the ROM-based executable program image exits normally to the MS-DOS operating system.
  • setup 1130 may configure the ROM-based executable program image as a TSR program, as described more completely below.
  • the ROM- based executable program image may (i) setup the necessary interrupt vectors, (ii) execute ROM-based code that configures the application as a TSR program and
  • loader 1100 contains the structure necessary to perform the operations that are required for execution of the ROM-based executable program image directly from the ROM.
  • the structure of create working data area means
  • loader 1100 for the ROM-based executable program image depends (i) upon the form of the executable program image file, i.e., whether loader 1100 is a .EXE executable image file or a .COM executable image file, and also, in some cases, (ii) upon the size of the data area required for execution of the ROM-based executable program image directly from ROM.
  • source code such as assembly code
  • the .EXE file can be converted to a .COM file using the MS-DOS operating system.
  • the operating system allocates 64 Kbytes of RAM so that loader 1100 of this invention is not required to create a working data area for a .COM file as long as the ROM-based executable program image requires a data work area of less than 64 Kbytes.
  • the data modules for the ROM-based executable program image may be linked with the compiled source code for loader 1100.
  • the .EXE file that is generated for loader 1100 contains in the header of the .EXE file the size of the data area required for the execution of the executable program image. Accordingly, in this embodiment, create working data area means 1110-1 is not required to specifically allocate a working data area for execution of the ROM-based executable program image directly from ROM.
  • create working data area means 1110-1 allocates the additional RAM required.
  • the memory initially allocated to loader 1100 by the operating system upon execution of loader 1100 is from memory addresses XXX to YYY (Fig. 57A) . This memory allocation is all that is required so that no further memory allocation operations are performed by loader 1100.
  • the operating system allocates loader 1100 memory in RAM from addresses XXX to YYY (Fig. 57B) .
  • loader 1100 only requires memory stemming from addresses XXX to AAA so that the memory from addresses AAA to YYY is released by loader 1100.
  • loader 1100 is allocated memory from addresses XXX through YYY by the operating system, but loader 1100 requires more memory the for the ROM-based executable program image data area so that loader 1100 uses the operating system to allocate additional memory from addresses YYY to BBB.
  • the first embodiment corresponds, for example, to a loader .EXE file that contains the required memory size in the file header.
  • the second embodiment corresponds, for example, to a loader that is a .COM file where the operating system allocates 64 Kbytes, but the executable program image requires a data area of less than 64 Kbytes.
  • the third embodiment (Fig. 57C) may be, for example, a loader .COM file for an executable program image that requires more than 64 Kbytes of data area.
  • data area initialization means 1110 The operations performed by data area initialization means 1110, existence verification means 1120, and setup means 1130 are described more completely below with respect to specific embodiments of loader 1100 of this invention.
  • loader 1100A (Fig. 58A) is used to configure a library of ROM-based functions in a portable computer, such as that described in copending and commonly assigned U.S. patent application serial number 07/375,721, entitled “Portable Low Power Computer” of John P. Fairbanks et al. filed on June 30, 1989 which is incorporated herein by reference in its entirety, as a terminate-and-stay-resident application.
  • the source code for this embodiment and each of the other embodiments described below was written in assembly language and compiled using the Microsoft Macro Assembler, version 5.1.
  • the compiled code was linked using Microsoft Overlay Linker, version 3.65. Both the Macro Assembler and the Overlay Linker are available from Microsoft Corp. of Redmond, Washington.
  • the data segment information for the ROM-based library of functions is linked with the compilation of loader 1100A source code to create an executable file, i.e., a .EXE file.
  • the data segment information required is determined by the ROM-based executable program image. For most well behaved TSR programs, at least the vector of the previous interrupt that the TSR program takes over must be maintained in the data segment information so that the TSR program can chain to that interrupt.
  • Loader 1100A supports any ROM-based library functions so long as the initialization operations, described more completely below, required for execution of the functions directly from ROM are incorporated in loader 1100A.
  • ROM-based library function loader 1100A When ROM-based library function loader 1100A is executed by the operating system, the operating system reads the .EXE file header and allocates sufficient random access memory RAM for both loader 1100A and the data segment for the ROM-based library functions. In addition, as is known to those skilled in the art, the operating system places a program suffix prefix (PSP) in memory to designate the start of loader 1100A. Generation of the PSP is a standard function performed by the MS-DOS operating system and is described in more detail in P. Duncan, Gen. Ed., The MS-DOS Encyclopedia. Microsoft Press, Redmond, Washington, pp. 108-111, 1988, which is incorporated herein by reference.
  • PSP program suffix prefix
  • the executable program image for loader 1100A contains sufficient information for the operating system to allocate the required working data area for the ROM- based library functions
  • the only operation performed by means for creating the working data area lllOA-1 is setup segments lllOA-1-1 which sets the segment registers DS and ES to the data segment.
  • the stack for the ROM-based library functions is within the data segment.
  • Initialize data area 1110A-2 (Fig. 58A) includes four operations in this embodiment.
  • Initialize data segment means 1110A-2-1 zeroes the RAM in the data segment. This is done as a clean-up for the data area.
  • Store PSP means 1110A-2-2 stores the address of the program segment prefix for later use.
  • Variable initialization means 1110A-2-3 initializes all necessary variables for the subsequent execution of the ROM-based library of functions. In this embodiment, this requires (i) storing the old interrupt vector pointer used for interrupt chaining by the functions in the library; (ii) the initialization of a menu system memory allocation scheme and (iii) initial ⁇ ization of words that are used to store the data segment for other ROM-based applications that utilize the library of functions.
  • loader 1100A initializes, in the RAM data area, all the necessary variables for the subsequent execution of the executable program image from ROM.
  • the oper ⁇ ating system uses the loader's PSP to track certain data that is unique to loader 1100A including command-line parameters and the segment address of the loader's environment. Accordingly, the last operation in initiali ⁇ zation of data area 1110A-2 is process command line 1110A-2-4.
  • command line lllOA-2-4 the PSP is accessed by look up 1110A-2-4-1 (Fig. 58B) to obtain any command line argument. If the command line argument is "I", command line argument check function 1110A-2-4-2 transfers processing to report version number 1110A-2-4-3 of command line processor 1110A-2-4-10 which in turn reports the version number of the ROM-based executable program image and terminates normally through terminate 1140A.
  • command line argument check function 1110A-2-4-4 passes processing to reset 1110A-2-4-5 of command line processor 1102A-2-4-10 which in turn resets the data area and terminates normally through terminate 1140A.
  • command line argument check function 1110A-2-4-6 transfers processing to unload 1110A-2-4-7 of command line processor 1102A-2-4- 10 which removes loader 1100A and any other information associated with the ROM-based executable program image from memory and terminates normally through terminate 1140A.
  • PSP lookup 1110A-2-4-1 does not detect a command line argument, processing passes through the three check functions 1110A-2-4-2, 1110A-2-4-4, and 1110A-2-4-6 to verify existence means 1120A (Fig. 58C) .
  • check memory means 1120A-1 checks to ascertain whether the ROM-based library of functions is already loaded.
  • the code located at the interrupt vector that loader 1100A plans to take over is checked to ascertain whether the code represents the library of functions. Upon installation of the library, the code is "VNA". Thus, if check 1120A-1 detects the string "VNA ", the library of functions is already loaded in the computer system. If the library of functions is already in memory, error message 1150A generates an error message that the library functions are already in memory and processing terminates normally through terminate 1140A. However, if the library functions are not already loaded, ROM check means 1120A-3 checks to ensure that the library of functions is in a ROM in the computer system.
  • means 1120A-3 checks for the string code for the library, i.e., "VNA". If the ROM-based library functions are not available, ROM check means 1120A-3 passes processing to error message 1150A which in turn generates a message that the library functions are not in ROM. Processing subsequently transfers to terminate 1140A which in turn performs the operations necessary to restore the computer system to the configuration prior to initiation of the execution of loader 1100A. These operations are the normal operations performed upon termination of an executable program image and as such are known to those skilled in the art. Upon verification that the ROM-based library functions exist, processing transfers from ROM check means 1120A-3 to setup 1130A (Fig.
  • loader 1100A for the ROM-based library functions eliminated the problems associated with relocations by effectively setting up in RAM the data area and the conditions required by the ROM-based library functions for execution.
  • loader 1100B (Fig. 59A-59D) is a .COM file.
  • Loader 1100B not only performs the steps necessary to run the ROM-based application program, but also includes steps to set up the ROM-based application program as a terminate and stay resident program.
  • the structure of data area initialization means 1110B and application existence verification means 112OB are somewhat different from means 1110A and 1120A of the previous embodiment.
  • the change in structure provides the most rapid response to the user. This demonstrates that in view of this disclosure, one skilled in the art may arrange the structure of each element of the loader of this invention to achieve speed or other functionality in addition to the basic objective of configuring computer system for execution of the ROM-based application directly from ROM.
  • a specific segment of memory i.e. 64 Kbytes of memory
  • the only operation in create work data area lllOB-1 is to simply set up the stack within the data area allocated by the operating system.
  • the data area is not zeroed by loader 1100B because each of the ROM-based applications sets up its data area to assure that the RAM is properly initialized.
  • data area initialization means 1110B-2 first uses memory check 1110B-2-1 to ascertain whether the ROM-based library functions are loaded. Specifically, the code associated with the interrupt vector for the ROM-based library functions is checked to see if the code is the string "VNA" If the library functions are not loaded, processing transfers to error message 1150B. Error message 1150B sends the user a report that the library functions were not found and processing terminates normally through terminate 1140B. Terminate 114OB functions in a manner equivalent to that described above for terminate 1140A.
  • Map 1110B-2-2 accesses an interrupt function in the extended BIOS of the computer, described in copending and commonly assigned U.S. patent application serial number 07/375,721, entitled “Portable Low Power Computer” of John P. Fairbanks et al. filed on June 30, 1989 and in commonly assigned and copending patent application serial no. 07/374,691 entitled “Method and Apparatus For Information Management In A Computer System” of Ian H.S. Cullimore, filed on June 30, 1989, both of which are incorporated herein by reference in their entirety, to establish address segment EOOOh as the ROM-based application.
  • the extended BIOS is instructed to address the segment from either the BIOS ROM or a ROM memory card in the computer system.
  • processing transfers to verification means 1120B. If the application specified by loader 1100B is detected in ROM by ROM check 1120B-1 (Fig. 59B) , (i.e. the string "PQTL" is "detected") processing continues. However, if the application is not in ROM, processing transfers to error message 1150B. An application not in ROM error is reported by error message 1150B and processing terminates normally.
  • ROM check 1120B-1 the version of the operating system is checked by operating system check 1120B-2 to assure that the operating system is compatible with the ROM-based application. If the operating system is not compatible, error message 1150 generates an operating system incapability error report and processing terminates normally.
  • memory check 1120-B-3 determines whether the ROM-based application is already loaded in the computer system. Recall that in loader 1100A, variable initialization means 1110A-2-3 (Fig. 58B) , initialized words that are used to store the data segment for ROM-based applications that use the library of functions. In this embodiment, the words are initialized to zero. When an application is loaded, the appropriate word is changed to be non-zero. Hence, memory check 1120-B-3 simply determines whether the word is zero or non-zero to ascertain whether the application is already loaded. If the ROM-based application is not loaded, processing progresses to setup 113OB which is described more completely below.
  • look-up 1120B-4 accesses the PSP command line check 1120B-5. Recall that in the previous embodiment, look-up was included in data area initialization means 1110A.
  • Command line check 1120B-5 determines whether the user has entered a "U”. If the command line contains a "U”, command line processor 1120B-6 releases memory allocated to loader 1100B and zeroes the word indicating whether the application is loaded. The processing then terminates normally. However, if the command line does not contain a "U" or contains no parameter, error message 1150B reports that the application is already loaded. While command line processing was supported by both loaders 1100A and 1100B, command line processing is not required for proper operation of the loaders. The command line processing simply provides the user with an additional means of control over the ROM-based executable program image.
  • Setup 113OB for this ROM-based application is more complex than previously described setup 1130A for loader 1100A.
  • the first operation within setup 113OB is initialization of variables 1130B-1 which initializes the terminate and stay resident variables in the RAM data area for the application. In this embodiment, there are two far jumps which are established and then an Alar ⁇ AFlag is cleared and the interrupt vectors are saved.
  • the Alarm_Flag is used in the sounding and alarm functions of the ROM-based application.
  • An INDOS counter and the disk transfer address are also initialized.
  • register set 1130B-2 initializes register AX for a jump after the data memory allocation for the TSR.
  • Move 1130B-3 (Fig. 59D) relocates the revector and interrupt code for the TSR to make room for the memory data allocation and register AX is also reset to the eventual location of the revector code. Processing than jumps to the revector location in register AX.
  • reset TSR interrupts 1130B-4 the TSR interrupts are reset to allow for relocation of the interrupt vector code.
  • the ROM-based application entry code is called by entry means 1130B-6 to complete the initialization.
  • release means 1130B-7 releases unneeded RAM and leaves th ROM-based application configured as an installed TSR program.
  • the precise operations, e.g., the initializa ⁇ tion of specific variables, performed in setup 113OB are not an essential aspect of the invention. Rather, the important aspect is that for operation of the ROM-based application, the necessary relocations and initialization must be performed by the loader so that the ROM-based application functions correctly as a TSR program.
  • PoqetLink When PoqetLink is included as a ROM-based applicatio within the computer system, yet another embodiment of the loader is used. This loader requires less memory than is allocated by the operating system when the loader is executed. Thus, this loader deallocates memory as illustrated in Fig. 57B. Also, the ROM-based executable program image executes directly, as described previously for non-TSR applications, upon completion of the operatio of the loader including the loader removing itself from memory. As previously described, after the loader removes itself, the PSP and the data segment for the ROM-based PoqetLink application remain in RAM. In this embodiment, the ROM-based PoqetLink allocates additional memory as required.

Abstract

In a computer system including at least two computers (100, 200) coupled by an electronic means (150) for passing information between the computers, according to the principles of this invention, a virtual network executive (10, 20) is installed in each computer (100, 200). The network executive (102, 202) in a first mode of operation is used to send and receive information between computers (100, 200) in the system. In a second mode of operation, the virtual network executive (202) in all the computers (200) in the system save one are configured to service requests from the one computer (100). This configuration of one computer in a system of computers controlling and using the other computers is referred to as a virtual computer. The virtual network executive (202) adjusts the transmission parameters, packet size and transmission speed when errors are detected in communication between computers (100, 200).

Description

VIRTUAL NETWORK ARCHITECTURE AND LOADER
BACKGROUND OF THE INVENTION Field of the Invention
This invention relates generally to computer systems and more specifically to a computer system including at least two computers which are interconnected by a virtual network and function as either a single virtual computer or two interconnected computers for sending and receiving information over the virtual network.
Description of the Prior Art
Many different computing systems are available today but most of these systems are built around fundamental components such as those illustrated in Figure 1. Typically, the fundamental components of a computer 20, include a central processing unit 10 (CPU) which is connected through an input bus 11 to an input module 12 and through an output bus 13 to an output module 14. CPU 10 is also connected through data buses 15, 16 to a memory unit 17. CPU 10 provides control and computing functions. Input and output modules 12, 14 are used to communicate between the computer user and CPU 10. Input module 12 supplies information to CPU 10. Typical input devices are a keyboard and a mouse. Output module 14 displays information from central processing unit 10. Typical output modules include a video display monitor, a printer and other visual display means such as plotters. Input unit 12 and output unit 14 are frequently referred to as input/output (I/0) units.
Memory unit 17 typically contains two general types of information, instructions and data. A computer program is a sequence of instructions that are executed by the computer to perform a specific function. Data in memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is executing in CPU 10.
Memory unit 17 typically includes mass memory 17A, sometimes called secondary memory, and main memory 17B. Main memory 17B is a relatively fast memory, i.e. a typical access time is in the range from 20 to approximately 400 nanoseconds. Access time is the time interval between when CPU 10 requests data from memory 17 and when memory 17 makes the requested data available to CPU 10.
Main memory 17B is usually used to store at least a portion of the program currently being executed by CPU 10 and data required by this program. Mass memory 17A, such as disks and tapes, is used to store programs, data, or portions of either programs and data which are not needed immediately by CPU 10 or which cannot be accommodated in main memory 17B because of size limitations of main memory 17B. Since programs and/or data are transferred in and out of mass memory 17A at the direction of CPU 10, mass memory units are typically included in the generic term "I/O units." Mass memory 17A, is significantly slower than main memory 17B. Access time for mass memory is typically on the order of tens of milliseconds. A computer operating system is typically used to control the operation of CPU 10 (Fig. 1) , main memory 17B and I/O modules 12, 14, 17A. In addition, the operating system provides an interface between computer user applications and the hardware. As used herein, hardware refers to the physical components of a computer system. The operating system of a computer typically includes a kernel which (i) creates user processes, as described below, (ii) schedules execution of user processes, (iii) provides user processes with system services, and (iv) services hardware interrupts and exceptions. The computer operating system is usually loaded into main memory 17B when the computer is booted. As used herein, "booted" refers to the sequence of operations that are performed when either power is first applied to the computer or the computer is reset. The definition of a "user process" requires an understanding of the sequence of steps by which user source code, i.e., a computer program, is transformed into a series of instructions for CPU 10. User source code for an application program, which is to be run on a computer using a particular operating system, is typically compiled and linked into a binary file which is known as an executable image. A "user process" is execution of the executable image by the kernel of the operating system. In a computer using an operating system such as Microsoft Corporation's MS-DOS operating system (MS-DOS) , the interface between the operating system and hardware such as the keyboard, the display screen, and the disks are included in a basic input/output system (BIOS) , which is usually contained in a read-only memory (ROM) within computer 20. (MS-DOS is a registered trademark of Microsoft Corporation.) The BIOS is designed to drive specific hardware based upon instructions, sometimes called commands, from the operating system.
More specifically, the MS-DOS operating system interfaces with the BIOS thorough a series of commands called interrupts. The interrupts are usually initiated by software executing in CPU 10. In response to an interrupt, CPU 10 obtains an address of the interrupt service routine from an interrupt vector table stored in main memory 17B. Typically, the address of an interrupt service routine points to areas of main memory 17B which contains ROM BIOS and the operating system where the interrupt service routine is stored. Thus, main memory 17B typically contains user processes, an operating system, and information to interface the operating system with the hardware coupled to CPU 10.
When two or more computers, similar to computer 20 in Fig. 1 are used, the information in the computers must be shared. Several methods have been developed for transferring information between independent computer systems. First as shown in Fig. 2A, the information in computer 20-1 may be copied onto a disk or a tape (disk/tape) 25 for example and the disk/tape 25 transported to computer 20-2 where the information is copied from disk/tape 25 into computer 20-2. However, if the computers 20-1, 20-2 are not in close proximity, physically moving the disk/tape from computer 20-1 to computer 20-2 may be undesirable. More importantly, disk/tape 25 for computer 20-1 may not be compatible with computer 20-2. For example, computer 20-1 accepts only 5 1/4" floppy disks while computer 20-2 accepts only 3 1/2" floppy disks.
Hence, computers 20-1, 20-2 are often linked over telephone lines using modems 26, 27 (Fig. 2B) . Computer 20-1 is connected to modem 26 through a serial port of computer 20-1. Most microcomputers have at least one serial port. Computer 20-2 and modem 27 are similarly coupled. Modems 26, 27 are connected typically over telephone lines 28.
A modem converts the digital signals supplied by the computer serial port to analog signals, which are subsequently passed over telephone lines to another modem. The second modem converts the analog signals received on the telephone lines to digital signals which are in turn supplied to the computer through the serial port. Modems typically transfer data at 9,600 baud or less. The transmission rate is limited by the quality of the line connecting the modems. Typically, the data transmission rate between the modems is established at connect time based upon the quality of transmission and does not change thereafter. Accordingly, if data is initially transferred at a high rate and subsequently interference on the line produces errors in the data transmission, the transfer continues at the same high rate irrespective of the quality of the transmission. Similarly, if initially the quality of the line is low and a low transmission rate is established, this rate is not subsequently altered.
The error checking of transmitted information assumes that the information sent is the same as the information received. Typically, for each block of data transmitted, an error code is calculated and transmitted as a part of the data block by the sending computer. The receiving computer calculates the error code for the block of data and then compares the calculated error code with the transmitted error code. If the error codes are not identical, the receiving computer transmits an error message to the sending computer and the block of data is transmitted again.
In yet another configuration for transferring information between computers, computer 20-1 is hardwired to computer 20-2 by a cable 29 (Fig. 2C) and a software program executing in computer 20-1 and the same software program executing in computer 20-2 establish a data link over cable 29. Typically, in these operations, the coupled system, i.e., computers 20-1, 20-2, cable 29 and the two executing software programs, is configured for two users, i.e., the input/output devices such as the keyboard on each computer 20-1, 20-2 are both functional, as are the computer video displays. However, in most situations, the data transfer between two directly linked computers 20-1, 20-2 is being performed by a single user. Therefore, the keyboard and video display operation of one of the computers is redundant and unneeded. Nevertheless, the present techniques for connecting two computers provide such capability. Further, the configuration of computers 20-1, 20-2 is limited to executing operations for the specific software programs that establish the link between computers 20-1, 20-2. The link between the computers cannot be accessed by any other user application.
In view of the shortcoming of the above methods for transferring information among computers, networks of computers have been developed. Networks of computers are formed, as shown in Fig. 3, with several computers 20-1 to 20-n, usually similar to computer 20 illustrated in Fig. 1, coupled to a common computer 21 usually referred to as the server. Server 21 is accessed through network 22. Network 22 permits common usage of data files as well as I/O devices which are connected to server 21.
An operating system for a network includes not only the operating system as described above for a single computer, but also additional software that coordinates the operation of computers 20-1 through 20-n and the server with respect to shared resources.
Traditionally, a MS-DOS executable program image is read off of disk, and loaded into memory by the MS-DOS operating system in response to the user providing the file name of the executable program image. Under the MS- DOS operating system, executable program image files usually have a file extension of ".EXE" and such a file is referred to as "a .EXE file". An alternative to a .EXE file, is an executable program image file with a file extension of ".COM". The distinction between .COM files and .EXE files are known to those skilled in the art.
The process of loading an executable program image, stored as a .EXE file, includes allocating data and stack space in RAM for the program, setting up the program suffix prefix (PSP) for the program, reading the program from disk. Frequently, the executable program image stored as an .EXE file includes a "Relocation" process that is performed upon loading and execution of the executable program image. In the Relocation process the MS-DOS EXEC function, using the relocation table at the start of the executable file, adjusts various values, primarily segment addresses, to the correct value.
As an example, in the following code, which is written in assembly language for the Intel 8088 microprocessor there is one relocation:
.model small
.code main proc mov ax, _Data Load Data Segment mov ds, ax to ds mov ah, 4ch Dos terminate function 4ch int 21h main endp end main
The relocation occurs at the point where _Data (an assembler code word meaning the segment value of the default data segment) is loaded into register AX during execution of the program by the MS-DOS operating system function EXEC. In the generation of the executable program image, neither the assembler nor the linker knows the start address of the program at the time of execution. The EXEC function places the proper value into the program, relative to the PSP, which is the beginning of the executable's program image in RAM. Thus, the actual program code of the application is changed at the time of execution.
The EXEC function is intended to work with RAM and the executable program image upon loading into RAM may be changed. However, if an executable program image is ran directly from ROM, the EXEC function, or any other function that performs a relocation fails to function properly because the function can not change the executable program image in ROM. Therefore, a relocation process is not possible for ROM-based executable program images. Thus, any operating system that modifies executable program images cannot execute a program directly in ROM. This shortcoming limits the operation of portable computers, for example, which use ROM cards instead of floppy disks.
SUMMARY OF THE INVENTION
The virtual network executive of this invention overcomes the limitations of the prior art systems for coupling computer systems and provides a new capability for communications between computers coupled by a datalink. Moreover, the virtual network executive is accessed through a set of commands, e.g. interrupts in one embodiment, so that any user application, through these commands, can access and use the virtual network controlled by the virtual network executive. Not only can any user application access the virtual network executive, but also any user application is provided two distinct sets of capabilities by the virtual network executive.
In a computer system including at least two computers coupled by an electronic means for passing information between the computers, according to the principles of this invention, the virtual network executive is installed in each computer. The virtual network executive in a first mode of operation is used to send and receive information between computers in the system. A user application in a first computer can send a message through the virtual network executive to a second computer and a user application in the second computer can receive the message through the virtual network executive and send a reply message back to the first computer.
In a second mode of operation, the virtual network executive in all the computers in the system except one are configured to service requests from the one computer. Hence, a user application executing in the one computer has access to the resources in all the server computers, e.g., the information and attached peripheral equipment, through the virtual network executive. This configuration of one computer in a system of computers controlling and using the other computers is referred to as a virtual computer. The virtual computer is fundamentally different from the typical arrangement wherein a server computer through a network services requests from computers attached to the server computer. Also, the multifunction capability of the virtual network executive provides flexibility and communication means previously unavailable to user applications executing in a computer system.
In addition to providing user applications with new capability, the virtual network executive includes novel means for sending and receiving information over a communication link between computers. The virtual network executive includes a first means, an application layer, for receiving, sending and generating messages. The application layer receives the command from a user application and generates a first message structure that is sent to a second means, a transport layer, for receiving, sending, and generating messages. Upon receiving the message from the application layer, the transport layer generates a second message structure, called a packet. The transport layer may construct one or more packets for each message received from the application layer. After construction of each packet, the transport layer sends the packet to a third means, a datalink layer, for sending and receiving information. The datalink layer sends the packet over the communication link to another datalink layer in a remote computer using predetermined transmission parameters.
The datalink layers only send and receive information so that upon the datalink layer in the remote computer receiving the packet, the packet is sent to the transport layer in that computer. The transport layers in the two computers control the predetermined transmission parameters, e.g., the speed of the transmission and the size of the packet sent over the communication link.
The sending transport layer generates an error code for the information in the packet and attaches the error code to the packet. The receiving transport layer generates an error code for the information in the received packet and compares the error code for the received packet with the error code in the packet. If the error codes are not the same, the receiving transport layer, sends an error message to the sending transport layer and the packet is resent. After a predetermined number of transmission errors occur in sending a packet, the sending transport layer adjusts the packet size, the transmission speed or both.
Thus, unlike prior art systems, the virtual network executive adjusts the transmission parameters, packet size and transmission speed, anytime a predetermined number of transmission errors are encountered and not just at connect time. According to the principles of this invention, the designation of sending and receiving computers is chosen by the user. The virtual network executive has the ability to perform either function in each computer in which it is installed.
The first message structure, which is generated by the application layer, includes a header and a data region for storing information to be transferred between the computers. The header, in one embodiment, includes (i) a field to identify the virtual network executive that generated the message, (ii) a field to identify the operation to be performed by the computer receiving the message, i.e., a field corresponding to the command from a user application, (iii) a field to indicate the direction of the message, i.e., whether the message is an operation request message or a reply message, and (iv) a field that identifies the remote computer to receive the message and the message itself. The application layer builds a unique message structure for each remote operation that the application layer supports.
The second message structure, which is generated by the transport layer, includes a header, which is different from the application layer header, at least a portion of the information in the first message structure, and an error code. To facilitate the transmission of information between computers, the application layer can compress and decompress the information passed over the communication link.
In the method of this invention for transferring information over a datalink coupling at least two computers, the information is transmitted and received over the datalink using predetermined parameters, i.e., a predetermined transmission rate and a predetermined blocksize, for the information transmitted and received. In one embodiment, the predetermined parameters are initially established at the time of the initial connection over the datalink. The predetermined parameters are selected to permit transmitting and receiving the largest blocksize at the highest speed. An iterative process is used to establish the predetermined transmission parameters.
After the initial connection, information is sent and received at the predetermined rate and blocksize until a predetermined number of errors are detected in sending a packet of information over the datalink. After detection of the predetermined number of errors, the blocksize is reduced, and the transmission attempted again. If the transmission is successful, the new blocksize and the same transmission speed are used. If the transmission is not successful, the blocksize is reduced again. This procedure continues until either the transmission is successful or the blocksize reaches a minimum size. When the blocksize reaches the minimum and the transmission is still not successful, the transmission speed is reduced and the blocksize increased to the maximum blocksize. Again, the blocksize is successively reduced until a successful transmission is achieved. If both the transmission speed and the blocksize reach a minimum without a successful transmission, the transmission is aborted. If the transmission rate is fixed for some reason, then only the blocksize is varied upon detection of a predetermined number of errors.
According to the principles of this invention, a novel loader and a method are also provided for configuring a computer system for execution of a executable program image directly from a read-only memory (ROM) , in particular, the executable program image for the virtual network architecture. The method and loader overcome the prior art limitations associated with relocations.
The loader of this invention is loaded into random access memory (RAM) by the computer system. Once the loader is in RAM, the loader sets up the conditions required for execution of the ROM-based executable program image directly from ROM. Specifically, in one embodiment, an initialization means initializes computer system for execution of the ROM-based executable program image directly from ROM. The initialization includes configuring a data area in RAM for the ROM-based executable program image.
After the necessary conditions for execution of the ROM-based executable program image are established, the loader preferably removes itself from RAM using a means for releasing RAM. The ROM-based executable program image is, thus, configured to execute directly from ROM using the data area created in RAM by the loader.
Therefore, the loader, in one embodiment, includes a (i) a means for initializing computer system for execution of ROM-based executable program image directly from ROM and (ii) means for releasing RAM. Of course, while in this embodiment the loader includes means for releasing the random access memory used by the loader itself, the loader of this invention would function properly without releasing the RAM utilized by the loader. However, such an embodiment would obviously result in somewhat diminished efficiency in utilization of the RAM because the loader would occupy RAM when the loader was no longer needed.
The direct execution of an application from ROM significantly enhances the operation of a computer because the amount of RAM available to the user is not diminished by the size of the executable program image of the application. Further, the loader makes it possible to operate portable computers using executable program images on either ROM cards or any other ROM. In another embodiment, the loader includes a data area initialization means, an application existence verification means, and setup means. The data area initialization means includes (i) a means for creating a working data area in RAM for the ROM-based executable program image and (ii) a means for data initialization which initializes, within the data area, the necessary variables for execution of the ROM-based executable program image directly from ROM. If the operating system creates a working data area of the appropriate size, the working data area creation means is unnecessary.
The application existence verification means ensures that the ROM-based executable program image is physically present on a ROM in the computer system. If application existence verification means finds the ROM-based executable program image, the loader continues operation with the setup means. However, if the ROM-based executable image is not on a ROM within the computer system, an error message is sent to the user by an error message means, and the loader terminates through a terminate means. The application existence verification means may also include means for checking whether the ROM-based executable program image is already loaded in the computer system.
The setup means sets the data segment register as well as any other registers and/or vectors that are required by the ROM-based executable program image. The operation of the setup means depends upon the nature of the ROM-based executable program image, as described more completely below. In general, the setup means at least releases the RAM required by the loader itself, and turns control of the computer system over to the ROM-based executable program image. The setup means may include means for configuring the ROM-based executable programs image as a terminate-and-stay-resident program.
After the initialization performed by the loader, the execution of the ROM-based executable program image depends upon the nature of the ROM-based executable program image. In general, the executable program images may be divided into (i) TSR applications and (ii) non-TSR applications. For non-TSR applications, control is turned over to the ROM-based executable program image after the initialization, and the ROM-based executable program image is executed. Upon completion of the execution, the ROM-based executable program image exits normally to the MS-DOS operating system. For TSR applications, the setup means, as described above, may configure the ROM-based executable program image as a TSR program. Alternatively, the ROM-based executable program image may (i) setup the necessary interrupt vectors, (ii) execute ROM-based code that configures the application as a TSR program and (iii) terminate-and-stay-resident releasing unnecessary code/data. In these embodiments, the ROM-based executable program image functions as a TSR program and so may not execute directly after the initialization. The important aspect is that, according to the principles of this invention, the loader contains the structure necessary to perform the operations that are required for execution of the ROM-based executable program image directly from the ROM.
According to the principles of this invention, a method is provided for configuring a computer system for execution of a ROM-based executable program image directly from a ROM. The method includes the steps of creating a working data area in RAM for the executable program image and initializing, within the RAM data area, the variables needed for execution of the ROM-based executable program image. Preferably, after the initialization step, the RAM used in the initialization is released.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a prior art computer system; Figure 2A illustrates information transfer between two uncoupled prior art computer systems as in Figure 1. Figure 2B illustrates information transfer between two prior art computer systems as in Figure 1 that are coupled by modems.
Figure 2C illustrates information transfer between _- prior art computer systems as in Figure 1 that are coupled by a direct link.
Figure 3 illustrates a network of prior art computer systems as in Figure 1. Figure 4 illustrates a general block diagram of the virtual network architecture of this invention.
Figure 5 is a more detailed block diagram of the virtual network architecture of this invention. Figure 6 illustrates the general message structure including a header and a data region according to the principle of this invention.
Figure 7A is the message structure for the function O h CONNECT service. Figure 7B is the message structure for the function OAh LISTEN service.
Figure 8 is the message structure for the function OAh DISCONNECT service.
Figure 9A is the message structure for the function OAh SEND service.
Figure 9B is the message structure for the function OAh RECEIVE service.
Figure 10A is the message structure for the function OAh MAP service. Figure 10B is the reply message structure for the function OAh MAP service.
Figure 11A is the message structure for the function 09h SELECT DISK service OEh.
Figure 11B is the reply message structure for the function 09h SELECT DISK service OEh.
Figure 12A is the message structure for the function 09h GET FREE DISK SPACE service 36h.
Figure 12B is the reply message structure for the function 09h GET FREE DISK SPACE service 36h. Figure 13A is the message structure for the function 09h MAKE DIRECTORY service 36h.
Figure 13B is the reply message structure for the function 09h MAKE DIRECTORY service 39h.
Figure 14A is the message structure for the function 09h REMOVE DIRECTORY service 3Ah.
Figure 14B is the reply message structure for the function 09h REMOVE DIRECTORY service 3Ah.
Figure 15A is the message structure for the function 09h CHANGE DIRECTORY service 3Bh.
Figure 15B is the reply message structure for the function 09h CHANGE DIRECTORY service 3Bh.
Figure 16A is the message structure for the function 09h DELETE FILE service 41h.
Figure 16B is the reply message structure for the function 09h DELETE FILE service 1h. Figure 17A is the message structure for the function 09h CREATE FILE service 3Ch.
Figure 17B is the reply message structure for the function 09h CREATE FILE service 3Ch.
Figure 18A is the message structure for the function 09h OPEN FILE service 3Dh.
Figure 18B is the reply message structure for the function 09h OPEN FILE service 3Dh.
Figure 19A is the message structure for the function 09h CLOSE FILE service 3Eh. Figure 19B is the reply message structure for the function 09h CLOSE FILE service 3Eh.
Figure 20A is the message structure for the function 09h WRITE FILE service 4Oh.
Figure 2OB is the reply message structure for the function 09h SELECT DISK service 4Oh.
Figure 21A is the message structure for the function 09h READ FILE service 3Fh READ FILE.
Figure 2IB is the reply message structure for the function 09h READ DISK service 3Fh. Figure 22A is the message structure for the function 09h LSEEK service 42h.
Figure 22B is the reply message structure for the function 09h LSEEK service 42h.
Figure 23A is the message structure for the function 09h CHMOD service 43h.
Figure 23B is the reply message structure for the function 09h CHMOD service 43h.
Figure 24A is the message structure for the function 09h GET DIRECTORY service 47h.
Figure 24B is the reply message structure for the function 9Oh GET DIRECTORY service 47h.
Figure 25A is the message structure for the function 09h FIND FIRST service 4Eh.
Figure 25B is the reply message structure for the function 09h FIND FIRST service 4Eh. Figure 26A is the message structure for the function 09h FIND NEXT service 4Fh.
Figure 26B is the reply message structure for the function 09h FIND NEXT service 4Fh.
Figure 27A is the message structure for the function 09h RENAME service 56h.
Figure 27B is the reply message structure for the function 09h RENAME service 56h.
Figure 28A is the message structure for the function 09h GET/SET TIME/DATE service 57h. Figure 28B is the reply message structure for the function 09h GET/SET TIME/DATE service 57h.
Figure 29 is the status structure according to the principles of this invention.
Figure 30 is the call out structure for the serve function of this invention.
Figure 31 is the status event handler structure which is pointed to by the status event address in Figure 30.
Figure 32 is a block diagram of the transport layer function TSEND.
Figure 33 is the packet structure according to the principles of this invention that is generated by transport layer function TSEND.
Figure 34 is the block diagram for the operation send packet 170S12 in Figure 32.
Figure 35 is a flow diagram for transport layer function TRECEIVE.
Figure 36 is a flow diagram for receive packet 170- R6 in Figure 35.
Figure 37 is a flow diagram for operation send reply 170-R13 in Figure 35.
Figure 38 is a flow diagram for data link function DRESET.
Figure 39A and 39B are a flow diagram for function SET CONNECTION SPEED according to the principles of this invention.
Figure 40 is a flow diagram for function RECEIVE CHARACTER STATUS according to the principles of this invention.
Figure 41 is a flow diagram for function RECEIVE CHARACTER according to the principles of this invention. Figure 42 is a flow diagram for SPEED RESYCHRONIZATON according to the principles of this invention.
Figure 43 is a flow diagram for function SET LISTEN SPEED according to the principles of this invention.
Figure 44 is a flow diagram for datalink function DSEND according to the principles of this invention.
Figure 45 is a flow diagram for function SEND PACKET SIZE according to the principles of this invention. Figure 46 is a flow diagram for function GET PACKET SIZE according to the principles of this invention.
Figure 47 is a flow diagram for datalink function DRECEIVE.
Figure 48 is a flow diagram for interrupt service routine 180-INT according to the principles of this invention.
Figure 49 is a flow diagram of interrupt service routine 180-RECV according to the principles of this invention. Figure 50 is a flow diagram for datalink function DCONNECT according to the principles of this invention. Figure 51 is a flow diagram for a function MAIN INITIALIZATION according to the principles of this invention.
Figure 52 is a flow diagram for a function CONNECT/LISTEN INITIALIZATION according to the principles of this invention.
Figure 53 is a flow diagram for a function CHECK LINE SPEED according to the principles of this invention.
Figure 54 is a flow diagram from datalink function DLISTEN according to the principles of this invention.
Figure 55A is a block diagram of a computer system including the loader of this invention for a ROM-based executable program image.
Figure 55B is a block diagram of one embodiment of the loader of this invention.
Figures 56A and 56B are flow diagrams for one embodiment of the loader of this invention.
Figures 57A through 57C are block diagrams of alternative RAM memory allocations associated with the loader of this invention.
Figures 58A through 58C are a flow diagram for one embodiment of a loader, according to the principles of this invention, for a library of ROM-based functions.
Figures 59A through 59D are a flow diagram for one embodiment of the loader of this invention for a ROM- based application which operates under the library of functions loaded by the loader of Figures 58A through 58C and which is configured as a terminate-and-stay-resident program.
DETAILED DESCRIPTION
According to the principles of this invention, a new computer architecture is provided for configuring at least two computers as a single virtual computer system. Specifically, a virtual network architecture is added to each computer in the system. The novel virtual network architecture permits a first computer to function in a normal manner while the second computer and other computers function only to service requests from the first computer and so are referred to as server computers. This configuration of computers is referred to as a virtual computer. Hence, according to the principles of this invention, the first computer has not only the main memory and the secondary memory of that computer available, but also the first computer can directly access the main memory the mass memory, and other peripheral equipment of the other computers as well through the virtual network architecture, sometimes referred to as the virtual network. In fact, the first computer has access to all the resources of the server computers.
The secondary memory of a server computer appears to the first computer as slow secondary memory. As used herein, slow refers relatively to the access time of information in the server computer relative to the access time for equivalent information in the first computer. The access time for the information in a server computer is the normal access time plus the time required to receive the request for information and to transmit the information back to the first computer. Thus, the access time for information in the server computer is greater than normal access time in the first computer so that the resources in the server computer are slow relative to the resources in the first computer. While the access time for information is slower than the access time for information in the first computer, the transfer of information, as described more completely below, is more flexible than the prior art transfer methods, but more importantly, the virtual network architecture provides a new virtual computer system capability for computer applications.
The virtual network architecture of this invention is interposed between user applications and the computer operating system. In one embodiment, the virtual network is included on a read-only memory in the computer and is loaded as part of the ROM BIOS, as described more completely below. In another embodiment, the virtual network would be loaded as a terminate and stay resident program.
The virtual network architecture provides two basic functions to user applications. The first function, in one embodiment, permits a user application to form a virtual network between two computers and establish one of the computers as the first computer and other computer as the server. The first function includes not only the ability to establish a connection with another computer, but also the ability to send and receive messages, to obtain the virtual network system status, and to initialize the virtual network system. The second function provided by the virtual network architecture to user applications is the ability to perform operating system commands utilizing the resources of the server computers while the user application is executing in the first computer.
One embodiment of this invention is illustrated in Fig. 4. In first computer 100, a user application 101, a virtual network executive 102, and an operating system 103 are included in main memory 117. In memory 217 of a second computer 200, a user application 201, a virtual network executive 202 and an operating system 203 are present. In this embodiment, user applications 101, 201 are functionally identical; virtual network executives 102, 202 are functionally identical; and operating systems 103, 203 are functionally identical.
In view of the following description, those skilled in the art could use the principles of this invention to implement the virtual network executive in computers having different operating systems. Such an embodiment would require different embodiments of the virtual network executive and user applications for each operating system. However, the functionality and general operation of the user applications with the virtual network architecture would be as described below.
Computers 100, 200 (Fig. 4) also include secondary memory 118, 218 and CPUs 110 and 210 as well as video display, input/output devices and other components and parts typically found in micro- and mini-computers. These features are known to those skilled in the art and are not included in Figure 4 for clarity. (See P. Norton and R. Wilton, The New Peter Norton Programmer's Guide to The IBM PC & PS/2. Microsoft Press, (1988).)
As shown in Fig. 4, CPUs 110, 210 are coupled by a serial line 150. Serial line 150 is connected to a serial port(not shown) of each computer 100, 200. Each serial port is coupled to the CPU of the computer according to principles known to those skilled to the art, and the coupling, i.e., the hardware components in the computer interfacing the serial port with the CPU, do not form a part of this invention. Rather, this invention provides the user a new capability for communication between computers using a serial connection or any other datalink. While a serial connection is used in this embodiment, in view of the following description, those skilled in the art could use the principles of this invention to couple computers 100, 200 through any number of physical or electronic connections.
User applications 101, 201 and operating systems 103, 203 are loaded in computers 100, 200 respectively using standard techniques known to those skilled in the art. User applications 101, 201, as described more completely below, include a series of commands which interact with virtual network executives 102, 202 to: (i) determine that virtual network executive 102,
202 is installed on computers 100, 200; (ii) activate virtual network executive 102, 202; (iii) configure computers 100, 200 as virtual computer 300; (iv) perform user specified operations on virtual computer 300; and
(v) send and receive information between user applications 101, 201. Typically, the user must interact with user applications 101, 201 to establish virtual computer 300 because either computer 100 or computer 200 can be selected as the first computer. When the first computer is selected, the other computer becomes by definition the server in virtual computer 300. In contrast to prior art systems for exchanging information between computers that permitted user input from any of the coupled computers, after virtual computer 300 is established, the server computer is under the control of the first computer and does not support user input from the server computer. After virtual computer 300 is established with computer 100 as the first computer and computer 200 as the server, user application 201 only supports exchange of information with computer 100 as needed, and user application 101 is in control of virtual computer 300. Hence, the user interacts with virtual computer 300 through user application 101 in computer 100.
Consequently, application 101 has the resources of both computers 100, 200 available.
When user application 101 sends a command to virtual network executive 102, virtual network executive 102 processes the command. As explained more completely below, virtual network executive 102 has a set of commands, sometimes called instructions, that control operation of vitural network executive 102. Therefore, the user application issues a command that is one of the set of commands. Moreover, any user application can use this set of commands to access the virtual network executive 102. Accordingly, unlike prior art systems, any user application can use the features of the virtual network architecture of this invention.
If the command from user application 101 specified operations with information in server computer 200, virtual network executive 102, as described more completely below, passes the command to virtual network executive 202 which in turn performs the requested operation in conjunction with the operating system 203 (and user application 201 in some cases) using the resources of computer 200. Upon completion of the requested operation, virtual network 202 sends the requested information and/or a message that the requested operation was completed to virtual network executive 102 which in turn passes the results to user application 101.
If the command from user application 101 did not specify operations with information in server computer 200, i.e., the command was for local information rather than remote information, virtual network executive 102 in conjunction with operating system 103, if required, processes the command. In either case, user application
101 is unaware that the command was processed by virtual network executives 102, 202. User application 101 does not provide information which is suitable for direct transmission to computer 200 over serial line 150. Thus, user application 101 issues a command that directs virtual network executive 102 to perform a specific operation. Generally, the command specifies an operation with certain information and user application 101 provides a pointer to a buffer that is to be used for that information. Virtual network executive
102 translates the command and if necessary, the information in the buffer identified by user application 101 into a message and then the message into packets of information that are transmitted over serial line 150 by computer 100. Similarly, when the packets of information are received by computer 200, virtual network executive 202 converts the packets of information into a message and subsequently the message into a buffer and a command.
After construction of the buffer of information from the transmitted packets, virtual network executive 202 performs the specified command using the information in the buffer as required. After the operation is complete, virtual network executive 202 converts the buffer into a reply message and then the reply message into packets which are transmitted to virtual network executive 102. Virtual network executive 102 then converts the received packets into a reply message and the reply message into a buffer and provides the buffer to user application 101. The previous description assumed that user application 101 accessed or used information in computer 200, but, as described more completely below, virtual network executive 102 also processes commands for information within computer 100.
In one embodiment, virtual network executives 102, 202 support two different functions 120, 130(Fig. 5). First function 120, 220 includes means for establishing virtual computer 300 from computers 100, 200 and means for passing information between computers 100 and 200. Second function 130, 230 supports selected operating system commands both locally and over the virtual network coupling computers 100 and 200.
Hence, virtual network executives 102, 202 operate in two modes. In a first mode of operation, user applications 101, 201 use first function 120, 220 in virtual network executive 102, 202 to send and receive information between computers 100, 200. In a second mode of operation, computers 100, 200 are configured as a virtual computer, i.e., one of the computers is placed in a server mode, and then first function 120, 220 and second function 130 are used by a user application on the other computer to access resources in both computers. The operation of virtual computer 300 using the virtual network established over serial line 150 is illustrated in Fig. 5. Virtual network executive 102, 202 includes an application layer 160, 260 which in turn includes a first function 120, 220 and a second function 130, 230, a transport layer 170, 180 and a datalink layer 180, 280. (As used herein, when two reference numerals are included after the name of an object, the objects in the figures are functionally identical.) Each function typically includes several services.
Each layer in virtual network executive 102, 202 communicates only with an adjacent layer. For example, application layer 160, 260 communicates with user application 101, 201 and transport layer 170, 270. As shown in Fig 5., serial line 150 is shown coupled with datalink layers 180, 280 so that datalink layers 180, 280 communicate with each other. Serial line 150 is only one example of a datalink coupling computers 100, 200.
Other datalinks for coupling computers are known to those skilled in the art. The principles of this invention can be implemented with any datalink. Datalink layer 180, 280 of the virtual network executive must be selected to communicate with the electronic datalink and transport layer 170, 270.
In one embodiment, the user first instructs application 101 to activate virtual network executive 102. In response to the user, application 101 sends a command to first function 120 to reset virtual network executive 102. Since this command is for a local operation, function 120 activates virtual network executive 102 in computer 100. The user repeats this process on computer 200 to activate virtual network executive 202.
After virtual network executives 102, 202 are activated, the user through user applications 101, 201 establishes the virtual network so that computer 100, 200 function as virtual computer 300. Hence, in this embodiment, the user instructs user application 201 to configure computer 200 as the server. Function 220, in response to the command from user application 201, configures virtual network executive 202 as a server so that virtual network executive 202 listens for a connect command on serial line 150. After virtual network executive 202 receives a connect command, as described below, computer 200, sometimes referred to as a node, services commands directed over virtual network 150 by user application 101.
Subsequently, the user instructs user application 101 to establish a connection between computer 100 and computer 200. User application 101, in response to the user, sends a connect command to function 120 in application layer 160. Connect is one of the services supported by function 120. Application layer 160 generates a connect message and calls transport layer
170. As explained more completely below, the application layer generates a unique message for each service supported by a function. However, the set of application layer messages all have a common structure that includes a message header and a data region following the header. The message structure is described below for each of the services in first and second functions 120, 130. Also, as explained below, the data region of a message is sometimes compressed to minimize the information that must be transmitted to the remote node.
Transport layer 170, which is responsible for correct delivery of the information to the server computer, breaks the connect message generated by application layer 160 into packets. Transport layer 170 processes each packet sequentially. Specifically, transport layer 170 adds a header and an error code, e.g., a CRC-16 checksum, to each packet and then calls datalink layer 180 to transmit the packet to computer 200.
Transport layer 170 then waits for a reply from transport layer 270 that the packet was received. When datalink 280 receives a packet, the packet is passed to transport layer 270, which checks the transmitted packet for errors and sends a reply through datalink 280 to datalink 180 and consequently to transport layer 170. If the packet was transmitted without error, the next packet is sent by transport layer 170. However, if an error occurs in transmission, transport layer 170 resends the packet. This continues until either transport layer 170 successfully transmits the packet or transport layer 170 determines that the packet cannot be transmitted with the present transmission speed and blocksize. Here, blocksize refers to the size of the packet in bytes.
In this embodiment, as explained more completely below, the maximum transmission rate is 115,200 bits per second and the maximum blocksize is 4 Kbytes. Typically, in an IBM PC or IBM PC compatible, the UART is the interface between software and hardware in the computer. The UART defines the maximum transmission rate. The specification for the typical UART is 19.2 Kbits per second, because the minimum baud rate divisor is specified as 6. However, by setting the baud rate divisor for the UART to 1, the 115,200 bits per second is obtained. If transport layer 170 determines that the information cannot be passed in large blocks without error, transport layer 170 decomposes the packet into a sequence of packets with a blocksize one half the prior blocksize. If the smaller blocksize cannot be transmitted successfully, transport layer 170 attempts to reduce the errors by again halving the blocksize of a packet. The size of the transmitted packet is continually halved until either the packet is either successfully transmitted or until the blocksize reaches the minimum 256 bytes. If the error rate is not reduced by the reduction in the blocksize, transport layer 170 directs datalink layer 180 to decrease the transfer speed and then the packet blocksize is increased to the maximum and the error reduction procedure is repeated. Unlike prior art systems that established a transmission speed at connect time, according to the principles of this invention the transmission parameters, i.e., the packet size and/or the transmission speed, are adjusted any time a predetermined number of transmission errors are encountered while sending a packet. Hence, virtual network executive of this invention is responsive to changes in transmission conditions.
After the packets are successfully received by datalink layer 280 and transport layer 270, transport layer 270 passes the message to application layer 260, application layer 260 processes the message provided by transport layer 270 and determines that a connect command was received. Accordingly, application layer 260 configures virtual network executive 202 in the server mode to receive information from virtual network executive 102.
After application layer 260 completes the operations specified in the received message, application layer 260 constructs a reply message and passes the reply message to transport layer 270. Transport layer 270 performs the same operations as previously described for transport layer 170 in sending the reply message to transport layer 170. As transport layer 170 receives each packet from transport layer 270 the reply message is constructed and upon completion passed to application layer 160 which in turn parses the reply message and provides the returned information to user application 101.
The complete set of commands supplied to virtual network executives 102, 202 and the functions within virtual network executives 102, 202 are explained more completely below.
After virtual computer 300 is established as described above, the user identifies the remote drives that are available to user application 101. In one embodiment, as described more completely below, the remote drives, i. e. , the drives in computer 200, are aliased as drives in computer 100. Typically, computer 100 may have drives identified by letters A through E. Thus, the remote drives are typically aliased as local drives F, G, .... Hence, when user application specifies an operation with one of drives F, G, ... , virtual network executive 102, as explained more completely below, sends the request over the virtual network. Virtual computer 300 in now established with computer 200 configured to service requests from user application 101 executing in computer 100. As explained more completely below, server computer 200 processes services associated with both first function 120 and second function 130.
In another mode of operation, user application 201 is not instructed to place computer 200 in the server mode using the server service of first function 220. Rather, user application 201 sends and receives messages through first function 220. In this mode of operation, user application 201, rather than the server service of first function 220, processes the commands from user application 101. Hence, virtual network executive 202 provides the user with the capability to either process commands automatically through the server service of first function 220 or provide specific services that are unique to the user by providing a user application that processes and sends messages through first function 220 of virtual network executive 202.
In one embodiment, virtual network executive 102, 202 services are invoked using interrupt 66h. First function 120 is invoked by user application 101, 201 issuing an interrupt 66h, function OAh and second function 130 is invoked by user application 101, 201 issuing an interrupt 66h, function 09h. The selection of a particular interrupt and particular functions are illustrative only and are not intended to limit the invention to the specific embodiments described herein. In view of this disclosure, those skilled in the art could implement this invention using other operating systems either by using other strategies to define entry points to the functions of this invention, or by implementing these services on the native operating system.
Thus, in this embodiment user applications 101, 201 invoke virtual network executives 102, 202 by issuing an interrupt 66h that specifies either function 09h or function OAh and a service for the specified function. The services supported under function 09h and function OAh are described more completely below.
As used herein, register names, e.g., AX (sometimes used as two registers called AH and AL) , BX (sometimes used as two registers called BH and BL) , CX (sometimes used as two registers called CH and CL) , DX (sometimes used as two registers called DH and DL) , SP, BP, SI, DI, CS, DS, SS, and ES, are those associated with the Intel Corporation of Santa Clara, CA, iAPX86, 88 and iAPX186, 188, 286, 386 and 486 family of micro-processor systems. However, these examples are illustrative only of the principles of the invention and are not intended to limit the scope of the invention to the specific embodiment described. In view of this disclosure, those skilled in the art can use the virtual network executive of this invention with other microprocessors and other operating systems.
The services within function 120, 220 of application layer 160, 260 are invoked, as described above, by user application 101, 201 issuing an interrupt 66h, function OAh, and a service. Table 1 lists the nine application layer services for function OAh in this embodiment, i.e., the services of interrupt 66h, function OAh that must be provided by the user application to access application layer 160. The register configuration that must be initialized by user application 101, 201, and the information in the registers that are returned to user application 101, 201 are also presented in Table 1. The services described herein are illustrative only of the principles of this invention and are not intended to limit the invention to the specific embodiments described. For example, function OAh could include either only a subset of the services in Table 1 or additional services to support user specific needs.
TABLE 1
Application layer Function OAh Services
LISTEN, Service OOh On entry:
AL: OOH
CX: Line baud rate/100 (0 = default)
DX: Port Selector (0 = COM1, 1 = COM2, ...)
SI: Timeout in ticks On return:
AX: Session identification (SID) or error code
CONNECT, Service Olh On entry:
AL: 01H BX: node identification of the remote computer CX: Line baud rate/100 (0 = default) DX: Port Selector (0 = COM1, 1 = COM2, ...) SI: Timeout in ticks On return: AX: SID or Negative error code
BX: Total number of drives available on the remote. DISCONNECT, Service 02h On entry: AL: 02H
BX: SID of session to close On return:
AX: Error code SEND, Service 03h On entry:
AL: 03H BX: SID
CX: Length of sent message DS:DX: Pointer to the message to be sent On return:
AX: Error code RECEIVE, Service 04h On entry:
AL: 04H BX: SID
CX: Length of buffer DS:DX: Pointer to the receive buffer
SI: Timeout in ticks On return: AX: Length of message or error code
STATUS, Service 05h On entry:
AL: 05H
BX: SID or -1 for all CX: Length of buffer DS:DX: Pointer to the status buffer On return:
AX: Error code RESET, Service 06h On entry:
AL: 06H
CX: Length of work buffer DS:BX: Pointer to a user supplied work buffer On return: AX: Error code MAP, Service 07h On entry:
AL: 07H BX: SID CL: Drive Number of local alias drive (0 = A, 1 = B, etc)
CH: Drive Number of remote drive (0 = A, 1 = B, etc)
DX: 0 = remove alias, 1 = create alias, 2 = return map table if DX equals 2 then: DS:CX: Pointer to buffer for receiving the
Drive Mapping Table. On return: AX: Error code SERVE, Service 08h On entry:
AL: 08H
CX: Line baud rate/100 (0 = default) DX: Port Selector (0 = COM1, 1 - COM2, ...) SI: Timeout in ticks BX:DI: Address of the Callout structure or Null
(0:0) if no handler On return: AX: Error code Function OAh errors are returned to the user application as negative values. Successful completion of a function is indicated by a positive (generally zero) return value. Possible return values from function OAh are presented in Table 2.
TABLE 2 Return Result obtained in Function OAh Value
0 - Successful function completion
-1 - Connection broken
-2 - Unknown node ID
-3 - Invalid line speed
-4 - Send/Receive error
-5 - Time out error
-6 - Cannot connect to specified node
-7 - Invalid buffer address
-8 - Buffer too small
-9 - Invalid Session ID
-10 - No more sessions available
-11 - CRC error
-12 - Unexpected message
-13 - Invalid remote drive
-14 - Drive not local and not aliased to a remote drive
-15 - Re-entrant Function request denied
-16 - Returned if a function 10 service is called prior to calling RESET
-17 - Server Terminated at User Request
Second function 130 is entered via the application program 101 issuing an interrupt 66h, function 09h call that includes a specific service. As previously described, in this embodiment a selected group of MS-DOS operating services are supported. The selected group of services may be considered a nearly orthogonal set of services. Orthogonal means that these services can be used to accomplish the complete range of interrupt 21 services. The selected set of services are listed in Table 3.
TABLE 3
Figure imgf000039_0001
To facilitate use of the virtual network architecture of this invention, interrupt 66h function 09h services have the same service number as the MS-DOS interrupt 21h services. Moreover, the register values that must be supplied when an interrupt 66h service is called are the same as those defined by MS-DOS for the corresponding interrupt 21h service with the exception that the MS-DOS function code in register AH and the parameter AL are pushed on the stack by the user application prior to the interrupt 66h. In one embodiment, the global interrupt 66h handler removes the pushed AX parameter prior to returning to the calling program so that the user program is not required to adjust the stack after interrupt 66h function 09h invocations.
The use of the MS-DOS interrupt 21h configuration not only makes use of the virtual network easier for the application programmer, but also facilitates the implementation of the virtual network architecture because chaining from interrupt 66 to interrupt 21h does not require a shuffling or reconfiguration of registers. In fact, as described more completely below, interrupt 66h function 09h generally uses interrupt 21h to ultimately perform the requested service.
A general overview of the operation of virtual network executive is given in Fig. 5. In another embodiment, a global interrupt 66h handler is entered when a user application issues an interrupt 66h. Prior to the user application issuing the interrupt 66h, the user application sets the parameters which are required by the interrupt function 66h function that is to be called. In this embodiment, in the case of all interrupt 66h functions other than function 09h, register AH has been set to the function number and register AL has been set to the service number. In the case of interrupt 66h function 09h, the user application sets register AX to the appropriate value for the service and then pushes that value onto the stack. The user application then sets register AH to 9 and issues interrupt 66h.
Upon receipt of interrupt 66h, the global interrupt 66h handler first increments the reentrancy level and if this entrance is not a reentrance switches stacks. The current CPU register values are saved and various parameters, e.g., the screen segment and related colors are determined. Global interrupt 66h handler then passes control to a main dispatcher which determines whether the interrupt 66h function is supported. In this embodiment, the main dispatcher determines whether the function number is less than or equal to OAh or is equal to 3Oh. If the function is not supported, subsequent operations depend upon the computer system in which the global interrupt 66h handler and the virtual network executive are loaded.
In the low power portable computer described in the copending and commonly assigned application of John P. Fairbanks, et al., entitled "Portable Low Power Computer," U.S. Serial No. 07/375,721, which is incorporated herein by reference, if the function is not supported, the interrupt 66h handler that was active when the virtual network executive was loaded is called. Upon return from that handling routine, control returns from the main dispatcher to the global interrupt 66h handler. The reentrancy level is decremented, the stack restored to its condition upon entry, the carry flag set if the handling routine returned an error code in register AX, and control returned to the calling application. Thus, the virtual network executive is transparent to the calling application.
In another embodiment, in computers other than the low power portable computer, if the function passed to the global interrupt 66h handler is not supported, the main dispatcher returns an error message indicating a bad parameter to the global interrupt 66h handler which in turn decrements the reentrancy level, sets the carry flag, restores the stack to its original condition and returns the error code to the user application. If the function passed in the interrupt 66h call is supported, the main dispatcher determines whether the requested service is valid by comparing the service with a maximum service number for that function. If the service is valid, the dispatcher loads the address of the handling function and passes control to that handling function. Upon return from the function, the main dispatcher returns control to the global interrupt 66h handler, which as described above, decrements the reentrancy level, sets the carry flag based upon the return code, resets the stack and returns to the calling user application. This is the sequence of operations in which function OAh of the virtual network executive are processed. However, the interrupt 66h function 09h services are processed in a somewhat different manner. The maximum service number for function 09h is 1. Accordingly, if function 09h is called with a service 0, the main dispatcher loads the VNA dispatcher which is described more completely below. If function 09h is called with any number other than 0 the service is not supported but since the function is 09h, control passes to the VNA dispatcher. Once the function 09h service is complete, the VNA dispatcher removes the saved registers from the stack, restores the stack to its state upon entry to the global interrupt 66h handler and returns to the user application. If the service is not supported and the function is not 09h, the processing is the same as that described above when the specified function was not supported.
Operation of the application layer services for functions 09h and OAh are described more completely below. While the global interrupt 66h handler processes other functions, valid functions other than functions 09h and OAh do not form a part of this invention and so are not considered further. In one embodiment of this invention, the application layer functions are written primarily in the "C" programming language and the interrupt handler and dispatchers are written in assembly language, there is of necessity a set of interface routines, written in assembly language, between the VNA dispatcher and the function 09h services and between the main dispatcher and the application layer function OAh services. These interface routines adjust the parameters from the register-based assembly conventions to the stack-based
"C" conventions in a manner known to those skilled in the art.
As described above, the VNA dispatcher receives control when the main dispatcher determines that an interrupt 66h has been issued with a requested function number of 09h. The VNA dispatcher first determines if the virtual network executive is active. If the virtual network executive is not active, then the VNA dispatcher executes the function locally. Specifically, if the requested service is the MS-DOS terminate function, then the virtual network executive reentrancy level is reset to 0, and the flag indicating whether VNA is active is set to indicate that VNA is inactive. The registers are then reset to the state that they were in prior to entering interrupt 66h and the value of register AX is popped off the stack and at this time, an interrupt 21h is executed. Upon return from interrupt 21h, processing transfers to the VNA dispatcher which in turn returns to the main dispatcher. If the virtual network executive is active, the VNA dispatcher examines the requested service number to determine if the service number is listed in the table of those service numbers that the virtual network executive directly supports under function 09h. If the service is not in the table, the service is executed locally in the same manner as when the virtual network executive was not active. Conversely, if the service is in the table, an interface function is called via the look-up table. The interface function parses parameters and places them on the stack and then passes control to the actual handling function.
Each of the handling functions parses the parameters passed by the user application to determine the path, handle, or other identifier that specifies the location of the desired operation. Based upon that information, the handling function either sets a flag to indicate that the functions should be executed locally and returns to the VNA dispatcher, or increments the VNA reentrancy level, performs the specified operation, as more completely described below, clears the flag to indicate that the function should not be executed locally, and returns to the VNA dispatcher.
Upon return to the VNA dispatcher from the handling function, the flag is examined to determine if the function has requested that the VNA dispatcher execute the function locally. If the flag is set, the function is executed as described above when VNA was inactive. If the flag is not set, the VNA dispatcher decrements the reentrancy level and returns to the main dispatcher as described above. In the following description, the operation of each application layer service for functions 09h and OAh are presented. Some of the services are performed locally and others remotely. As used herein, local refers to the computer that is executing the particular operation and remote refers to other computers that are accessed as a result of the local operation. For each remote operation through the virtual network, the application layer function constructs a message that is in turn supplied to the transport layer through a transport function call. In the description of the application layer operations, the calls to the transport layer are described. In each call to a transport layer function, the application layer provides the information given in Table 4 and receives the information indicated in Table 4 from the transport layer function. The transport layer functions called are described more completely below after the description of the application layer functions. The transport layer functions in turn call datalink functions that are described after the transport layer functions.
The application layer message structure (Fig. 6) is identical for both function OAh and function 09h services. In Fig. 6 through Fig. 28B, the first byte in each row of a message is identified at the left of the row. Also, either the value or a descriptor of the value or values is given in each byte of these Figures. Each message 160-M consists of an eight byte header 160-MH and a data region 160-MD. The portion of the message after the header is collectively the data region, but in most case the data region contains several bytes of information that characterize the data and then the actual data. Thus, the data region is a storage area in the message for information that is transmitted over the virtual network. The message may include up to 64 KBytes of information including the eight byte header.
The eight byte header of the message constructed by application layer 160, 260 has a fixed structure. In this embodiment, the first three bytes, bytes OOh to 02h, of the application layer header are used identify the source of the message. Thus, in Fig. 6, "VNA" indicates that the message was generated by application layer 160 (Fig. 5) of virtual network executive 102. The fourth byte is a space, which may be considered part of the source identification. In Figures 7A through 28B, the space is represented by the ASCII code for a space, "20h". The fifth byte is used to indicate whether the message packet is an operation message packet or a reply message packet, i.e., the direction of the transmission. If the fifth byte is OOh, the message packet is an operation message packet. If the fifth byte is Olh, the message packet is a reply message packet. The sixth byte is used to identify the service generating the message. The sixth byte represents the command specified by the user application. For example, for function 09h services, the sixth byte corresponds to the hexadecimal representation of the service given in Table 3. The seventh and eighth bytes of the message packet are the session identification (SID) , which is described more completely below.
The remainder of the message provides information that is specific to the function being processed. Generally, in the operation packet the remainder of the information contains data provided by the user application. In the reply packet, the remainder of the message corresponds to the information and/or operations specified in the transmission message, and is usually provided by the application layer to the user application.
Function OAh service CONNECT attempts to establish a session with the remote node specified in register BX. (Here a node refers to one of the individual computers connected to the virtual network.) In one embodiment of this invention, application layer 160, 260 and transport layer 170, 270 support multiple server computers so that virtual computer 300 would include first computer 100 and a plurality of server computers. As described below, LISTEN, in response to a CONNECT, returns a session identification (SID) . CONNECT message 160-C supplied to transport layer 170, 270 by application layer 160, 260 is illustrated in Fig. 7A.
In this embodiment the node identification and the session identification are identical. However, in general, a node identification is used to uniquely identify each computer in a single virtual computer. The SID is used to identify tasks that are performed over the virtual network so as to prevent contentions or confusion between tasks. For example, a user application could request information from a server computer and this request would have a SID of 1. Subsequently, the user application could request other information before the information associated with SID 1 is provided by the server computer. Thus, the second information request is SID 2. The user application can identify the information being provided by the server computer through the SID. Similarly, in a multitasking environment, a SID could be associated with each task. The use of multiple SIDS requires further development of the datalink layer described below. CONNECT message 160-C (Fig. 7A) illustrates the general message architecture according to the principles of this invention. The fifth byte is set to "FFh". Since the SID is generated by LISTEN in response to CONNECT, the seventh and eighth bytes in CONNECT message 160-C are OOh to show that an SID is not yet established. In this embodiment, CONNECT message 160-C is 16 bytes in length. The ninth and tenth bytes contain the maximum working buffer size for data transmission. The eleventh and twelfth bytes are used as a first identification field and the thirteenth and fourteenth bytes as a second identification field.
In one embodiment, as described previously, the virtual network architecture is included in a low power portable computer which includes a global interrupt 66h handler that processes all interrupt 66h calls and subsequently passes the interrupt 66h calls to the appropriate handlers such as virtual network executive 102 (Fig. 5) . Thus, the first identification field is used to identify the version of the global interrupt 66h handler, and the second identification field is used to identify the version of virtual network executive 102. As the global interrupt 66h handler and/or virtual network executive 102 are modified, different versions of global interrupt 66h handler and/or the virtual network executive may be incompatible. The fifteenth and sixteenth bytes in CONNECT message 160-C (Fig 7A) contain the message dialect. The message dialect is a version number for the message structure used in the application layer messages. For example, the set of message structures illustrated in Figs. 7A to 28B are considered message dialect 0. Subsequently, if one or more of the message structures is changed, the message dialect for the new set of message structures would be, for example, 1.
Since, as described more completely below, the operation of the virtual network executive is related to the message structure, different message dialects may not function with a virtual network executive that does not include the capability to process both message dialects. As illustrated in Table 1, user application 101 (Fig. 5) passes application layer CONNECT service (i) the node ID for the computer to which the connection is to be made; (ii) the transmission speed; (iii) a timeout value which is the time period, typically one second, to wait for a response from the remote node; and (iv) the serial port for the connection.
The handling function for service CONNECT calls application layer function VCONNECT and passes this information to function VCONNECT. Upon entry, function VCONNECT first determines whether virtual network executive is active. An error is returned to the user application if virtual network executive is not active.
If virtual network executive is active, function VCONNECT calls transport layer function TCONNECT, described more completely below. Function VCONNECT passes the node ID, speed, timeout and port information received from the user application to function TCONNECT. If function TCONNECT operates successfully, function VCONNECT receives as a return value the SID. In this embodiment, for the SID to be valid the SID must be greater than zero and must be less than a predetermined maximum value. The actual return values used are arbitrary. The important aspect is that successful return values are differentiated from error return values.
If function TCONNECT operates successfully and returns a valid SID, function VCONNECT builds the message header, described above, in the local message buffer that was passed to function VRESET, which is described more completely below. As used herein, when a function builds the message header, the function also initializes the data region of the message in the local buffer. The buffer size in the message (bytes 08h and 09h in Fig. 7A) is set to the local message buffer size which is defined by function VRESET, described more completely below. The identification bytes are set to the local version identifiers where local means the versions being used in the computer initiating the CONNECT. After construction of the message, function VCONNECT calls the transport layer function TSEND to send the message. Function TSEND is described more completely below with respect to Fig. 32.
If function TSEND returns an error, function VCONNECT calls function TDISCONNECT in the transport layer which in turn disconnects the local machine from the remote machine. Function VCONNECT returns the return value from function TSEND to application program 101. Conversely, when function TSEND is successful, function VCONNECT calls transport layer function TRECEIVE with the current SID, the length of the receive buffer, a pointer to the receive buffer and a timeout value. If TRECEIVE returns an error, function VCONNECT calls function TDISCONNECT and then returns the error to application program 101.
If function TRECEIVE is successful, function VCONNECT selects the lesser of the local buffer size and the remote buffer size and sets the work buffer size to the selected value. Hereinafter, references to the local message buffer refer to the region in the work buffer that is used to construction the application layer messages. Function VCONNECT also parses message 160-L, described more completely below and saves the information in the remainder of the reply message. Function VCONNECT returns the SID and the total number of remote drives to user application 101.
When function OAh service LISTEN is called by a user application, LISTEN waits for a CONNECT request to arrive signaling the start of a virtual computer session. Upon successful completion of service LISTEN, a SID(bytes 06h and 07h in Fig. 7B) and a disk drive count(bytes OAh and OBh) are returned by LISTEN for the node which responds to CONNECT. The drive count indicates which local drives are available for use by the remote node issuing the CONNECT. Specifically, the disk drive count identifies the number of information storage drives which may be accessed using operating system disk drive services. Also, upon the successful completion of LISTEN, the node is placed in RECEIVE, which is described below. The SID is used in all subsequent operations to identify the session.
Message 160-L, which is generated by LISTEN in response to a CONNECT is illustrated in Fig. 7B. The first eight bytes are identical to the CONNECT message in Fig. 7A except the fifth byte is changed to Olh to indicate that the message is a reply message. Bytes 08h and 09h are the local message buffer size. Bytes OCh and ODh are the two identifiers for the local global interrupt 66h handler and the virtual network executive. Bytes lOh and llh are the server type. A first server type is associated with LISTEN and a second server type is associated with SERVE, which is described more completely below. The server type corresponds to the two possible modes of operation described previously. Bytes 12h and 13h represent the message dialect of the local virtual network executive.
When the user application calls service LISTEN, the handling function for LISTEN in turn calls function VLISTEN. The communication speed, the timeout value, and the port are passed to function VLISTEN. Upon entry, function VLISTEN first determines whether the virtual network executive is active. An error is returned to the user application if the network executive is not active. If the network executive is active, function VLISTEN calls transport layer function TLISTEN, described more completely below, to wait for a connect request. If function TLISTEN returns an error, the error is returned to the user application.
However, if function TLISTEN is successful, the SID is set to the SID value that is returned to the remote node. The receive message buffer is set to point to the local message buffer and transport function TRECEIVE is called to receive the incoming connect message. If the length of the received message is zero or byte six of the message is not set to -1, function TDISCONNECT is called and the length of the received message is returned to the calling user application.
If the length of the received message is not zero and the sixth byte is -1, and if the local buffer size if greater than the buffer size in the received message buffer, the work buffer size is set to the buffer size in the received message. Otherwise, the work buffer size is set to the local buffer size. The selected buffer size in placed in the reply message. The global interrupt 66h handler and the virtual network executive identifiers are also placed in the local message, and the identifiers in the CONNECT message are saved. Similarly, the other information in reply message 160-L is placed in the local message buffer. Transport layer function TSEND is called to send the reply message. If function TSEND returns an error, function TDISCONNECT is called and the result of TDISCONNECT returned to the user application. If function TSEND is successful, the SID is returned to the calling user application. The handling function for service DISCONNECT calls function VDISCONNECT in response to a call from a user application. Function VDISCONNECT may also be called another application layer service to close a session with a remote node. An error code is returned indicating success or failure of the function. Any aliased drives, as defined below in service MAP, are invalidated and services that reference a previously aliased drive return an invalid drive error. DISCONNECT message 160-DC is illustrated in Fig. 8. The first eight bytes have the general structure described above with the sixth byte being set to "FEh" to indicate DISCONNECT. The 08h and 09h bytes contain an arbitrary parameter that is not used at this time.
Function VDISCONNECT is passed the SID to be disconnected. Function VDISCONNECT first determines whether the network executive is active. An error is returned to the user application if the network executive is not active.
If the network executive is active, and the remote node is in the server mode, as described below, each of the active files that the server has open are closed. The DISCONNECT message is built in the local buffer and transport function TSEND called to send the message to the server. The server status is set inactive and each drive associated with the SID being closed is removed from the drive mapping table by marking the drive with a minus one in this embodiment. The drive mapping table is described more completely below with respect to service MAP. The SID is reset to zero and transport function TDISCONNECT called. The result from function TDISCONNECT is returned to the calling user application or the calling function.
Function OAh service SEND is used to send a user application specific message to the remote node where an outstanding receive is active. SEND returns zero to the user application indicating that the message was successfully sent. A negative error is returned if the message can not be sent. SEND generates the message structure 160-S (Fig. 9A) that is described more completely below. RECEIVE is used to wait for a message to be received. Upon receipt of a message RECEIVE returns the actual length of the message to the calling service.
SEND creates generic message 160-S illustrated in Fig. 9A and RECEIVE creates generic reply message 160-R illustrated in Fig. 9B. Both messages use the general structure described above for the first eight bytes of the message with the sixth byte being set to "FCh" to indicate a generic message. Bytes 08h and 09h indicate the length of the data region of the message that starts in byte OAh.
User application 101 calls service SEND and the handling function for SEND calls function VSEND with a SID, a message length and a pointer to a message buffer. Upon entry, function VSEND first determines whether the network executive is active. An error is returned to the user application if the virtual network executive is not active.
If the virtual network executive is active, function VSEND builds generic message 160-S, illustrated in Fig. 9A. The maximum message size is the size of the local message buffer size minus the two bytes used for data length in the message and the eight byte header. If the passed message length supplied to SEND by user application 101 is greater than the local message buffer size, the message length is set to the local message buffer size and the length in bytes 08h and 09h is set to the local message buffer size also.
Next the generic message supplied by user application 101 is copied to the local message buffer and transport layer function TSEND is called. The information supplied to function TSEND and the operation of function TSEND are described more completely below. Function VSEND returns the completion code supplied by function TSEND to the calling user application.
Typically, a user application also calls service RECEIVE and the handling function for RECEIVE calls function VRECEIVE with a SID, a message length a timeout value, and a pointer to a message buffer. Upon entry, function VRECEIVE first determines whether the virtual network executive is active. An error is returned to the user application if the virtual network executive is not active.
If the virtual network executive is active, function VSEND calls transport function TRECEIVE to receive a generic message in the local message buffer. If TRECEIVE receives a message having a length greater than zero in bytes 08h and 09h, the length in these bytes is saved. If the saved length is greater than the local buffer size, the saved length is set to the local buffer size. The message is copied from the local message buffer to the message buffer passed in the call to function
VRECEIVE. Function VRECEIVE returns the length of the receive message to the calling user application.
STATUS is used to obtain information about the virtual network. The status information is placed in a buffer supplied by the user application. Structure 160- STATUS of the buffer is illustrated in Fig. 29. The SID count field (Fig. 29 bytes 02h and 03h) indicates the number of sessions currently active and described in the supplied buffer. Following the SID count field is a 18h byte session status descripter which is repeated in the buffer SID count times. In one embodiment, SID count is always one.
As illustrated in Fig. 29, the session status descripter includes SID (bytes 04h and 05h ) , remote node ID (bytes 06h and 07h) , bytes sent (bytes 08h to OBh) , bytes received (bytes OCh to OFh) , send errors (bytes lOh and llh) , receive errors (bytes 12h and 13h) , speed of transmission (bytes 14h and 15h) , and the identification information, (bytes 16h to 19h) which was described above with respect to CONNECT. STATUS can be called from a hook, i.e., a section of software that is passed to SERVE by a pointer in the call to SERVE.
User application program 101 calls STATUS with the SID, the length of the status buffer, and a pointer to the status buffer. Subsequently, the STATUS handling function calls function VSTATUS which in turn calls transport layer function TSTATUS, which is described more completely below, with the parameters defined in Table 4. Function TSTATUS gets the virtual network status. If TSTATUS returns an error code, the error code is returned to the user application program. However, if an error code is not detected, the global interrupt 66h handler and the virtual network executive version numbers of each active session are set to the version number of the remote global interrupt 66h handler and the remote the network executive version numbers respectively. The message dialect is set to zero. Finally, a successful return code is supplied to the user application program 101.
Function OAh service RESET is used to initialize/activate or deactivate virtual network executive 102 (Fig. 5) . Virtual network executive 102 is enabled by user application 101 passing service RESET a valid buffer pointer and a valid buffer length. Virtual network executive 102 is deactivated by calling service RESET with either a null pointer and/or an invalid buffer length (preferably zero) .
Service RESET handling function calls function
VRESET. The length and the buffer pointer are passed to function VRESET. Initially, function VRESET sets the virtual network status, the server status, and the SID to zero.
If the passed length and the buffer pointer are both zero, success is returned to the calling program if the virtual network termination offset and termination segment are zero. However, if the virtual network termination offset and segment are non-zero, the program segment prefix(PSP) address is obtained. If the PSP address is not zero, the PSP pointer in the passed buffer is set to the PSP termination address and the termination offset and segment are set to zero. Success is then returned to the user application. Success is also returned if the PSP address is zero.
If the length of the passed buffer is less than the predetermined minimum buffer size, 256 Kbytes in one embodiment, a buffer length error is returned to the calling user application. If the passed buffer pointer is zero, and the passed buffer size is non-zero and greater than the predetermined minimum size, a buffer pointer error is returned.
If the passed length and buffer pointer are both non-zero, the local buffer size and the beginning location of the local buffer are set. The current drive, the default drive and the total number of locally available drives are obtained. The drive mapping table is initialized. The default disk transfer area(DTA) and the number of disks are obtained, and the current DTA is set to the default DTA. The version numbers for the local global interrupt 66h handler and the virtual network executive are obtained. Transport layer function TRESET is called to reset the transport layer.
If function TRESET returns success, the PSP address is obtained. If the PSP address is non-zero, the PSP pointer in the passed buffer is set to point to the PSP terminate address. If the PSP pointer is not equal to the first PSP, the terminate offset and segment are reset to zero and the PSP pointer is set to the first PSP. Next, the virtual network executive status is set to active and the result from function TRESET is returned to the calling user application.
Function OAh service MAP is used to (i) alias a local drive to a remote drive once a session is activated by service RESET, (ii) disassociate a remote drive from its alias, or (iii) to interrogate the virtual network executive for the current mapping status. Once a drive is aliased, all references to the aliased drive are redirected over the virtual network, as described more completely below.
MAP service message 160-MAP is illustrated in Fig. 10A. The first eight bytes have the general header structure described above with the sixth byte being set to "FDh" to indicate a MAP. The 08h and 09h bytes indicate the remote drive that is aliased. The reply message 160-RMAP is illustrated in Fig. 10B and is identical to MAP message except the fifth byte indicates a reply message and bytes 08h and 09h contain an error code. The assignment of a local drive alias to a remote drive is arbitrary.
Service MAP maintains a drive mapping table. The drive mapping table has twenty-six entries. Each entry in the table contains (i) the remote drive number (0=A, 1=B, ...) for this entry and (ii)the SID associated with this entry. The zeroth element in the drive mapping table is the entry associated with local drive A. Information concerning virtual drive Q is entry 16 in the drive mapping table. Entry 16 would indicate the remote drive number that Q is aliased to, and the SID for that alias. To alias a drive, user application 101 calls service MAP with a SID, local drive identifier, a remote drive identifier, and an alias parameter. If the alias parameter has a value of 2, then the twenty-six word array passed by the user application is returned as a user drive mapping table. The user drive mapping table is a subset of the drive mapping table. Each element in the table has no SID value, and drives mapped by other sessions (as indicated by the SID) are shown as not mapped. The MAP service handling function passes these parameters to function VMAP. Function VMAP first determines whether the network executive is active. An error is returned to the user application if the network executive is not active.
If the network executive is active, function VMAP determines whether the passed alias parameter is zero.
If the parameter is zero, the drive identifier associated with the aliased local drive in the drive mapping table is set to a value, for example -1, that indicates that the aliased local drive has been removed. A success condition is returned to user application 101.
If the alias parameter has a nonzero value, the map message header is constructed in the local message buffer. Bytes 08h and 09h of the message are set to the remote drive identifier passed in the call to function VMAP. After construction of message 160-MAP, function VMAP calls transport layer function TSEND to send the message.
If function TSEND returns an error code, function VMAP calls transport layer function TDISCONNECT to terminate the session. Otherwise, function VMAP calls transport function TRECEIVE to receive reply message 160- RMAP (Fig. 10B) that contains the mapped drive letter. If TRECEIVE does not return an error code and the returned drive does not indicate that the remote drive is unavailable, the aliased drive in the drive mapping table is set to the remote drive and the SID indicator to the SID. A success code is then returned to the user application.
If the remote drive is unavailable, a bad drive error code is returned to the user application. If TRECEIVE returns an error code, function VMAP calls transport layer function TDISCONNECT to terminate the session.
Function OAh service SERVE is called by a user application to configure the computer (node) as a server. Service SERVE is actually a higher level service than the other services described above because when service SERVE is successfully implemented in a node, the service responds to the application layer commands from the remote computer that controls the virtual computer. Thus, the basic features of service SERVE are described here and then after the description of the application layer function 09h services, service SERVE is described more completely. Service SERVE calls function VLISTEN to wait for a CONNECT message 160-C (Fig. 7A) from a remote machine and calls function VDISCONNECT at the request of that remote machine. User application 201 (Fig. 5) passes SERVE the address of a callout structure 160-CSTRUCT (Fig. 30) containing the addresses of a Generic Message Handler, a Status Event Handler and a User Terminate Handler. The entries in the callout structure are optional and unused entries must be set to 0:0. The format of callout structure 160-CSTRUCT is illustrated in Fig. 30.
The Generic Message Handler is called by the server whenever SERVE receives a generic message. The Status Event Handler is called by the server when a request is received from a remote machine and again before a reply to the request is sent. The Generic Message Handler is called, as described below, with the length of the message data in register CX, the size of the message data buffer in register BX and the address of the message data in register DX:AX.
The Generic Message Handler services the request, updates the message buffer with new data and returns the length of the updated message buffer or an error code in register AX. If register AX is zero, then no reply message is sent. If register AX is -1, the Server does not send a reply and calls function VDISCONNECT.
The Status Event Handler is called with address of the Status Event structure in register DX:AX. Status Event structure 160-STATSTRUCT contains a current status structure (See Fig. 31) followed by the far address of the current message. The Status Event Handler is called every time the server receives a message other than a generic send message (Fig. 9A) and again just prior to the server sending a reply message other than a generic reply message (Fig. 9B) .
The Generic Message Handler and the Status Event Handler are allowed to use the services of virtual network executive 202 as long as the request does not require communication with a remote node. References to application layer function 09h services (Table 3) that require remote access return with the Carry flag set and register AX set to five (Access denied) . References to application layer function 10 services (Table 1) that require remote access return with an error code of -15 in register AX.
The User Terminate Handler is used by the user application program to signal the Server to terminate
(after any necessary clean up) . The server calls the User Terminate Handler after a remote function request is serviced and at a predetermined time interval, e.g.. every 15 seconds, in one embodiment, while waiting to receive a remote function request. The User Terminate Handler returns a zero in register AX indicating that the server should not terminate. A one returned in register AX signals the server to terminate.
The handling function for select disk service OEh of function 09h calls function SELDSK with the SID, the specified drive, and a pointer to the local message buffer. Initially, function SELDSK sets up the eight byte header for message 160-SDSK, as shown in Fig. 11A. Bytes 08h and 09h of the message are then set to the drive passed in the call to function SELDSK. Function SELDSK calls transport layer function TSEND to transport the message across the virtual network to the node indicated by the SID.
If select disk message 160-SDSK (Fig. 11A) is transmitted successfully by function TSEND, function SELDSK calls transport layer function TRECEIVE to receive reply message 160-RSDSK. The response to select disk message 160-SDSK is illustrated in Fig. 11B. The generation of the select disk reply message is described below in the discussion of the server function operation. If function TRECEIVE is successful, function SELDSK gets the returned drive letter from bytes 08h and 09h of reply message 160-RSDSK. The returned drive letter is set in the register AX and processing returned to user application as described above.
If either TSEND or TRECEIVE returns an error flag, the carry flag is set and the return error value is placed in register AX. Again, processing is returned to the user application as described above.
The handling function for get free disk space service 36h of function 09h calls function FREESPACE with the SID, the specified drive, and a pointer to the local message buffer. The operation of function FREESPACE is nearly identical with that described above for function SELDSK. Message 160-FS in Fig. 12A is constructed in the local message buffer and transport layer functions TSEND and TRECEIVE used as previously described. Reply message 160-RFS (Fig. 12B) received by function TRECEIVE has the number of sectors per cluster in bytes 08h and
09h; the number of free clusters in bytes OAh and OBh; the number of bytes per sector in bytes OCh and ODh; and the total number of clusters on the disk in bytes OEh and OFh. Function FREESPACE enters these four values in registers AX through DX respectively. The error handling and return are as described in function SELDSK.
The handling functions for function 09h make directory service 39h, remove directory service 3Ah, change directory service 3Bh, and delete file service 41h all call function DIRFUNCS. Each service provides function DIRFUNCS with the SID, the service identification, the drive, a pointer to the path for the service, and a pointer to the local message buffer. The messages for service 39h. (Fig. 13A) , for service 3Ah (Fig. 14A) , for service 3Bh (Fig. 15A) , and for service delete file 41h (Fig. 16A) have the same basic structure. The only difference is the service identification in byte six. Similarly, the reply messages. Fig. 13B, Fig. 14B, Fig. 15B, and Fig. 16B respectively also have the same structure.
Hence, function DIRFUNCS first creates in the local message buffer the message header using the information passed to the function. After the message header is created, the path name prepended with a drive letter and a colon is copied into the local message buffer. The drive letter is determined by the drive identifier passed to function DIRFUNCS. As previously described, transport layer function TSEND is used to send the message over the virtual network and transport function TRECEIVE to receive the reply message from the server indicated by SID. If function TSEND and function TRECEIVE are successful, register AX is set to length of the reply message which is given by result in bytes OAh and OBh in the reply message. If the error code in bytes 08h and 09h of the reply message indicate an error, the carry flag is set. If function TSEND or function TRECEIVE generates an error, the carry flag is set and register AX set to operating system network error code. Processing returns to the user application as described above.
Messages 160-CF, 160-OF for service create file 3Ch and service open file 3Dh are given in Fig. 17A and Fig. 18A, respectively and associated reply messages 160-RCF, 160-ROF are given in Fig. 17B and Fig. 18B, respectively. The structure of these messages are identical, and both services access function CROP. The handling functions for these services pass the SID, the service identifier, the drive identifier, the access attribute of the file, a pointer to the path for the file and a pointer to the local message buffer to function CROP. Function CROP opens or creates a file and provides the user application with a 16 bit integer, called a handle, that is subsequently used to identify the file.
However, function CROP opens a file in a remote node and the operating system in the local node is not aware of this operation. Therefore, the local operating system could create a handle for a local file that would be the same as the handle for a remote file. To prevent this potential conflict, each time function CROP is called the first operation is to generate another handle using the local operating system so that the local operating system handle count remains consistent with the number of files opened or created. Thus, the first operation in function CROP is to use the operating system to locally duplicate the file handle "StdOut" (Standard Output) . This operation assures unique file handles. Function CROP then sets register AX to the handle generated by duplication and checks to determine whether the handle was successfully generated. If an error occurred, the carry flag is set and function CROP returns control to the user application as described above. After assuring unique handles, function CROP generates in the local message buffer the header for the service identified in the call to function CROP. After the message header is created, the path name prepended with a drive letter and a colon is copied into the local message buffer. The drive letter is determined by the drive identifier passed to function CROP. As previously described, transport layer function TSEND is used to send the message over the virtual network and function TRECEIVE is used to receive the reply message from the server indicated by SID. If function TRECEIVE transmission is successful and bytes 08h and 09h of the reply message do not inidicate an error, register AX is already set to the appropriate handle, as described above. Thus, the table of file handle structures is updated with the current SID and the handle set to the returned value in bytes OAH and OBh of the reply message. (See Figs. 17B and 18B.) Processing returns to the user application as described above.
If function TRECEIVE transmission is successful and bytes 08h and 09h of the reply message inidicate an error, register AX is set to the value in bytes OAh and OBh of the reply message and the carry flag is set. The locally duplicated file handle is closed so that the handles remain unique. Processing returns to the user application as described above. However, if function TRECEIVE or function TSEND returns an error code, register AX is set to operating system network error and the carry flag is set. Also, the locally duplicated file handle is closed so that the handles remain unique and processing is returned to the user application as described above.
Close file service 3Eh handling function calls function NETCLOSE to close a remote file. Function NETCLOSE is passed a pointer to the local message buffer and the handle of the file to be closed. Function NETCLOSE obtains the SID for the passed handle from the table of handles and then constructs message 160-CFI shown in Fig. 19A in the local message buffer. As previously described, transport layer function TSEND is used to send the message over the virtual network and function TRECEIVE to receive the reply message from the server indicated by SID.
If function TRECEIVE transmission is successful, register AX is set to the result received in bytes OAh and OBh of reply message 160-RCFI (Fig. 19B) . If the error code in bytes 08h and 09h of the reply message indicate an error, the carry flag is set and processing returns to the user application as described above. If the error code does not indicate an error, the local file handle in the table of file handle structures is closed. The file handle and the SID in the table of file handles are set to zero. Processing returns to the user application as described above.
However, if either function TRECEIVE or function TSEND returns an error code, register AX is set to operating system network error code and the carry flag is set. Processing returns to the user application as described above.
Write file service 4Oh handling function calls function NETWRITE. Function NETWRITE is passed a handle for the file to be written over, a pointer to the information to be written along with the length of the information, and a pointer to the local message buffer. Message 160-W generated by function NETWRITE is illustrated in Fig. 20A and reply message 160-RW from the server in Fig. 2OB. Prior to considering the operation of function
NETWRITE, a compression scheme used in function NETWRITE is considered. Compression of the information written across the virtual network increases the performance of the network. However, the function NETWRITE could also be used without compression or alternatively with compression schemes other than the one described herein. Moreover, the information in array of the other messages, e.g., the generic send message described above, could also be processed with the following compression scheme.
In this embodiment, information compression is achieved using a run length limited (RLL) scheme. The compressed buffer has the following form:
Length (# of objects in buffer) [object 1] (First object)
[object 2] (Second object)
[object n] (Final object) .
Each object i, where i =1 to n, has one of the following forms:
Compressed object:
Tag indicating object type(byte)
Length # of compressed bytes(word) Data Uncompressed data(word) Uncompressed object:
,L' Tag indicating object type(byte) Length Size of uncompressed object(word)
Data 'length' bytes of uncompressed data.
Thus, a stream of data with identical adjacent bytes generates a compressed object, and a stream of data containing non-identical adjacent bytes generates an uncompressed object. For example, consider a buffer having the following data and assuming Intel byte ordering:
01 01 01 01 01 02 03 04 05 06 07
02 02 02 02
The compressed buffer contains:
03 'R' 05 00 01
'L' 06 00 02 03 04 05 06 07 'R' 04 00 02
As described more completely below, when write or send compresses information the corresponding function, read or receive, must decompress (expand) the data. The decompression (expansion) scheme consists of just the inverse operations of the compression scheme, i.e., reading the number of objects and then for each object performing the appropriate operation for the given flag. Returning to the operation of function NETWRITE, the handle passed in the call to function NETWRITE is used as an index into the handle table to obtain the SID for the write operation. Since the length of the data in the information buffer may be greater than the length of the local message buffer, a pointer, called the buffer offset, is used track the portion of data in the information buffer that has been transmitted. Initially, the buffer offset is set to zero so that the pointer is aligned with the start of the data. After each transmission, the buffer offset is incremented by the length of the data region in the local message buffer, sometimes called the buffer length.
Hence, if the buffer offset is less than the length of the information to be written, function NETWRITE compares the local message buffer length with the length of the data remaining to be written in the information buffer. If the length of the remaining data buffer is greater than the local message buffer, length is not changed, but if the length of the remaining data is less than the local message buffer length, length is set to the length of the remaining data.
After determination of the buffer length for transmission, the eight byte header for write message 160-W is generated in the local message buffer. The file handle passed is placed in bytes 08h and 09h and then the data being transmitted is compressed, as described above. The length of the compressed data is placed in bytes OAh and OBh of the message and the compressed data follows starting in byte OCh. Transport function TSEND is used to transmit the message to the remote node, and if function TSEND is successful, transport function TRECEIVE is called.
If function TRECEIVE successfully receives reply message 160-RW shown in Fig. 2OB, register AX is set to the result in bytes OAh and OBh of the reply message. If bytes 08h and 09h of the reply message indicate an error occurred, the carry flag is set and processing returns to the user application as described above. If no error occurred, the value of the result is compared with the buffer length. If the result is less than the buffer length, the remote device is full because the operating system, when a full device is encountered, terminates writing, but does not generate an error message. When such an error occurs and the buffer length is greater than the result, the result is added to the current value of the buffer offset. The sum is placed in register AX and processing returned to the user application as described above. Thus, the user application can compare the returned length with the length of the information to ascertain that an error occurred. If the buffer length and the result in the reply message are the same, the buffer offset is incremented by adding the buffer length to the buffer offset and the transmission process repeated until the buffer offset equals the information length. When the buffer offset equals the information length, the buffer offset is placed in register AX and processing returned to the user application as described above.
If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and the error code operating system network error is placed in register AX. Processing is returned to the user application as described above.
Read file service 3Fh handling function calls function NETREAD. Function NETREAD, which functions similarly to NETWRITE is passed a handle for the file to be read, a pointer to the buffer where the information read is to be placed along with the length of the buffer, and a pointer to the local message buffer. Message 160-READ, which is generated by NETREAD, is illustrated in Fig. 21A and reply message 160-RREAD from the server in Fig. 21B.
The handle passed in the call to function NETREAD is used as an index into the handle table to obtain the SID for the read operation. Since the length of the local message buffer may be less that the length of the buffer for the information read, a pointer, called the buffer offset, is used track the portion of buffer for the read information that is filled. Initially, the buffer offset is set to zero so that the pointer is aligned with the start of the data. After each transmission, the buffer offset is incremented by the length of the data region in the local message buffer, sometimes called the buffer length.
The eight byte header for read message 160-READ is generated in the local message buffer. The file handle passed is placed in bytes 08h and 09h and the length of the data to be read is placed in bytes OAh and OBh of the message. Transport function TSEND is used to transmit the message to the remote node. A flag indicating that more data is to be read is set. If function TSEND is successful, transport function TRECEIVE is called.
If function TRECEIVE successfully receives the reply message shown in Fig. 2IB, and if bytes 08h and 09h of the reply message do not indicate that an error occurred, the data in the reply message is decompressed into the information buffer. Subsequently, the buffer offset is set to the length of the decompressed data. The more flag in bytes OCh and ODh of the reply message are next examined to ascertain whether more data will be sent from the remote node. If the more flag is set, processing branches back to the call to transport function TRECEIVE. If the more flag is not set, all the data has been received and register AX is set to the buffer offset which is the length of the data read. Processing is returned to the user application as previously described. If function TRECEIVE generates an error, the receive is retried. However, if an error occurred as indicated in the reply message, register AX is set to the length received as indicated in bytes OAh and OBh of the reply message, which in this case is an error code generated by the operating system in the remote node. The carry flag is set and processing returned to the user application as previously described. Similarly, if function TSEND fails to successfully send the message, the carry flag is set and the error code operating system network error is placed in register AX. Processing is returned to the user application as described above.
Lseek service 42h handling function calls function NETLSEEK. Function NETLSEEK is passed the handle of the file being accessed, an offset value, a relation indicator that represents the seek mode, and a pointer to the local message buffer. The handle passed in the call to function NETLSEEK is used as an index into the handle table to obtain the SID for the seek operation. Next the eight byte message header for message 160-SEEK (Fig. 22A) is created in the local message buffer. The passed handle is placed in bytes 08h and 09h of the message buffer, the passed file offset in bytes OAh through ODh, and the passed relation in bytes OEh and OFh. Hence, message 160-SEEK, as shown in Fig. 22A, has been created. Transport function TSEND is called to transmit message 160-SEEK to the server node. If function TSEND is successful, transport function TRECEIVE is called to receive reply message 160-RSEEK (Fig. 22B) from the server node. If transport function TRECEIVE is successful and the error code in the reply message(bytes 08h and 09h) indicates an error, register AX is set to the extended error returned in bytes OAh and OBh of the reply message and the carry flag is set. Processing is returned to the user application as described above. However, if an error was not generated by the seek operation, register AX is set to bytes OCh and ODh of reply message 160-RSEEK and register DX is set to bytes OEh and OFh of the reply message. Bytes OCh through OFh in the reply message are the new file offset. Processing is returned to the user application as described above. If either transport function TSEND or transport function TRECEIVE generate an error, register AX is set to indicate operating system network error and the carry flag is set. Processing again returns to the user application as described above. Service Chmod 43h handling function calls function
NETCHMOD. Service Chmod 43h is used to either set or get the attribute of a remote file. Hence, function NETCHMOD is passed the SID, the attribute, a flag that indicates whether to get the file attribute or set the file attribute, a remote drive indicator, the path for the file and a pointer to the local message buffer.
Using the passed information, function NETCHMOD builds message 160-CHMOD shown in Fig. 23A in the local message buffer. The SID, the attribute, function code(the passed flag) , and the path length are place in bytes 08h and 09h, OAh and OBh, OCh and ODh respectively. The path is copied to the local message buffer and prepended with a drive letter, based upon the passed drive indicator, and a colon. Transport function TSEND is used to send the completed message to the remote server node. If function TSEND is successful, transport function TRECEIVE is called to receive reply message from the remote server node. If function TRECEIVE successfully received the reply message illustrated in Fig. 23B, register AX is set to the value in bytes OAh and OBh of the reply message. If the operation in the remote node was successful, these bytes contain the attribute. Otherwise, the bytes contain an error code. If the error code bytes in the reply message, bytes 08h and 09h indicate an error, the carry flag is set and processing returns to the user application as described above. Conversely, if these bytes indicate no error, register CX is set to the value of register AX and processing returns to the user application as described above. If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
Get current directory service 47h of function 09h is used to obtain the current directory for a specified path on a remote drive. Thus, when current directory service handling function calls function NETGETDIR, the SID, the remote drive indicator, the path on the remote drive, and a pointer to the local message buffer are passed to function NETGETDIR. Using the passed information, function NETGETDIR generates the header for message 160- GDIR, illustrated in Fig. 24A, in the local message buffer. Bytes 08h and 09h in the message are set to the passed remote drive indicator. The return pointer is initialized to the location OEh in the reply buffer. Function NETGETDIR then calls transport layer function TSEND to transmit the message to the server node. If function TSEND is successful, function NETGETDIR calls transport function TRECEIVE. Upon TRECEIVE successfully receiving reply message 160-RGDIR (Fig. 24B) register AX is set to the extended error code in bytes OA and OBh. If the error code bytes in the reply message, bytes 08h and 09h indicate an error, the carry flag is se and processing returns to the user application as described above. Conversely, if these bytes indicate no error, the path name in the reply message is copied to th path name passed in the call to function NETGETDIR and processing returns to the user application as described above. If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
Terminate session service 4Ch is processed locally so that a message structure is not needed. Terminate session service handling function calls function NETTERMINATE which in turn calls function VDISCONNECT, described above, if this is an active connection with a remote node. After the call to function VDISCONNECT, the virtual network executive is identified as inactive and processing returned to the operating system. Find first service 4Eh finds the first file matching a particular file specification. This service uses a structure defined by the operating system as the disk transfer area (DTA) . Therefore, to assure proper functioning of this service in all computers, prior to initiating the network executive for the first time, a local interrupt 21h find first service should be performed. This operation effectively initializes the DTA so that it is available.
The handling function for find first service calls function NETFINDFIRST. The SID, a file attribute, a remote drive indicator, a path and a pointer to the local message buffer are passed to function NETFINDFIRST. Function NETFINDFIRST builds the standard eight byte header in message 160-FF, as illustrated in Fig. 25A, for the find first service in a manner similar to that previously described for other function 09h services.
After the message header is created, the path name prepended with a drive letter and a colon is copied into the local message buffer. The drive letter is determined by the drive identifier passed to function NETFINDFIRST. The file attribute passed to function NETFINDFIRST is placed in bytes 08h and 09h of the local message buffer and the path length in bytes OAh and OBh. As previously described, TSEND is used to send the message over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message
160-RFF (Fig. 25B) from the server node indicated by SID.
If function TRECEIVE successfully receives the message, register AX is set to the extended error code in bytes OAh and OBh of reply message 160-RFF (Fig. 25B) . If the error code bytes in the reply message, bytes 08h and 09h, indicate an error, the carry flag is set and processing returns to the user application as described above. Conversely, if these bytes indicate no error, the 2Bh byte result in the reply message is copied to the current DTA, and processing returns to the user application as described above.
If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
Find next service 4Fh finds the next file matching a particular file specification. This service is typically used after find first service 4Eh. Thus, the search process has already been initialized. Consequently, when the handling function for find next service calls function NETFINDNEXT only the SID and a pointer to the local message buffer are passed the function. Function NETFINDNEXT also builds the standard eight byte header in message structure 160-FN, as illustrated in Fig. 26A, for the find next service in a manner similar to that previously described for other function 09h services. After the message header is created, a copy of the DTA that was returned by the find first service is copied into the data area of the message. The remaining operations after construction of the message are identical to those described above for function NETFINDFIRST after the generation of the message, which are incorporated herein by reference. Rename service 56h renames a file on a remote drive.
The handling function for rename service calls function NETRENAME. The SID, a remote drive indentifier for the file to be renamed, a path for the file to be renamed, a remote drive indentifier for the renamed file, a path for the renamed file, and a pointer to the local message buffer are passed to function NETRENAME. Function NETRENAME builds the standard eight byte header in message 160-REN, as illustrated in Fig. 27A, for the rename service in a manner similar to that previously described for other function 09h services. After the message header is created, the path name for the file to be renamed is prepended with a drive letter and a colon is copied into the local message buffer. The path name is terminated with a zero. The drive letter is determined by the drive identifier for the file to be renamed that is passed to function NETRENAME. The length of this path name is placed in bytes 08h and 09h of the local message buffer. The path name for the renamed file is prepended with a drive letter and a colon is copied into the local message buffer after the first path. The path name is terminated with a zero. The drive letter is determined by the drive identifier for the renamed file that is passed to function NETRENAME. The length of this path name is placed in bytes OAh and OBh of the local message buffer. As previously described, function TSEND is used to send message 160-REN over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message 160-RREN (Fig. 27B) from the server node indicated by SID. If function TRECEIVE successfully receives message
160-RREN (Fig. 27B) , register AX is set to the result in bytes OAh and OBh of reply message 160-RREN and processin returns to the user application as described above. If the error code bytes in the reply message, bytes 08h and 09h, indicate an error, register AX is set to the result in bytes OAh and OBh of the reply message (Fig. 27B) . Th carry flag is set and processing returns to the user application as described above.
If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
Function 09h get/set file's date and time 57h is used to either get the date and time for a remote file or set the date and time for a remote file. The handling function for service 57h calls function NETDATETIME. The file handle, a function indicator to distinguish between the get and the set operation, the date and the time for a set operation, and a pointer to the local message buffer are passed to function NETDATETIME by the handling function. Function NETDATETIME builds the standard eight byte header of message 160-GT, as illustrated in Fig. 28A, for service 57h in a manner similar to that previously described for other function 09h services. The SID is obtained from the file handle table using the passed handle. After the message header is created, the handle is placed in bytes 08h and 09h, the function indicator in bytes OAh and OBh, the time in bytes OCh and ODh, and the date in bytes OEh and OFh.
As previously described, function TSEND is used to send the message over the virtual network and if function TSEND is successful, function TRECEIVE is called to receive reply message 160-RGT (Fig. 28B) from the server node indicated by SID.
If function TRECEIVE successfully receives reply message 160-RGT (Fig. 28B) , and the error code bytes in the reply message, bytes 08h and 09h, do not indicate an error, register AX is set to zero. Register DX is set to the date in bytes OCh and ODh of the reply message. Register CX is set to the time in bytes OAh and OBh of the reply message and processing returns to the user application as described above.
If the error code bytes in the reply message, bytes 08h and 09h, indicate an error, register AX is set to the result in bytes OAh and OBh of the reply message (Fig.
28B) . The carry flag is set and processing returns to the user application as described above.
If either function TRECEIVE fails to receive the replay message, or function TSEND fails to successfully send the message, the carry flag is set and an operating system network error code is placed in register AX. Processing is returned to the user application as described above.
Function OAh SERVE service handling function calls application layer function VSERVE. The handling function passes a speed for communication with the server node, a timeout value that indicates the time interval to wait for a response from a remote node, a port to use in establishment of the virtual network, the data segment register value, the extra segment register value and a pointer to the callout structure, described above, that contains the addresses of the Generic Message Handler, the Status Event Handler, and the User Terminate Handle. A byte map 160-CSTRUCT for the callout structure is given in Fig. 30.
Function VSERVE first ascertains whether the network executive is active. If the network executive is not active, a flag is returned to the user application indicating that the network executive is not active. After checking whether the network executive is active, the server status is set to active and function VLISTEN, described above, is called to poll for a connect request from a remote node. Upon receipt of a connect, function VLISTEN provides an SID and function VSERVE sets SID equal to the value provided by function VLISTEN. If the SID is not greater than zero, the server status is se to inactive and the SID is returned to the user application.
If the SID is greater than zero, function VSERVE first sets up a critical error handler intercept. The critical error handler fails the function in manner known to those skilled in the art. For example, see R. Duncan (Editor) , The MS-DOS Encyclopedia. Microsoft Press, Redmond, Washington pp. 390-398, (1988).
Next function VSERVE calls a function SERVERMAIN. Function SERVERMAIN is described more completely below. Function SERVERMAIN terminates in one of the following ways:
(i) a receive error that is not a timeout; (ii) any send error; (iϋ) the User Terminate Handler returning a nonzero value; or (iv) any server function including generic send and receive returning an error value. Upon return to function VSERVE from function SERVERMAIN, the critical error handler to reset and the server status is set to inactive. The result of SERVERMAIN is returned to the user application.
The SID, the data segment register value, the extra segment register value and the pointer to the callout structure are passed to function SERVERMAIN by function VSERVE. Function SERVERMAIN is the function dispatcher for the server, i.e., this function receives the message from the first computer, a remote node, performs the operation specified in the message locally, and constructs and dispatches a reply message to the remote node. Hence, function SERVERMAIN generates each of the reply messages described above for function 09h and function OAh services when function VSERVE is called by user application 201.
Upon entry to function SERVERMAIN, the current DTA is obtained and associated with a variable, i.e., the variable is held with that address. If the callout table is defined and the callout table has a defined Status Event Handler, in this embodiment, a non-null entry, the event callout is set to the address of the Status Event Handler in the callout table. The event callout register DS is set to the passed data segment register value and event callout register ES is set to the passed extra segment value. The byte structure in one embodiment of the Status Event Handler is illustrated in Fig. 31.
Function SERVERMAIN next ascertains whether the User Terminate Handler in the callout table (Fig. 30) is defined. If the User Terminate Handler is defined, function SERVERMAIN calls the User Terminate Handler, which was described above. If the User Terminate Handler returns a zero, processing continues as described below. If a nonzero value is returned, a user termination flag is set and processing transfers to the server error exit. The server error exit performs the clean-up operations necessary to close the server and calls transport layer function TDISCONNECT. Upon completion of function TDISCONNECT, the error is returned to the user application.
If the User Terminate Handler is not defined, or the User Terminate Handler returns a zero, function SERVERMAIN calls transport layer function TRECEIVE. If function TRECEIVE generates a timeout error, function SERVERMAIN returns processing to the step that determines if the User Terminate Handler is defined. If function TRECEIVE generates any other error, processing transfers to the server error exit described above. If function TRECEIVE successfully receives a message, the first four bytes of the message are checked to ascertain whether the identifier indicates that the message was sent by the virtual network executive. If the proper identifier is not detected, processing transfers back to the step that determines if the User Terminate Handler is defined. Otherwise, function SERVERMAIN calls application layer function VSTATUS, described above. After function SERVERMAIN calls function VSTATUS, if the Status Event Handler is defined, the Status Event Handler is called with the address of the status buffer. If the function number in byte six of the message does not indicate a generic message, the server function corresponding to byte six of the message is called. These functions are described more completely below. After completion of the function, the length of the reply message generated by the called server function is stored for further processing as described below.
If byte six of the message indicates a generic message, the stored message length is set to zero. If the Generic Message Handler is defined in the callout structure, function SERVERMAIN calls the Generic Message Handler providing the length of the message data in register CX, the size of the local message buffer in register BX and the address of the message data in register pair DX:AX. The Generic Message Handler services the request, updates the local message buffer with new data and returns the length of the updated message buffer or an error code in register AX. The actual operation or operations performed by the Generic Message Handler are defined by the user application, because the user application must provide the Generic Message Handler. However, the Generic Message Handler must parse the message in Fig. 9A and generate information for the message in Fig. 9B.
The length returned by the Generic Message Handler is stored for further processing as described below. If the length is greater than zero, the eight byte generic reply message header (Fig. 9B) is constructed in the local message buffer and the length of the message is put in bytes 08h and 09h of the generic reply message. The stored length is updated to the length of the message. After processing by either the specified server function or the Generic Message Handler, if the stored length is greater than zero, function SERVERMAIN again calls the Status Event Handler, if the handler is defined. After the call to the handler, transport layer function TSEND is called to send the reply message to the remote node. If function TSEND returns an error, processing transfers to the server exit error, described above.
If the Status Event Handler is not defined or if function TSEND does not return an error, and if the stored length is less than zero, which indicates that an error has occurred, processing transfers to the server exit error, described above. Conversely, if the stored length is greater than zero, processing transfers back to the check to determine if the User Terminate Handler is defined.
Each of the function 09h functions (Table 3) has a counterpart that is called by SERVERMAIN. Generally, each of these functions parses the message sent, uses the information in the message to set registers to the appropriate values, and issues an interrupt 21h to the local operating system. The function uses the information supplied by interrupt 21h to generate the reply message for the function. Specifically, services select disk OEh, get free space 36h, make directory 39h, remove directory
3Ah, change directory 3Bh, delete file 41h, change mode 43h, lseek 42h, rename 56h, and get date and time 57h fall in this class. The other function 09h services require additional operations, as described below. The server functions for services create 3Ch and open
3Dh parse the incoming message and initiate the appropriate interrupt 21h service. After building the eight byte reply message header (Figs. 17B and 18B) , the result returned by the operating system is placed in bytes OAh and OBh of the reply message. If the operating system set the carry flag, the error code in bytes 08h and 09h of the reply message are set in this embodiment to one. If the carry flag is not set, an empty slot is found in the local file handle table. The SID for the empty slot is set to the SID in the incoming message and the slot to the result returned by the operating system, i.e., the handle. The size of the reply message is returned to function SERVERMAIN.
The server function for service close 3Eh is similar to the functions for create 3Ch and open 3Dh. The difference is that this function searches in the local file handle table for the handle corresponding to the SID in the incoming message. If the handle corresponding to the SID is the correct handle, both the SID and the handle are set to zero. The server function for service read 3Fh is somewhat more complex because the length of the data to be read (bytes OAh and OBh in the incoming message (Fig. 21A) ) may be greater that the data region in the reply message. Thus, this function parses the incoming message to obtain the file handle and the length of the data to be read. If the read length is greater than the data length of the reply message, the read is broken into a series of reads such that all but possibly the last read fill the data region of the reply message. For each read, the eight byte header for the reply message is created and then an interrupt 21h read is sent to the operating system where the length of the read is equal to the data region in the reply message. The length of the read returned by the operating system is added to the length of the previous reads and saved so that comparison of the stored value and the read length from the incoming message shows that the read is complete. The read data is compressed, as previously described, and put in the local message buffer. The length of the compressed data is placed in bytes OAh and OBh of the reply message. If the operating system set the carry flag indicating an error in the read, bytes 08h and 09h in the reply message (Fig. 2IB) are set to a nonzero value in this embodiment. If an operating system error did not occur and there are additional bytes to read the more flag is set, but if there are not additional bytes to read the more flag is not set. Next, the Status Event Handler is called if the handler is defined. After the call to the handler, transport layer function TSEND is called to send the reply message to the remote node. If function TSEND returns an error, processing transfers to the server exit error, described above. If function TSEND does not return an error, this process is repeated until all the bytes have been sent. When all the bytes have been sent, a length of zero is returned to function SERVERMAIN. The server function for service write 4Oh parses the incoming message (Fig. 20A) , decompresses the data, as described above, and initiates an interrupt 21h write. The function then builds the eight byte header for the reply message (Fig. 2OB) in the local message buffer and sets the OAh and OBh bytes of the reply message to the result provided by the operating system. If the carry flag has been set by the operating system, the error code in the reply message is set to a nonzero value. The length of the reply message is returned function SERVERMAIN.
The server function for service get directory 47h also parses the incoming message (Fig. 24A) and subsequently initiates an interrupt 21h get directory service. The function then builds the eight byte header for the reply message (Fig. 24B) in the local message buffer and sets the OAh and OBh bytes of the reply message to the result provided by the operating system. If the carry flag was set by the operating system, the error cod in the reply message is set to one and the path length (bytes OCh and ODh) is set to two in this embodiment. If the carry flag was not set, the path is copied to the local message buffer and the path length is set appropriately. The length of the reply message is returned to function SERVERMAIN.
The server functions for find first 4Eh and find next 4Fh are similar to the server function for write 4Oh, described above, except the appropriate interrupt 21h is called for the service indicated in byte six of the incoming message (Figs. 25A and 26A) . Also, as previously described, the DTA is copied into the data region of the reply message (Figs. 25B and 26B) .
With respect to function OAh services, the Generic Message Handler process VSEND and VRECEIVE messages as described above. In response to a VDISCONNECT message (Fig. 8) , the open files are checked against the SID in the message. If an open file has the SID, the file is closed. Subsequently, transport layer function TDISCONNECT is called and a zero length is returned to function SERVERMAIN. VLISTEN and VSTATUS are not serviced by the server because a connection has been achieved and STATUS is only a local command and no message is sent over the network. VRESET simply resets and nothing is sent over the network so that server has no response.
Server function M&PDRV for service map FDh responds to incoming message 160-MAP (Fig. 10A) . Two possible problems arise in accessing remote drives in the virtual computer. First, the requested drive may not physically exist in the remote node. Second, the operating system in the remote node may take action that would inhibit operation of the virtual network executive. For example, originally most IBM PC compatible microcomputers had only one floppy disk drive, but that drive could be addressed as either drive A or drive B. Drive B in this case did not physically exist. If drive A was being used, and then a command was given for drive B, the operating system would cue the user to insert a disk in drive B and press any key to continue. Obviously, such a response at the remote node would limit operation of the virtual computer. Therefore, the virtual network executive does not permit mapping to a remote drive that does not physically exist. Upon receiving incoming message 160-MAP (Fig. 10A) , server function MAPDRV builds the eight byte header for the reply message 160-RMAP (Fig. 10B) in the local message buffer and sets the 08h and 09h bytes of the reply message to invalid drive. Function MAPDRV next ascertains whether the drive specified in message 160-MAP is both physically present and not removable in the remote node. If both of these conditions are true, bytes 08h and 09h of the reply message are set to the requested drive. A similar action is taken if the drive is removable and the drive exists. The length of the reply message is returned to function SERVERMAIN.
Transport layer 170 (Fig. 5) is called by either a function 120, 130 in application layer 160, or a function in datalink layer 180. In this embodiment, a function that calls a transport layer function interfaces with the transport layer function via a 'C type stack frame with parameters pushed on the stack, from right to left. (Herein, 'C refers to the C programming language as described by B. Kernighan and D. Ritchie, The C Programming Lancruaσe. 1st Edition, Prentice Hall,
Englewood Cliffs, N.J. (1978).) The parameters pushed on the stack are listed in Table 4. Transport layer 170 can process a message from application layer 160 having a size of 64 Kbytes or less. Transport layer 170 breaks the message from application layer 160 into a number of packets. Transport layer 170 assures the correct delivery of each packet to the remote node indicated by the session identification number (SID) by using a CRC-16 checksum, as explained more completely below. Specifically, the transport layer prepends a header to each packet, and appends a CRC-16 checksum. The packet is then handed to datalink layer 180 for delivery to the remote destination.
Transport layer 170 is responsible for detecting errors in the communication link and for handling packet resends when necessary. Transport layer 170 breaks a large message into a sequence of packets when necessary, i.e., when either a specified number errors occur in transmission of the packets or the message has a size greater than the maximum size that can be transmitted in a packet. In one embodiment, a message is divided into 4
KBytes or smaller packets. In general, the maximum packet size must be compatible with the error checking scheme used to assure accurate transmission of the packet. If an error occurs during a packet transfer, transport layer 170 resends the packet a predetermined number of times. If the packet is not sent without error in the predetermined number of times, transport layer responds by halving the size of the packet. If the packet size is at the minimum 256 bytes in one embodiment, then datalink layer 180 is directed to reduce the line speed, and the packet size is increased to the maximum size, 4 KBytes in this embodiment. Further transmission errors cause this process to reoccur, until neither packet size nor speed can be reduced further, whereupon transport layer 170 aborts the transmission process, and returns an appropriate error code to the calling function. Transport layer 170, like the datalink and application layers, is capable, in design, of handling multiple sessions. However, one embodiment restricts the maximum number of sessions because datalink layer 180 would require further development to support multiple sessions.
In this embodiment, transport layer 170 supports a set of seven functions called TLISTEN, TCONNECT, TDISCONNECT, TSTATUS, TRESET, TSEND, and TRECEIVE. The input information that must be provided to each transport layer function by the calling function and the results returned to the calling function are shown in Table 4.
TABLE 4 Transport Layer Functions
TLISTEN
On entry:
Speed: Line baud rate divided by 100 (0 to allow select best speed) . timeout: # of clock ticks to wait for data (0 =
infinite) port: 0 = COM1, 1 = COM2, ... On return:
SID or Negative error code is returned.
TCONNECT
On entry: nodeid: Remote node identification Speed: Line baud rate divided by 100 (0 to allow select best speed) . timeout: # of clock ticks to wait for data (0
infinite port: 0 = COM1, 1 = COM2, ... On return:
SID or negative error code is returned.
TDISCONNECT On entry: sid: Session identification. On return:
An error code is returned indicating success or failure.
TSTATUS
On entry: sid: session identification length: length of supplied buffer statbuf: pointer to supplied buffer On return:
Buffer supplied by the calling function is filled with the status information in the Virtual Network Data Structure and TSTATUS returns zero or an error code.
Virtual Network Data Structure: local node id num. of active sessions array of SID data structures (one for each active session)
SID data structure: session ID ID of remote node number of bytes sent number of bytes received number of send errors number of rev errors current baud rate SAI Version VNA Version Application Msg Dialect TRESET
On entry: length: length of supplied work buffer buffer: pointer to supplied work buffer
On return:
Returns an error code.
TSEND
On entry: sid: session identification length! length of message message: pointer to message On return:
An error code is returned.
TRECEIVE
On entry: sid: session identification length: length of received message buffer: pointer to received message timeout: # of clock ticks to wait for data (0 =
infinite)
On return:
The length of message or an error code is returned.
Transport layer function errors are returned to the application as negative values. Successful completion of a transport layer function is indicated by a positive (generally zero) return value. One embodiment of the return values is given in Table 5.
TABLE 5 Transport Layer Function Return Valve Result in Function Successful function completion -1 - Connection broken
-2 - Unknown node ID
-3 - Invalid line speed
-4 - Send/Receive error -5 - Time out error
-6 - Cannot connect to specified node
-7 - Buffer too small
-8 - Invalid buffer address
-9 - Invalid Session ID -10 - No more sessions available
-11 - CRC error
-12 - Unexpected message
Transport layer functions TLISTEN, TCONNECT, TDISCONNECT, TSTATUS, and TRESET are virtually null operations and each of these functions simply acts as a conduit between application layer 160 and datalink layer 180. Generally, when an application layer function calls the corresponding transport layer function, the transport layer function in turn calls the corresponding datalink layer function. Accordingly, each of the transport layer functions must support the information required by the application layer functions. For example, TSTATUS places status information about the network executive in the supplied buffer. The structure placed in the buffer is equivalent to the application layer status data structure 160-STATSRUCT (Fig. 29) previously described.
While the above functions acts as a conduit, transport layer functions TSEND and TRECEIVE control the number of packets, the size of each packet and the transmission speed used by datalink layer 180 in transmitting each packet to a remote machine. Specifically, when an application layer function calls transport layer function TSEND, the operations illustrated in Fig. 32 are performed. Transport layer functions TSEND (TSEND) 170-S, upon entry, first performs SID check 170-S1. SID check 170-S1 ascertains whether the SID passed in the call to TSEND 170-S is valid. A SID is valid if the SID is not equal to zero, is less than the maximum SID permitted, and is one of the SIDs associated with a session. If the SID passed to TSEND 170-S is invalid, processing transfers to SID error return 170-S2 which in one embodiment sets the error return code to a -9 and returns to the calling function in application layer 160 (Fig. 5) . If SID check 170-S1 (Fig. 32) determines that the SID is valid, pointer check 170-S5 examines the message pointer passed in the call to TSEND 170-S to ascertain whether the message pointer is defined, i.e., not null. The message pointer identifies the start of the message generated by application layer 160 (Fig. 5) . Accordingly, the message pointer must be defined so that TSEND 170-S (Fig. 32) can locate and subsequently process the message. If pointer check 170-S5 determines that the message pointer is not defined, processing passes to pointer error return 170-S4 which, in one embodiment, sets the error return code to -8, invalid buffer address, and returns to the calling function in application layer 160 (Fig. 5).
If pointer check 170-S5 (Fig. 32) determines that the message pointer is defined, processing transfers to reset counter 170-S6. As described more completely below, a bad message error counter is used in determining when to adjust the transmission speed and the packet blocksize. Accordingly, reset counter 170-S6 resets the bad message error counter to zero.
After the bad message error counter is reset, number of packets 170-S7 initially uses the message length as supplied in the call to TSEND 170-S to calculate the number of packets that must be transmitted to the remote node. Recall that in this embodiment a message from the application layer may be up to 64 Kbytes in length, but as previously defined, transmission layer 170 (Fig. 5) can send a packet having a maximum size of 4 Kbytes. Number of packets 170-S7 (Fig. 32) divides the message length by the current packet length and rounds the result to the next higher integer value. Thus, if the length of the message is 64 Kbytes and the current packet length is the maximum 4 Kbytes, number of packets 170-S7 calculates that 16 packets must be transmitted.
Buffer offset initialization 170-S8 sets the buffer offset to zero so that the processing starts at the beginning of the local message buffer. The buffer offset is adjusted so that the offset indicates the data in the local message buffer for the next packet. After buffer offset initialization 170-S8, packet available check 170-S9 determines whether another packet is available for transmission. If all the packets have been successfully sent, packet available check 170-S9 transfers processing to return 170-S10 which in turn transfers control to the calling function in application layer 160 (Fig. 5) with a return code indicating successful completion of TSEND 170-S (Fig. 32).
If packet available 170-S9 determines that packets are available for transmission, processing transfers to build packet 170-S11. Build packet 170-S11 first constructs the header for the packet. In one embodiment, as illustrated in Fig. 33, header 170-MH is 14 bytes in length. The first two bytes are a rudimentary signature, for example, "VI". The third and fourth byte contain a message identification. Since transport layer transfers at least two blocks for every packet, (a send and a receive) the message identification is used to identify which packet the transferred block represents. In one embodiment, the message identification is simply increased sequentially as TSEND processes each packet. The fifth and sixth bytes are the node identification for the source of the packet while the seventh and eighth bytes are the node identification for the destination of the packet. The total number of packets comprising the message as calculated by number of packets 170-S7 is placed in the ninth and tenth bytes of the header while the number of the packet being transmitted is in the eleventh and twelfth bytes of the header. The thirteenth and fourteenth bytes of the header are used to transmit the length of the data contained in this transmission packet. After build packet 170-S11 constructs the header, the data for the packet is copied from the local message buffer into the transmission packet, i.e., entered in the storage area of the packet 170-MD. After the data is copied, build packet 170-S11 calculates the CRC-16 checksum and appends the calculated CRC-16 checksum to the end of the data. In this embodiment, the reverse CRC-16 generating function is used to obtain the CRC-16 checksum. See J. Campbell, C Programmer's Guide to Serial Communications. Chapt. 19, Howard W. Sams and Co., Indianapolis, In. pp 533-550 (1987) . Hence, build packet 170-S11 has constructed a transport layer header, a data region consisting of a portion of the message provided by application layer 160 (Fig. 5) , and has appended a CRC-16 error code.
Upon construction of the packet by build packet 170- Sll (Fig. 32) , the packet is provided to send packet 170- S12 which is described more completely below with respect to Fig. 34. Briefly, send packet 170-S12 calls datalink layer function DSEND, and provides the packet for transmission. Datalink layer 180 either returns a successful completion code, or an error code to send packet 170-S12. Error check 170-S13 determines whether an error code was returned or whether the transmission was successful. If the transmission was successful, error check 170-S13 transfers processing to packet available 170-S9 which then either sends the next packet or returns to application layer 160 (Fig. 5) . However, if error check 170-S13 (Fig. 32) detects an error, processing transfers to message bad check 170-S14.
If the error returned by send packet 170-S12 was a bad message error, processing transfers to count check 170-S15 which determines whether the bad message count as represented by the bad message error counter is less than five. If the bad message error count is less than five, count check 170-S15 transfers control to number of packet 170-S7 which in turn starts the transmission process over.
If count check 170-S15 determines that the bad message counter is equal to or greater than five, processing transfers to set packet number 170-S16 which i turn sets the packet number to one. This branch changes the transmission parameters prior to attempting a resend. Both message bad check 170-S14, when the message is not bad, and set packet number 170-S16 transfer processing to hardware error check 170-S16. If either the connection was broken or a bad node ID was returned by send packet 170-S12, hardware error check 170-S16 transfers to error code return 170-S19. However, if neither the connection was broken nor a bad node ID was returned, processing transfers to blocksize check 170-S20.
If the blocksize is greater than 256 bytes, processing transfers to change blocksize 170-S24 which halves the current blocksize. If the blocksize is equal to 256 bytes, block size 170-S20 transfers to change speed check 170-S21 which determines whether a reduction in the transmission speed if possible. If the virtual network is established through a modem or the speed is at a minimum, the transmission speed cannot be changed so that change speed check 170-S21 transfers to send/receive error return 170-S22 which returns a send error to the calling application layer function. If the speed can be reduced, change speed check 170-S21 calls reduce speed 170-S23 which in turn uses the datalink function DRESET, described more completely below, to reduce the speed of transmission.
Both reduce speed 170-S23 and change block size 170- S24 transfer control to resend 170-S25. Resend 170-S25 resets the buffer offset to the location of the start of the packet where the error occurred and returns processing to build packet 170-S11. Accordingly, the transmission parameters have been changed and the transmission reinitiated at the point of the transmission error. The ability to change the transmission parameters during the transmission of a message is not available in prior art systems. Rather the prior art systems determine the transmission parameters upon connection and use these parameters for all subsequent transmisssions. Send packet 170-S12 (Fig. 32) is illustrated in more detail in Fig. 34. Initialize error counter 170-SP1 first sets the send error counter and the datalink send error counter to a selected value, typically three. After the send error counter initialization 170-SP1, processing transfers to datalink send 170-SP2 which calls the datalink function DSEND, described more completely below. Function DSEND transmits the packet to the remote node. Datalink send 170-SP2 transfers to datalink send error check 170-SP3 which ascertains whether a datalink send error occurred. If a datalink send error did not occur, processing transfers to datalink receive 170-SP9, but if an error was generated at datalink send 170-SP2, the send error counter is decremented by decrement send error counter 170-SP4. Hardware error check 170-SP5 determines whether the datalink send error was a connection broken error or a bad node ID. If either of these errors occurred, processing transfers to error return 170-SP6 which returns to send 170-S12.
However, if hardware error check 170-SP5 fails to detect either error, the datalink send error counter is decremented by decrement error counter 170-SP7. Count check 170-SP8 ascertains whether the error counter has a zero value. If count check 170-SP8 determines that the error count is zero, processing transfers to error return 170-SP6 which functions as described above. However, if the count check is greater than zero, processing transfer to datalink send 170-SP2 which resends the packet.
When datalink send 170-SP2 sends a packet without error, as described above, datalink send error check 170- SP3 transfers to datalink receive 170-SP9 which waits for a reply message from the remote node containing a header, return code and CRC-16 checksum. When datalink receive 170-SP9 receives a reply message, error check 170-SP10 analyzes the return code to determine whether a a datalin receive error occurred. When a datalink receive error is detected error check 170-SP10 branches to error return 170-SP15 which in turn sets the error code, flushes the datalink, as described below, and transfers to decrement counters 170-SP19. However, if error check 170-SP10 does not detect an error, processing transfers to CRC sum chec 170-SP11.
CRC sum check 170-SP11 calculates a CRC-16 checksum for the header and compares the calculated checksum with the CRC-16 checksum received by datalink receive 170-SP9. If the CRC-16 checksums are not the same, processing transfers to return CRC error 170-SP16 which in turn calls datalink flush and sets the error code to a CRC error and subsequently transfers processing to decrement counters 170-SP19. If CRC sum check 170-SP11 does not detect an error, processing transfers to message ID check 170-SP12. If the message ID from datalink receive 170-SP12 does not match the message ID of the transmitted packet, processing transfers to return bad message 170-SP17 which sets the error code to bad message ID. Finally, return code 170-SP13 checks the return code from datalink receive 170-SP70 and if it is less than zero, transfers processing to 170-SP18 which sets the return error code and passes processing to decrement counters 170-SP19. If error checks 170-SP10, 170-SP11, 170-SP12 and 170-SP13 fail to detect an error, processing transfers to return 170-SP14 which provides a successful return code to send 170-S. Decrement counters 170-SP19, upon receiving control, decrements the datalink error counter and the send error counter and passes control to count check 170-SP20. If the error count is greater than zero, processing transfers to datalink send 170-SP12 which repeats the send process. Conversely, if count check 170-SP20 detects zero, processing transfers to error return 170-SP21 which returns an error code to send 170-S. In one embodiment, process 170-SP9 through 170-SP18 are included in a separate function that is called by send packet 170-S12 after error check 170-SP3.
As previously described, TSEND is responsive to a remote node TRECEIVE. The TRECEIVE function is similar to the TSEND function and is illustrated in Fig. 35 through Fig. 37. Function TRECEIVE of transport layer 170, as illustrated in Fig. 35, first performs SID check 170-R1 and pointer check 170-R5. The operation of these checks is equivalent to that described previously for the SID check 170-S1 and pointer check 170-S5 in send 170-S (Fig. 32) , which is incorporated herein by reference. Pointer check 170-R5 transfers processing to receive packet 170-R6. Receive packet 170-R6, which is described more completely below with respect to Fig. 36, calls datalink function DRECEIVE. Receive packets 170-R6 provides the length of the received data, the header and the CRC-16 checksum as well as an error code if an error was detected. Error check 170-R7 determines whether receive packet 170-R6 generated an error. If no error was detected, copy data 170-R12 copies the received data to the receive buffer and then transfers processing to send reply 170-R13.
Send reply 170-R13 is described more completely below with respect to Fig. 37. Briefly, send reply 170-R13 sends the packet of information to datalink receive 170- SP9 (Fig. 34) . If an error occurs in send reply 170-R13 (Fig. 35) , error check 170-R14 passes processing to receive packet 170-R6, which functions as previously described.
If send reply 170-R13 did not generate an error, error check 170-R14 passes control to last packet check 170-R16 which in turn either passes processing to return 170-R18 if the last packet was processed, or passes processing to buffer full check 170-R17. If the receive buffer is full, processing passes to buffer error return 170-R19 which returns a buffer full error to the calling function in application layer 160. If the buffer is not full, buffer full check 170-R17 passes processing to receive packet 170-R6 to obtain the next packet from TSEND.
The above description assumed that error check 170-R7 did not receive an error from receive packet 170-R6. If error check 170-R7 detects an error, processing transfers to increment counter 170-R8 which after incrementing the received error counter passes control to hardware error check 170-R9. If receive packet 170-R6 returned a bad node ID, connection broken, or time out error, hardware error 170-R9 transfers to return error code 170-R15.
Otherwise, hardware error 170-R9 transfers to message bad check 170-R10. If a bad message error was not generated by receive packet 170-R6, message bad check 170-R10 passes processing to receive packet 170-R6. However, if a bad message error was generated, message bad check 170-R10 passes control to set packet number 170-Rll which sets the packet number to one and then transfers control to receive packet 170-R6. TRECEIVE continues to loop from receive packet 170-R6 through the subsequent steps until last packet check 170-R16 returns to the calling program.
Receive packet 170-R6 (Fig. 35) is illustrated in more detail in Fig. 36. Upon entry to receive packet 170- R6, datalink receive 170-RP1 calls datalink function DRECEIVE. Function DRECEIVE receives the packet sent by DSEND, which was called by datalink send 170-SP2 (Fig. 34) . The packet received, as previously described, has a header, a data region and a CRC-16 checksum. Error check 170-RP2 (Fig. 36) checks to determine whether datalink receive 170-RP1, generated an error code. If an error code was generated by datalink receive 170-RP1 processing transfers to datalink flush 170-RP3 which calls the datalink function DFLUSH. Subsequently, selected error check 170-RP4 determines whether the return error was a connection broke error, a time out error, or a bad node ID error. If the error was one of these three selected errors, processing transfers to return error code 170-RP7 which in turn returns to error check 170-R7 (Fig. 35) . If another error was generated, processing transfers to send reply 170-RP5, which is described more completely below. Send reply 170-RP5 generates an error packet and sends the packet to datalink send 170-SP2
(Fig. 34) . After send reply 170-R5 (Fig. 36) completes transmission of the error packet, processing transfers to return error code 170-RP6 which subsequently returns to error check 170-R7 (Fig. 35) . If error check 170-RP2 (Fig. 37) does not detect an error, processing transfers to CRC error check 170-RP8. CRC error check generates a CRC-16 checksum for the received data packet and compares this checksum with the received CRC-16 checksum. If the CRC-16 checksums are identical, CRC error 170-RP8 transfers the processing to packet error 170-RP12. Packet error compares the pocket number with the received packet number and if they are not the same, transfers processing to datalink flush 170-RP3 which calls datalink function DFLUSH, which is described more completely below. Datalink flush 170-RP3 in turn passes processing to send reply 170-RP5, which is described more completely below, and finally to return bad message error 170-RP15. If the packet numbers are the same, packet error 170-RP12 transfers to data return 170- RP16 which returns the length of the received data, the header and a CRC-16 checksum to receive packet 170-R6.
The above discussion assumed CRC error check 170-RP8 did not detect an error. However, if CRC error 170-RP8 detects an error, processing transfers to data flush 170- RP3, send reply 170-RP5 and return CRC error code 170- RP11. The operation of these processes 170-RP3, 170-RP5 and 170-RP11 are equivalent to that described previously for processes for 170-RP3, 170-RP5 and 170-RP15, which is incorporated herein by reference.
Send reply 170-RP5 (Fig. 36) is illustrated in more detail in Fig. 37. Upon entry to send reply 170-RP5, create reply packet 170-SRl generates a packet containing the transport layer header, the passed return code and a CRC-16 checksum. After creation of the packet, initialize counter 170-SR2 initializes an error counter to zero. Datalink send 170-SR3 calls datalink layer function DSEND to transmit the packet created by create packet 170-SRl to the remote machine that sent the received packet. Error 170-SR5 checks to determine whether an error was generated in datalink send 170-SR3. If no error was generated, processing transfers to return 170-SR6 and consequently control passes to the next operation in receive packet 170-R6.
However, if datalink send 170-SR3 generated an error, error check 170-SR5 passes processing to counter check 170-SR7. If the error counter is less than 5, counter check 170-SR7 passes control to increment counter 170-SR4 which increments the error counter and passes processing back to datalink send 170-SR3. Conversely, if the counter error is greater than or equal to 5, counter check 170-SR7 passes control to datalink error 170-SR8 which returns to receive packet 170-R6 with a datalink error code. Thus, transport layer functions TSEND and TRECEIVE call datalink layer function DFLUSH, DSEND and DRECEIVE. In addition to these functions, datalink layer 180 also includes DLISTEN, DCONNECT, DDISCONNECT, DSTATUS and DRESET. As described above, each of these functions responds to the corresponding function in the transport layer. The possible return codes from the datalink functions are presented below in Table 6.
Datalink layer 180 is responsible for the delivery of a single packet across the network (i.e., physical layer), along with support services. No accuracy check is made by the datalink layer. In the event that transport layer 170 requests a speed change, datalink layer 180 arbitrates that change, if possible. Datalink layer 180 is low level, which means that the layer is hardware dependent. In the embodiment presented in Microfiche Appendix A and incorporated herein by reference, datalink layer 180 is compatible with IBM personal computers and IBM compatible personal computers. Through the proper use of datalink layer 180, however, transport layer 170 may effect hardware independence.
Datalink function DRESET (DRESET) is used to initialize or reinitialize the datalink driver. Transport layer function TRESET or any other function calling DRESET passes a parameter to DRESET which indicates to perform either a normal reset or to alter the transmission speed.
One embodiment of function DRESET 180-RST is shown in Figure 38. Reset check 180-RST1 analyzes the parameter passed to function DRESET and passes processing to initialize 180-RST2 if a normal reset is indicated.
Initialize 180-RS2 sets variables used in the datalink functions to selected values. Specifically, datalink layer functions use an intercharacter timeout variable and another timeout variable to monitor the time period spent waiting for an action to occur. These variables are distinguished by referencing "the timeout variable" and "the intercharacter timeout variable." Both of these variables are set to zero as is a flag used to indicate the connection status. A zero value for either timeout variable indicates that the variable is not being used for monitoring the elapsed time.
In this embodiment, the connection status flag is set to zero to indicate no connection or a successful connection; to a -1 to indicate a connection or listen being attempted; and to a -2 to indicate attempting speed arbitration. After the flags and variables are set, initialize 180-RST2 sets the transmission delay variable to a predetermined value, e.g., one, and processing transfers to return 180-RST3 which returns a success to the calling function. Reset check 180-RST1 passes processing to set parameters 180-RST4 when the parameter passed to function DRESET indicates a speed change. Set parameters 180-RST4 first sets the timeout variable to 30 seconds and then calls set speed 180-SS (not shown) to set the transmission speed to 300 baud. Set speed 180-SS is used to set the UART speed to the index passed to the function.
Set speed 180-SS first points to the table of UART baud rate divisors and then loads the divisor corresponding to the passed index. The UART status is monitored until any transmission operation is complete and then the UART baud rate divisor access is enabled. The loaded divisor is sent to the UART, the low byte being sent first and then the high byte. Subsequently, access to the UART baud rate divisor is disabled and processing returned to the calling routine, in this case, to set parameters 180-RST4. Subsequent references to set speed 180-SS refer to this sequence of operations.
After the speed is set to 300 baud by set speed 180-SS, the baud rate index is set to indicate the speed. Subsequently, set parameters 180-RST4 transfers processing to set connect speed 180-CS. Set connect speed 180-CS establishes a transmission rate with a remote node. The operations in set connect speed 180-CS are described more completely below with respect to Figures 39A and 39B. If the operation of set connect speed 180-CS is successful, no error flag is returned and error check 180-RST5 transfers processing to set delay count 180-DC. Set delay count 180-DC first loads the baud rate index. A first variable, loop count, is used to indicate relative machine speed. In this embodiment, loop count is defined by function DCONNECT as the number of times that the register pair DX:AX can be incremented during the time interval between two ticks. A tick, in this embodiment, is 55 milliseconds. If the baud rate is greater than 19,200, the delay count is set equal to the loop count multiplied by eight and divided by the baud rate divisor.
Conversely, if the baud rate is less than 19,200, delay count is set to zero. After delay count is set, set delay count 180-DC returns processing to the calling function. Subsequent references to set delay count 180-DC refer to this set of operations. Accordingly, after set delay count 180-DC completes processing, DRESET 180-RST returns through 180-RST3 to the calling function.
If set connect speed 180-CS generated an error, as described more completely below, error check 180-RST5 transfers processing to error return 180-RST6 which sets the carry flag and returns processing to the calling function.
Set connect speed 180-CS is shown in more detail in Figures 39A and 39B. Generally in the figures, a circle enclosing a letter represents a connection in that figure and a triangle containing a letter represents a connection to another figure. Also in the figures, elements with a similar label are equivalent and multiple references to the same element within a figure are indicated by the label followed by a capital letter.
The first operation in set connect speed 180-CS is set connection status 180-CS1 which sets the connection status flag to indicate that speed arbitration is being attempted. Subsequently, transmit connect character 180-CS2 sends a character to the specified remote node. In one embodiment, the connect character is "ENQ". As used herein, transmit character means that a function is called to send the character over the virtual network. This function is passed the character to be transmitted and a delay factor. The character transmission function waits for the number of ticks specified by the delay factor and then tests the UART status until the transmission holding buffer is empty. The passed character is then sent and processing returns to the calling function. In the subsequent description, a reference to "transmit character" refers to this sequence of operations.
After transmit connect character 180-CS2, timeout check 180-CS3 waits two ticks and then checks the timeout variable described previously. If a timeout has occurred, processing transfers to timeout error return 180-CS4 which in turn sets the return value to a timeout error and the carry flag prior to returning to the calling function. If a timeout has not occurred, timeout check 180-CS3 transfers processing to receive character status 180-RCS. The operations of receive character status 180-CS are described more completely below with respect to Figure 40. Receive character status 180-RC either (i) receives the character sent by the remote node in response to transmit connect character 180-CS, (ii) generates an error code, or (iii) indicates that a character is not ready and then passes processing to character check 180-CS5. If a character was not ready or the character was not an acknowledge, character check 180-CS5 returns processing to transmit character 180-CS2. As used herein, an acknowledge or an acknowledge character refers to a character such as "ACK". If the character is an acknowledge, processing transfers to set timeout 180-CS6 which sets the timeout variable to five seconds.
Processing is then transferred to receive character 180-RC, which is described more completely below with respect to Figure 41. Receive character 180-RC either returns a character or an error to the calling function. Accordingly, error check 180-CS7 transfers control to error return 180-CS9 upon receipt of an error. Error return 180-CS9 sets the carry flag and returns processing to the calling function.
If an error was not returned, processing transfers to start of baud rate sequence check 180-CS8. If the character received does not indicate the start of baud rate sequence, processing transfers to send/receive error return 180-CS10, which in turn sets the return value to a send/receive error and sets the carry flag prior to returning.
If the start of baud rate sequence is received, processing transfers to receive character 180-RC-A, which receives the low byte for the speed of the remote node and the high byte for the speed of the remote node. If either of these receives generates an error, error check 170-CS7-A functions as previously described for error check 180-CS7. If an error is not detected by error check 170-CS7-A, speed requested check 180-CSll compares the received speed with the requested speed. Here requested speed refers to the speed passed in the call to set connect speed 180-CS. If the received speed is less than the requested speed, processing transfers to revise speed 180-CS12 which in turn sets the requested speed to the received speed.
If the speeds are the same or revise speed 180-CS12 completes operation, processing transfers to speed valid check 180-CS13 which ascertains whether the speed is valid. If the speed is either greater than the maximum allowable speed or less than 300 baud, processing transfers to speed error return 180-CS22 which sets the return value to an invalid line speed error and returns after setting the carry flag.
If the speed is valid, receive character 180-RC-B receives the next character transmitted from the remote node. Error check 180-C7-B functions, as previously described, and if there is not an error passes control to end baud rate string check 180-CS14. If the received character does not indicate the end of the baud rate sequence, processing transfers to send/receive error return 180-CS10. However, if the character is the end of baud rate sequence, processing transfers to transmit baud rate 180-CS15 (Fig. 39B) .
Transmit baud rate 180-CS15 is a sequence of actions that sends the selected speed over the virtual network to the remote node. In this embodiment, transmit baud rate 180-CS15 waits eight ticks and then transmits a character that indicates a start of a baud rate change. After transmission of the character, receive character (Fig. 41) is called. Again, receive character either returns a character or an error. If an error is returned, the carry flag is set, the return value is set to a timing error and processing transferred to the calling function. If no error is returned, the received character is checked to determine whether the character is an acknowledge. If the character is not an acknowledge, the carry flag is set, the return value is set to a send/ receive error, and processing return to the calling function.
If an acknowledge is received, after two ticks, the start of baud rate sequence is transmitted followed by the low byte of the speed, the high byte of the speed, and the end of transmission character. This completes operation of transmit baud rate 180-CS15 so that processing transfers to receive character 180-RC-C. If an error is returned, error check 180-CS-16 transfers processing to timeout error return 180-CS4. If the return character is not an acknowledge character, acknowledge check 180-CS17 transfers processing to send/receive error return 180-CS10. If an acknowledge is received, set speed 180-SS is called and performs the operations described above.
Subsequently, receive character 180-RC-D is called and error check 180-CS16-A and acknowledge 180-CS17-B function as described previously. If the received character is an acknowledge, an end of session character is transmitted by transmit end of session 180-C19 and receive character 180-RC-D is used to receive the character from the remote node. If an error is detected, error check 180-CS16-B transfers processing to timeout error return 180-CS4. If the received character is an end of session character, processing is transferred by end of session check 180-CS20 to return 180-CS21, or otherwise to send/receive error 180-CS10.
Function receive character status 180-RCS is illustrated in Figure 40. This function receives one character into register AL, or alternatively sets the Z flag if a character is not ready. Initially, function receive character status 180-RCS performs start test 180-RCS1. Start test 180-RCS1 determines whether a connection is made and whether there is a framing error. A framing error normally occurs only when the two nodes are sending at different baud rates to one another. If there is a connection and a framing error, start test 180-RCS1 passes processing to speed resynchronization 180-SRE, which is described more completely below with respect to Figure 43. Speed resynchronization 180-SRE adjusts the connect speed so that both nodes are communicating at the same speed.
If speed resynchronization 180-SRE returns an error, error check 180-RCS5 returns processing to return 180-RCS4 which clears the Z flag and returns to the calling function. Conversely, if speed resynchronization 180-RCS5 does not return an error, error check 180-RCS5 transfers processing to set error code 180-RCS6 which in turn sets the error return value to a speed change error. Processing is then again transferred to return 180-RC4 which clears the Z flag and returns to the calling function.
If there is no framing error and a connection, start test check 180-RCS1 passes processing to character ready 180-RCS2. If a character is not ready, processing transfers to error return 180-RCS4, which sets the Z flag and returns. Conversely, if a character is ready, processing transfers to read character 180-RCS3, which reads the character from the UART and subsequently transfers processing to return 180-RCS4 which clears the Z flag and returns.
Function receive character 180-RC (Fig. 41) receives one character into register AL. Upon entry, timeout check 180-RC1 determines whether the timeout variable is one. If the variable is one, processing transfers to error return 180-RC11 which sets the carry flag and returns a timeout error. Conversely, if the timeout variable is not one, UART status 180-RC2 reads the UART line status to ascertain whether there is a framing error.
Framing error 180-RC3 then ascertains whether there is a framing error or whether the connection status flag is zero. If there is no framing error or the connection status flag is zero, processing transfers to character ready check 180-RC4. If no character is ready, processing returns to timeout check 180-RC1. Conversely, if a character is ready, read character 180-RC6 obtains the character and transfers processing to return 180-RC7.
If there is a framing error or the connection status flag is not zero, framing error 180-RC3 transfers processing to save timeout 180-RC5 which saves the current timeout value. Processing then transfers to speed resynchronization 180-SRE, which is described more completely below with respect to Fig. 42. Upon completion of speed resynchronization 180-SRE, restore timeout 180-RC8 restores the same saved timeout value and transfers processing to speed change error 180-RC9. If an error is generated by speed resynchronization 180-SRE, speed change error 180-RC9 transfers processing to error return 180-RC11. Conversely, if no error was generated, processing transfers to return speed change 180-RC10 which sets the result of the function to indicate the speed change.
Speed resynchronization function 180-SRE, which was called by receive character function 180-RC (Fig. 41) and receive character status 180-RCS (Fig. 40) is illustrated in Figure 42. In this function, reset timeout 180-SRE1 first zeroes the timeout variable. Subsequently, clear
UART port 180-SRE2 reads the UART data port so as to clear the port. Minimum speed check 180-SRE3 then ascertains whether the speed is set at 300 baud. If the speed is 300 baud, error return 180-SRE4 sets the carry flag and returns a value of speed error to the calling function.
If the speed is not at a minimum, minimum speed check 180-SRE3 transfers to set speed 180-SS, which functions as previously described. Specifically, set speed 180-SS sets the speed in the node to 300 baud and transfers processing to save baud rate 180-SRE5 which sets the baud rate index to correspond to the set baud rate. Next, set listen speed 180-LS is called to resynchronize the speed with the remote node. The operations in set listen speed 180-LS are described more completely below with respect to Figure 43. After completion of set listen speed 180-LS, set delay count 180-DC is called. The operation of set delay count 180-DC was described above and is incorporated herein by reference. Upon completion of set delay count 180-DC, return 180-SRE6 returns control to the calling function.
Function set listen speed 180-LS is illustrated in Figure 43. The call to set listen speed passes the baud rate as a parameter. Set connection status 180-LS1 saves and then sets the connection status flag to -2 to indicate that a speed arbitration is being attempted. Subsequently, receive character 180-RC is used to receive either a character or return an error. If an error is returned, error check 180-LS2 transfers processing to error return 180-LS3 which restores the connection status flag and sets the carry flag prior to returning. If an error is not returned, end of listen check 180-LS9 ascertains whether the received character indicates the end of set listen speed and if so transfers processing to return 180-LS4. Return 180-LS4 sends an acknowledgment that the end of set listen speed character was received; restores the connection status flag to the value upon entry; and returns to the calling function. Otherwise, connect character check 180-LS5 determines whether a connect character was received. If such a character was not received, processing returns to receive character 180-RC.
However, if connect character check 180-LS5 receives a connect character, processing transfers to set timeout 180-LS6 which in turn sets the timeout variable for five seconds. Processing then transfers to transmit baud rate 180-LS7. In this embodiment, transmit baud rate 180-LS7 includes a number of operations. Specifically, an acknowledge character is transmitted and then two ticks later a start baud rate sequence character is transmitted. The low byte of the speed and the high byte of the speed are followed by an end of baud rate sequence character and then processing transfers to save baud rate 180-LS8. Save baud rate 180-LS8 loads the baud rate index from the table based upon the speed and then sets the baud rate index to the loaded index. Set speed 180-SS sets the speed in the local machine, as previously described. An acknowledge character is then sent at the new speed and processing then transfers to receive character 180-RC.
Datalink layer function DSEND is used to send a packet to the remote node where an outstanding function DRECEIVE is active. DSEND returns zero indicating that the packet is successfully sent. A negative error is returned if the packet cannot be sent. The function calling DSEND passes the node ID, the length of the message, and a pointer to the message buffer to function DSEND. One embodiment of DSEND is illustrated in Figure 44.
Disable keyboard 180-S1 turns off the keyboard scanning and transfers processing to send packet size 180-SPS. Send packet size 180-SPS sends to the remote node the size of the packet to be sent. The operation of send packet size 180-SPS is illustrated in more detail in Figure 45. If send packet size 180-SPS returns an error, processing is transferred by error check 180-S3 to enable keyboard 180-S10 which restores keyboard scanning and passes control to return 180-S11 which in turn passes control to the calling function.
If an error is not detected by error check 180-S3, increment bytes sent 180-S4 adds the packet size to the variable that is used to count the number of bytes transmitted since the last reset. Next, for each byte in the packet, byte available 180-S5 ascertains whether there are any additional bytes and then load byte 180-S12 loads the byte so that transmit character 180-S13 can send the byte across the virtual network.
After the packet has been sent, byte available 180-S5 transfers control to get packet size 180-GPS. Get packet size 180-GPS obtains the size of the received packet from the remote node. If an error is generated, processing transfers to enable keyboard 180-S10. However, if an error is not returned, packet size check 180-S7 ascertains whether the passed packet size matches the received packet size. If the packet sizes are different, set error 180-S9 - Ill - sets the return value to send/ receive error and transfers processing to enable keyboard 180-S10. Conversely, if the packet sizes are the same, set success 180-S8 sets the return value to success before passing control to enable keyboard 180-S10.
Function send packet size 180-SPS, which was called by function DSEND, is illustrated in Figure 45. Initialize 180-SPS1 first sets the receive active flag to one and then saves the transmission delay. The transmission delay is then set to delay count, which was described above. The timeout variable is set to fifteen seconds. Timeout 180-SPS2 checks the timeout variable to ascertain whether a timeout has occurred. If a timeout has occurred, set error 180-SPS3 sets the return value to send/ receive error and set flag 180-SPS4 sets the carry flag. Subsequently, restore 180-SPS5 restores the value of the transmission delay to the saved value and resets the receive active flag to zero before passing control to return 180-SPS6. If timeout check 180-SPS2 does not detect a timeout, initiate transmission 180-SPS7 transmits a start of transmission character to the remote node. Receive character status 180-RCS then either receives a character, generates an error, or indicates that a character is not ready as described above. Accordingly, if character ready check 180-SPS9 ascertains that a character is not ready, processing returns to timeout check 180-SPS2. If a character is ready and an error was generated, error check 180-SPS10 returns processing to set flag 180-SPS4. If an error is not returned, acknowledge check 180-SPS11 ascertains whether the character returned by receive character status 180-RCS was an acknowledge character. If the character was not an acknowledge character, processing transfers to set error 180-SPS3. Conversely, if an acknowledge was received, transmit packet size 180-SPS12 sends to the remote node the size of the packet to be sent. Specifically, transmit package size 180-SPS12 transmits a character indicating the start of the transmission, the low byte of the packet size, the high byte of the packet size, and then a character to indicate end of the transmission. Receive character
180-RC then receives a character as described previously with respect to Figure 41. If receive character 180-RC returns an error, error check 180-SPS10-A transfers processing to set flag 180-SPS4. If the character is an acknowledge, acknowledge test 180-SPS11-A transfers processing to restore 180-SPS5. Otherwise, acknowledge test 180-SPS11-A transfers processing to set error 180-SPS3.
Function get packet size 180-GPS, which was also called by function DSEND 180-S, is illustrated in
Figure 46. Initialize 180-GPS1 sets the receive active flag to one and saves the transmission delay and timeout values. Subsequently the transmission delay is sent to delay count, which was described previously. Processing then transfers to receive character 180-RC-A.
If receive character generates an error, error check 180-GPS2 transfers processing to speed change error 180-GPS3 which returns processing to receive character 180-RC-A if the error was set to a speed change error. Conversely, speed change error 180-GPS3 transfers to set flag 180-GPS4 which sets the carry flag and then transfers to restore 180-GPS5. Restore 180-GPS5 returns the saved transmission delay and timeout values to the appropriate variables and sets the receive active flag to zero before transferring processing to return 180-GPS6.
If receive character 180-RC-A did not generate an error, error check 180-GPS2 transfers processing to initiate transmission check 180-GPS7. If the received character did not indicate an initiation of transmission, processing is returned to receive character 180-RC-A. If the received character indicates an initiation of transmission, transmit acknowledge 180-GPS8 sends an acknowledge character to the remote node and then passes processing to receive character 180-RC-B.
Again, if there was an error, error check 180-GPS9 transfers processing to speed change error 180-GPS3 which proceeds as described above. If an error was not generated and a start of transmission character was not received, processing is returned to receive character 180-RC-B by start transmission 180-GPS10. Otherwise, start transmission 180-GPS10 passes processing to receive character 180-RC-C, which receives the low byte of the packet length. Similarly, receive character 180-RC-D receives the high byte of the packet length and receive character 180-RC-D receives the end of the transmission character. If any of these receives generates an error, processing is returned to speed change error 180-GPS2.
Finally, if receive character 180-RC-D does not receive an end of transmission character, end of transmission check 180-GPS11 transfers to set error 180-GPS13 which in turn sets a send/receive error. If an end of transmission is received, transmit acknowledge sends an acknowledge signal to the remote node and clear flag 180-GPS12 clears the carry flag before transferring processing to restore 180-GPS5. As previously described, many of the datalink functions are hardware dependent and accordingly, datalink layer 180 embodiment described herein represents a set of functions for use with an IBM PC compatible computer. However, in view of this disclosure, one skilled in the art can use the application layer functions and the transport layer functions with any datalink layer which provides the services described for those functions.
Many of the datalink functions, in this embodiment, use the fact that every 55 milliseconds, a hardware line on the PC bus, IRQ0, is asserted and causes an interrupt 08h to execute. The operation performed by interrupt 08h is dependent upon the interrupt service routine that is pointed to by the interrupt 08h vector in the low memory of the computer. By changing the address pointed to by this vector a program can cause different functions to be executed at a 55 millisecond interval. As previously described, the 55 millisecond interval is referred to as a "tick".
The datalink layer of this invention uses two different interrupt service routines for interrupt 08h. The first interrupt service routine, 180-INT, is illustrated in Figure 48, and the second, 180-RCV, is illustrated in Figure 49. The second interrupt service routine 180-RCV is used when the datalink is in a receive and the first interrupt service 180-INT is used at all other times when the virtual network is active.
Both of these interrupt service routines are extremely speed critical and the computer code has been optimized for running reliably at full speed. In particular for interrupt service routine 180-RCV, all interrupts other than interrupt 08h are disallowed and assumptions are made about the states of the registers upon entry into the interrupt service routines, as described more completely below.
Interrupt service 180-INT (Fig. 48) upon entry first accesses save registers 180-INTl which saves the necessary registers for the interrupt. Subsequently, increment delay count 180-INT2 increases the delay count. Operations 180-INT3 through 180-INT10 examines the two timeout variables, described previously, and if either variable represents a timeout, the timeout flag is set. Otherwise, the timeout variables are decremented.
Subsequently receive active flag check 180-INT11 ascertains whether the receive active flag is set. If the flag is not set, chain to interrupt 08h 180-INT13 chains through to the old interrupt 08h and then passes processing to restore registers 180-INT14. Restore registers 180-INT14 resets the registers' values to those saved in save register 180-INTl and then return 180-INT15 returns processing to the calling function.
If the receive active flag is set, processing transfers to perform BIOS services 180-INT12. Other processes may be serving interrupt 08h and these processes may take an inordinate amount of time to complete. Therefore, to enhance speed, the function does not chain to the old interrupt 08h. Rather, perform BIOS services 180-INT12 provides the minimum set of services that are normally provided by the BIOS.
Specifically, the BIOS time count at address 0:46Ch is incremented. If the BIOS timer count equals 1800B0h (one day) , the BIOS timer count is set to zero and the BIOS timer overflow flag is set to one. Next, if the BIOS drive time counter at address 0:44Oh is greater than one, the BIOS drive timer is decremented. This completes the services in perform BIOS service 180-INT12.
The second interrupt 180-RCV1 (Fig. 49) has been optimized for the maximum speed. Normally, an interrupt service routine saves the current registers before any other processing. However, this routine saves only register AX. The routine also uses only register AX. However, the routine does access memory so that a segment register pointing to the segment of memory to be accessed is required. The normal interrupt service routine saves at least one segment register and then loads the segment register for the interrupt service routine. However, before enabling interrupt service routine 180-RCV1, all other interrupts are disabled and this interrupt is enabled only during a small section of the datalink function DRECEIVE, which already has a segment set to the datalink data segment. Since all other interrupts have been turned off, no other interrupt service routines can become active when this interrupt becomes active.
Therefore, it is unnecessary to save and load the data segment register DS because the register is already loaded with the proper value.
Thus, the operations in the interrupt service routine 180-RCV1 include save register 180-RCV1, increment the delay count 180-RCV2, and check the intercharacter timeout value 180-RCV3. If the intercharacter timeout value is greater than one, the timeout is incremented and processing returns to end of interrupt 180-RCV5. Otherwise intercharacter timeout check 180-RCV3 passes processing directly to end of interrupt 180-RCV5. End of interrupt 180-RCV5 signals the end of the interrupt to the interrupt controller and restores the register AX. Finally, return 180-RCV6 returns processing to the calling program. Datalink function DRECEIVE is used by the transport layer to wait for a message to be received. On receipt of a message, function DRECEIVE returns the actual length of the message. DRECEIVE is passed the node ID, the length of the receive buffer, a pointer to the receive buffer, and a timeout value corresponding to the number of ticks to wait for data. Function DRECEIVE returns the length of the message or an error code.
One embodiment of datalink function DRECEIVE 180-R is illustrated in Figure 47. Initialize 180-R1 sets the timeout variable to the passed parameter and the timeout flag to zero. Processing subsequently transfers to get packet size 180-GPS (Fig. 46) . Upon receiving the packet size, error check 180-R2 passes processing to initialize receive 180-R7 if an error was not generated. Conversely, if get packet size 180-GPS generated an error, processing passes through error check 180-R2 to set error 180-R3 which in turn sets the error code to the result of get packet size 180-GPS. Subsequently, set timeout 180-R4 sets the timeout variable and the intercharacter timeout variable both to zero. Timeout error check 180-R5 passes processing to error return 180-R6 if a timeout error is not detected. If timeout error check 180-R5 detects a timeout error, processing transfers to send packet size 180-SPS prior to returning to error return 180-R6. Send packet size 180-SPS functions as previously described (Fig. 45) .
Initialize receive 180-R7, upon receiving processing from error check 180-R2, first turns on the receive active flag and then sets the timeout variable to zero and the intercharacter timeout variable to six. Initialize receive 180-R7 then turns on interrupt service routine
180-RCV1 (Fig. 49) . Subsequently, processing transfers to UART status 180-R8 (Fig. 47) which checks the UART status port. If a character is ready at the port, character ready test 180-R9 passes processing to read character 180-R10. After reading the character, buffer address
180-R11 ascertains whether the address is at 0:0h. If the address is not at 0:0h, the read character is not stored by store character 180-R12. Step 180-R11 could be removed from function 180-R and is used only to support the check line connection operation in function DCONNECT and the check line listen operation in function DLISTEN. As described more completely below, both these operations could be moved into the transport layer obviating the need for step 180-R11. After buffer address 180-R11, adjust variables
180-R13 increments the character received count and sets the intercharacter timeout variable to three. More character test 180-R14 then ascertains whether there are more characters to receive. If more characters are remaining to be sent, processing transfers to UART status 180-R8 and processing proceeds as previously described. If there are no more characters available, update 180-R15 adds the number of characters received to the number of characters received since the last reset and sets the error code to the characters received. Restore interrupt 180-R24 turns off interrupt service routine 180-RCV and turns on interrupt service routine interrupt 180-INT. Processing then transfers to set timeout 180-R4.
The previous discussion assumed that character ready 180-R9 detected a character. However, if a character is not detected, processing transfers to interC timeout 180-R16 which examines the intercharacter timeout variable. If the variable indicates a timeout, processing transfers to set error 180-R17 which sets an error code for the intercharacter timeout variable and returns processing to restore interrupt 180-R24.
However, if the intercharacter timeout variable does not indicate a timeout, framing error check 180-R18 passes processing to UART status 180-R8 upon detection of a framing error. Otherwise, processing transfers through to restore interrupt 180-R24-A which, as previously described, turns on interrupt service routine 180-INT and turns off interrupt service routine 180-RCV. Subsequently save timeout 180-R19 saves the timeout values for the timeout variable and the intercharacter timeout variable and then speed resync 180-R20 functions as previously described. Upon completion of speed resynchronization, restore timeout 180-R21 restores the timeout and intercharacter timeout values to the saved parameters. If speed resynchronization generated an error, error check 180-R22 passes processing to set timeout 180-R4.
Conversely, if no error was detected, restore 180-R23 restores all parameters to the values upon entry and transfers processing back to the start of function DRECEIVE 180-R. Datalink function DCONNECT 180-C (Fig. 50) is called in response to transport layer function TCONNECT. Function DCONNECT attempts to establish a connection with the specified remote node. The calling function passes the nodeid, a speed parameter, the port for the connection and the number of ticks to wait for data. As previously described, since there is only a single node in the present embodiment, the nodeid parameter is redundant. The speed parameter passed to function DCONNECT, if non-zero, is the desired baud rate divided by 100.
Upon entry to function DCONNECT 180-C (Fig. 50) , set connection status 180-Cl first sets the connection status flag to -1 to indicate a connection is being attempted. Subsequently, main initialization 180-MI, which is shown in more detail as steps 180-MI1 through 180-MI8 in Fig. 51, initializes the general conditions. Specifically, save interrupt 180-MI1 first gets the current interrupt 08h vector and saves it. Next, clear flag 180-MI2 clears the receive active flag, and set interrupt 180-MI3 sets interrupt 08h to interrupt service routine 180-INT. Initialize variables 180-MI4 initializes the other variables in DCONNECT and those used in other functions to the required values. Subsequently, call set speed 180-SS functions as previously indicated to set the speed for the transmission. Disable 180-MI5 disables all UART interrupts, while clear registers 180-MI6 reads the status and data from the UART to clear the registers.
Next, calculate speed 180-MI7 counts the number of times the register pair DX:AX can be incremented during the timespan between two clock ticks and stores that value in a variable called loop count in this embodiment. Return 180-MI8 returns processing to connect/ listen initialization 180-CLI in Figure 50.
The operations in connect/ listen initialization 180-CLI are shown in more detail in Figure 52. Specifically, set timeout 180-CLI1 sets the timeout variable to the parameter passed to function DCONNECT
180-C. Speed check 180-CLI2 passes processing to return parameter 180-CLI5 if the speed parameter was passed to DCONNECT. Return parameter 180-CLI5 returns the index of the passed parameter. Conversely, if a speed parameter was not given, i.e. zero was passed to function DCONNECT, set parameters 180-CLI3 sets the speed parameter to the maximum baud rate and return 180-CLI4 returns the index of 300 baud to set baud rate index 180-C2 (Fig. 50) .
Set baud rate index 180-C2 sets the baud rate index to the value return by connect/listen initialization 180-CLI. Subsequently, processing passes to speed valid check 180-C3 which ascertains whether the requested speed is valid.
If the requested speed is invalid, processing transfers from speed valid check 180-C3 to set error 180-C4 which in turn sets the return value to invalid line speed error. Set error 180-C4 transfers processing to set connection status 180-C1-A which sets the connection status flag to zero and then passes processing to restore 180-C14. Restore 180-C14 denies UART divisor access, disables UART interrupts, and then resets interrupt 08h to the old interrupt 08h vector that was stored. Processing then transfers to return 180-C15.
If the requested connect speed is valid, speed valid check 180-C3 transfers processing to set speed 180-SS, which functions as previously described to set the requested speed. Subsequently, speed arbitration 180-C5 ascertains whether a specified speed was set or speed arbitration requested.
If a specified speed was set, processing transfers to transmit character 180-C11 which in turn sends an end of connect/listen character to the remote node. After waiting one tick, timeout check 180-C12 ascertains whether a timeout has occurred. If a timeout has occurred, set error 180-C13 sets the return value to timeout error and transfers processing to set connection status 180-C1-A, which was previously described.
If a timeout has not occurred, timeout check 180-C12 transfers to receive character status 180-RCS, which functions as previously described. If no character is ready, or the character received by receive character status 180-RCS is not an acknowledgment of the end of transmission, processing returns to transmit character 180-C11. However, if character test 180-C16 detects an acknowledgment of the end of connect, processing transfers to set delay count 180-DC-A which functions as previously described. Connection set 180-C1-B sets the connection status flag to zero and processing transfers to return
180-C15.
If speed arbitration 180-C5 detects a zero value, processing transfers to set character 180-C6 which in turn sets the connection character to a first character. Subsequently, set connect speed 180-CS performs the functions previously described with respect to Figs. 39a and 39b. Set connect character 180-C6-A sets a second connect character and passes processing to set connection status 180-C1-A. Set connection status 180-C1-A sets the status connection flag to zero. Next, set delay count 180-DC functions as previously described and baud rate check 180-C7 passes processing to set delay count 180-DC-A, if the baud rate is less than or equal to 19,200. Alternatively, baud rate check 180-C7 passes processing to check lines send 180-CLS which is described more completely below with respect to Fig. 53.
Upon the completion of check line send 180-CLS, error check 180-C8 ascertains whether an error was returned. If an error was returned error check 180-C8 transfers processing to set connection status 180-C1-A which functions as previously described. Conversely, if no error was returned, error check 180-C8 passes transfer to receive block 180-C9 which calls datalink function DRECEIVE to receive a block of data from the remote node with a 15 second timeout. If the block is received without error, error check 180-C10 passes processing to set connection status 180-C1-A. Otherwise 180-C10 passes processing to set delay count 180-DC-A. In connect 180-C, operations 180-CLS, 180-C8, 180-C9, and 180-C10 are used to verify the operation of the line connecting the computers. In another embodiment, these operations would be moved into the transport layer for improved efficiency.
Function check line send 180-CLS is shown in more detail in Fig. 53. Upon entry send block 180-CLS1 first generates a block of data and then calls datalink function DSEND to send this block of data across the virtual network. If DSEND functions without error, error check 180-CLS2 passes processing to return 180-CLS3. However, if send block 180-CLS1 generates an error, processing is transferred by error check 180-CLS2 to drop speed 180-CLS4. Drop speed 180-CLS4 calls datalink function DRESET with the parameter indicating a change of speed. Accordingly, function DRESET operates as previously described. If DRESET returns an error, error check
180-CLS5 transfers processing to error return 180-CLS6 which sets the carry flag and returns to the calling function. If an error is not returned from drop speed 180-CLS4, error check 180-CLS5 initiates the line check at the lower speed by again calling send block 180-CLS1. The datalink function corresponding to function DCONNECT is function DLISTEN, which waits for a DCONNECT request to arrive, signaling the start of a session. DLISTEN also prepares to perform arbitration on the line speed to determine the optimum line speed. DLISTEN is passed the speed, a timeout value, and a port for the connection.
One embodiment of function DLISTEN is illustrated in Fig, 54. Operations 180-L1 through 180-L2 are equivalent to operation 180-Cl through 180-C2 described above for Figure 50, which are incorporated herein by reference. Speed valid 180-L3 passes processing to set error 180-L4 if the requested speed is invalid. Set error 180-L4 sets the return value to invalid line speed error and subsequently transfers processing to set connection status 180-CS, which sets the connection status flag to zero. Subsequently, restore 180-L6 performs the same operations as previously described for restore 180-C14 (Fig. 50) , which are incorporated herein by reference.
If the requested speed is valid, speed valid check 180-L3 transfers processing to set speed 180-SS which functions as previously described. Upon completion of se speed 180-SS, set connect character 180-L9 establishes a first connection character and then set listen speed 180-LS functions as previously described. Upon completio of set listen speed 180-LS, set connect character 180-L10 sets a connection character different from that set by set character 180-L9. If set listen speed 180-LS generates an error, error check 180-L11 transfers processing to set connection status 180-L5 which functions as previously described.
If set listen speed 180-LS operates successfully, error check 180-L11 transfers to speed arbitration 180-L12. If the passed speed parameter is not zero, speed arbitration 180-L12 passes control to set delay count 180-DC-A which functions as previously described.
Conversely, if speed arbitration has been specified, speed arbitration 180-L12 transfers to set delay count 180-DC, again which functions as previously described. Baud rate check 180-L13 returns through 180-L14 to the calling program if the current baud rate is less than 19,200. If the baud rate is greater than 19,200, baud rate check 180-L13 goes to set timeout 180-L15 which sets the timeout value to 15 seconds. After the timeout value is set, verify connection 180-L16 calls datalink function DRECEIVE to verify a connection. If the DRECEIVE generates an error, error check 180-L17 transfers to timeout 180-L18. Timeout 180-L18 checks for a timeout error. If a timeout error is detected, error return 180-L19 returns processing with a timeout error, otherwise timeout check transfers processing to set timeout 180-L15.
If the verify connection 180-L16 does not generate an error, error check 180-L17 passes processing through check line speed 180-CLS, which was described above. Subsequently, processing transfers to set delay count 180-DC-A. Again, the line checking performed by function DLISTEN 180-L could be implemented in the transport layer. The remaining datalink functions DSTATUS, DCONNECT, DDISCONNECT and DFLUSH are straightforward. Function DSTATUS places the status information requested in the supplied buffer. Specifically, the nodeid is set to one. The variables used to track the number of bytes sent and received since the last reset are placed in the structure and the speed index is used to lookup the current speed which is subsequently placed in the buffer. The buffer is then returned to the transport layer. Function DFLUSH in this embodiment is a null operation and so the function simply returns to the calling function.
Function DDISCONNECT denies UART divisor access, disables the UART interrupts and resets interrupt 08h to the old interrupt 08h vector and returns success.
As previously described datalink errors are returned to transport layers as negative values. Successful completion of a function is indicated by a positive (generally zero) return value. In this embodiment possible return values are given in Table 6.
TABLE 6
DATALINK RETURN VALUE
Return Valve Result of Datalink Function
0 Successful function completion
-1 Connection broken -2 Unknown nodeid -3 Invalid line speed -4 Send/receive error -5 Timeout error -6 Cannot change speed -7 Intercharacter timeout error
Unlike prior art systems for transferring information between a first and a second computer system, any user application can be adapted to use the virtual network executive of this invention to transfer information between two computer systems. The user application must simply provide the information and the commands previously described for the application layer. Two user applications, are described below for use with the virtual network executive of this invention. One of the user applications, called "PoqetLink", is a user interface application for the MS-DOS operating system. PoqetLink allows any person with minimal knowledge of MS-DOS to manage disk files.
Specifically, PoqetLink allows the user to manipulate files and directories with the capabilities to copy, delete, rename, print and view files as well as being able to view create, and remove directories. Hence, there is a rough equivalence between user application PoqetLink and the MS-DOS commands COPY, DEL, REN, PRINT, RMDIR, CHDIR, MKDIR, DIR, PRINT and TYPE.
In addition, user application PoqetLink allows manipulation of the virtual network executive through attach, detach, connect, disconnect, serve and configure commands. The PoqetLink program provides a user interface and converts user commands provided through that interface into the appropriate sequence of commands and information for the virtual network executive of this invention. To use the user application PoqetLink for local processing, the virtual network architecture system must be loaded into the computer before executing PoqetLink. For remote processing, the local and remote computers must be directly connected, i.e., have an RS232 connection, with a virtual network architecture and user application PoqetLink active on both computers.
To execute PoqetLink commands, the user, for example, highlights a file to act upon using the cursor control keys and then presses the menu key (function key F10) and uses the cursor control keys to highlight the appropriate item, for instance, "FILE." The user then presses the return key and again uses the cursor control keys to select the appropriate option, "COPY" for example. Pressing the enter key then causes the option to execute and the user is prompted for any additional information needed.
Hence, to configure the machines for operation the user first sets PoqetLink on one machine to server mode (this is the same as designating the machine to be a remote machine) . On the other machine, the local machine, the user instructs PoqetLink to establish a logical connection to the remote machine by performing the connect function. When the virtual network executive connection is established, all processes involving the remote disk drive(s) are redirected across the virtual network to the remote machine.
More specifically, when the connect request is executed if a virtual network connection is already established, then executing the connect option does nothing. Otherwise, the PoqetLink connect request establishes the virtual network executive VCONNECT, as previously described. If the connection is successful, a list of available drives of the remote machine is retrieved via a generic send/receive exchange between the local machine and the server machine. Specifically, PoqetLink uses the generic send/receive messages, previously described, to obtain the list of available drives. The current drive of the server machine is then mapped to an available local drive. If there is more than one remote drive, the other remote drives are not mapped. The user must execute the PoqetLink attach option from the volume menu to map any other remote drives. After attachment, remote drives are treated as local drives.
After the serve request described above is executed, the virtual network server, as previously described, processes out after a selected time period if a connect request is not received. If such a timeout occurs,
PoqetLink reinitiates the virtual network serve request. If the server receives a disconnect request, the disconnect performs a virtual network executive reset and then returns control to user application PoqetLink which displays the main PoqetLink screen.
As described above, the PoqetLink user application permits file manipulation without direct knowledge of the MS-DOS operating system. With user application PoqetLink the user tags (or marks) one or more files of one or more directories and then executes the desired function. As used herein, tag is a function in PoqetLink that is used to indicate files that will be affected by the file copy and delete functions. To tag a file, the user moves the highlight bar to that file name and presses the tab key or alternatively uses the tag option of the tag menu. If a directory name is tagged and that directory is open, all the files within that directory are tagged.
Untag is a function in PoqetLink used to unmark files. To untag a file, the user moves the highlight bars to the file name and presses the shift and tab keys simultaneously or uses the untag option of the tag menu. If a directory name is untagged and that directory is open, all files within that directory are untagged. Clear tags is a tag menu option to untag all tagged files.
To copy files, the user tags the files to be copied and executes the copy option from the file menu.
PoqetLink then asks for the copy destination. The user may supply the full drive and directory path, or the path only. If no drive is given the files tagged are copied to the current drive. The current drive may be changed by using the change volume command of the volume menu.
To delete files a user tags the files to be deleted and executes the delete option from the file menu.
To rename a file, the highlight bar is positioned on the name of the file to be renamed and the rename option is executed from the file menu.
PoqetLink has a print command that is similar to the print command available with DOS except that this print command can print a file to a remote printer. Remote printing requires that PoqetLink be connected to a PoqetLink server with a printer and that PoqetLink is configured to use the remote printer. The files to be printed are tagged and then the print option on the file menu is selected. If no files are tagged, then the current highlighted file is printed. Another PoqetLink function is view. View is like the type command in MS-DOS, but view provides more capability. To view a file, the user positions the highlight bar on the file name and then presses control enter, or executes the view option of the file menu. For the view function, PoqetLink accesses the specified information using the appropriate application layer commands described above, and when the information is retrieved by the virtual network executive, PoqetLink the provides the necessary coding to display the text on the screen. To view directory information with PoqetLink, the user opens that directory. PoqetLink initially opens the root directory and that directory remains open. PoqetLin shows directory information in a list and when a directory in the middle of the list is open, PoqetLink inserts the directory information at that position in the list. The user can browse the list by scrolling up and down, paging up and down, going to the beginning or to the end of the list, or moving forward and backward to a directory name. To remove directory information, not the directory itself, one would perform a close directory. The term close directory means to remove the directory information from the list but not physically from the disk. PoqetLink maintains a status of all directories in the list either as open or as closed. The directory level is subindented, i.e., the root or parent directory occupies the first column and its subdirectories are indented, and subdirectories of subdirectories are further indented.
To view information of a subdirectory when its parent directory status is closed, the user must position the highlight bar in the parent directory and perform an open directory. Subsequently, the user must position the highlight bar on the subdirectory and perform an open directory. To create a new subdirectory, \A\B, the highlight bar is positioned on the A directory and the directory option is selected. If the directory A is not open, it is opened by pressing the insert key. The PoqetLink make directory selection is then executed. The user is prompted for the name of the new subdirectory, which is now created. Similarly, to remove a directory using PoqetLink the highlight bar is positioned on the name of the directory to be removed and then the remove directory option is selected.
Hence, the PoqetLink user application provides a series of menu selections wherein the user selects a file or a directory and then a second menu option to perform these operations upon the selected files or directory.
Upon the user selecting a command, PoqetLink then converts the user selection into a series of operations i.e., the application layer commands described previously to perform the operation requested by the user. A second user application requires that the remote mode be placed in the server mode using PoqetLink. The second user application is then loaded in the other machine and used to obtain disk directory information for the server. The embodiment of this invention, as described above, was designed for operation with IBM personal computers and IBM compatible personal computers. However, this embodiment was illustrative only of the principles of this invention and was not intended to limit the scope of the invention to the particular embodiment described. In view of this disclosure, those skilled in the art can now implement the novel virtual network executive of this invention in other computer architectures and in other computer programming languages. The virtual network architecture of this invention is interposed between user applications and the computer operating system. In one embodiment, as described above the virtual network is included on a read-only memory (ROM) in the computer and is loaded as part of the ROM BIOS. In another embodiment, the virtual network would be loaded as a terminate-and-stay-resident program. In either case, after loading the virtual network functions as a terminate-and-stay-resident program.
In a prior art terminate-and-stay-resident program, the executable code and data were separated into a memory resident portion and a transient portion, which were both loaded in random access memory (RAM) (i.e., main memory 17B (Fig. 1)) . The memory resident portion contained executable application code and data. The transient portion installed the executable application code. Typically, the prior art transient portion of the terminate-and-stay-resident (TSR) program initialized data and interrupt handlers contained in the memory resident portion and executed an MS-DOS function that left the RAM resident portion in RAM and freed the memory used by the transient portion.
According to the principles of this invention, the executable application code for virtual network architec¬ ture is ran directly from ROM and not RAM as in prior art TSR programs. Since relocation cannot be performed on a ROM-based executable program image, a novel "loader" is used to configure the computer system for execution of the ROM-based executable program image. As used herein, "an executable program image" is the same as the "executable image" described above. Moreover, the loader of this invention is not limited to ROM-based TSR applications. In general, the loader of this invention configures a computer system for execution of any executable program image from ROM including both memory card ROMs and permanently installed ROM within a computer such as the ROM BIOS.
One embodiment of a computer system 1220 including loader 1100 of this invention is illustrated in Figure 55A. Computer system 1220 (Fig. 55A) includes an input module and an output module similar to those described previously for prior art system 20 (Fig. 1) . However, for clarity, only the key components associated with loader 1100 are illustrated in computer system 1220 (Fig. 55A) . Typically, loader 1100 is stored on secondary memory 1217A of computer system 1220 as either a .EXE file or a .COM file. Read-only memory ROM 1230 contains executable program image 1250 associated with loader 1100. Random access memory 1217B contains operating system 1203. CPU 210 communicates with ROM 1230, RAM 1217B and secondary memory 1217A over paths 1240, 1241, and 1242 respectively. In addition, path 1243 connects secondary memory 1217A and 1217B and is used to illustrate that CPU 1210 may move a file such as loader 1100 directly into RAM 1217B using operating system 1203. The operation and architecture of computer system 1220 are equivalent to prior art system 20 (Fig. l) and therefore are known to those skilled in the art.
Loader 1100 (Fig. 55A) of this invention is loaded into RAM 1217B by operating system 1203. For example, loader 1100 is placed into the portion of RAM 1217B between addresses XXX and YYY by operating system 1203 in the conventional method described above in response to a user's instruction to execute loader 1100 for a particular ROM-based executable program image 1250. Once loader 1100 is in RAM 1217B, loader 1100 sets up the conditions required for execution of ROM-based executable program image 1250 directly from ROM 1230. Specifically, initialization means 1100-1 (Fig. 55B) initializes computer system 1220 (Fig. 55A) for execution of ROM-based executable program image 1250. Initialization means 1100-1 configures a data area in RAM 1217B for ROM-based executable program image 1250.
After the necessary conditions for direct execution of the ROM-based executable program image 1250 are established, loader 1100 preferably removes itself from RAM 1217B using means for releasing RAM 1100-2 (Fig. 55B) . After loader 1100 removes itself from RAM 1217B, the data area for ROM-based executable program image 1250 is left in memory. ROM-based executable program image 1250 (Fig. 55A) is, thus, configured to execute directly from ROM 1230. Thus, according to the principles of this invention, loader 1100, in one embodiment, includes a means for initializing computer system 1220 for execution of ROM- based executable program image 1250 directly from ROM 123 and means for releasing RAM. Of course, while in this embodiment loader 1100 includes means for releasing the random access memory used by the loader itself, the loade of this invention would function properly without releasing the RAM utilized by the loader. However, such an embodiment would obviously result in somewhat diminished efficiency in utilization of RAM 1217B because loader 1100 would occupy RAM when loader 1100 was no longer needed.
The direct execution of an application from ROM significantly enhances the operation of a computer becaus the amount of RAM available to the user is not diminished by the size of the executable program image of the application. Therefore, the user has more RAM available for data and/or other information such as other applications than if the executable program image occupied RAM. Further, loader 1100 makes it possible to operate portable computers using executable program images on either ROM cards or any other ROM in the computer.
The structure and operation of loader 1100 depends on both ROM-based executable program image 1250 and the steps used to generate loader 1100. In each case, loader 1100 performs the steps necessary to insure proper execution of the ROM-based application.
Loader 1100 of this invention is illustrated in more detail Figure 56A. In this embodiment, loader 1100 includes data area initialization means 1110, application existence verification means 1120, and setup means 1130.
Data area initialization means 1110 configures a data area in RAM for the ROM-based executable program image. Data area initialization means 1110, in one embodiment, includes (i) means for creating a working data area 1110-1 (Fig. 56B) for the ROM-based executable program image in RAM and (ii) means for data initialization 1110-2, which initializes within the data area the necessary variables for execution of the ROM-based executable program image directly from ROM.
Application existence verification means 1120 (Fig. 56A) ensures that the ROM-based executable program image is physically present on a ROM in the computer system. If application existence verification means 1120 finds the ROM-based executable program image, loader 1100 continues operation with setup means 1130. However, if the ROM-based executable image is not on a ROM within the computer system, an error message is sent to the user by error message means 1150, and loader 1100 terminates through terminate means 1140.
Setup means 1130 sets the data segment register as well as any other registers and/or vectors that are required by the ROM-based executable program image. The operation of setup means 1130, depends upon the nature of the ROM-based executable program image, as described more completely below. In general, setup means 1130 at least releases the RAM required by loader 1100 itself, and turns control of the computer system over to the ROM-based executable program image. After loader 1100 releases the RAM it required, the data area for the ROM-based executable program image remains in RAM. The execution of the ROM-based executable program image depends upon the nature of the ROM-based executable program image. In general, the executable program images may be divided into (i) TSR applications and (ii) non-TSR applications. For non-TSR applications, control is turned over to the ROM-based executable program image, and the
ROM-based executable program image is executed directly after the initialization of the RAM data area. Upon completion of the execution, the ROM-based executable program image exits normally to the MS-DOS operating system.
For TSR applications, setup 1130 may configure the ROM-based executable program image as a TSR program, as described more completely below. Alternatively, the ROM- based executable program image may (i) setup the necessary interrupt vectors, (ii) execute ROM-based code that configures the application as a TSR program and
(iii) terminate-and-stay-resident releasing unnecessary code/data. Since the ROM-based executable program image is configured as a TSR program, the ROM-based executable program image may not execute directly after the initialization of the RAM data area. Accordingly, according to the principles of this invention, loader 1100 contains the structure necessary to perform the operations that are required for execution of the ROM-based executable program image directly from the ROM. The structure of create working data area means
1110-1 of loader 1100 for the ROM-based executable program image depends (i) upon the form of the executable program image file, i.e., whether loader 1100 is a .EXE executable image file or a .COM executable image file, and also, in some cases, (ii) upon the size of the data area required for execution of the ROM-based executable program image directly from ROM. Typically, as is known to those skilled in the art, source code, such as assembly code, is compiled and linked to form a .EXE file that contains machine code. Alternatively, the .EXE file can be converted to a .COM file using the MS-DOS operating system. For .COM files, the operating system allocates 64 Kbytes of RAM so that loader 1100 of this invention is not required to create a working data area for a .COM file as long as the ROM-based executable program image requires a data work area of less than 64 Kbytes.
Alternatively, when loader 1100 is created, the data modules for the ROM-based executable program image may be linked with the compiled source code for loader 1100. In this case, the .EXE file that is generated for loader 1100 contains in the header of the .EXE file the size of the data area required for the execution of the executable program image. Accordingly, in this embodiment, create working data area means 1110-1 is not required to specifically allocate a working data area for execution of the ROM-based executable program image directly from ROM.
Finally, if an executable program image requires more RAM for the working data area than that which is normally allocated by the operating system, e.g., more than 64 Kbytes allocated when loader 1100 is a .COM file, create working data area means 1110-1 allocates the additional RAM required.
These operations are schematically illustrated in Figures 57A through 57C. In a first embodiment, the memory initially allocated to loader 1100 by the operating system upon execution of loader 1100 is from memory addresses XXX to YYY (Fig. 57A) . This memory allocation is all that is required so that no further memory allocation operations are performed by loader 1100. In a second embodiment, the operating system allocates loader 1100 memory in RAM from addresses XXX to YYY (Fig. 57B) . However, loader 1100 only requires memory stemming from addresses XXX to AAA so that the memory from addresses AAA to YYY is released by loader 1100. Finally, in a third embodiment loader 1100 is allocated memory from addresses XXX through YYY by the operating system, but loader 1100 requires more memory the for the ROM-based executable program image data area so that loader 1100 uses the operating system to allocate additional memory from addresses YYY to BBB. The first embodiment (Fig. 57A) corresponds, for example, to a loader .EXE file that contains the required memory size in the file header. The second embodiment (Fig. 57B) corresponds, for example, to a loader that is a .COM file where the operating system allocates 64 Kbytes, but the executable program image requires a data area of less than 64 Kbytes. The third embodiment (Fig. 57C) may be, for example, a loader .COM file for an executable program image that requires more than 64 Kbytes of data area.
The operations performed by data area initialization means 1110, existence verification means 1120, and setup means 1130 are described more completely below with respect to specific embodiments of loader 1100 of this invention.
In one embodiment, loader 1100A (Fig. 58A) is used to configure a library of ROM-based functions in a portable computer, such as that described in copending and commonly assigned U.S. patent application serial number 07/375,721, entitled "Portable Low Power Computer" of John P. Fairbanks et al. filed on June 30, 1989 which is incorporated herein by reference in its entirety, as a terminate-and-stay-resident application.
The source code for this embodiment and each of the other embodiments described below was written in assembly language and compiled using the Microsoft Macro Assembler, version 5.1. The compiled code was linked using Microsoft Overlay Linker, version 3.65. Both the Macro Assembler and the Overlay Linker are available from Microsoft Corp. of Redmond, Washington.
In this embodiment, the data segment information for the ROM-based library of functions is linked with the compilation of loader 1100A source code to create an executable file, i.e., a .EXE file. The data segment information required is determined by the ROM-based executable program image. For most well behaved TSR programs, at least the vector of the previous interrupt that the TSR program takes over must be maintained in the data segment information so that the TSR program can chain to that interrupt.
The nature of the library functions is not an essential aspect of this invention. Loader 1100A supports any ROM-based library functions so long as the initialization operations, described more completely below, required for execution of the functions directly from ROM are incorporated in loader 1100A.
When ROM-based library function loader 1100A is executed by the operating system, the operating system reads the .EXE file header and allocates sufficient random access memory RAM for both loader 1100A and the data segment for the ROM-based library functions. In addition, as is known to those skilled in the art, the operating system places a program suffix prefix (PSP) in memory to designate the start of loader 1100A. Generation of the PSP is a standard function performed by the MS-DOS operating system and is described in more detail in P. Duncan, Gen. Ed., The MS-DOS Encyclopedia. Microsoft Press, Redmond, Washington, pp. 108-111, 1988, which is incorporated herein by reference.
Since the executable program image for loader 1100A contains sufficient information for the operating system to allocate the required working data area for the ROM- based library functions, the only operation performed by means for creating the working data area lllOA-1 is setup segments lllOA-1-1 which sets the segment registers DS and ES to the data segment. In this embodiment, the stack for the ROM-based library functions is within the data segment.
Initialize data area 1110A-2 (Fig. 58A) includes four operations in this embodiment. Initialize data segment means 1110A-2-1 zeroes the RAM in the data segment. This is done as a clean-up for the data area. Store PSP means 1110A-2-2 stores the address of the program segment prefix for later use. Variable initialization means 1110A-2-3 initializes all necessary variables for the subsequent execution of the ROM-based library of functions. In this embodiment, this requires (i) storing the old interrupt vector pointer used for interrupt chaining by the functions in the library; (ii) the initialization of a menu system memory allocation scheme and (iii) initial¬ ization of words that are used to store the data segment for other ROM-based applications that utilize the library of functions. The precise initialization of the variables is not an essential feature of this invention and depends upon the particular ROM-based library functions. The important aspect is that loader 1100A initializes, in the RAM data area, all the necessary variables for the subsequent execution of the executable program image from ROM.
As is known in those skilled in the art, the oper¬ ating system uses the loader's PSP to track certain data that is unique to loader 1100A including command-line parameters and the segment address of the loader's environment. Accordingly, the last operation in initiali¬ zation of data area 1110A-2 is process command line 1110A-2-4.
Initially, in process command line lllOA-2-4, the PSP is accessed by look up 1110A-2-4-1 (Fig. 58B) to obtain any command line argument. If the command line argument is "I", command line argument check function 1110A-2-4-2 transfers processing to report version number 1110A-2-4-3 of command line processor 1110A-2-4-10 which in turn reports the version number of the ROM-based executable program image and terminates normally through terminate 1140A.
If the command line argument is "R", command line argument check function 1110A-2-4-4 passes processing to reset 1110A-2-4-5 of command line processor 1102A-2-4-10 which in turn resets the data area and terminates normally through terminate 1140A. Finally, if the command line is neither a "I" nor a "R" but is a "U", command line argument check function 1110A-2-4-6 transfers processing to unload 1110A-2-4-7 of command line processor 1102A-2-4- 10 which removes loader 1100A and any other information associated with the ROM-based executable program image from memory and terminates normally through terminate 1140A.
If PSP lookup 1110A-2-4-1 does not detect a command line argument, processing passes through the three check functions 1110A-2-4-2, 1110A-2-4-4, and 1110A-2-4-6 to verify existence means 1120A (Fig. 58C) .
In this embodiment, check memory means 1120A-1 checks to ascertain whether the ROM-based library of functions is already loaded. The code located at the interrupt vector that loader 1100A plans to take over is checked to ascertain whether the code represents the library of functions. Upon installation of the library, the code is "VNA". Thus, if check 1120A-1 detects the string "VNA ...", the library of functions is already loaded in the computer system. If the library of functions is already in memory, error message 1150A generates an error message that the library functions are already in memory and processing terminates normally through terminate 1140A. However, if the library functions are not already loaded, ROM check means 1120A-3 checks to ensure that the library of functions is in a ROM in the computer system. Specifically, in this embodiment means 1120A-3 checks for the string code for the library, i.e., "VNA...". If the ROM-based library functions are not available, ROM check means 1120A-3 passes processing to error message 1150A which in turn generates a message that the library functions are not in ROM. Processing subsequently transfers to terminate 1140A which in turn performs the operations necessary to restore the computer system to the configuration prior to initiation of the execution of loader 1100A. These operations are the normal operations performed upon termination of an executable program image and as such are known to those skilled in the art. Upon verification that the ROM-based library functions exist, processing transfers from ROM check means 1120A-3 to setup 1130A (Fig. 58C) , which, in this embodiment, releases the RAM memory area associated with loader 1100A itself. Thus, all that remains in RAM is the data area, i.e., the data segment for the ROM-based executable program image, which includes initialized variables necessary for execution of the ROM-based executable program image directly from ROM, and the PSP. Accordingly, loader 1100A for the ROM-based library functions eliminated the problems associated with relocations by effectively setting up in RAM the data area and the conditions required by the ROM-based library functions for execution.
In another application of the novel loader of this invention for ROM-based executable program images, appli- cation programs, which function under the ROM-based library of functions described above, are maintained in a ROM. In this embodiment, loader 1100B (Fig. 59A-59D) is a .COM file. Loader 1100B not only performs the steps necessary to run the ROM-based application program, but also includes steps to set up the ROM-based application program as a terminate and stay resident program.
In this embodiment, the structure of data area initialization means 1110B and application existence verification means 112OB, as described more completely below, are somewhat different from means 1110A and 1120A of the previous embodiment. The change in structure provides the most rapid response to the user. This demonstrates that in view of this disclosure, one skilled in the art may arrange the structure of each element of the loader of this invention to achieve speed or other functionality in addition to the basic objective of configuring computer system for execution of the ROM-based application directly from ROM.
As previously described, when the operating system executes a .COM file, a specific segment of memory, i.e. 64 Kbytes of memory, is allocated. Accordingly, the only operation in create work data area lllOB-1 (Fig. 59A) is to simply set up the stack within the data area allocated by the operating system. In this embodiment, the data area is not zeroed by loader 1100B because each of the ROM-based applications sets up its data area to assure that the RAM is properly initialized.
In this embodiment, the ROM-based application is designed to operate under the library of functions described above. Thus, data area initialization means 1110B-2 first uses memory check 1110B-2-1 to ascertain whether the ROM-based library functions are loaded. Specifically, the code associated with the interrupt vector for the ROM-based library functions is checked to see if the code is the string "VNA..." If the library functions are not loaded, processing transfers to error message 1150B. Error message 1150B sends the user a report that the library functions were not found and processing terminates normally through terminate 1140B. Terminate 114OB functions in a manner equivalent to that described above for terminate 1140A.
Map 1110B-2-2 accesses an interrupt function in the extended BIOS of the computer, described in copending and commonly assigned U.S. patent application serial number 07/375,721, entitled "Portable Low Power Computer" of John P. Fairbanks et al. filed on June 30, 1989 and in commonly assigned and copending patent application serial no. 07/374,691 entitled "Method and Apparatus For Information Management In A Computer System" of Ian H.S. Cullimore, filed on June 30, 1989, both of which are incorporated herein by reference in their entirety, to establish address segment EOOOh as the ROM-based application. In general, the extended BIOS is instructed to address the segment from either the BIOS ROM or a ROM memory card in the computer system. After map 1110B-2-2, processing transfers to verification means 1120B. If the application specified by loader 1100B is detected in ROM by ROM check 1120B-1 (Fig. 59B) , (i.e. the string "PQTL" is "detected") processing continues. However, if the application is not in ROM, processing transfers to error message 1150B. An application not in ROM error is reported by error message 1150B and processing terminates normally.
After ROM check 1120B-1, the version of the operating system is checked by operating system check 1120B-2 to assure that the operating system is compatible with the ROM-based application. If the operating system is not compatible, error message 1150 generates an operating system incapability error report and processing terminates normally.
Next, memory check 1120-B-3 (Fig. 59C) determines whether the ROM-based application is already loaded in the computer system. Recall that in loader 1100A, variable initialization means 1110A-2-3 (Fig. 58B) , initialized words that are used to store the data segment for ROM-based applications that use the library of functions. In this embodiment, the words are initialized to zero. When an application is loaded, the appropriate word is changed to be non-zero. Hence, memory check 1120-B-3 simply determines whether the word is zero or non-zero to ascertain whether the application is already loaded. If the ROM-based application is not loaded, processing progresses to setup 113OB which is described more completely below.
However, if the ROM-based application has already been loaded, look-up 1120B-4 accesses the PSP command line check 1120B-5. Recall that in the previous embodiment, look-up was included in data area initialization means 1110A. This demonstrates that the specific allocation of operations to one of the structures that comprise the loader of this invention is not an essential aspect of the invention. Thus, many alternative embodiments of the loader of this invention may be formed by those skilled in the art in view of this disclosure.
Command line check 1120B-5 determines whether the user has entered a "U". If the command line contains a "U", command line processor 1120B-6 releases memory allocated to loader 1100B and zeroes the word indicating whether the application is loaded. The processing then terminates normally. However, if the command line does not contain a "U" or contains no parameter, error message 1150B reports that the application is already loaded. While command line processing was supported by both loaders 1100A and 1100B, command line processing is not required for proper operation of the loaders. The command line processing simply provides the user with an additional means of control over the ROM-based executable program image.
Setup 113OB for this ROM-based application is more complex than previously described setup 1130A for loader 1100A. The first operation within setup 113OB is initialization of variables 1130B-1 which initializes the terminate and stay resident variables in the RAM data area for the application. In this embodiment, there are two far jumps which are established and then an AlarπAFlag is cleared and the interrupt vectors are saved. The Alarm_Flag is used in the sounding and alarm functions of the ROM-based application. An INDOS counter and the disk transfer address are also initialized.
Next in setup 113OB, register set 1130B-2 initializes register AX for a jump after the data memory allocation for the TSR. Move 1130B-3 (Fig. 59D) relocates the revector and interrupt code for the TSR to make room for the memory data allocation and register AX is also reset to the eventual location of the revector code. Processing than jumps to the revector location in register AX. In reset TSR interrupts 1130B-4, the TSR interrupts are reset to allow for relocation of the interrupt vector code.
The ROM-based application entry code is called by entry means 1130B-6 to complete the initialization. Finally, release means 1130B-7 releases unneeded RAM and leaves th ROM-based application configured as an installed TSR program. Again, the precise operations, e.g., the initializa¬ tion of specific variables, performed in setup 113OB are not an essential aspect of the invention. Rather, the important aspect is that for operation of the ROM-based application, the necessary relocations and initialization must be performed by the loader so that the ROM-based application functions correctly as a TSR program.
When PoqetLink is included as a ROM-based applicatio within the computer system, yet another embodiment of the loader is used. This loader requires less memory than is allocated by the operating system when the loader is executed. Thus, this loader deallocates memory as illustrated in Fig. 57B. Also, the ROM-based executable program image executes directly, as described previously for non-TSR applications, upon completion of the operatio of the loader including the loader removing itself from memory. As previously described, after the loader removes itself, the PSP and the data segment for the ROM-based PoqetLink application remain in RAM. In this embodiment, the ROM-based PoqetLink allocates additional memory as required.
The alternative embodiments of this invention, as described above, were designed for operation with IBM personal computers and IBM compatible personal computers. However, these embodiments were illustrative only of the principles of this invention and were not intended to limit the scope of the invention to the particular embodiments described. In view of this disclosure, those skilled in the art can implement the novel loader of this invention in other computer architectures and in other computer programming languages.

Claims

CLAIMSWe claim:
1. A system comprising: first computer means; second computer means; means, operatively coupling said first and second computer means, for transmission of information between said first and second computer means; and virtual network executive means, operating in each computer means, for (i) transferring information between said first and second computer means over said transmission means in a first mode of operation, and (ii) forming a virtual computer including said first computer means and said second computer means in a second mode of operation; wherein upon said virtual network executive means configuring said computer means as a virtual computer, said first computer means controls said virtual computer and said second computer means services commands from said first computer means so that a user application executing in said first computer means has access to all information stored in the virtual computer.
2. A system as in Claim 1, said virtual network executive means further comprising: first means, responsive to a user application in one of said computer means, for receiving and sending information and for generating a first message structure containing said information; second means, operatively coupled to said first means, for receiving and sending information and for generating a second message structure; wherein said second means receives said first message structure and said second message structure includes a header, at least a portion of said first message, and an error code; third means, operatively coupled to said second means and to said transmission means, for receiving and sending information; and wherein said third means receives and sends said second message structure over said transmission means with predetermined transmission parameters, said parameters including a blocksize and a transmission speed.
3. A system as in Claim 2, said first means further comprising: data compression means wherein said information is compressed prior to generation of said first message structure and said compressed information is used in said first message structure.
4. A system as in Claim 3, said first means further comprising: data decompression means wherein, upon receiving compressed information, said compressed information is decompressed.
5. A system as in Claim 2, wherein said second message structure is comprised of bytes of information of data, and said second means further comprising: means for generating said error code based upon processing each byte of information in said second message header and said at least a portion of said first message so that if any byte is changed a different error code is generated.
6. A system as in Claim 2 wherein: said second means further comprises means for adjusting the predetermined transmission parameters including (i) the size of said second message and (ii) the transmission speed used by said third means for sending said second message over said transmission means, wherein at least one of said message size and transmission speed are adjusted after a predetermined number of errors in transmitting said second message structure.
7. A method for communication between two computer systems comprising: operatively coupling said first and second computer systems for transmission of information between said first and second computer systems; transferring information between said first and second computer system over said transmission means in a first mode of operation; and forming a virtual computer including said first computer system and said second computer system in a second mode of operation; wherein upon configuring said computer systems as a virtual computer, said first computer system controls said virtual computer and said second computer system services commands from said first computer system so that a user application executing in said first computer system has access to all information stored in the virtual computer.
8. A method for communication between two computer systems comprising: operatively coupling said first and second computer systems for transmission of information between said first and second computer system; and providing virtual network executive means, operating in each computer system, for (i) transferring information between said first and second computer systems over said transmission means in a first mode of operation, and (ii) forming a virtual computer including said first computer syste and said second computer system in a second mode of operation; wherein upon said virtual network executive means configuring said computer systems as a virtual computer, said first computer system controls said virtual computer and said second computer system services commands from said first computer system so that a user application executing in said first computer system has access to all information stored in the virtual computer.
9. A system comprising: first computer means including first virtual network executive means, operating in said first computer means and responsive to each command in a set of commands, for (i) transferring information between said first computer means and another computer over a coupling means between said first computer means and said another computer means in a first mode of operation, and (ii) forming a virtual computer including said first computer means and said another computer means in a second mode of operation, said first computer means for executing a first user application wherein said first user application accesses said first virtual network executive means by issuing said commands in said set of commands; second computer means including second virtual network executive means, operating in said second computer means and responsive to each command in a set of commands, for (i) transferring information between said second computer means and another computer means over a coupling means between said second computer means and said another computer means in a first mode of operation, and (ii) forming a virtual computer including said second computer means and said another computer means in a second mode of operation, said second computer means for executing a second user application wherein said second user application accesses said second virtual network executive means by issuing said commands in said set of commands; and means, operatively coupling said first and second computer means, for transmission of information between said first and second computer means; wherein upon said second user application issuing a server command to said second virtual network executive means, said second virtual network executive means configures said second computer means as a server computer such that said first and second computer means comprise a virtual computer, and said first user application executing in said first computer means controls said virtual computer.
10. A virtual network executive, operative in a computer system having a plurality of computers operatively coupled for sending and receiving information over a datalink, comprising: means for transmitting and for receiving information over said datalink using predetermined transmission parameters, said parameters including a blocksize and a transmission speed; means for detecting an error in said transmission of information over said datalink; and means for adjusting the transmission of information upon detection of a predetermined number of errors in said transmission.
11. A virtual network executive as in Claim 10, sai means for transmitting and for receiving further comprising: means for generating a message structure, said message structure including a header, at least a portion of said information, and an error code wherein said message structure is transmitted and received by said transmitting and receiving means.
12. A virtual network executive as in Claim 11, wherein said message structure is comprised of bytes and said means for transmitting and receiving further comprising: means for generating said error code based upon processing each byte of information in said message header and said at least a portion of said information so that if any byte is changed a different error code is generated.
13. A virtual network executive as in Claim 12, said error detecting means further comprising: means, operatively coupled to said receiving and transmitting means, for generating a second error code for the received message header and the received at least a portion of said information and for comparing said second error code with the received error code wherein upon said first and second error codes being different, a transmission error is detected.
14. A virtual network executive as in Claim 13, said means for adjusting the transmission of information further comprising means for adjusting the predetermined transmission parameters including (i) the size of said message structure and (ii) the transmission speed, wherein at least one of said message size and said transmission speed are adjusted after a predetermined number of errors in transmitting said second message structure.
15. A virtual network executive, operative in a computer system having a plurality of computers operatively coupled for sending and receiving information over a datalink, comprising: first means, responsive to a user application in one of said computer means, for receiving and sending information and for generating a first message structure containing said information; second means, operatively coupled to said first means, for receiving and sending information and for generating a second message structure; wherein said second means receives said first message structure and said second message structure includes a header, at least a portion of said first message, and an error code; and third means, operatively coupled to said second means and to said datalink, for receiving and sending information; wherein said third means receives and sends said second message structure over said datalink with predetermined transmission parameters, said parameters including a blocksize and a transmission speed.
16. A virtual network executive as in Claim 15, said first means further comprising: data compression means wherein said information is compressed prior to generation of said first message structure and said compressed information is used in said first message structure.
17. A virtual network executive as in Claim 16, sai first means further comprising: data decompression means wherein, upon receivin compressed information, said compressed information is decompressed.
18. A virtual network executive as in Claim 15, wherein said second message structure is comprised of bytes of information of data, and said second means further comprising: means for generating said error code based upon processing each byte of information in said second message header and in said portion of said first message so that if any byte is changed a different error code is generated.
19. A virtual network executive as in Claim 15, wherein said second means further comprises: means for adjusting said predetermined transmission parameters including (i) the size of said second message and (ii) the transmission speed used by said third means for sending said second message over said transmission means, wherein at least one of said message size and said transmission speed are adjusted after a predetermined number of errors in transmitting said second message structure.
20. A method for transferring information over a datalink coupling at least two computer systems comprising: transmitting and receiving information over said datalink with predetermined transmission parameters; detecting an error in said transmission of information over said datalink; and adjusting the transmission parameters upon detection of a predetermined number of errors in said transmission.
21. A method as in Claim 20, further comprising prior to the transmitting and for receiving step: generating a message structure, said message structure including a header, at least a portion of said information, and an error code wherein said message structure is transmitted and received in said transmitting and receiving step.
22. A method as in Claim 21, wherein said message structure is comprised of bytes and further comprising the step of: generating said error code based upon processing each byte of information in said message header and said at least a portion of said information so that if any byte is changed a different error code is generated.
23. A virtual network executive as in Claim 22, said error detecting step further comprising: generating a second error code for the received message header and the received at least a portion of said information and comparing said second error code with the received error code wherein upon said first and second error codes being different, a transmission error is detected.
24. A virtual network executive as in Claim 23, said step of adjusting the transmission parameters further comprising adjusting at least one of (i) the size of said message structure and (ii) the transmission speed.
25. A structure for using in transmitting information between computer systems comprising: header means for identifying a direction for transmission of the information, and a destination for the information; and means, adjacent said header means, for storing said information.
26. A structure as in Claim 25, said header means further comprising: means for identifying the source of the structure.
27. A structure as in Claim 26, said header means further comprising: means for identifying an operation to be performed using said information stored in said structure.
28. A plurality of structures as in Claim 27 wherein each pair of said structures is uniquely associated with only one operation to be performed and one structure of said pair is transmitted and the other structure of said pair is received.
29. In a computer system having an operating system and random access memory(RAM), a loader for a read only memory(ROM)-based executable program image wherein upon execution of said loader, RAM is allocated to said loader, said loader comprising: means for initializing said computer system for execution of said ROM-based executable program image; and means, operatively coupled to said initializing means, for releasing RAM; wherein upon completion of initialization of said computer system by said initializing means, said releasing means releases RAM required for said loader itself and said ROM- based executable program image is configured for execution directly from said ROM in said computer system.
30. A loader for a read-only memory(ROM)-based executable program image comprising: means for initializing a computer system for execution of said ROM-based executable program image; and means, operatively coupled to said initializing means, for releasing random access memory(RAM) ; wherein upon loading of said loader in said computer system and in turn completion of initialization of said computer system by said initializing means, said releasing means releases RAM used by said loader itself and said
ROM-based executable program image is configured for execution directly from ROM.
31. The loader of any one of Claim 29 or Claim 30 wherein said initializing means further comprises means for data area initialization wherein said data area initialization means configures a data area in said RAM for said ROM-based executable program image.
32. The loader of Claim 31 wherein said data area initialization means further comprises means for creating a working RAM data area for the ROM-based executable program image wherein said working data area creation means configures the size of said RAM data area.
33. The loader of Claim 32 wherein said data area initialization means further comprises means, operatively coupled to said working data area creation means, for data initialization wherein said data initialization means initializes, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
34. The loader of Claim 31 wherein said data area initialization means further comprises means for data initialization wherein said data initialization means initializes, within a RAM data area, variables necessary for execution of said ROM-based executable program image.
35. The loader of Claim 31 further comprising means, operatively coupled to said initialization means and to said releasing means, for application existence verification wherein said application existence verification means checks for the existence of said ROM- based executable program image in a ROM within said computer system.
36. The loader of Claim 35 wherein said existence verification means further comprises means for determining whether said ROM-based executable program image is already loaded in said computer system.
37. The loader of Claim 31 wherein said means for releasing is included in a setup means.
38. The loader of Claim 37 wherein said setup means further comprises means for configuring said ROM-based executable image image as a terminate-and-stay-resident program.
39. A loader for a read-only memory(ROM)-based executable program image comprising: means for data area initialization wherein said data area initialization means configures a data area in a random access memory (RAM) for said ROM-based executable program image; and means, operatively coupled to said data area initialization means, for application existence verification wherein said application existence verification means checks for the existence of said ROM-based executable program image in a ROM.
40. The loader of Claim 39 wherein said data area initialization means further comprises means for creating a working RAM data area for the ROM-based executable program image wherein said working data area creation means configures the size of said RAM data area.
41. The loader of Claim 40 wherein said data area initialization means further comprises means, operatively coupled to said working data area creation means, for data initialization wherein said data initialization means initializes, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
42. The loader of Claim 39 wherein said data area initialization means further comprises means for data initialization wherein said data initialization means initializes, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
43. The loader of Claim 39 wherein said existence verification means further comprises means for determining whether said ROM-based executable program image is already loaded in a computer system.
44. The loader of Claim 39 further comprising means for configuring said ROM-based executable image image as a terminate-and-stay-resident program.
45. A method for configuring a computer system for execution of a read-only memory(ROM)-based executable program image directly from ROM comprising the steps of: initializing said computer system for execution of said ROM-based executable program image; and releasing random access memory(RAM) ; wherein upon completion of said initialization of said computer system by said initializing step, RAM used by operations in the initializing step is released and said ROM-based executable program image is configured for execution directly from ROM.
46. The method of Claim 45 wherein said initializing step further comprises the step of allocating a data area in said RAM for said ROM-based executable program image.
47. The method of Claim 46 wherein said initializing step further comprises configuring the size of said RAM data area.
48. The method of Claim 47 wherein said initializing step further comprises initializing, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
49. The method of Claim 45 wherein initializing step further comprises initializing, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
50. The method of Claim 45 further comprising the step of checking for the existence of said ROM-based executable program image in a ROM within said computer system.
51. The method of Claim 50 wherein checking step further comprises determining whether said ROM-based executable program image is already loaded in said computer system.
52. The method of Claim 45 further comprising the step of configuring said ROM-based executable image image as a terminate-and-stay-resident program.
53. A method for configuring a computer system for execution of a read-only memory(ROM)-based executable program image directly from ROM comprising the steps of: creating a data area in a random access memory (RAM) for said ROM-based executable program image; and checking for the existence of said ROM-based executable program image in a ROM within said computer system.
54. The method of Claim 53 wherein said creation step further comprises the step of configuring the size of said RAM data area.
55. The method of Claim 54 wherein said creation step further comprises the step of initializing, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
56. The method of Claim 53 wherein said creation step further comprises the step of initializing, within said RAM data area, variables necessary for execution of said ROM-based executable program image.
57. The method of Claim 53 wherein checking step further comprises determining whether said ROM-based executable program image is already loaded in a computer system.
58. The method of Claim 53 further comprising the step of configuring said ROM-based executable image image as a terminate-and-stay-resident program.
PCT/US1990/005118 1989-09-11 1990-09-11 Virtual network architecture and loader WO1991004537A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US40566189A 1989-09-11 1989-09-11
US405,661 1989-09-11
US56932890A 1990-08-17 1990-08-17
US569,328 1990-08-17

Publications (1)

Publication Number Publication Date
WO1991004537A1 true WO1991004537A1 (en) 1991-04-04

Family

ID=27019183

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1990/005118 WO1991004537A1 (en) 1989-09-11 1990-09-11 Virtual network architecture and loader

Country Status (3)

Country Link
JP (1) JPH05502528A (en)
AU (1) AU6520090A (en)
WO (1) WO1991004537A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6485093B2 (en) * 2015-02-16 2019-03-20 日本電気株式会社 Policy management apparatus, virtual network management method and program

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3909791A (en) * 1972-06-28 1975-09-30 Ibm Selectively settable frequency divider
US3940744A (en) * 1973-12-17 1976-02-24 Xerox Corporation Self contained program loading apparatus
US4188665A (en) * 1977-11-29 1980-02-12 International Business Machines Corporation Programmable communications subsystem
US4218757A (en) * 1978-06-29 1980-08-19 Burroughs Corporation Device for automatic modification of ROM contents by a system selected variable
US4430704A (en) * 1980-01-21 1984-02-07 The United States Of America As Represented By The Secretary Of The Navy Programmable bootstrap loading system
US4590557A (en) * 1983-09-12 1986-05-20 Pitney Bowes Inc. Method and apparatus for controlling software configurations in data processing systems
US4590556A (en) * 1983-01-17 1986-05-20 Tandy Corporation Co-processor combination
US4607332A (en) * 1983-01-14 1986-08-19 At&T Bell Laboratories Dynamic alteration of firmware programs in Read-Only Memory based systems
US4769771A (en) * 1984-01-20 1988-09-06 U.S. Philips Corporation Multiprocessor system comprising a plurality of data processors which are interconnected by a communication network
US4833596A (en) * 1985-02-28 1989-05-23 International Business Machines Corporation Logical arrangement for controlling use of different system displays by main processor and co-processor
US4849877A (en) * 1986-12-22 1989-07-18 American Telephone And Telegraph Company Virtual execution of programs on a multiprocessor system
US4937036A (en) * 1986-04-28 1990-06-26 Xerox Corporation Concurrent display of data from two different display processors and user interface therefore
US4947477A (en) * 1988-03-04 1990-08-07 Dallas Semiconductor Corporation Partitionable embedded program and data memory for a central processing unit
US4949248A (en) * 1988-07-15 1990-08-14 Caro Marshall A System for shared remote access of multiple application programs executing in one or more computers
US4951192A (en) * 1987-06-04 1990-08-21 Apollo Computer, Inc. Device for managing software configurations in parallel in a network

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3909791A (en) * 1972-06-28 1975-09-30 Ibm Selectively settable frequency divider
US3940744A (en) * 1973-12-17 1976-02-24 Xerox Corporation Self contained program loading apparatus
US4188665A (en) * 1977-11-29 1980-02-12 International Business Machines Corporation Programmable communications subsystem
US4218757A (en) * 1978-06-29 1980-08-19 Burroughs Corporation Device for automatic modification of ROM contents by a system selected variable
US4430704A (en) * 1980-01-21 1984-02-07 The United States Of America As Represented By The Secretary Of The Navy Programmable bootstrap loading system
US4607332A (en) * 1983-01-14 1986-08-19 At&T Bell Laboratories Dynamic alteration of firmware programs in Read-Only Memory based systems
US4590556A (en) * 1983-01-17 1986-05-20 Tandy Corporation Co-processor combination
US4590557A (en) * 1983-09-12 1986-05-20 Pitney Bowes Inc. Method and apparatus for controlling software configurations in data processing systems
US4769771A (en) * 1984-01-20 1988-09-06 U.S. Philips Corporation Multiprocessor system comprising a plurality of data processors which are interconnected by a communication network
US4833596A (en) * 1985-02-28 1989-05-23 International Business Machines Corporation Logical arrangement for controlling use of different system displays by main processor and co-processor
US4937036A (en) * 1986-04-28 1990-06-26 Xerox Corporation Concurrent display of data from two different display processors and user interface therefore
US4849877A (en) * 1986-12-22 1989-07-18 American Telephone And Telegraph Company Virtual execution of programs on a multiprocessor system
US4951192A (en) * 1987-06-04 1990-08-21 Apollo Computer, Inc. Device for managing software configurations in parallel in a network
US4947477A (en) * 1988-03-04 1990-08-07 Dallas Semiconductor Corporation Partitionable embedded program and data memory for a central processing unit
US4949248A (en) * 1988-07-15 1990-08-14 Caro Marshall A System for shared remote access of multiple application programs executing in one or more computers

Also Published As

Publication number Publication date
AU6520090A (en) 1991-04-18
JPH05502528A (en) 1993-04-28

Similar Documents

Publication Publication Date Title
US4768150A (en) Application program interface to networking functions
US5600823A (en) Method for optimizing software for any one of a plurality of variant architectures
CA1321654C (en) Remote boot
KR950002709B1 (en) Information transfer method and arragnement
US4891785A (en) Method for transferring data files between computers in a network response to generalized application program instructions
US5715387A (en) Method and system for loading and confirming correct operation of an application program in a target system
EP0605959B1 (en) Apparatus and methods for making a portion of a first name space available as a portion of a second name space
US5367688A (en) Boot system for distributed digital data processing system
CA2010591C (en) Kernels, description tables and device drivers
US6314567B1 (en) Apparatus and method for transferring state data when performing on-line replacement of a running program code and data
EP0371229B1 (en) Computer system having host computer
EP0490980B1 (en) Multiple facility operating system architecture
KR100272908B1 (en) Apparatus and method for implementing rotocols
US5638517A (en) Method and apparatus for transmitting a message from a computer system over a network adapter to the network by performing format conversion and memory verification
US5896534A (en) Operating system independent apparatus and method for supporting input/output devices unsupported by executing programs
JP5236367B2 (en) Shared Java JAR file
KR970004090B1 (en) Virtual execution of program on a multiprocessor system
US7155550B2 (en) Program-executing apparatus and portable information processing apparatus
JP2991242B2 (en) How to use a multiprocessor computer system
JPH11502341A (en) Link protocol for data transmission between processors
WO1991004537A1 (en) Virtual network architecture and loader
US6665752B1 (en) Interrupt driven interface coupling a programmable media access controller and a process controller
JP4060890B2 (en) File system primitives that allow reprocessing of I / O requests by multiple drivers in a hierarchical driver I / O system
JP2645065B2 (en) Information download system
Cook et al. The Crystal Nugget-Part I of the First Report on the Crystal Project

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AT AU BB BG BR CA CH DE DK ES FI GB HU JP KP KR LK LU MC MG MW NL NO RO SD SE SU

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BF BJ CF CG CH CM DE DK ES FR GA GB IT LU ML MR NL SE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: CA