Pursuing Unix and Windows NT coexistence

In part two, we detail Unix/NT coexistence strategies in porting Unix applications to NT, file sharing, and IP address managment using NT

By Dave Herdman
Abstract
There are a number of strategies that can be pursued to promote the coexistence of Windows NT and Unix. In my previous article we looked at using NT as a common code base and running applications on NT and Unix. In this article we consider several other coexistence strategies. First we look at the flip side of my previous article, namely the practicalities of porting Unix applications to NT while preserving Unix APIs. (2,400 words)

Many organizations have well-established, Unix-based software that they want to port to NT. As we highlighted previously, the NT APIs are significantly different from Unix and a direct port would be very labor intensive. It is, of course, desirable to port Unix code with very little modification, particularly for an initial NT product release. There are various types of software on the market that assist with this. Perhaps the most comprehensive is the DataFocus Nutcracker toolset. Nutcracker X/SDK provides the following support for Unix programs on NT:

Much of this support is provided by link libraries and dynamic link libraries (DLLs) that make the Unix APIs available under NT. In addition to the above, Nutcracker provides Wintif, which allows the display of Motif GUI applications with a Windows look and feel. Nutcracker's developers say that fewer than 0.1 percent of Unix code needs to be changed to allow most applications to run under NT. Not all the tools in the package were developed by Datafocus. For example many of the Unix utilities provided with the toolkit are in fact the well-known MKS tools.

Nutcracker has quite a distinguished customer list. Among them is Digital Equipment Corp., which used Nutcracker to port its licensed version of IBM's Netview 6000, Polycentre Netview, from Digital Unix to NT.

Opinion on such porting tools, both for and against, is espoused with almost religious zeal. My view, for what it's worth, is that such tools provide a good way to get into the NT market quickly. Also many Unix shops might prefer this route to the wholesale adoption of Microsoft's Win32 API. On the other hand, I don't think it's a good idea to still be using these tools two or three years from now; sooner or later you must go native. This is not necessarily an all or nothing proposition, as Nutcracker allows mixing of Unix and Win32 APIs, and it's therefore possible to gradually "evolve" a ported application to use Win32.

What about networking?
For many sites networking is the key to any Unix/NT coexistence strategy. NT comes with built-in TCP/IP networking support for most of the common core protocols including IP, TCP, UPD, ARP, and ICMP. A number of application layer protocols are supported as standard, including a character cell FTP client and an FTP server.

NT also comes with a fairly primitive GUI telnet client application. As NT is not really an interactive multiuser operating system "telnetting" into NT is of limited use. However, there are many telnet server implementations for NT. One comes with the NT resource kit. So what, you might say. Most if not all of this has been possible with PC desktops as far back as Windows 3.1. The big difference with NT TCP/IP is that it is "built in" and not "bolted on." This means you get seamless, robust TCP/IP networking support similar to the support the Unix world has enjoyed for many years.

Sharing filesystems between NT and Unix
Microsoft provides neither an NFS client nor server implementation for NT. There are third-party client/server products available from a good number of vendors, some of which are listed below. Several issues need to be taken into account when purchasing NFS software for NT. You need to decide if NFS client or server functionality is required because unlike Unix, both functions are not always included in a given product. NT supports long filenames and in theory should be able to preserve most filenames used on a Unix host intact. Some of the NFS products I have used still map long filenames into unfriendly 8+3 DOS style names. I suspect this is a hangover from 16-bit NFS products, and that this annoying behavior will disappear as the products are reengineered to take full advantage of Win32 capabilities.

Product Capability Vendor URL
PC-NFS 5.1 NFS Client SunSoft www.sunsoft.com
PC-NFSpro NFS Client, NFS Server Other TCP/IP applications SunSoft www.sunsoft.com
Chameleon32NFS 4.01 NFS Client, NFS Server Other TCP/IP applications NetManage www.netmanage.com
NFSware NFS Client, NFS Server Other TCP/IP applications Process Software www.process.com
Interdrive NT V2.1 NFS Client FTP Software www.ftp.com
Interdrive NT Server V1.2 NFS Server, LPD print server FTP Software www.ftp.com
DiskShare for Windows NTv1.0 NFS Server Intergraph www.intergraph.com
Omni-NFS Windows NT NFS Client, NFS Server LPD/LPR, FTP client & server XLink Technology Inc www.xlink.com
Omni-NFS Server NFS Server, LPD XLink Technology Inc www.xlink.com

