The CAPITAL LETTERS trick that helped merge Windows 95 into NT

Keeping track of checks, 1990s style

The early versions of Windows NT were the last hurrah for the Windows 3.1-esque Program Manager. But getting the Windows 95 shell into the codebase occasionally required using CAPITAL LETTERS.

The development of Windows 95 was underway around the same time as Windows NT 3.1 was being prepared for launch, looking like Windows 3.1 but a completely different beast under the hood.

While the Windows NT team was focused on shipping the new operating system, thoughts were turning to how the Windows 95 code could be integrated, giving the world Windows NT 4.0.

Windows NT 3.1 was, of course, not the last of the Program Manager line. A Microsoft engineer told The Register during a pre-pandemic Build conference that one of the focuses of Windows NT 3.5 was to deal with the operating system's perceived poor performance. To that end, a whiteboard with figures showing performance and memory statistics was set up to track progress.

NT 3.5 turned out to be that rare thing at Microsoft – an operating system update that performed better with less memory than its predecessor.

As the Windows 95 team fiddled with the bells and whistles of the updated user interface, the Windows NT team concentrated on shipping their product, but, according to veteran Microsoft engineer Raymond Chen, "they appreciated being kept in the loop."

With the development of Windows 95 finally drawing to a close, the NT team began taking a more active role in getting Microsoft's vision for a new user interface onto Windows NT. Setting aside the architectural changes that came with Windows NT 4.0, the most eye-catching update was the Windows 95 interface.

For some elements, such as the new window management features, the Windows NT team had some work to do. Chen recalled: "The window managers on Windows NT and Windows 95 both had ancestry in the Windows 3.1 window manager, so a lot of the designs were the same, but the code had long since diverged significantly, so it wasn't so much merging the code as it was using the Windows 95 code as a reference implementation when reimplementing the features on Windows NT."

Other components were more straightforward, relatively speaking. Chen noted that Explorer, for example, was taken as-is into the Windows NT codebase and updated to be more Windows NT-like. The process was bidirectional so that when the Windows 95 codebase was updated, the Windows NT team wouldn't have to make the same changes all over again.

The question was how to avoid Windows NT work affecting the Windows 95 code. After all, the latter had more than enough bugs of its own without any being introduced by the port.

"Protecting the changes was done in a variety of ways," Chen said. "One was to enclose all the new code inside #ifdef WINNT directives so that they weren't compiled by Windows 95, or #ifdef... #else... #endif blocks if the Windows NT version had to diverge from the Windows 95 version."

Then there were things like sizeof, which was used to calculate the size of a CHAR string buffer. The Unicode-aware Windows NT returned a different value. The solution in affected scenarios was to change sizeof(stringBuffer) to sizeof(stringBuffer) / sizeof(stringBuffer[0]). It wouldn't affect Windows 95, but the fix presented another challenge for the Windows NT team – how to know when a sizeof had been vetted.

The answer was capitalization. "Their solution," said Chen, "was to define a synonym macro."

#define SIZEOF sizeof

"When the Windows NT team verified that a sizeof was correct, or when they fixed it to be correct, they changed the sizeof to SIZEOF. That way, they could search the code for lowercase sizeof to see what still had yet to be inspected.

"The Windows 95 team were told to continue using sizeof in new code, so as not to mess up this convention."

Users of modern source control systems might scoff at such a bodge, but it did the trick. Decades ago, Microsoft used an internal source code system known as SLM. The letters stood for Source Library Manager, according to Chen, but it was pronounced "slime." He said: "SLM did not support branches, so moving changes from Windows 95 to Windows NT involved manually doing three-way merges for all of the files that changed since the last drop."

"I suspect that this manual process was largely automated, but it was not as simple as a git merge." ®