Programming Windows 95

[Karmen Mcarthun]

Adesktop application in C++ is a native application that can access the full set of Windows APIs, and either runs in a window or in the system console. Desktop applications in C++ can run on Windows XP through Windows 11 (although Windows XP is no longer officially supported and there are many new Windows APIs since then).

There are several broad categories of Windows applications that you can create with C++, described below. Each has its own programming model and set of Windows-specific libraries. The C++ standard library and third-party C++ libraries can be used in any of them.

A native desktop client application, or Win32 application, is a Windows desktop application written in C or C++ that uses native Windows C APIs or Component Object Model (COM) APIs CRT and Standard Library APIs, and 3rd party libraries. A Win32 application that runs in a window requires the developer to handle Windows messages inside a Windows procedure function. Despite the name, a Win32 application can be compiled as a 32-bit (x86) or 64-bit (x64) binary. In the Visual Studio IDE, the terms x86 and Win32 are synonymous.

The Universal Windows Platform (UWP) is the modern Windows API. UWP apps run on Windows 11, Windows 10, XBox, Windows Phone, Surface Hub, and other devices. UWP apps use XAML for the user-interface, and are fully touch-enabled. A desktop application is distinct from a Universal Windows Platform (UWP) app.

In Windows 10 and later, you can package your existing desktop application or COM object as a UWP app. It can use UWP features such as touch, or call APIs from the modern Windows API set. You can also add a UWP app to a desktop solution in Visual Studio, package them together in a single package, and use Windows APIs to communicate between them.

Visual Studio 2017 version 15.4 and later lets you create a Windows Application Package Project to greatly simplify the work of packaging your existing desktop application. A few restrictions apply to the registry calls or APIs your desktop application can use. However, in many cases you can create alternate code paths to achieve similar functionality while running in an app package.

.NET features the Windows Presentation Foundation (WPF) for rich graphics, and you can consume both Win32 and the modern Windows Runtime API. As a general rule, we recommend using C++ for desktop applications when you require:

Many Windows components are implemented as COM objects and follow standard COM rules for object creation, interface discovery, and object destruction. Using COM objects from C++ desktop applications is relatively straightforward, but writing your own COM object is more advanced.

An MFC application is a Windows desktop application that uses the Microsoft Foundation Classes to create the user interface. An MFC application can also use COM components and CRT and Standard Library APIs.

MFC provides convenient helper classes for window management, serialization, text manipulation, printing, and modern user interface elements such as the ribbon. To be effective with MFC, you should be familiar with Win32.

Many Windows programming scenarios also require the Windows SDK, which includes the header files that enable access to the Windows operating system components. By default, Visual Studio installs the Windows SDK as a component of the C++ Desktop workload, which enables development of Universal Windows apps. To develop UWP apps, you need a Windows 10 or later version of the Windows SDK.

A tutorial for programmers wishing to write applications for Windows using the C programming language and the native Win32 application programming interface (API). Programs written using this book run under every version of Windows from Windows 95 through Windows XP and beyond. Knowledge of C is required.

A tutorial for programmers wishing to write applications for Windows using Visual Basic .NET and the Windows Forms class library. This book is a translation of my book Programming Microsoft Windows with C# from the C# programming language to Visual Basic .NET.

For program source code, go to the Microsoft Press page and click Companion Content at the right, or download individual source code files and executables from or the complete CD as ProgWinVB.zip (709K).

Download individual source code files and executables from or the complete diskette as ProgWin95.zip (1.06M). Chapters 12 and 20 contain material that I do not hold the copyright on and are not included.

This book shows C programmers how to write applications for the OS/2 2.1 Presentation Manager. The book is an update of the Microsoft Press book Programming the OS/2 Presentation Manager. The earlier book was based on the 16-bit OS/2 1.1 environment; this one focuses on the 32-bit OS/2 2.1 environment. Download individual source code file from , or the original contents of the companion diskette from

