?

Log in

No account? Create an account

Tue, Oct. 18th, 2016, 09:41 pm
Computing: FEATURE - Server integration - Windows onto Unix

I stumbled across an old article of mine earlier, and tweeted it. Sadly, the server seems to have noticed and slapped a paywall onto it. So, on the basis that I wrote the bally thing anyway, here's a copy of the text for posterity, grabbed from Google's cache. Typos left from the original.

FEATURE - Server integration - Window onto Unix

If you want to access a Unix box from a Windows PCs you might feel that the world is against you. Although Windows wasn't designed with Unix integration in mind there is still a range of third-party products that can help. Liam Proven takes you through a selection of the better-known offerings.

10 March 1998

Although Intel PCs running some variant of Microsoft Windows dominateat the world is against you. Although Windows wasn't designed with Unix integration in mind there is still a range of third-party products that can help. Liam Proven takes you through a selection of the better-known offerings. the desktop today, Unix remains strong as a platform for servers and some high-end graphics workstations. While there's something to be said in favour of desktop Unix in cost-of-ownership terms, it's generally far cheaper to equip users with commodity Windows PCs than either Unix workstations or individual licences for the commercial Unix offering, such as Sun's Solaris or SCO's products, that run on Intel PCs.

The problem is that Windows was not designed with Unix integration as a primary concern. Granted, the latest 32-bit versions are provided with integrated Internet access in the form of TCP/IP stacks and a web browser, but for many businesses, a browser isn't enough.

These power users need more serious forms of connectivity: access to Unix server file systems, text-based applications and graphical Unix programs.

These needs are best met by additional third-party products. Most Unix vendors offer a range of solutions, too many to list here, so what follows is a selection of the better-known offerings.

Open access

In the 'Open Systems' world, there is a single, established standard for sharing files and disks across Lans: Network File System (NFS). This has superseded the cumbersome File Transfer Protocol (FTP) method, which today is mainly limited to remote use, for instance in Internet file transfers.

Although, as with many things Unix, it originated with Sun, NFS is now the de facto standard, used by all Unix vendors. In contrast to FTP, NFS allows a client to mount part of a remote server's filesystem as if it were a local volume, giving transparent access to any program.

It should come as no surprise that no version of Windows has built-in NFS support, either as a client or a server. Indeed, Microsoft promotes its own system as an alternative to NFS under the name of CIFS. Still, Microsoft does include FTP clients with its TCP/IP stacks, and NT Server even includes an FTP server. Additionally, both Windows 95 and NT can print to Unix print queues managed by the standard LPD service.

It is reasonably simple to add NFS client support to a small group of Windows PCs. Probably the best-regarded package is Hummingbird's Maestro (formerly from Beame & Whiteside), a suite of TCP/IP tools for Windows NT and 95. In addition to an NFS client, it also offers a variety of terminal emulations, including IBM 3270 and 5250, Telnet and an assortment of Internet tools. A number of versions are available including ones to run alongside or independently of Microsoft's TCP/IP stack. DOS and Windows 3 are also provided for.

There is also a separate NFS server to allow Unix machines to connect to Windows servers.

If there are a very large number of client machines, though, purchasing multiple licences for an NFS package might prove expensive, and it's more cost-effective to make the server capable of serving files using Windows standards. Effectively, this means the Server Message Block (SMB) protocol, the native 'language' of Microsoft's Lan Manager, as used in everything from Windows for Workgroups to NT Server.

Lan Manager - or, more euphemistically, LanMan - has been ported to run on a range of non-MS operating systems, too. All Microsoft networking is based on LanMan, so as far as any Windows PCs are concerned, any machine running LanMan is a file server: a SCO Unix machine running VisionFS, or a Digital Unix or OpenVMS machine running PathWorks. For Solaris systems, SunLink PC offers similar functionality.

It's completely transparent: without any additional client software, all network-aware versions of Windows (from Windows 3.1 for Workgroups onwards) can connect to the disks and printers on the server. For DOS and Windows 3.1 clients, there's even a free LanMan (Dos-based) client available from Microsoft. This can be downloaded from www.microsoft. com or found on the NT Server CD.

