Migrating UNIX Applications to Windows via Microsoft Services for UNIX
Microsoft Windows, with its robust architecture, ability to utilize commodity Intel servers, and suite of migration and interoperability tools, is a compelling choice for those enterprises looking to migrate UNIX applications to a modern and cost-effective platform. This paper covers the business reasons for migrating UNIX applications to Microsoft Windows and discusses some of the specific features and technologies that facilitate that migration. The interoperability features of Microsoft Services for UNIX (SFU) make the overall migration easier, and Microsoft Windows Server 2003 and SFU together provide an excellent migration target platform.
On This Page
UNIX may have been the default application platform for many enterprises in the past. However, two factors have combined to force businesses to consider alternatives—the ever increasing power of Intel-based servers and their dramatically lower costs compared to proprietary Reduced Instruction Set Computing (RISC)-based UNIX servers.
The power of individual Intel architecture CPUs has continued to grow, following and even outpacing Moore’s Law. With the addition of hyper-threaded processors and the availability of symmetrical multi-processor (SMP) servers and the operating system to take advantage of them, it’s easy to see that Intel-based servers have the horsepower to run business critical applications.
Historically, Intel-based servers have been considerably less expensive than UNIX (RISC) servers. Although still the case, with the increased power of current Intel processors, the high volume Intel-based servers are an attractive choice for businesses when compared to the low volume, proprietary RISC offerings of UNIX vendors.
At first glance, the cost savings of an Intel-platform is seemingly offset by the potential costs of migrating UNIX applications to an Intel-based platform. However, it isn’t the platform that provides the functionality needed to run a business—it’s the applications that are built on the platform. If the first step to adopting a lower-cost server alternative is a complex and costly migration of all of their applications, many businesses might be unwilling to embark on this type of change.
Some companies see Linux as a way to minimize this cost. Their reasoning is that Linux is a type of UNIX, so the migration process should be straightforward and simple. However, although Linux and UNIX share many commands, Linux and UNIX are not the same. For that matter, not all Linux distributions and not all UNIX products are the same. The reality is that migrating UNIX applications involves significant effort.
Microsoft has a packaged solution specifically designed to help organizations attempting to migrating UNIX applications. This solution includes Windows Server 2003, Microsoft Services for UNIX (SFU), and a set of tools and services, which, when combined, actually make the migration process to Windows easier than a migration to Linux. This paper explores the issues involved with migrating UNIX applications either to Linux or to Windows Server 2003 with SFU.
Services for UNIX
Windows Server 2003 provides many services that interoperate well with UNIX systems, including a Telnet client and server, lpr and lpd print services allowing cross platform printing, and the basic connectivity and file moving resources of TCP/IP. However, for complete interoperability and a robust and feature-rich migration platform, the addition of SFU provides all the features and tools to simplify the migration of your UNIX LOB application.
SFU provides a single comprehensive package to meet the interoperability requirements described above and implements the following features:
File sharing between UNIX and Windows by using Network File System (NFS). SFU provides:
Client for NFS
Server for NFS
Gateway for NFS
Remote command-line access between Windows and UNIX. SFU provides:
Comprehensive cross-platform scripting abilities. SFU provides a consistent implementation of:
More than 350 commonly used UNIX commands and utilities
Common network administration by providing Network Information System (NIS) server functionality using the Microsoft Windows Server 2003 Active Directory™ service
Password synchronization between Windows and UNIX
Installation using Microsoft Windows Installer
Administration of Services for UNIX components and services by using the Microsoft Management Console (MMC).
Management of SFU components by using Windows Management Instrumentation (WMI)
In addition to these features, SFU can be installed on Windows 2000, Windows XP, or Windows Server 2003-based computers and can interoperate with a variety of UNIX-based computers. SFU 3.0 also supports Microsoft Windows NT 4.0 SP6a and earlier versions of UNIX for password synchronization. Source code for the UNIX PAM/SSOD components of password synchronization is supplied, as are precompiled binaries for Solaris 7 or 8, HP-UX 11i, Red Hat Linux 8.0, and IBM AIX 5L 5.2.
The single biggest concern for most organizations as they consider a RISC/UNIX to Intel migration is that their applications, currently hosted on UNIX server, might not run in the new environment and need extensive rewriting or replacement. This process can be expensive, both in terms of actual cost and the risk the migration presents because changing core applications can significantly change the way the entire organization operates. Additionally, most organizations have substantial investments in UNIX management scripts and training that they can ill afford to lose.
There are three broad areas of concern when considering this type of migration:
Application migration, which is the actual transfer of applications
Resource migration, which moves the supporting resources, including files, accounts, and databases
Skills migration, which can require your entire staff to gain a new type of expertise to support the new environment
The default assumption is that Linux will easily meet these three concerns, but that assumption is actually not justified. Applications and skills migration both run into subtle but pervasive differences between the various UNIX and Linux variants. Specifically, the differences in libraries available and exactly how they are implemented will require modifications to many applications, while the differences in utilities, tools, and shells will require significant adjustment for administrators, developers, and users. Resource migration from UNIX to Linux should be fairly painless, though, by using the NFS file system and many of the same configuration files. However, Red Hat and some other versions of Linux do not handle or set up their groups in the same way as most UNIX versions but instead create a separate group for each user, with the same group name as the username. Applications that expect to take advantage of group permissions and membership will need to have either the application or the underlying environment modified.
SFU provides an excellent migration solution that addresses all three of these concerns. It provides a high performance environment that makes porting applications and scripts easy and comfortable to the UNIX developer or systems administrator. SFU includes a rich set of more than 1,900 UNIX APIs that work exactly as they do in UNIX. It also includes a complete UNIX environment with hundreds of UNIX applications and both Korn and C shells so that organizations can easily port their custom applications and scripts to the Windows environment with little or no change. There is no loss of investment in skills and scripts because the same skills and scripts can be used in the Windows environment.
For example, LBM Systems, LLC used SFU to port its UniQue and ClusterQue output management applications to Windows. As Steven Bardwell, president of LBM, explained, “The port to Interix was really quite easy. Certainly no harder or more time consuming than porting to any other UNIX.“ For more details from the LBM Systems case study, see: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=51457.
With SFU, the actual migration of a UNIX application, whether pure character, curses, or X Window-based, is often the easiest and least risky part of the whole migration process. This technology operates at the kernel level as a full Windows subsystem and includes accompanying utilities to provide an environment that both feels like and operates like any other UNIX system. It offers a single rooted file system and full support for case-sensitive filenames, job control, compilation tools, shell scripts, and more than 300 UNIX commands and utilities. Because this subsystem is part of the Windows kernel, it offers true UNIX functionality without emulation or performance degradation. Its single rooted file system masks the Windows volume-based ("C:", "D:”, etc.) file system from the UNIX environment and allows utilities and configuration files to reside in the same location a UNIX user or systems administrator would expect to find them.
As applications are migrated from UNIX, the file system, print, and account resources that support the applications also need to migrate. Attempting to migrate both applications and resources at the same time substantially increases the risk of the migration and makes troubleshooting problems that much more difficult.
Red Hat and other Linux variants provide a good set of interoperability tools, including both client and server for NFS, and support for NIS for account management. Because of the differences in how groups are set up on Red Hat, administrators will likely need to modify the underlying account assumptions to create more generic groups, but this step isn’t significant when moving to a fresh Linux environment.
SFU also provides a full set of interoperability tools, including NFS client and server products and full support for NIS. These tools greatly simplify the migration and allow the developer and systems administrator the ability to do a staged migration. Developers can either migrate the actual application, while leaving the files and data it depends on hosted on UNIX, or move the data and file resources first and migrate the actual application after. SFU provides the interoperability tools to put the developer and systems administrator in control of the migration timeline and process without having to worry about the location of resources.
An often overlooked but important concern in any migration plan is the migration of skills. UNIX developers’, users’, and systems administrators’ knowledge and skills represent substantial investments for an enterprise. The assumption is that Red Hat and other Linux variants, being similar to UNIX, will provide a seamless migration of skills, but this isn’t strictly true. There are significant differences in both supported command options and output among the many utilities and tools that make up the environment. Also, the Linux bash shell, while providing many similarities to the UNIX Korn shell, lacks some of the features of Korn shell, and scripts will often not migrate without significant modification. By providing a complete UNIX environment on Windows, the Interix technology in SFU allows these skills to migrate as well, maintaining the value to the enterprise while greatly reducing the learning curve for new skills.
SFU uses the same configuration files and administrative utilities the UNIX administrator expects, including inetd.conf and resolv.conf and also where she or he expects to find them—in the /etc directory. This capability enables an easy and low-risk transition while maximizing the skills migration. The UNIX administrator doesn’t need extensive retraining—with familiar tools and a familiar environment, the transition is similar to moving from one UNIX to another. And with files in familiar locations, changes to scripts and code are minimized, reducing the overall risk of the migration. These capabilities can make porting a UNIX application to Windows actually easier than porting the same application to Linux, where both the tools and the environment have subtle but important differences.
The following components of the UNIX environment are widely used by administrators and developers.
Red Hat and other Linux variants provide the bash shell as the predominant shell, with a C shell (tcsh) available as well. The bash shell is a flexible and powerful shell that is backwards compatible with the basic UNIX Bourne shell (/bin/sh) while sharing many of the features and improvements of the Korn shell. Scripts written to take advantage of the Korn (/bin/ksh) shell’s features may need some modification, and the command line behavior of bash is not identical to ksh. The public domain version of the Korn shell (pdksh) is available for Red Hat Linux but isn’t used by default.
SFU includes the pdksh shell, /bin/ksh, a POSIX.2-conforming shell, and the tcsh implementation of the C shell as /bin/tcsh (and /bin/csh as a symbolic link). SFU doesn’t provide a pure Bourne shell but instead uses a symbolic link to /bin/ksh to provide for scripts that expect to find /bin/sh. With pdksh providing a very high degree of backward compatibility for Bourne shell scripts, any scripts written for Bourne shell should require little, if any, modification. For SFU users who want the bash shell, it is available for download from Interop Systems (http://www.interopsystems.com/tools).
The C shell, while not primarily a scripting environment, has long been a favorite of many interactive users and administrators, and both Red Hat Linux and SFU provide /bin/tcsh for those users.
Most UNIX applications, and virtually all UNIX scripts, both expect and take advantage of the rich command line environment available in UNIX. Although Red Hat and other Linux variants provide many of these same tools, the different Linux versions each have a slightly different mix. Many of the tools support slightly different command line options and can have subtle differences in the final output, causing problems for programs and scripts expecting a particular result. In many cases, the design goal for the particular utility was less concerned with backwards compatibility to UNIX than with providing additional flexibility and options.
SFU, on the other hand, had a design goal of providing complete compatibility with UNIX and includes more than 300 native UNIX utilities to provide the user, administrator, or developer the tools they expect. These UNIX utilities are full, native UNIX applications that behave exactly as a UNIX user would expect and include everything from tar and cpio to awk, sed, and tr.
Applications, scripts, and interactive shell users will find these utilities in the locations they expect to find them. This standard UNIX environment greatly simplifies migration, because organizations can take advantage of their existing investment in training and skills and also re-use scripts and custom applications without huge porting costs.
Telnet and r-utilities
Current Red Hat and other Linux variants generally provide a Telnet server and client, as well as a full set of r-utilities, though some earlier versions of Red Hat excluded Telnet. SFU includes Win32-and Interix-based Telnet servers and clients, as well as full support for the “r-utilities,” providing for full compatibility and cross-platform maintenance and scripting capabilities. The Win32 Telnet server allows full connectivity and limits the number of sessions only by the number of licensed connections allowed to the server. The Interix telnetd daemon provides full UNIX compatibility and uses the /bin/ksh or /bin/tcsh as its default shell, giving UNIX users a familiar and comfortable look and feel that supports standard UNIX scripts.
SFU support for the UNIX r-utilities includes remote copy (rcp), both client and server for remote distribution (rdist and rdistd), remote login (rlogin), and remote shell (rsh). Although some organizations may choose not to use these tools in their environment, or strictly limit them for security reasons, they can provide a simple and effective cross-platform tool. For these organizations, either the commercial SSH from F-Secure, or the Open Source version, OpenSSH, can be used. OpenSSH is also available for download from Interop Systems.
Both Linux and SFU have available a wide variety of third-party and Open Source utilities, shells, and tools and both provide the ability to easily compile available Open Source programs. For SFU, the best source for pre-compiled Open Source utilities is the Tool Warehouse at Interop Systems (http://www.interopsystems.com/tools/warehouse.htm). Interop Systems provides a warehouse of precompiled tools and community forums where developers can discuss migration issues.
If you are planning to migrate your UNIX applications to Windows, you can benefit from the expertise of developers who have already performed this migration. Microsoft has provided a great deal of material to help you port UNIX applications to the Windows environment, from assessing the need for migration to a complete migration guide that will walk you through the specific steps you will need to follow for a successful migration.
You can find a detailed discussion of UNIX ANSI C/C++/Fortran code migration patterns and practices at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp.
Windows Server 2003 with SFU versus Linux
Windows Server 2003 with SFU provides a complete UNIX development and deployment environment, including Korn and C shells, more than 300 UNIX utilities, and more than 1900 UNIX APIs, along with complete interoperability tools. Red Hat and other Linux variants depend primarily on the bash shell, though versions of the Korn and C shells are available. Additionally, while the various versions of Linux provide similar APIs and utilities to those of UNIX, they are not exact matches and can require significant porting effort. Also, porting to Linux is not a single target. Although several of the Linux vendors are attempting to reach a common porting goal, this effort doesn’t include all vendors and is still in its early days, meaning that any port to a specific Linux distribution can require additional work to support other distributions.
The different distributions of Linux are not an anomaly—UNIX itself evolved into discrete versions supported by different vendors. In order to fulfill the portability promise of UNIX, the POSIX standard was created. UNIX variants could support the POSIX standard, which meant that they would support applications that were also written to that standard. SFU is substantially POSIX-compliant. If your LOB applications were written to take advantage of this portable standard, you will reap the benefits of that effort as you migrate to Windows—but not if you migrate to Linux, which is not yet POSIX compliant.
The biggest difference between the two platforms comes in a comparison of the added value each provides. Once you port to Linux, you still don’t have access to the rich resources of the Windows environment. With a port to Linux, you have merely moved from one underlying platform to another. A move to the Windows environment brings a significant amount of added value, from coordination with your desktop environment to a wealth of new applications to the Web Services capabilities of the .NET framework. Finally, Microsoft provides a much greater level of support for Windows than Linux vendors do for their distribution, from online communities to vendor phone support to the migration guide mentioned above.
Interoperability with Windows and UNIX
Even if you decide to migrate some or all of your key applications, you might need to support an environment with both Windows servers and UNIX servers, either for a brief migration period or a longer period of dual platforms. SFU provides the interoperability tools to reduce the burden and risk of supporting both environments. Migrating to Red Hat or one of the other Linux variants provides many of the same challenges as migrating to Windows, plus you’ll likely need to support three operating environments during the migration because Windows is likely to be at least part of the environment.
Red Hat and the other Linux variants rely primarily on SAMBA to provide interoperability with Windows clients and servers. SAMBA uses the Server Message Block (SMB) protocol that is native to Windows networking to provide file system interoperability with Windows clients and servers. SAMBA, however, lags behind Windows Server 2003 in compatibility with Active Directory and Volume Shadow Copy, limiting its usefulness in environments that take advantage of the advanced features available in Windows Server 2003.
Windows Server 2003 with SFU provides a complete and extensible interoperability environment with tools to allow UNIX and Windows to peacefully coexist and share resources. Included are tools for file system interoperability, such as Client for NFS, Server for NFS, and Gateway for NFS, to provide full file system interoperability across the network. SFU further provides tools for authentication and account interoperability, including Server for NIS, User Name Mapping (UNM), and two-way password synchronization. Also included are Print Services for UNIX (part of the base Windows Server 2003 operating system) to provide printing compatibility and tools for administration and script compatibility, such as Telnet, Perl, and the Korn and C shells.
Network File System
NFS has been the standard on UNIX for years, providing a simple and effective way to share file systems across the network. SFU includes both an NFS client and server for full interoperability with UNIX systems. Gateway for NFS is also a part of SFU and provides access to NFS resources on the network to all Windows computers on the network without adding additional software on the downstream Windows computers.
The Client for NFS module in SFU provides a flexible and compatible NFS client that makes accessing the file system resources stored on legacy UNIX servers easy and practically seamless to the Windows user. The Client for NFS is completely integrated into the Windows Explorer interface and includes full command line support that lets users access files stored on UNIX servers transparently. The command line support gives the systems administrator the flexibility to easily script across platform boundaries by using either Windows or UNIX syntax from the command line.
The Server for NFS module in SFU provides full support for both UDP and TCP connections and supports NFS 2 and NFS 3 for full compatibility to a wide variety of UNIX clients. Users on UNIX systems can have full access to file systems on Windows servers transparently, greatly facilitating the transition and migration of applications.
The Gateway for NFS module in SFU provides a mechanism that permits full access to UNIX file system resources to downstream Windows clients without requiring the purchase or installation of additional software on the Windows clients. NFS resources are mapped to drive letters on the Gateway computer and then shared back to Windows clients by using standard Windows SMB shares. Although power users might prefer a locally installed Client for NFS, using Gateway for NFS can greatly simplify migration and interoperability issues during the transition period by ensuring continued access for all users with a minimum amount of configuration changes.
Note: Gateway for NFS can be installed only on server level products, and it can’t be installed on the same server as Client for NFS—the two are mutually exclusive. However, Gateway for NFS incorporates client access to UNIX NFS resources for the server where Gateway for NFS is installed.
Windows developers are familiar with the APIs that are a part of the Windows development environment, while UNIX developers are used to the UNIX APIs, including APIs that are often specific to a particular version of UNIX. SFU includes both the Interix Software Development Kit (SDK) and the gnu SDK, giving developers access to more than 1,900 UNIX APIs that are part of the Interix SDK while supporting both the Microsoft Visual C++ compiler for C programs and the gnu compilers and development tools, including gcc, g++, and gdb. Native Windows developers can use the IDE and compiler they are more familiar with, while UNIX developers have the range of gnu compilers and tools to choose from, including the gnu debugger, gdb.
In addition, the broad range of Open Source tools and utilities are either already ported and available (via Interop Systems) or can be ported to SFU, giving developers the environment and tools of their choice. Microsoft’s partnership with Interop Systems (http://www.interopsystems.com) also provides new and updated libraries and API’s for the SFU environment.
Two-way password synchronization is included with SFU. This mechanism allows users to change their passwords for both UNIX and Windows from either environment, greatly simplifying interoperability during a UNIX to Windows migration.
SFU supports NIS for user authentication and its own UNM service, as well as providing a PCNFS server to support other applications that require it. UNM can use either its own Active Directory-based NIS or an existing UNIX-based NIS for authentication—or it can use PCNFS-type files.
There are a number of issues involved with porting a UNIX application to either Red Hat or one of the other Linux variants—or to the Windows environment. These include the migration of user accounts, the migration of the actual application, and migration of the supporting data and resources for the application.
Moving your applications is only part of a complete solution. You also need to move your user community and the security scheme for your applications.
NIS is used across a wide variety of UNIX platforms to provide a single networked authentication and sign-on mechanism. SFU supports NIS as the authentication mechanism for NFS access and provides a full Server for NIS that allows UNIX systems administrators to move their master NIS database to Active Directory and migrate their existing UNIX accounts to Windows. Red Hat and other Linux variants support OpenLDAP, but this doesn’t provide for full single sign on and requires additional administration that is not integrated with the rest of the Red Hat administration. Additionally, as most enterprises include Windows users, the lack of Active Directory support in Red Hat limits options.
UNIX, Linux, and Windows accounts are inherently different and use different authentication mechanisms. This difference can cause significant and often subtle problems during the migration phase when users, developers, and administrators need access to resources on both UNIX and Windows servers. Even when accounts are carefully created to have identical logons, they are still different—user jdoe on a UNIX machine is not the same as user DOMAIN\jdoe in Windows. To facilitate the transition and migration, SFU includes the UNM service, as mentioned in the previous section. UNM provides a mechanism to map UNIX accounts to Windows accounts and Windows accounts to UNIX accounts, even when the accounts have different logons. This capability greatly simplifies account maintenance during the transition period of a UNIX to Windows migration, allowing users full access based on the appropriate set of credentials. Only a single UNM server needs to be established and maintained in the domain, simplifying maintenance and setup issues.
Unlike Red Hat and other Linux distributions, which are not yet fully POSIX compliant, SFU contains a POSIX.1-conformant subsystem that includes support for both the full POSIX specification but also supports additional extensions and features, including sockets, Berkeley Software Distribution (BSD) 4.4 interfaces, System V interprocess communication (IPC) mechanisms, pseudo terminals, and memory mapped files that are not part of the POSIX.1 standard.
Both applications that are written to conform to the pure POSIX.1 specification, and those that use some combination of conditional compilation (#ifdef preprocessor commands) or wrapper functions to deal with possible alternatives, can be ported without modification to the SFU’s subsystem. Porting software to the SFU subsystem involves:
Making the source as portable as possible. If you’ve written a pure POSIX application, it should simply re-compile under Interix, but few applications are pure POSIX applications. Understanding where your application differs from POSIX, and using the guidelines for migration provided, can help your migration go smoothly.
Using the extensions to POSIX that are supported. While SFU supports POSIX, it also supports common extensions and APIs taken from other standards, including the Single UNIX Specification and extensions taken from traditional UNIX systems, such as BSD or System V derivatives.
Addressing issues specific to SFU’s subsystem, using the UNIX Application Migration Guide at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp.
SFU supports a number of extensions beyond the strict POSIX.1 standard, including the XPG4.2 spec. To take full advantage of these extensions, you need to use a #define _ALL_SOURCE 1 at the beginning of your code before any header files are included with a #include statement. Otherwise, the more restrictive _POSIX_SOURCE will be used.
The extensions that are included with the Interix SDK include:
Memory mapped files
System V IPC mechanisms, such as shared memory, message queues, and semaphores
Berkeley style sockets
BSD string and memory functions, such as bcopy() and strncasecmp() that are part of the Single UNIX Specification, as well as the BSD 4.4 strsep() and strcasestri()
Curses and terminal routines from the ncurses package and termcap routines
Pseudo terminals—both BSD and System V methods are supported
There are some code practices that can cause more problems on SFU’s subsystem as compared to traditional UNIX. Specifically, dereferencing an uninitialized pointer can often be unnoticed in a traditional UNIX system but will result in a segmentation fault in SFU. Even when unnoticed this practice leads to subtle problems, and for this reason such dereferencing is considered bad coding and is not advisable for your application. While this may mean some work during the initial port, the resulting application will be more robust.
The security system used in Windows can be stricter than those on traditional UNIX systems. The concept of a user identifier (UID)/group identifier (GID) pair, defined in the /etc/passwd and /etc/group files, is replaced by a single security identifier (SID) that includes a unique domain-name/logon-name pair and domain-name/group-name pair that are both part of a single namespace. As there are no /etc/passwd or /etc/group files, developers need to handle struct passwd differently. For instance, the getpwnam() and getgrnam() calls accept domainname+username pair instead of username or group name only, and pw_gecos is populated with text taken from the Description field in the Windows user account.
The Interix SDK includes X11 libraries, header files, and various tools for building X Windows applications. However, SFU does not include an X Windows server, which means that X Windows applications that need to be displayed on the local workstation will need an X Windows server installed. There are a number of excellent X Windows server products available, including a version specifically written for Interix—Interop X Server 8.0 for SFU/Interix from Interop Systems.
Most code written for X Windows assumes a directory structure of /usr/X11, but Interix uses a version specific directory structure, /usr/X11Rn, where n is replaced with the release level of X11. This difference is best handled by creating a symbolic link to point to the new directory and doesn’t require any code changes in applications. Version 3.0 of SFU only included X11R5, but X11R6.6 is shipping natively in the 3.5 version of Services for UNIX (to be released January 2004) and is already available for download from the Interop Systems Tool Warehouse at http://www.interopsystems.com/tools/warehouse.htm for those applications that require a later version of X11 than that originally shipped with SFU 3.0.
For character mode applications that use curses, the Interix SDK includes the ncurses implementation of curses written by Eric S. Raymond and Zeyd M. Ben-Halim. This highly compatible and robust implementation of curses is detailed, along with full documentation about writing curses applications and the specifics of the ncurses implementation, in the SFU Help application.
Intel-based systems have now reached the performance levels required for business applications. This factor, combined with the low cost of these systems, is causing companies to look at migrating applications to an Intel-based platform.
While Red Hat or other Linux variants might seem like a natural migration target for UNIX applications moving to Intel-based platforms, this option is not without costs and issues:
A lack of integration of applications and management, increasing the overall costs of developing and maintaining Linux applications
No single source for comprehensive support
Broad hardware support, but the quality of drivers is uneven and there is no certification or verification of drivers
Microsoft Windows Server 2003 with SFU provides the tools and environment that can support native UNIX applications with less conversion effort than is required with Linux. In addition, porting to Windows Server 2003 provides a wealth of post-migration opportunities to extend your applications to take advantage of the features of the Windows Server 2003 environment, including the .NET Framework and the Microsoft applications stack. Microsoft Windows Server 2003 with SFU is the ideal operating system platform to host applications from the legacy UNIX environment.
The Windows Server System offers many powerful benefits as a migration target, including the following:
An integrated solution, with consistent applications, servers, client and platform management
Powerful centralized management capabilities through MMC, its extensible snap-in architecture, and the Group Policy distribution system
The largest support organization and community in the world, backed up by extensive testing, development, and verification services and a single point of failure and resolution for the majority of problems
A robust and extensible platform, with sophisticated development tools, a wide range of available applications, and an easy path to Web services through the .NET architecture
See the following resources for further information:
Microsoft Windows Services for UNIX home page at http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx
UNIX Tools Community at http://www.interopsystems.com/tools/
Porting Applications in C at http://www.microsoft.com/technet/interopmigration/unix/sfu/portappc.mspx
UNIX Application Migration Guide:
UNIX Migration Resource Center at: http://www.migrationforunix.com/