NT terminals and thin clients
Another aspect of NT/Unix interworking that seems to be enjoying very rapid growth right now is the provision of NT services to Unix desktops, be these workstations or X terminals. This technology enables Unix users to take advantage of standard Win32 applications such as Word and Excel. Microsoft does not currently cater to this, but the number of third-party vendors whose products facilitate such interworking is growing. It should be noted that these products do not emulate NT on Unix machines. Rather the NT apps are run on a special NT server, and the GUI is displayed across the network to the user's workstation. X-terminal vendors are particularly well represented in this marketplace with NCD and Tektronix both offering products. Perhaps this is because these companies recognize that the X-terminal market will steadily decline in the coming years.

Standard Windows NT is multitasking but not multiuser. This means that Windows NT can run many tasks simultaneously, but only one user can be logged in at a time. Consequently out of the box NT is not sufficient to provide a facility similar to X.

Microsoft has authorized a set of extensions to NT that allow a single NT server to support multiple users. This combined with third-party software allows non-NT graphics machines to run NT applications. The network transport for these applications is either TCP/IP or Citrix's proprietary Intelligent Console Architecture (ICA) protocol. Citrix is very active in this marketplace and its ICA 3 protocol has been licensed by other vendors. Its initial product, WinFrame, allows low-end machines such as 386s (thin clients) to act as NT display terminals, allowing organizations to deploy NT without massive reinvestment in new desktop hardware or extra memory on client machines.

Product placeholder Vendor Web
WinFrame Thin Client using ICA Citrix www.citrix.com
WinCenter Pro NT on X devices using either X11 or ICA NCD www.ncd.com
WinDD NT on X devices using either X11 or ICA Textronix www.tektronix.com
WinTerm Thin Client using ICA Wyse www.wyse.com
NTRIGUE NT on X devices using either X11 or ICA Insignia www.insignia.com

Network programming
NT supports the "socket" API for network programming. This is accomplished via Windows Sockets (Winsock). The Winsock API is a largely compatible superset of standard BSD (Berkeley Standard Distribution) sockets. The Windows Sockets API also has a number of extensions not found in BSD implementations. All these calls start with the prefix "WSA." Windows socket programming is fairly straightforward for those with Unix socket experience.

One example of the differences is that the program must initialize the Winsock DLL (DLLs are conceptually similar to shared libraries in Unix) before any socket calls can be made. You must call the WSAStartup() routine in order to do this. If this is not done, all subsequent Winsock API calls will fail. This initialization call also tests to ensure that the desired minimum version of the Winsock DLL is in fact available on the system. NT 3.5.1 supports version 1.1 of the Winsock specification. Version 4 of NT supports both Winsock 1.1 and 2.0.

RPC under NT
Those considering developing home-grown client/server applications are advised to check out remote procedure call (RPC) before embarking on a sockets-based design. Unfortunately for those from the Sun world, the native NT RPC implementation is OSF DCE-compliant rather than Sun's preferred ONC RPC. Rather annoyingly Microsoft's RPC calls have slightly different syntax from the OSF calls commonly used on many Unix systems. If you wish to go the ONC RPC route there are several third-party vendors offering products for NT, including Distinct's 32-bit TCP/IP SDK.

IP address management using NT
One of the major headaches in managing hundreds or even thousands of desktop machines is the initial allocation and subsequent management of network parameters such as IP addresses. The Internet community has recognized this and the Distributed Host Configuration Protocol (DHCP) was evolved some years ago. Microsoft has embraced DHCP enthusiastically and has made it a cornerstone of its TCP/IP-on-NT strategy. Indeed some PC folks even think that DHCP is a Microsoft invention (which, of course, it is not). Using DHCP a machine can issue a broadcast request at power-up and can be allocated an IP address, subnet mask, default gateway, domain name, and a list of domain name system (DNS) servers by a DHCP server.