Samba in the server

So far, so good - as long as your Unix vendor offers a version of LanMan for its platform. If not, there is an alternative: Samba. This is a public domain SMB network client and server, available for virtually all Unix flavours. It's tried and tested, but traditionally-minded IT managers may still be biased against public domain software. Even so, Samba is worth a look; it's small and simple and works well. It only runs over TCP/IP, but this comes as standard with 32-bit Windows and is a free add-on for Windows 3. A Unix server with Samba installed appears in "Network Neighborhood" under Windows as another server, so use is completely transparent.

File and print access is fine if all you need to do is gain access to Unix data from Windows applications, but if you need to run Unix programs on Windows, it's not enough. Remote execution of applications is a built-in feature of the Unix operating system, and works in three basic ways.

The simplest is via the Unix commands rexec and rsh, which allow programs to be started on another machine across the network. However, for interactive use, the usual tools are Telnet, for text-terminal programs, and the X Window System (or X) for GUI applications.

Telnet is essentially a terminal emulator that works across a TCP/IP network, allowing text-based programs to be used from anywhere on the network. A basic Telnet program is supplied free with all Windows TCP/IP stacks, but only offers basic PC ANSI emulation. Traditional text-based Unix applications tend to be designed for common text terminals such as the Digital VT220 or Wyse 60, and use screen controls and keyboard layouts specific to these devices, which the Microsoft Telnet program does not support.

A host of vendors supply more flexible terminal emulators with their TCP/IP stacks, including Hummingbird, FTP Software, NetManage and many others. Two specialists in this area are Pericom Software and J River.

Pericom's Teem range of terminal emulators is probably the most comprehensive, covering all major platforms and all major emulations. J River's ICE range is more specific, aiming to connect Windows PCs to Unix servers via TCP/IP or serial lines, providing terminal emulation, printing to Unix printers and easy file transfer.

Unix moved on from its text-only roots many years ago and modern Unix systems have graphical user interfaces much like those of Windows or the MacOS. The essential difference between these and the Unix GUI, though, is that X is split into two parts, client and server. Confusingly, these terms refer to the opposite ends of the network than in normal usage: the X server is the program that runs on the user's computer, displaying the user interface and accepting input, while the X client is the actual program code running on a Unix host computer.

The X factor

This means that all you need to allow PCs to run X applications is an X server for MS Windows - and these are plentiful. While Digital, Sun and other companies offer their own X servers, one of the best-regarded third-party offerings, Exceed, again comes from Hummingbird. With an MS Windows X server, users can log-in to Unix hosts and run any X-based application as if they were using a Unix workstation - including the standard X terminal emulator xterm, making X ideal for mixed graphical and character-based work.

The only drawback of using terminal emulators or MS Windows X servers for Unix host access is the same as that for using NFS: the need for multiple client licences. However, a radical new product from SCO changes all that.

The mating game

Tarantella is an "application broker": it shifts the burden of client emulation from the desktop to the server. In short, Tarantella uses Java to present a remote desktop or "webtop" to any client computer with a Java-capable web browser. From the webtop, the user can start any host-based application to which they have rights, and Tarantella downloads Java code to the client browser to provide the relevant interface - either a terminal emulator for character-based software or a Java X emulator for graphical software.

The host software can be running on the Tarantella server or any other host machine on the network, meaning that it supports most host platforms - including Citrix WinFrame and its variants, which means that Tarantella can supply Windows applications to all clients, too.

Tarantella is remarkably flexible, but it's early days yet - the first version only appeared four months ago. Currently, Tarantella is confined to running on SCO's own UnixWare, but versions are promised for all major Unix variants and Windows NT.

There are plenty of ways to integrate Windows and Unix environments, and it's a safe bet that whoever your Unix supplier is they will have an offering - but no single product will be perfect for everyone, and those described here deserve consideration. Tarantella attempts to be all things to all system administrators, but for now, only if they are running SCO. It's highly likely, though, that it is a pointer to the way things will go in the future.

