X
Business

Microsoft moves to coexist with UNIX

Three recent product releases that illustrate the trend toward UNIX.
Written by Tim Landgrave, Contributor
No, Microsoft isn’t replacing Windows XP with UNIX as its core server operating system. But some product announcements from Redmond over the last few months do indicate a new willingness to not only admit the existence of UNIX, but also to recognize its success in the enterprise.

I'll take a look at three recent product releases that illustrate the trend toward UNIX.

Coexisting with UNIX machines
Since the release of Windows NT, Microsoft has had a limited set of tools that allowed it to coexist in a UNIX environment. With earlier releases (3.x), Microsoft was content to allow NT servers and clients to use UNIX resources, such as LPR for printers. Starting with version 4.0, however, Microsoft released a product called “Services for UNIX” that let NT replace UNIX servers by providing emulation of key UNIX protocols (e.g., NFS). But last year, Microsoft introduced version 2 of Services for UNIX for Windows 2000 and Windows NT 4.0, and with that came a dramatic change in Microsoft’s attitude toward UNIX in the enterprise.

The new release provided tools that encouraged coexistence for shops required to run both operating systems. These tools included the following:

  • A gateway for NFS, allowing Windows clients to connect to UNIX NFS data (without installing any client-side code) by leveraging the familiar desktop networking interface
  • Two-way password synchronization, making it easier for users to maintain one password for both Windows and UNIX
  • A user-name mapping server that associates Windows and UNIX user names, allowing users to connect to NFS resources without having to log on to UNIX systems separately

This is only a sample of the new features that helped make 2000 a much more UNIX-enterprise-friendly product. They are also features one would expect a modern server vendor to offer in order to “play well with UNIX.” The features are based on published standards and could be implemented without changing the way the underlying server operates.

The Mac attack
The effort to make a real Macintosh product (and not a silly port of the Windows interface, like prior versions) required Microsoft to participate in a much more strategic and substantial engagement. I find it interesting that Microsoft chose to wait until the Macintosh OS was based on UNIX before it undertook such a massive porting project.

The wait certainly makes sense from the Office product perspective. Why port to an operating system (Mac OS) where you already have 95 percent market share and only a small potential upside market when you can port to an audience (UNIX) with which you have 0 percent market share—clearly a huge upside.

With this release, Microsoft optimized Office to run not only on the UNIX-based OS X operating system but also to take advantage of the Macintosh’s unique interface. This is a big admission on Microsoft’s part that other GUIs have merit By taking advantage of the Macintosh OS/X design team’s expertise, Microsoft was able to create a richer graphical experience for Macintosh users.

Microsoft also made an interesting investment in its collaboration client. Rather than foisting the fat Outlook client on Macintosh users, Microsoft developed a new, clean, slick, usable product called Entourage. Entourage still connects to Exchange 2000 and Hotmail, but it also connects to other mail systems. Microsoft finally has a truly elegant, UNIX-based e-mail client and productivity product. Of course, neither is available on UNIX platforms other than OS/X, but it has created a huge potential market for Apple. Just like he did in the early 80s, Steve Jobs has another chance to recognize that Apple can be an operating-systems provider rather than simply a hardware company. By moving the GUI framework from OS/X to other UNIX variants (Sun, Linux, FreeBSD), Apple could become a client middleware provider. It will be interesting to see what decision Jobs makes this time.

Microsoft SQL Server for Java
As significant as Microsoft’s Office investment in UNIX is, the investment in opening up SQL Server to the UNIX community is 10 times more important—especially when you consider that this comes at the same time as Microsoft’s big .NET development push. So how is Microsoft doing this? In late January, Microsoft rolled out beta 2 of its level 4 JDBC Drivers for SQL Server 2000.

With this software installed, any Java client can access SQL Server data and stored procedures from its native platform. The fact that Microsoft elected to implement the drivers as level 4 drivers is even more significant, since the level 4 specification requires that all client-side code be contained in Java-only code files (JAR) without requiring external system drivers.

To a certain extent, this is a reaction to market reality. As long as Microsoft refused to legitimize the use of SQL Server as a JDBC data source, it ceded the Java database market to IBM DB2, Oracle, and the handful of mom-and-pop outfits creating their own customer drivers (see http://www.inetsoftware.de/English). But on a higher level, it’s an admission from the SQL Server team that the Java/EJB development paradigm will be around for a long time and that unless companies at least have the option of using Microsoft database technology, Microsoft is guaranteed of losing out on a significant amount of market share to competing database technologies.

Community response
Technically, the product is being well received in the beta forums. One company is developing a system featuring Microsoft JDBC with an Apache Web server and the TomCat application server. Another is replacing a back-end AS/400 DB2 database being accessed via an IBM WebSphere application with a back-end SQL Server 2000 Database using the JDBC technology. These are exactly the kinds of scenarios that Microsoft hopes for (i.e., that companies can use Microsoft technology in places where it would have been impossible before).

If you analyze these trends on a macro level, they say something much different about Microsoft. No matter how much Java and non-MS platform bashing you may hear coming down from the top at Microsoft, all its product teams recognize the need to not only coexist with competing technologies, but, where possible, use their intellectual property assets to enhance a company’s experience when they use Microsoft products as part of a solution.

The recognition that Microsoft doesn’t have to “rip and replace” enterprise systems in order to be successful will go a long way toward increasing the acceptance of Microsoft technology in the enterprise. Microsoft is beginning to understand what most of us have known for years.

Editorial standards