Programming Windows: In the Beginning (Premium)

As noted previously, Windows 1.0 finally arrived in November 1985, two years after it was first announced. Described by Microsoft as an “operating environment” for MS-DOS, Windows provided a mouse-driven GUI under which traditional DOS applications, as well as new Windows applications, could run side-by-side in tiled windows.

The initial version of Windows didn’t offer overlapping application windows in deference to Apple, though individual Windows applications could display their own overlapping sub windows for dialog boxes and the like. But even in its earliest and most basic incarnation, Windows provided still-modern features like a system-wide clipboard by which applications could share data, display-independent graphics capabilities, broad driver support for graphics cards and printers, and more.

To understand why such advances were important, consider an example.

By 1985, the notion of “windows” within applications had become common. DOS-based Developer environments like Borland Turbo Pascal supported this functionality, allowing programmers to juggle multiple source code files and output displays. So did DOS-based productivity applications, like Lotus 123 and Microsoft Word, where being able to switch between multiple documents on the fly was obviously useful.

In DOS, these applications all had to implement windowing independently, and each had its own methods for drawing the screen, keeping hidden content in memory, determining keyboard shortcuts, and more. For the user, the differences could be confusing and make for an inconsistent experience when moving between different applications, especially if they were made by different vendors. And inter-application data interoperability was either non-existent or, via special Terminate and Stay Resident (TSR) utilities, difficult to use and inconsistently available and compatible.

Windows, like other GUIs, sought to end the confusion and make life easier on both application developers and users. That windowing functionality, which evolved along with Windows as the product moved from versions 1.0 to 3.1 over several years, was an integrated part of the system, something that developers didn’t need to independently duplicate and something that users only needed to learn once. And data interoperability, inside of an application or between different applications, was automatic.

Put simply, Windows abstracted the underlying system for both audiences. Developers could write applications to the then-new Windows API. And users could use Windows applications in this environment, sure that they would look and work similarly and would interoperate with each other and with the underlying PC seamlessly.

(Fun aside. Where the Macintosh mouse had a single button, the Microsoft Mouse, which was first released alongside Microsoft Word for DOS, had two. The first of the two buttons functioned similarly to the single Macintosh mouse button, allowing the user to “click” or “select” onscreen items. In Windows itself, the second button simply duplicated the functionality of the first button, while Windows applications could define its functionality independently; right-clicking to access a context menu of options wouldn’t come until later after Microsoft Office first implemented this feature.)

1985 wasn’t just notable for being when Microsoft released the first version of Windows. The would-be software giant also released its first in-house C compiler that year as it geared up for the release of Windows. That release was marked, if briefly, in the April 1985 issue of Byte Magazine.

Microsoft Releases Its Own C Compiler. Microsoft has released Microsoft C version 3.0, which replaces the Lattice-developed C previously sold by Microsoft for the IBM PC. Microsoft’s C compiler provides file-sharing and record-locking features for use in network environments; a separate Windows Toolkit will help C programmers develop applications to run under Microsoft Windows. Microsoft says that source and object code can be linked to run directly under MS-DOS or XENIX without modification. Microsoft C is $395.

As an Amiga enthusiast and aspiring developer in the late 1980s, I later became familiar with the Amiga version of Lattice C. (The first Amiga was coincidentally also released in 1985). And while I wasn’t aware of its use by Microsoft for MS-DOS before that, I did know that the development of Windows apps originally did occur in MS-DOS, and not in Windows, in the early days. So, yes, the Microsoft C compiler noted in that blurb is a DOS application, not a Windows application.

That makes sense because early versions of Windows, again, were not true operating systems, and the overhead of Windows combined with a developer environment would likely have overwhelmed the resources of many PCs in the mid-to-late 1980s. But this setup also made early Windows software development ponderous: The developer would edit code in a DOS-based environment like Microsoft C, compile and link it, and then run Windows to test the app. If there was a problem—and there is always a problem when you’re writing code—they would then have to exit back to DOS and repeat the process all over again.