USING WINDOWS FROM UNIX

There are a host of solutions available for accessing Unix servers from Windows PCs. Rather fewer go the other way, allowing Unix users to use Windows applications or data stored on Windows servers.

For file-sharing, it's easiest to point out that the various solutions outlined in the main article for accessing Unix file systems from Windows will happily work both ways. Once a Windows machine has access to a Unix disk volume, it can place information on to that volume as easily as it can take it off.

For regular transfers, or those under control of the Unix system, NFS or Samba again provide the answer. Samba is both a client and a server, and Windows for Workgroups, Windows 95 and Windows NT all offer server functionality.

Although a Unix machine can't access the hard disk of a Windows box which is only running an NFS client, most NFS vendors also offer separate NFS servers for Windows. It would be unwise, at the very least, to use Windows 3 or Windows 95 as a file server, so this can reasonably be considered to apply mainly to PCs running Windows NT.

Here, the licensing restrictions on NT come into play. NT Workstation is only licensed for 10 simultaneous incoming client connections, so even if the NFS server is not so restricted, allowing more than this violates Microsoft's licence agreement. Different versions of NT Server allow different numbers of clients, and additional licences are readily available from Microsoft, although versions 3.x and 4 of NT Server do not actually limit connections to the licensed number.

There are two routes to running Windows applications on Unix workstations: emulating Windows itself on the workstation, or adding a multi-user version of Windows NT to the Unix network.

Because there are so many applications for DOS and Windows compared to those for all other operating system platforms put together, several companies have developed ways to run Windows, or Windows programs, under Unix. The simplest and most compatible method is to write a Unix program which emulates a complete Intel PC, and then run an actual copy of Windows on the emulator.

This has been done by UK company Insignia, whose SoftWindows was developed with assistance from Microsoft itself. SoftWindows runs on several Unix architectures including Solaris, IRIX, AIX and HP-UX (as well as the Apple Macintosh), and when running on a powerful workstation is very usable.

A different approach was tried by Sun with Wabi. Wabi once stood for "Windows Application Binary Interface", but for legal reasons, this was changed, and now the name doesn't stand for anything. Wabi translates Windows API calls into their Unix equivalents, and emulates an Intel 386 processor for use on RISC systems. This enables certain 16-bit Windows applications, including the major office suites, to run under Unix, without requiring an actual copy of Microsoft Windows. However, it isn't guaranteed to run any Windows application, and partly due to legal pressure from Microsoft, development was halted after the 16-bit edition was released.

It's still on sale, and versions exist for Sun Solaris, SCO Unix and Caldera OpenLinux.

Both these approaches are best suited to a small number of users who don't require high Windows performance. For many users and high-performance, Insignia's NTrigue or Tektronix' WinDD may be better answers. Both are based on Citrix WinFrame, which is a version of Windows NT Server 3.51 licensed from Microsoft and adapted to allow true multi-user access. While WinFrame itself uses the proprietary ICA protocol to communicate with clients, NTrigue and WinDD support standard X Windows, allowing Unix users to log-in to a PC server and remotely run 32-bit Windows software natively on Intel hardware.

Thu, Oct. 20th, 2016 09:12 pm (UTC)
waistcoatmark

Wow. There are some names there that I've not heard of in a very long time...

Fri, Oct. 21st, 2016 11:18 am (UTC)
liam_on_linux

Yep. Very few of them are still around today, sadly.

It's interesting reading this now. I don't mention DESQview/X -- I guess it was already dead by then. I call Samba "public domain", which is embarrassing -- it shows how little I understood about Free software back then.

Incidentally, I'm guessing from the content that this is older than the dateline Computing has put on it. It doesn't mention NT4, which is surprising, but then again it doesn't explicitly specify NT 3.51 either, except in the context of WinFrame. When NT4 came out, I was still at PC Pro -- I wrote about it in the mag -- so a freelance piece like this must be from later.

There's no Windows 98, either. And no ssh!