Note: I didn't have time to publish this as technology was moving too fast. Isn't the Net a nice place to put things.

Network Connectivity and Interoperability
Between "DOS" Machines and A UNIX Server

Bruce C. Gabrielson, PhD
PO Box 550
Chesapeake Beach, MD

June 1992


This document considers connectivity and interoperability between a UNIX based SUN Server and a network of Intel 80x86 DOS type machines running Novell NetWare. Interoperability has been defined by Naecker[1] as "the ability of distributed computer systems to work in concert with other components of the network".

This paper will also attempt to lay a foundation for understanding some of the products that have been provided to improve connectivity and interoperability across boundaries of diverse platforms and operating systems and network protocols.

Background on Interoperability

UNIX, DOS, Macintosh, VMS, etc. are all separate operating systems developed prior to the current push towards interoperability. UNIX is basically a peer-to-peer operating system while the others when networked are basically server-centric. Server-centric means that managing security is a matter of granting or withholding access privileges on each node. Initially, these platforms were intended for stand alone operation or to only communicate with other platforms that used the same operating systems. As networks evolved, they originally followed the format of a central server with attached workstations.

Regardless of operating system, the server acts as a traffic cop between programs (called clients or applications) running on local or remote systems. The server:

* allows access to a display by a client;
* accepts or sends network messages;
* intercepts other network messages from other clients;
* performs two/three-dimensional drawing, freeing the client from processing-intensive graphics;
* tracks resources (such as Windows, cursors, fonts and graphics contexts) that are shared between clients;
* allows distributed processing, as mentioned above;
* allows multi processing and multitasking (such as X in UNIX).

Protocol Development

All network communications are based on protocols. Protocols define message preparation, communications channel establishment, and communications management during transfer. As the message is prepared for transmission, an address is attached and, if the message is long, it may be split into smaller packets. The lower protocol rules make sure the other station is ready to receive the message, and then define how the transmission should be monitored by each station as it passes over the cable

The various equipment vendors initially defined their own protocols for network communications. The Internet protocol (IP) suite was originally established by DARPA for defense network communications. The Internet protocol is now widely accepted in industry and education.

IP is the protocol responsible for routing information across the network through the use of routing tables. Several other protocols maintain and initialize the routing tables. When packets are too large and need to be fragmented, IP will fragment and then reassemble at the destination. The IP headers for each packet contain the proper order for reassembly. The format of an IP packet is shown in Figure 1 and described in Table I.

Figure 1 - Format (Fields) of an IP Packet

Table I - TCP Packet Fields

Version Field - 4 bits
Contains revision number of protocol which both nodes and routers must agree upon.

IP Header Length - 4 bits
Specifies length of datagram header.

Type of Service - 8 bits
Field used by upper-layer protocols to tell IP how to handle datagram. Broken into Precedence, Delay, Throughput, and Reliability.

Length - 16 bits
Specifies size, in bytes, of entire IP packet.

Identification - 8 bits
Used to determine which fragments belong together.

Flags - 3 bits
Used to determine the order of the current fragment.

Fragment Offset - 13 bits
Allows break alignment since contains the distance of this fragment's data from the start of the original datagram.

Time-To-Live - 8 bits
Designates length of time datagram can exist on the Internet.

Protocol - 8 bits
Designates the upper-layer protocol to receive the TPDU after IP has finished its processing.

Header Checksum - 16 bits
Computed on entire header to ensure data integrity.

IP source and destination

As ever expanding networks began to need communications between various operating systems, a standard set of communication rules, the Open System Interconnection (OSI) model, became necessary. In the United States, acceptance of the OSI model has been resisted primarily because the TCP/IP Internet protocol is already widely accepted and supported. However, the OSI protocol model, shown with the Internet model in Figure 2 and discussed in Table II, is an emerging standard which will eventually allow all type of platforms to communicate within the network environment. The problems created by interoperability with this model, or other existing protocols, have become a major issue, particularly between UNIX and DOS based machines.

Figure 2 - OSI/Internet Model Mapping

Table II - OSI Model Description

Rules at the top determine how information can be sent over a network and then used by the other system's application.
Middle level rules describe how connections are established and how packets of information can be sent.
Bottom level rules define the actual transmission process and media.

