Microsoft had been developing SQL Server 4.2 for the forthcoming OS/2 2.0, the first 32-bit version of OS/2. Since SQL Server 4.2 was also planned to be 32-bit, porting the product from its UNIX lineage would be easier because memory segmentation issues wouldn't be a concern. In theory, the 32-bit SQL Server would also perform faster. Many articles comparing 32-bit and 16-bit performance issues appeared in the press, and everyone assumed the 32-bit environment would bring awesome performance gains (although few articles explained correctly why this might or might not be true).
The principal performance gain expected would be due to memory addressing. To address memory in the 16-bit segmented address space of OS/2 1. x , basically two instructions were required: one to load the correct segment, and one to load the memory address within that segment. With 32-bit addressing, the instruction to load the segment was unnecessary and memory could be addressed with one instruction, not two. Because addressing memory is so common, some quick calculations showed that the 32-bit version might yield an overall performance increase of perhaps 20 percent or more, if all other operations were of equal speed.
The 32-Bit Platform and Memory Gains
Many people mistakenly believed that SQL Server needed to be a fully 32-bit platform to address more than 16 MB of memory. Under OS/2 1. x , an application could access a maximum of 16 MB of real memory; however, an application could access more than 16 MB of virtual memory, but paging would result. In OS/2 2.0, an application could access more than 16 MB of real memory and avoid paging. This would allow SQL Server to have a larger cache, and getting data from memory rather than from disk always results in a huge performance gain. However, to the application, all memory in OS/2 is virtual memoryin versions 1 .x and 2.0. So even the 16-bit version of SQL Server would be able to take advantage of the ability of OS/2 2.0 to access larger real-memory spaces. A 32-bit version was unnecessary for this enhancement.
Unfortunately, the early beta versions of OS/2 2.0 were significantly slower than OS/2 1. x , more than offsetting the efficiency in addressing memory. So rather than a performance gain, users saw a significant loss of performance in running Microsoft SQL Server 1.1 and preliminary builds of the 32-bit SQL Server 4.2 on OS/2 2.0.
Suddenly, the plans for the release of OS/2 2.0 were suspect. Instead of being delivered by the end of 1991, it was unclear whether IBM could deliver version 2.0 at all. At any rate, it appeared doubtful that OS/2 would ship any sooner than the end of 1992. The decision became clearMicrosoft would move SQL Server back to a 16-bit implementation and target it for OS/2 1.3.
Reworking back to 16-bit would cost the Microsoft developers about three months, but they had little choice. In the meantime, another problem appeared. IBM shipped OS/2 1.3, but this version worked only for its brand of PCs. Theoretically, other computer manufacturers could license OS/2 from Microsoft and ship it as part of an OEM agreement. However, the demand for OS/2 had become so small that most OEMs didn't ship it; as a result, buying OS/2 for other PCs was difficult for customers. For the first time, despite the seeming incongruity, Microsoft produced a shrink-wrapped version of OS/2, version 1.3, code named Tiger . Tiger shipped in the box with Microsoft SQL Server and Microsoft LAN Manager, lessening the problem that the product was essentially targeted to a dead operating system.
Microsoft SQL Server version 4.2 entered beta testing in the fall of 1991, and in January 1992, Microsoft CEO Bill Gates (with Sybase's Bob Epstein sharing the stage) formally announced the product at a Microsoft SQL Server developers' conference in San Francisco. Version 4.2 truly had been a joint development between Microsoft and Sybase. The database engine was ported from the UNIX version 4.2 source code, with both Microsoft and Sybase engineers working on the port and fixing bugs . In addition, Microsoft produced the client interface libraries for MS-DOS, Windows, and OS/2, and for the first time it included a Windows GUI tool to simplify administration. Source code for the database engine was merged back at Sybase headquarters, with files exchanged via modem and magnetic tape.
Microsoft SQL Server version 4.2 shipped in March 1992. The reviews were good and customer feedback was positive. As it turned out, the source code for the database engine in this version was the last code that Microsoft received from Sybase (except for a few bug fixes exchanged from time to time).
After Microsoft SQL Server 4.2 shipped, the Big Question for 1992 was, "When will a 32-bit version of Microsoft SQL Server be available?" The issue of 32-bitness became an emotional one. Many people who were the most strident in their demands for it were unclear or confused about what the benefits would be. They assumed that it would automatically have a smaller footprint, run faster, address more memory, and generally be a much higher-performing platform. But the internal work with a 32-bit version for OS/2 2.0 had shown that this wouldn't necessarily be the case.