The basic DHCP mechanism is as follows: DHCP clients broadcast a "discover" message which is processed by the DHCP server either on the local subnet or remotely. In normal operation the DHCP server(s) will be able to offer an IP address from the available pool. The client reviews all the offers it receives and issues a "request" message for one of the offered addresses. The server offering the address will send an "acknowledgement" message.

DHCP addresses are "leased" to clients. That is to say the address is made available to the client machine for a relatively short time (default is three days). The client must renew the lease before expiration. This process can be fairly complex under certain circumstances, and a discussion of this is too lengthy for inclusion here. In order for DHCP clients to reach servers on a different subnet, the router or routers between the subnets must be configured to support BOOTP forwarding. This feature allows DHCP broadcasts to propagate beyond a local subnet. Incidentally the reason the feature is known as BOOTP forwarding is because DHCP is in fact a superset of the older BOOTP protocol. The forwarding element remains unchanged.

In fact the above description is slightly misleading. DHCP does not just allocate IP addresses to clients. It is possible to allocate many more attributes such as a default gateway address. One aspect worth bearing in mind is that DHCP server software is only included with the more expensive NT Server and not the Workstation version. However, most recent Unix variants now include DHCP servers as do some of the OpenVMS TCP/IP products.

NetBIOS over TCP/IP
One area that seems to cause some confusion is the distinction between "traditional" TCP/IP applications and Microsoft's use of NetBIOS over TCP/IP. This technology has been around for some time and was standardized in RFC 1001 and 1002. This technology allows TCP/IP to be used as the transport for Netbios sessions (such as a network disk drive or a printer), thus extending it from a "LAN-only" protocol to one which may be used in a multisegmented, routed network. As a consequence many NT shops use TCP/IP transport.

Traditionally LANmanager hosts located each other by issuing broadcast requests to identify a particular (LANmanager) hostname on the LAN. Obviously such a technique cannot work in a routed TCP/IP network. The initial workaround for this was the introduction of the LMHOSTS file. This file is almost identical to the Unix hosts file except that it associates a LANman hostname with an IP address. In large networks this method suffers from the same maintenance and integrity problems as the Unix hosts file.

Consequently Microsoft developed Netbios name server software known as WINS (Windows Internet Name Server). Conceptually this is similar to DNS, however WINS is only used to look up the IP addresses for NetBIOS use and not for "traditional" TCP/IP applications such as FTP and telnet. One important difference is that client IP addresses will change frequently if DHCP is used. WINS is able to reflect these changes in a timely manner as each client will register its new name to IP address mapping with a local WINS server.

X-servers and clients
Microsoft has not seen fit to provide NT with any native X Window, client/server capability. Once again a good number of third-party software vendors have rushed to fill this gap, and there are now multiple products to choose from. Popular vendors include SunSoft, Hummingbird, and WRQ. Their products were reviewed in a previous SunWorld article. (See Resources.)

Data sharing
One traditional mechanism for sharing data between PCs and Unix has been DOS (FAT) formatted floppy disks. NT does little to change this long-standing situation. NT supports a number of filesystems including DOS FAT and the newer NT-specific NTFS. Many Unix systems support the reading and writing of FAT-formatted floppy disks, but to the best of my knowledge only Linux currently provides the capability to read NTFS-formatted disks. Indeed current versions of NT cannot format floppy disks as NTFS, only as FAT.

Resources

If you have visited a computer bookstore recently you have realized that there is no shortage of NT-related books. Some that are particularly relevant for those considering Unix and NT integration are listed here.

Microsoft's Resource Kit books provide much more technical detail than is provided in the standard manual set:

There are several good books on NT networking including these:

Reference works for NT internals and administration include the following:

Other Web resources:

About the author
Dave Herdman is a principal with Open Systems Interconnections Ltd., a consultancy and reseller based in London. Herdman speaks often at industry conferences in Europe on Unix. Reach Dave Herdman at dave.herdman@sunworld.com.