The Internet Protocol Suite

Transmission Control Protocol (TCP) is considered the primary Internet transport protocol. TCP and IP together make up what is called the Internet Protocol suite. TCP/IP is a connection oriented, end to end protocol suite which provides other services such as file transfer protocol (FTP), simple mail transfer protocol (SMTP), and terminal services (TELNET).

The TCP/IP suite does not define the lower Data-Link and Physical layers in order to allow interoperation with many implementations. TCP/IP can run over Ethernet, Token Ring, Token Bus, HDLC, and X.25 systems with minor configuration adjustments.

UNIX and Novell NetWare

UNIX is an operating system developed for the multi-user environment. The kernel, depicted in Figure 3, is in effect the UNIX operating system. It is the master control program which allocates computer resources to various user tasks. The kernel starts up a separate user interactive program called a shell for each user that logs into the system. The shell acts as a command interpreter so the user can interface with the system. The different shells allow the kernel to maintain unified overall control by providing separation of individual users or tasks.

Figure 3 - UNIX Kernal

DOS was developed initially to operate a single pc in a non-networked environment. Since DOS isn't configured for networks, another multi-user oriented operating system is required for these machines. Novell NetWare is a separate operating system which was written initially to bypass the DOS and its I/O system (BIOS) altogether and provide pc support for multi-user environments.

NetWare's shell allows users to run DOS commands in the normal manner, while also recognizing NetWare commands. Similar to UNIX, the NetWare shell intercepts network commands and sends them to the server using IPX/SPX protocols. Specifically, Netware allows computer users to connect their systems together and share resources, files, and programs using its own unique networking protocol suite.

The NetWare Protocol Suite

Netware is based on a layered protocol architecture called Xerox Network System (XNS). The NetWare model is shown in Figure 4. Internetwork Packet Exchange (IPX) is a connectionless protocol for routing and addressing from node to destination node. The fields of the IPX packets are shown in Figure 5 and described in Table III.

Figure 4 - NetWare Model

Figure 5 - IPX Packet Fields

Table III - IPX Packet Fields

Checksum - 16 bits
Conforms to the XNS header.

Length - 16 bits
Gives length of IPX datagram.

Transport Control - 8 bits
Used by routers to set field to zero by IPX prior to sending packet.

Packet Type - 8 bits
Specifies upper-layer protocol to which packet information is being passed.

Destination Network - 32 bits
Specifies packet's destination network address.

Destination Host - 48 bits
Specifies physical hardware address for the destination node.

Destination Socket - 16 bits
Specifies process within the destination node.

Source Network - 32 bits
Network address of packet source.

Source Host - 48 bits
Physical hardware address for source.

Source Socket - 16 bits
Address of source socket.

Netware uses Sequence Packet Exchange (SPX) to connect and reliably deliver packets between workstations and servers. SPX and TCP are similar in that both allow several requests to be outstanding. TCP's source and destination ports are similar to SPX socket numbers and connection IDs.

NetWare to UNIX Integration

NetWare is written in C, and has versions available for all platforms. A SUN Server is normally operated under the UNIX operating system. However, Novell supplies a version of NetWare specifically for the SUN server which offers an alternative solution. Therefore, with the proliferation of Novell LAN'S, SUN and other UNIX-based Workstations, there now arises the question as to how such resources might best be configured in terms of operating systems and the type of network to be supported.

There are two existing primary ways of integrating NetWare and UNIX, plus a new approach which incorporates IPX/SPX into the UNIX server. The first integrates NetWare into UNIX using the TCP/IP environment. The second approach uses NetWare for UNIX to enable systems to run UNIX applications. PC based TCP/IP is more flexible in the wide area network environment than NetWare for UNIX since NetWare clients running both NetWare and TCP/IP can access either UNIX or NetWare remote servers using their respective protocols.

Under UNIX (the SUN operating environment is called SOLARIS 2.0, the operating system is called Sun OS), the windowing system provided by SUN Microsystems is Xll, and provides a unique concept in networking known as X, or X Windows (described later). If a user attempted to interconnect an existing Ethernet network of PC's with a SUN server with its UNIX operating system and X Windows network, there would be a host of unforeseen difficulties.