Emulating such an experience today is somewhat pointless, though Microsoft’s modern compilers—for languages such as C#, C++, and others—can still be run completely from the Command Prompt in Windows 10.

But in the mid-1980s, most would-be Windows developers were coming, I imagine, from MS-DOS. And those with Microsoft C compiler experience would have likely used what Microsoft called—and, yes, they really wrote it like this—the Microsoft C Run-Time Library, a set of over 200 functions and macros for the C programming language that provided interfaces to DOS functions (like file access) and more general programming tasks such as string manipulation. (Microsoft C predated ANSI C, which added string manipulation functionality directly to the C language; previously, strings were arrays of characters.)

(Fun aside. In the 1980s, the C runtime library—sorry, I have to write that correctly—supported both MS-DOS and XENIX, Microsoft’s implementation of UNIX for IBM and compatible PCs. In some cases, you could use the same code to create applications that ran on both platforms.)

But it wasn’t enough to have Microsoft C or some other compatible C (or Pascal, or assembly language) development tool. Aspiring Windows developers also needed something called the Windows Software Development Kit (SDK), which cost an addition $495. (Today, Microsoft’s latest compilers and the Windows SDK, as well as a modern integrated development environment, or IDE, that is both extensible and supports multiple languages, are both available for free.)

Even in the beginning, Windows provided an incredible number of advantages for developers and the applications they created. And so it is perhaps not surprising that the Windows API (application programming interface) provided by the Windows SDK consisted of about 450 functions, over double the number available in the C runtime library for MS-DOS.

An advertisement for the Windows SDK that appeared in various issues of Byte Magazine in 1986 provides a high-level view of why developers would want to target the new operating environment.

Software with a new view. Giving your applications the Windows treatment begins with a new look. The rich graphical environment allows you to rethink how you want your program to be presented on screen. It lets you mix text and graphics. You can incorporate multiple fonts in a variety of sizes, faces and styles. And it provides the basic building blocks that make it easy to create drop-down menus, dialog boxes, scroll bars, icons and more. These features not only simplify your application design, but also provide the familiar interface that makes your software easier to learn and use.

Easing the data shuffle. Of course, there’s more to Windows than just looks. Now, different applications can work together. In concert. The Windows Clipboard provides support for users to cut and paste information between your applications and others. Or you can use messages to establish “hot links” to transfer data automatically.

Upgrading made easy. Windows’ device independent design allows you to build your application today and take advantage of new technology as it becomes available. When new graphics cards, printers and pointing devices appear they can be used with your software, without modifying your code. Simply by installing the new driver.

When Byte finally reviewed the Windows SDK in June 1987, the reviewers were quite impressed, though the publication noted that Microsoft’s minimum system requirements— PC-DOS or MS-DOS 2. 0 or higher, 512 KB of RAM, a CGA or EGA graphics adapter with a compatible graphics monitor, and two floppy disks—were a bit low.

What was conspicuously missing, Byte noted, was a tutorial.

“The binder containing the Programming Guide, Quick Reference, and Application Style Guide explains one simple program, which prints ‘Hello, Windows’,” the review notes. “The example is useful, but one example is not enough. It took us quite a bit of reading and playing around with the sample programs on the disks before we started to understand Windows and how the applications work. A tutorial guide is desperately needed to explain the new concepts and caveats of Windows programming. [But] once you get a feel for Windows programming, the documentation is efficient and easy to use. The manuals are organized logically with an ample number of examples, all in Microsoft C, and a good index.”

Fortunately, that tutorial soon arrived: Charles Petzold, a contributing editor for PC Magazine and the Microsoft Systems Journal (the predecessor to MSDN Magazine) contracted with Microsoft Press to write Programming Windows, the seminal Windows development tutorial that would lead an entire generation of programmers—myself included—to Microsoft’s new platform.

More soon. Including our first look at early Windows application source code.