Following a little discussion on my Facebook page initiated by my Xamarin colleague and old friend Larry O'Brien, I began to realize that some people believe that I invented the excessively overlong Windows "Hello World" program. I'm afraid I did not.

I learned Windows programming from documents included with the Windows 1.0 beta and release Software Development Kits. These included a printed API reference, of course, but beyond that the most important document was the Programming Guide, which was published with the SDK in 1985 as 258 7"x9" looseleaf pages in a binder. This document contained five sample programs that I studied in great depth in attempting to learn the Windows API. These samples were named

Although it was the very first Windows sample program, the HELLO program was quite fancy: Besides displaying "Hello Windows" in its title bar and client area, it added an About item to the system menu and displayed a dialog box when that item was selected.

The HELLO.H header file is missing from the book, but it was undoubtedly very short and only defined identifers that were referenced in both the C file and the HELLO.RC resource script, which looked like this:

As I studied this program and experimented with it, it became quite obvious to me that it was longer and more complex than it needed to be. I began to believe that it was not a good introductory program for someone learning the Windows API, and I thought that explaining Windows programming might benefit with something shorter and simpler. So I methodically began trimming this program down to size. (I had no idea at the time I might actually write a book about Windows programming, but it helps me in learning something new if I imagine trying to explain it to somebody else.)

I wondered if the code could be restructured to add clarity. The separate definitions of the HelloInit and HelloPaint functions seemed unnecessary, so I eliminated those and replaced the function calls with the bodies of those functions.

I think I then started looking at the text strings. As you can see, towards the top of the file some global char pointers are declared, and the beginning of WinMain uses LocalAlloc to allocate memory for these strings and then load them from the resource script with LoadString. Although I recognized the value of defining strings external to the source code, the needs of internationalization didn't seem appropriate for a first program. I wondered if the strings could be declared and initialized right in the source code, and it turned out they could. (Keep in mind that it was not at all obvious that standard C programming practices would work in a Windows program. That's how weird this was.)

Following the CreateWindow call, calls to GetSystemMenu and ChangeMenu put another item on the system menu. I wondered: Was this absolutely necessary to the proper functioning of a Windows program? I commented out those lines, and the program still ran. Because the program could no longer display the dialog box, I eliminated the About function and the processing of the WM_SYSCOMMAND message and the dialog template, and then I realized the only thing left in the resource script was the icon. Could a Windows program survive without a custom icon? Apparently yes. Could a Windows program be compiled and linked without a resource script? Turned out it could.

I tried a bunch of other simplifications. Some worked, some did not. But eventually I got it down to the bare essentials: Two functions, seven local variables, no yucky global variables, and no resource script.

The first edition of Programming Windows was published in 1988 and focused on Windows 2. Interestingly, the first code in that book did not present the "classical" Windows "Hello World" program but instead played around with multiple windows and let the titlebars say "hello.". You can browse the code from that first edition here:

It was the second edition of Programming Windows (1990 and focusing on Windows 3.0) that first included what is now the familiar Windows "Hello World" program. Here's all the source code from that edition:

ActiveX controller - a deprecated framework that allows libraries to be ran both in the browser (Internet Explorer) and on the machine itself. But it turned out it was a big security issue and was turned off as a functionality from the browsers. Though still the easiest way to programmatically connect to MS Office programs and some OS stuff. COM objects are basically the same thing.

Batch files (executed by cmd.exe) - the default shell since Windows NT. Batch files have .bat or .cmd extensions (Windows batch files: .bat vs .cmd?). The 32bit versions of even the latest version of Windows still have the cmd.exe predecessor command.com, which has fewer capabilities than cmd.exe. Through RUNDLL32.exe batch files have some limited access to some built-in .dll libraries ( -rundll32-commands-list-windows-10-a.html). And through WMIC.exe they also have some limited access to the WMI classes. Batch files can become extremely powerful if you embed another language within - you can call C#, PowerShell, JScript and etc. languages from a .bat file.

3a8082e126