When using NetWare to get around the interconnection problem, TCP/IP, Network File System (NFS), and an X Windows server can be loaded on every NetWare client requesting UNIX interoperability. The X Window server is optional for users needing to run X Window applications.

NetWare for UNIX is a hardware-independent version of NetWare, portable to various UNIX host environments. Using NetWare for UNIX as the common protocol, a UNIX server would be connected to a group of PC's in a network, and the PCS would be served exactly as they are served today by Intel 8Ox86 servers. Systems can run UNIX applications and function simultaneously as a NetWare server, but can't run NetWare Loadable Modules (NLM) because of their hardware independence. The benefits of UNIX and NetWare integration are provided in Table IV from Kawai Leung[3]. This same article lists at least twenty-five UNIX OEM vendors providing NetWare for UNIX.

Table IV - Benefits of UNIX and NetWare Integration

Information Sharing - Critical information is increasingly being stored and manipulated on UNIX servers.

File and Print Services - High-end UNIX servers offer a fault-resilient environment for storing gigabytes of data while ensuring continuous data availability.

Client/Server Computing - This method distributes application processing among UNIX servers, with low-cost PC clients acting as the front ends. UNIX servers are used for back-end applications and data-intensive processing.

Tunneling IPX Through IP Networks

Novell's NetWare IPX protocol is functionally equivalent to the Internet Datagram Protocol (IDP). Tunneling encapsulated IPX datagrams within UDP packets so that IPX traffic can travel across an IP Internet. With this approach, the IP internet will appear as a single IPX network to a Novell user.

The IPX datagram is carried in the data portion of a UDP packet as shown in Figure 6. All IP and UDP fields are set normally. IPX uses the network number to route each packet through the IPX internet to the destination network. To work correctly in the absence of internet wide IP broadcast capabilities, each IPX router and server needs to maintain a list of the IP addresses of other IPX routers and servers.

Figure 6 - IPX Packet Carried as Data in UDP Packet

The problem with using this approach is that because of the ping-pong nature of the IPX protocol (a response is required for each packet before the next packet can be sent), encapsulation generates a significant amount of traffic on the IP network. In addition, this process can not support a client pc that is attached directly to the IP network.

Security of Wide-Area IPX

Using the wide-area IP internet to transfer IPX data poses some security concerns. IPX traffic in unconcerned with media security in NetWare networks since they are normally isolated from the outside world physically using cabling and modem interfaces through individual users. IP internets invite access through the gateway, with security only as good as the entire IP through which the data is tunneled. Therefore, the following classes of internetwork attacks are possible.

IPX clients can gain access to resources through normal access control attacks such as password cracking.

Unauthorized IPX gateways can divert IPX traffic to unintended routes. If IP is captured during transfer it could change it then resend it to its destination.

Firewalls are the most complete but also costliest way to guard against Internet invaders. Generally, these take the form of up-front protection at the router through which outside users must pass to access the protected network (Figure 7). However, if the router is programmed to pass IPX, then an attack on the router is possible.

Unauthorized agents can monitor and manipulate IPX traffic flowing over physical media used by the IP Internet and under control of the agent.

The network can be modified to watch for IPX embedded in IP. This packet could then be captured.

Figure 7 - Typical Firewall Configuration

Novell's NetWare/IP

NetWare /IP basically eliminates the need to run IPX as the transparent protocol between the client and the server. Using the NetWare Loadable Module (NLM) on the file server requires that an IP-based software be running on each individual client pc. The end result is it becomes possible for the client pc to use TCP/IP as the transport protocol while retaining full communications with NetWare file servers running IP and IPX.

To support communications between IP and IPX-based file servers, a file server must be configured as a gateway between the IP network(s) and the IPX network(s). The file server must have two separate network interface cards, one connected to the IP network using the IP network protocol, and the other connected to the IPX network using IPX. The file server used as a gateway provides the path and protocol conversion between the two networks, allowing a NetWare/IP client to use a file server that is actually located on an IPX network segment and vice versa.

For the NetWare/IP client to work, the NetWare file server component, TCPIP.NLM, must be loaded and configured at the file server along with a NetWare/IP component, NWIP.NLM.

DOS Plus UNIX in a Single Computer

