Windows NT and Windows 95: A Tale of Integration
The early iterations of Windows NT marked the final moments for the familiar Program Manager reminiscent of Windows 3.1. As the development of Windows 95 progressed, the integration of its shell into the Windows NT codebase occasionally necessitated the use of CAPITAL LETTERS, a quirky yet effective coding practice.
During this period, while the Windows NT 3.1 team was gearing up for its launch, the Windows 95 project was simultaneously taking shape. Although visually similar to its predecessor, Windows 3.1, Windows NT was a fundamentally different entity beneath its surface. As the Windows NT team focused on delivering their operating system, they began contemplating how to incorporate the innovations from Windows 95, ultimately leading to the creation of Windows NT 4.0.
As the Windows 95 team polished the aesthetics of their user interface, the Windows NT team remained dedicated to their shipping timeline. Veteran Microsoft engineer Raymond Chen noted that the NT team appreciated being kept informed about the developments in Windows 95, fostering a collaborative spirit between the two groups.
With the completion of Windows 95 on the horizon, the NT team took a more proactive stance in integrating Microsoft’s vision for a refreshed user interface into Windows NT. Among the significant architectural changes introduced with Windows NT 4.0, the most striking was undoubtedly the adoption of the Windows 95 interface.
Some features, particularly the new window management capabilities, required considerable effort from the Windows NT team. Chen recounted that while both Windows NT and Windows 95 shared a common ancestry with the Windows 3.1 window manager, their codebases had diverged significantly over time. Thus, the integration process was less about merging code and more about using Windows 95 as a reference point for reimplementing features within Windows NT.
Other components, however, proved to be more straightforward. For instance, Explorer was seamlessly integrated into the Windows NT codebase and subsequently adapted to align more closely with Windows NT’s architecture. This bidirectional process ensured that updates made to the Windows 95 codebase would not necessitate redundant changes for the Windows NT team.
A critical challenge lay in preventing the work on Windows NT from inadvertently introducing bugs into the Windows 95 code. Chen explained that safeguarding these changes involved various strategies, one of which included enclosing new code within #ifdef WINNT directives. This approach ensured that the Windows 95 compilation process would not inadvertently include any Windows NT-specific modifications.
Another technical hurdle arose with the sizeof operator, which calculated the size of a CHAR string buffer. Due to the Unicode-aware nature of Windows NT, this operator returned a different value than expected. To address this, the team modified instances of sizeof(stringBuffer) to sizeof(stringBuffer) / sizeof(stringBuffer[0]), a change that would not impact Windows 95 but presented the Windows NT team with the challenge of tracking which sizeof instances had been verified.
The solution came in the form of capitalization. Chen elaborated, “Their solution was to define a synonym macro.” The macro was defined as follows:
#define SIZEOF sizeof
Once the Windows NT team confirmed the accuracy of a sizeof instance or corrected it, they replaced it with SIZEOF. This clever convention allowed them to search for lowercase sizeof to identify which instances still required inspection. Meanwhile, the Windows 95 team was instructed to continue using sizeof in new code to maintain this distinction.
While modern source control systems might render such a workaround obsolete, it effectively served its purpose at the time. Decades ago, Microsoft relied on an internal source code management system known as SLM, which stood for Source Library Manager, albeit humorously pronounced “slime.” Chen noted that SLM lacked support for branches, making the transfer of changes from Windows 95 to Windows NT a laborious process involving manual three-way merges for all modified files since the last update. Although this manual process may have been automated to some extent, it was certainly not as straightforward as a simple git merge.
