The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Windows Services for UNIX
How do you migrate your UNIX applications to x86 servers, and link your new applications to legacy systems, without causing an administrative nightmare? Windows Services for UNIX could be the answer, allowing you to run UNIX applications on Windows servers, and develop for both platforms from Visual Studio. Simon Bisson investigates.
Author: Simon Bisson
Last updated: Dec 2004
Servers based on Intel’s x86 architecture are a commodity: cheap to buy and cheap to run, they have become the life-blood of the data centre. Once a few high-end UNIX systems sat and ran your business; now they’re surrounded by humming racks of cheap x86 systems, and they’re coming to the end of their lives. So how do you migrate your existing applications to new servers, and at the same time link your new applications to your legacy systems, without causing disruption to your business processes? Compatibility File system support Performance Reality check
One option is to switch to an x86 variant of UNIX, such as Linux. However if you’ve already chosen Microsoft Windows as your main platform, that will mean bringing in new expertise, and another layer of system administration tools. Microsoft’s Services for UNIX (SFU) 3.5, which is available as a free download, is intended to give you the best of both worlds: a familiar set of UNIX tools so your existing UNIX staff can work with Windows servers with only minimal training; and tools to integrate Windows authentication and Windows file systems with your UNIX systems. Install SFU on a PC or x86-based server and you’ll find open source tools (including the Perl scripting language) and familiar UNIX utilities happily co-existing alongside Active Directory and the Windows interface.
A 223Mb download, SFU mixes several different tools. At the heart of SFU is the Interix subsystem, built on technology which Microsoft acquired in 1999 from Softway Systems and released as Microsoft Interix 2.2. This runs on top of the Windows kernel at the same level as the Win32 subsystem, and allows UNIX applications to run on Windows. An integral part of SFU since version 3.0, the Interix subsystem is now supported by more than 3,000 UNIX utilities and tools (including Windows services that behave like their UNIX equivalents).
SFU is a powerful tool for developers as well as system administrators. You can use it to take existing UNIX applications and quickly port them to Windows, using familiar Windows development tools. It comes with an SDK that supports more than 1,900 UNIX APIs, and developers can use familiar UNIX development tools, including the gcc and g++ compilers. While many businesses will see this as a tool for migrating from legacy hardware to a new platform with minimal pain and disruption, it’s also a valuable way of delivering in-house UNIX tools to partners and customers without forcing them to install UNIX servers.
Developers will also find that SFU integrates with Visual Studio, to the extent that new project types targeting SFU become available to Visual Studio when you install SFU. This approach means you can use a single source code tree for Windows and UNIX versions of your applications, with separate build scripts for each environment. A single project means less scope for bugs and inconsistencies, helping keep costs down.
So how compatible is SFU with both Windows and UNIX? First, and foremost, it’s a POSIX-compliant environment, which means that any code written to POSIX standards should compile and run under SFU. Windows users (and these days UNIX users as well) are used to window-based user interfaces, and so SFU includes an X11R6.6 emulation layer, helping migrate X-based applications to Windows quickly and with minimal changes. The latest 3.5 release of SFU builds on version 3’s Interix subsystem, adding more UNIX tools and improving both telnet and NFS support. Performance is also improved with support for Posix-compliant pthreads, and an SDK aids in application migration.
All this adds up to an environment where all you need to do to port code from UNIX to Windows is make some minor changes, perhaps changing library calls, and then recompile. SFU makes the migration process more like compiling for a different version of UNIX. Once you’ve got your application running through SFU, it’s then possible to begin to change it into a pure Windows application while your users carry on working the way they always have. The SFU SDK is an important tool, as it allows developers to work with over 1,900 UNIX APIs in Windows, as well as providing tools and scripts that ease the process of migrating C, C++ and FORTRAN code. There are even build and installer tools to help compile and deploy ported applications.
Other SFU features include extensions to Perl that allow direct manipulation of the Windows Registry. You can use this to edit registry keys on the fly, without forcing a reboot – a useful tool when tuning applications. You can also use SFU to add Windows Management Instrumentation to your UNIX applications, allowing you to use tools like Microsoft Operations Manager 2005 to control your ported applications, without writing extra management code.
Developers with existing UNIX experience will be able to work with familiar tools. The existing Windows command line tools are extended, with Korn and C shells as well as common UNIX utilities such as cron and awk, and the multi-purpose ‘at’ command for automating scripts and batch jobs. You’ll even find the familiar ‘man’ pages for the commands you’re using! Installing SFU means that you can work with vi and Word at the same time, or export reports from core business UNIX applications straight into Excel, all from the same desktop.
Migrating code from one platform to another isn’t the only reason for installing SFU on your desktops and servers. It’s common for Windows and UNIX to coexist in the same machine room, and you’re often going to need to connect the two operating systems together. You can use Samba to connect to CIFS mounts on Windows machines, but it’s not the most secure solution. An alternative is to use SFU to set up NFS (Network File System) mount points on your servers, or to connect desktop PCs to NFS shared resources on UNIX file servers.
SFU’s support for NFS is good, with a client that includes a local data cache to increase speed, and a server that exports CD drives and NTFS storage (you can’t use the NFS server to export FAT or FAT32 storage as it is closely linked to the NTFS security model). An NFS Gateway makes things easier for client PCs, exposing NFS mounts as standard Windows shares. This means you don’t need to install SFU on all your desktop PCs, and it allows older systems to access NFS files. SFU handles mappings between NFS and NTFS access and permissions, with command-line tools to set UNIX permissions on Windows files and directories.
You can even use SFU to turn on case-sensitive file and directory naming in Windows, making sure that exported Windows file systems are compatible with UNIX – and the mount command SFU adds to Windows is finally case sensitive in the latest release, making it easier to connect to UNIX resources. Volume Shadow Copy in Windows Server 2003 allows you to backup shared resources without affecting open files, so UNIX users’ files can be backed up while they’re still in use.
Sharing files and directories is an important part of interoperation, but while Windows’ Active Directory is based on the Kerberos protocols, the user attributes used by Windows differ significantly from the UNIX model. However SFU does allow Windows system administrators to work with UNIX users and permissions directly from Windows.
Firstly, SFU allows you to unify user and password management, integrating Active Directory, LDAP and NIS. You’ll find that you’ll be able to synchronise Active Directory with NIS servers, while SFU’s username mapping services map UNIX UIDs and GIDs to Windows SIDs (and vice versa). You can even combine several UNIX identities into a single Windows user – ideal if you’re using a single program to access data on multiple UNIX servers running in different administration domains. Like all good interoperability tools, SFU works two ways, so UNIX tools can be used to administer Windows (even using a Telnet server to give console mode access to your Windows servers).
Of course there’s one big question: performance. The Interix sub-system that’s at the heart of SFU runs at the same level as Win32, on top of Windows kernel. This means that SFU is a true Windows component, not another emulation layer or a virtual machine. While most SFU code should run as fast as equivalent Windows code, there can be slowdowns if you’re using network sockets, as UNIX implementations can be very different from Winsock. When migrating code to Windows it’s best to port to SFU first, before making changes.
Network performance isn’t the only downside with SFU. While there is support for X111R6 code, there’s no actual X Server. Other missing features include libraries and tools for database access, and familiar UNIX tools like emacs and the Apache web server. The Interop Systems website at http://www.interopsystems.com/tools is a useful resource here as it provides access to more than 60 extra UNIX tools that have been compiled for use with SFU. These include Desktop-X (an X Windows display utility for SFU). Open Source ODBC driver managers and the FreeTDS tool for working with Sybase and SQL Server, bash (a Bourne shell), openSSH, pkg-config, Tcl/Tk, emacs and the Apache Web server.
SFU can help with complex migrations. The last 15 years have seen five or six different developers working on Star-Track, a vehicle tracking system for Group 4 Securitas. Never intended to be cross-platform, the application was developed for Solaris, though in 1996 Dr Adrian Bowen, the Systems Development Manager, ported it to RedHat Linux, a process he remembers as being “mostly painless”.
Scalability concerns forced a rethink of the system design, and in order to fit in with corporate IT policies the development team decided to port the application to Windows using SFU, rather than completely rewriting the application. Dr Bowen found that the source code for the Star-Track application ported and compiled to SFU without any major work. “It was the same amount of work as when I’d moved it from Solaris to Linux. It looks like a variant of Linux.” Dealing with the obsolete XView windows console used by the application was a little trickier, but it still took less than a week. The dynamic linking and loading support in SFU 3.5 meant the team could move the user interface to a Tk toolkit. Dr Bowen just downloaded it, ran the make files and then ran the code on SFU.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