There are at least four software products on the market that claim to provide coexistence of DOS and UNIX in computers[4].

Softpc, although slower than normal DOS, emulates a DOS environment under a UNIX operating system. Example architectures are:

- DECstation 3100 with Ultrix 3.0 And DECWindows 2.0
- Apollo et al 68000 family workstations

In this environment a user can still access the other Windows and run UNIX commands while the DOS application runs.

VP/ix runs as a UNIX extension on Intel architecture to create a virtual DOS pc under UNIX. It is an approach or concept rather than a brand name, and is available from a variety of UNIX/xenix vendors. Since VP/ix is a task running under UNIX, more than one such task may be concurrent and provide effectively multiple DOS environments, each running the same or different applications. See also "Extracts from Johnson & Reichard" below.

Merge 386 is similar to VP/ix, but uses an actual DOS physical partition on the hard disk while also accessing virtual DOS files within the UNIX file system. Multiple DOS applications are possible.

XDOS does not actually provide coexistence. It is a scheme for converting or translating a DOS executable (.EXE or .COM file) into an image that will execute under UNIX on a non-intel machine. Since this approach actually modifies the application itself, it isn't true interoperability.

Sun Microsystems, Inc.[5] has a link to IBM mainframe channels called the Sunlink Channel Adapter. A Sun workstation can then run Sunlink Local 3270 in order to emulate a variety of local channel connected devices. In this environment the sun workstation would have a window open for the 3270 emulation and be logged into the IBM mainframe. Other Windows open on the same workstation will then allow for capturing, cut & paste, etc. An additional product called Sunlink CG3270 (which requires one of the basic Sunlink products as a prerequisite) will provide additional control over the 3270 emulation window by emulating an IBM 3179g color terminal.

Sun Microsystems, Inc. has the capability in Sunlink DNI for linking to DEC's DECnet vax phase IV as an end node (no routing beyond that node). Logins and file transfer can occur in both directions. Ethernet is the Physical Layer protocol, and vtlOO emulation is included. Copying text from the vtlOO Windows to Sun Windows is facilitated with the Sun mouse.

Sun Microsystems, Inc.[6] has included the MIT xWindow System, Version 11 in their xll/news product.


In 1991 there were 40 million IPX/SPX nodes in regular use[7]. With such a large existing base, in industry there was a tremendous need for direct UNIX/Novell integration. The UnixWare Advanced Server includes both IPX/SPX and TCP/IP. IPX/SPX is included as a part of the UNIX source code in the Berkeley 4.4 BSD-Lite.

X-Windows Access Control on DOS PC's

Under UNIX, a window viewing system is available called X-Windows. UNIX window systems allow users a method to control access to a display or otherwise control how the information is presented. The X-Window system by default in particular does not allow other hosts to access the display unless access has been granted using the xhost command. In the X-Window System, Version 11, authorization protocols are also provided which enables using the xauth command for enhanced access control.

X-terminals are special devices which connect to networks and operate using the X-Window System. These devices are not true workstations since they do not contain their own operating system, but are set-up to operate similar to true workstations.

DOS based systems have no similar window control function. However, DOS based PC's can be operated under X-Windows. An article by Lewis, Trachtenberg and Associates[8] identifies approximately sixteen different products that provide X-Windows servers on DOS based machines. One such product is identified in Table V.

Table V - Sample Product

Spectra Graphics/GAS (503-641-2200) makes PC-View, an MSDOS based X server which interfaces with PC/TCP Plus networking software from FTP Software and Excelan's LAN WorkPlace for DOS. The server works with (a) 286, 386, 486 (b) EGA, VGA DGIS displays. (c) DOS 3.2 and above (d) Microsoft, Logitech, Mouse Systems Mice (e) 640k memory up to 16 MB memory [the PC-View/16 is available for PCs with extended memory).

Windows TCP/IP

A promising area of research into DOS/UNIX integration relates to the use of Windows based applications that provide TCP/IP connectivity. TCP/Connect II[9] for Windows offers "an integrated IP service using TCP/IP and NFS standards to connect users with platforms that support TCP/IP including UNIX, Open VMS, MVS, and Macintosh." The package is implemented as a Microsoft Dynamic Link Library, which allows it to work with the Window's memory management facilities and run primarily in high memory on the users PC. The user can run both Windows and DOS applications.

