Microsoft's development role for SQL Server 1.0 was quite limited. As a small porting team at Sybase moved its DataServer engine to OS/2 and moved the DB-Library client interfaces to MS-DOS and OS/2, Microsoft provided testing and project management. Microsoft also developed some add-on tools to help make the product easy to install and administer.
Although a number of sites were running OS/2 as an application server with SQL Server or as a file server with LAN Manager, few were using OS/2 for their desktop platforms. Before Windows 3.0, most desktops remained MS-DOS-based, with its well-known limit of 640 KB of addressable real memory. After loading MS-DOS, a network redirector, network card device drivers, and the DB-Library static link libraries that shipped with SQL Server version 1.0, developers trying to write a SQL Server application were lucky to get 50 KB for their own use.
For SQL Server 1.1, rather than ship the DB-Library interface that Sybase had ported from UNIX to MS-DOS, Microsoft wrote its own, from scratch. Instead of 50 KB, developers could get up to 250 KB to write their applications. Although small by today's standards, 250 KB was a huge improvement.
The same source code used for DB-Library for MS-DOS also produced the Windows and OS/2 DB-Library interfaces. But the MS-DOS RAM cram is what motivated Microsoft to write a new implementation from scratch. The widespread adoption of Windows 3.0 quickly eliminated the MS-DOS memory issuebut this issue was a real problem in 1989 and 1990.
With SQL Server 1.1, Microsoft provided client software and utilities, programming libraries, and administration tools. But the core SQL Server engine was still produced entirely by Sybase; Microsoft didn't even have access to the source code. Any requests for changes, even for bug fixes, had to be made to Sybase.
Microsoft was building a solid support team for SQL Server. It hired some talented and dedicated engineers with database backgrounds. But with no access to source code, the team found it impossible to provide the kind of mission-critical responsiveness that was necessary for customer support. And, again, fixing bugs was problematic because Microsoft depended entirely on Sybase, which had become successful in its own right and was grappling with its explosive growth. Inevitably, some significant differences arose in prioritizing which issues to address, especially when some issues were specific to the Microsoft-labeled product and not to Sybase's product line. Bugs that Microsoft deemed of highest priority sometimes languished because Sybase's priorities were understandably directed elsewhere. The situation was unacceptable.
It was a great day in the SQL Server group at Microsoft when in early 1991, Microsoft's agreement with Sybase was amended to give Microsoft read-only access to the source code for the purpose of customer support. Although they still couldn't fix bugs, at least Microsoft's SQL Server group could read the source code to better understand what might be happening when something went wrong. And they could also read the code to understand how something was expected to work. As anyone with software development experience knows , even the best specification will be ambiguous at times. There's simply no substitute for the source code as the definitive explanation for how something works.
As a small group of developers at Microsoft became adept with the SQL Server source code and internal workings, Microsoft began to do virtual bug fixes. Although they still weren't permitted to alter the source code, they could identify line-by-line the specific modules that needed to be changed to fix a bug. Obviously, when they handed the fix directly to Sybase, high-priority bugs identified by Microsoft were resolved much quicker.
After a few months of working in this way, the extra step was eliminated. By mid-1991, Microsoft could finally fix bugs directly. Because Sybase still controlled the baseline for the source code, all fixes were provided to Sybase for review and inclusion in the code. The developers at Microsoft had to make special efforts to keep the source code highly secured, and the logistics of keeping the source code in sync with Sybase was sometimes a hassle, but all in all, this was heaven compared to a year earlier. Microsoft's team of developers was becoming expert in the SQL Server code, and they could now be much more responsive to their customers and responsible for the quality of the product.