Contrary to what many people might assume, Microsoft senior management never pressured the SQL Server development team not to develop a full 32-bit version for OS/2. One of the joys of working for Microsoft is that senior management empowers the people in charge of projects to make the decisions, and this decision was left with Ron Soukup.
In early 1992, however, the development team faced some uncertainty and external pressures. On one hand, the entire customer base was, by definition, using OS/2. Those customers made it quite clear that they wantedindeed expecteda 32-bit version of SQL Server for OS/2 2.0 as soon as IBM shipped 2.0, and they intended to remain on OS/2 in the foreseeable future. But when OS/2 2.0 would be available was unclear. IBM claimed that OS/2 2.0 would ship by the fall of 1992. Steve Ballmer, Microsoft senior vice president, made a well-known pledge that he'd eat a floppy disk if IBM shipped the product in 1992.
The SQL Server team was now under pressure to have a version of SQL Server running on Windows NT as soon as possible, with prerelease beta versions available when Windows NT was prereleased. The SQL Server team members knew that Windows NT was the future. It would be the high-end operating system solution from Microsoft, and from a developer's perspective, Windows NT would offer many technical advantages over OS/2, including asynchronous I/O, symmetric multiprocessing, and portability to reduced instruction set computing (RISC) architectures. They were champing at the bit to get started.
Although Microsoft had decided in 1991 to fall back to a 16-bit version of SQL Server, Microsoft's developers had continued to work on the 32-bit version. By March 1992, just after shipping version 4.2, they saw that both the 16-bit and 32-bit versions ran slower on the beta versions of OS/2 2.0 than the 16-bit version ran on Tiger (OS/2 1.3). Perhaps by the time OS/2 2.0 actually shipped, it might run faster. But then again, it might not the beta updates of OS/2 2.0 didn't give any indication that it was getting faster. In fact, it seemed to be getting slower and more unstable.
For a product with the scope of SQL Server, there's no such thing as a small release. There are big releases and bigger releases. Because resources are finite, the developers knew that working on a product geared toward OS/2 2.0 would slow down the progress of Windows NT development and could push back its release. Adding more developers wasn't a good solution. (As many in the industry have come to learn, adding more people is often the cause, and seldom the solution, to software development problems.) Furthermore, if Microsoft chose to develop simultaneously for both OS/2 2.0 and Windows NT, the developers would encounter another set of problems. They would have to add an abstraction layer to hide the differences in the operating systems, or they'd need substantial reengineering for both, or they'd simply take a lowest -common-denominator approach and not use services or features of either system fully.
So Microsoft developers decided to stop work on the 32-bit version of SQL Server for OS/2 2.0. Instead, they moved full-speed ahead in developing SQL Server for Windows NT, an operating system with an installed base of zero. They didn't constrain the architecture to achieve portability back to OS/2 or to any other operating system. They vigorously consumed whatever interfaces and services Windows NT exposed. Windows NT was the only horse, and the development team rode as hard as they could. Except for bug fixing and maintenance, development ceased for SQL Server for OS/2.
Microsoft began to inform customers that future versions, or a 32-bit version, for OS/2 2.0 would depend on the volume of customer demand and that the primary focus was now on Windows NT. Most customers seemed to understand and accept this position, but for customers who had committed their businesses to OS/2, this was understandably not the message that they wanted to hear.
At this time, Sybase was working on a new version of its product, to be named System 10. As was the case when they were working on version 4.2, the developers needed Microsoft SQL Server to be compatible with and have the same version number as the Sybase release on UNIX. OS/2 vs. Windows NT was foremost at Microsoft, but at Sybase, the success of System 10 was foremost.
Although System 10 wasn't even in beta yet, a schedule mismatch existed between the goal of getting a version of Microsoft SQL Server onto Windows NT as soon as possible and getting a version of System 10 onto Windows NT, OS/2 2.0, or both as soon as possible. The development team decided to compromise and specialize. Microsoft would port SQL Server version 4.2 for OS/2 to Windows NT, beginning immediately. Sybase would bring Windows NT into its umbrella of core operating systems for System 10. Windows NT would be among the first operating system platforms on which System 10 would be available. In addition, Microsoft would turn the OS/2 product back over to Sybase so those customers who wanted to stay with OS/2 could do so. Although Microsoft hoped to migrate most of the installed customer base to Windows NT, they knew that this could never be 100 percent. They were honestly pleased to offer those customers a way to continue with their OS/2 plans, via Sybase. The SQL Server development team truly didn't want them to feel abandoned .
This compromise and specialization of development made a lot of sense for both companies. The development team at Microsoft would be working from the stable and mature version 4.2 source code that they had become experts in. Bringing up the product on a brand new operating system was difficult enough, even without having to worry about the infant System 10 code line. And Sybase could concentrate on the new System 10 code line, without worrying about the inevitable problems of a prebeta operating system. Ultimately, System 10 and SQL Server for Windows NT would both ship, and the two companies would again move back to joint development. That was the plan, and both sides expected this to be the case in 1992.
The SQL Server team at Microsoft started racing at breakneck speed to build the first version of SQL Server for Windows NT. Time to market was, of course, a prime consideration. Within Microsoft, the team had committed to shipping within 90 days of the release of Windows NT; within the development group , they aimed for 30 days. But time to market wasn't the only, or even chief, goal. They wanted to build the best database server for Windows NT that they could. Because Windows NT was now SQL Server's only platform, the developers didn't need to be concerned about portability issues, and they didn't need to create an abstraction layer that would make all operating systems look alike. All they had to worry about was doing the best job possible with Windows NT. Windows NT was designed to be a portable operating system, and it would be available for many different machine architectures. SQL Server's portability layer would be Windows NT itself.
The development team tied SQL Server into management facilities provided by Windows NT, such as raising events to a common location, installing SQL Server as a Windows NT service, and exporting performance statistics to the Windows NT performance monitor. Because Windows NT allows applications to dynamically load code (using DLLs), an open interface was provided to allow SQL Server to be extended by developers who wanted to write their own DLLs.
This first version of Microsoft SQL Server for Windows NT was far more than a port of the 4.2 product for OS/2. Microsoft essentially rewrote the kernel of SQL Serverthe portion of the product that interacts with the operating system directly to the Win32 API.
Another goal of SQL Server for Windows NT was to make it easy to migrate current installations on OS/2 to the new version and operating system. The developers wanted all applications that were written to SQL Server version 4.2 for OS/2 to work unmodified against SQL Server for Windows NT. Because Windows NT could be dual- booted with MS-DOS or OS/2, they decided that SQL Server for Windows NT would directly read from and write to a database created for the OS/2 version. During an evaluation phase, for instance, a customer could work with the OS/2 version, reboot the same machine, work with the Windows NT version, and then go back to OS/2. Although it would be difficult to achieve, the developers wanted 100 percent compatibility.
The Windows NT-Only Strategy
Many have questioned the Windows NT-only strategy. But in 1992, the UNIX DBMS market was already overcrowded, so Microsoft developers felt they wouldn't bring anything unique to that market. They recognized that SQL Server couldn't even be in the running when UNIX was a customer's only solution. Microsoft's strategy was based on doing the best possible job for Windows NT, being the best product on Windows NT, and helping make Windows NT compelling to customers.
The decision to concentrate on only Windows NT has had far-reaching effects. To be portable to many operating systems, the Sybase code base had to take on or duplicate many operating system services. For example, because threads either didn't exist on many UNIX operating systems or the thread packages differed substantially, Sybase had essentially written its own thread package into SQL Server code. The Windows NT scheduling services, however, were all based on a thread as the schedulable unit. If multiprocessors were available to the system and an application had multiple runnable (not blocked) threads, the application automatically became a multiprocessor application. So the Microsoft SQL Server developers decided to use native Windows NT threads and not the Sybase threading engine.
The development team made similar choices for the use of asynchronous I/O, memory management, network protocol support, user authentication, and exception handling. (In Chapter 3, we'll look at the SQL Server architecture in depth and delve into more of these specifics. The point here is that the goals intrinsic to portability are in conflict with the goal to create the best possible implementation for a single operating system.)
The developers reworked SQL Server's internals and added many new management, networking, and extensibility features; however, they didn't add new external core database engine features that would compromise compatibility. For example, the developers ensured that there were no differences in the SQL dialect or capabilities of the Windows NT and OS/2 versions. The plan was for the future System 10 version to implement many new features. This release would be fundamentally a platform release. To emphasize compatibility with the OS/2-based 4.2 product and with the Sybase product line, Microsoft decided to call the first version of SQL Server for Windows NT version 4.2 . The product was referred to as simply Microsoft SQL Server for Windows NT and often internally as SQL NT , a designation that the press and many customers also were beginning to use.
In July 1992, Microsoft hosted a Windows NT developers' conference and distributed a prebeta version of Windows NT to attendees. Even though SQL Server didn't exist yet at a beta level, Microsoft immediately made available via CompuServe the 32-bit programming libraries that developers needed forporting their applications from OS/2 or 16-bit Windows to Windows NT. Just as they had enjoyed success back in 1990 by being among the first database products to provide the DLLs necessary for writing Windows 3.0-based applications, Microsoft sought to do the same with Windows NT.
Commitment to Customers
Incidentally, at approximately the same time, Microsoft also shipped a maintenance release for SQL Server for OS/2 (and they shipped another the following year). In porting to Windows NT, the development team found and fixed many bugs that were generic to all platforms. Even though they wouldn't create new SQL Server versions for OS/2, they really meant it when they said that they didn't want to abandon the OS/2 customers.
By March 1993, Microsoft went a step further and made a public beta release; anyone (even competitors ) could obtain a SQL Server Client/Server Development Kit (CSDK), the prerelease product, for a nominal charge that essentially covered expenses. Microsoft set up a public support forum on CompuServe and didn't demand that participants sign a nondisclosure agreement. It shipped more than 3000 CSDKs. By May 1993, the volume on the support forum for the prerelease product exceeded that for the shipping OS/2 product. The feedback was highly positive: Microsoft had a winner. The dream of an eventual "client/server for the masses" was being realized.
In July 1993, Microsoft shipped Windows NT 3.1. Within 30 days, achieving their internal goal, the SQL Server development team released the first version of Microsoft SQL Server for Windows NT to manufacturing. Customer and press reaction was terrific . SQL Server for Windows NT was listed in many publications as among the top and most important new products of 1993.
In October 1992, Microsoft shipped the first beta version of SQL Server for Windows NT. The product was essentially feature-complete, provided a full Win32 version of all components , and shipped to more than 100 beta sites. For a database server, having 100 beta sites was unprecedented, as the typical number of beta sites for such a product was approximately 10.