X-Windows (Extracts from Johnson & Reichard[10])

X runs on just about every computer including DOS PC's Macintoshes, Hewlett-Packards, PS/2s, Suns, Data Generals, DECs, Amigas, and Crays. Except for a few minor differences, the C language interface is the same across all these platforms. The standard X C Library routines are the same on every machine running X, which means interface code ports directly from one machine to the other.

X also runs on all UNIX workstations. Digital Equipment, Hewlett-Packard, IBM, and Apple all offer their own versions of X. Other vendors offer the generic X from MIT with their workstations, such as Data General's slick Aviion series[11]. Still other vendors have offered merged X servers by combining x with proprietary windowing systems and offer merged X servers. Although there are several implementations of X, it is important to note that they are not all the same.

The display server is the program that controls and draws all output to the display monitors, tracks client input, and updates windows accordingly. A Client is an application program that performs a specific task.

The generic X Window System consists of the Xlib graphics subroutine library, the X network protocol, an X toolkit and several window managers (such as uwm). The application programmer links the client program through Xlib.

One of the most difficult areas of X is making X applications communicate with each other. Application interoperability is difficult, and X provides many features to help make programs talk to one another.

Bindings are apparently language specific.

To run X-Windows in an Intel machine with DOS OS, UNIX rather than DOS must be running (i.e., the Xlib stuff is designed for a UNIX environment, not a DOS environment.

Examples of Client programs: text editors, spread sheets & clock displays (note the similarity to DOS Windows 3.1 applications).

Connection between client & server
shared memory link (local)
TCP/IP or DECnet (networked)

Connection to an X Server is implemented in the call Xopen Display. It could be that X clients and X servers are programs that are carefully written to follow X conventions and not ordinary applications which just happen to communicate with something called X Windows.

"X-Window Events" are asynchronous events that flow from the server to the client. (It is important to recognize that the Server manages "screens" which include the keyboard and pointing device as well as one or more monitors).

Conclusions and Recommendations

Fundamental questions that are yet to be resolved: What, if any, direct DOS applications will allow TCP/IP interfacing with X Windows, and what role, if any, is played by Windows 3.1 in those instances? Does the IPX protocol have inherent weaknesses that could be exploited either directly, or through the IP protocol when tunneling between NetWare networks?


[1] P. A. Naecker, "Well Connected X", DEC Professional, June 1990.
[2] IBM's System Network Architecture (SNA), DEC's Digital Network Architecture (DNA), Novell's NetWare protocol suite, Apple's Local Talk.
[3] Netware-to-UNIX: Take Two", Kawai Leung, LAN Times, February 14, 1994.
[4] Personal Workstation, April 1990.
[7] Gaskin, James, IPX/SPX For UNIX? You Can Bank on It, Network Computing, March 1, 1994.
[8] "Compilation of Frequently Asked Questions about X Windows", Lewis, Trachtenberg & Associates, March 13, 1991 (Members of the MIT X Consortium, Cambridge, MA
[9] Intercon Systems Corp., (703) 709-9890, Herndon, VA.
[10] Advanced X Windows Applications Programming", Johnson & Reichard, MIS: Press.
[11] P. A. Naecker, "Well Connected X", DEC Professional, June 1990.

Additional Reference Sources

[1] PC Computing, November, 1989
[2] Personal Workstation, April 1990
[3] Xlib Programming Manual, Volume 1, by Adrian Nye, O'Reilly & Associates, Inc.
[4] Xlib Reference Manual, Volume 2, by Adrian Nye, O'Reilly & Associates, Inc.
[5] X Toolkit Intrinsics Programming Manual OSF/Motif Edition, Volume 4, by Adrian Nye & Tim O'Reilly, O,Reilly & Associates, Inc.
[6] X Toolkit Intrinsics, Reference Manual Volume 5, by Staff of O'Reilly & Associates, O'Reilly & Associates, Inc.
[7] OSF/Motif Programmer's Reference, Prentice Hall
[8] Object Oriented Programming with the X Window System Toolkits, by Jerry D. Smith, John Wiley & Sons, Inc.