Get Cracking: New Shell on Windows NT

Avoiding pitfalls when porting your apps from Windows 95

by Nancy Winnick Cluts

The much-awaited release of Microsoft Windows NT 4.0 with the Windows 95 shell (referred to internally at Microsoft as NT SUR, or Shell Update Release) is coming. Developers planning to run their applications on Windows NT SUR need to be aware of a couple of gotchas that have surfaced during early beta testing—as with any update of an operating system.

This article will cover the two most prevalent reasons why things might not go quite as you expect on the updated operating system. But don’t worry. I also let you in on the ways to avoid these pitfalls and enjoy the benefits of running your applications on both Windows 95 and Windows NT SUR.

Those of you currently running the Windows 95 operating system on one machine (or more) and Windows NT on another know how frustrating it can be to switch between the two shells. How many times have you right-clicked an icon on your Windows NT desktop and wondered why the context menu you’ve come to know and love hasn’t popped up? I know. I’ve done it too many times to count. I was delighted to be able to run Windows NT with the new shell while it was still in development.

Which operating system am I running under?

Because of the subtle differences in supported functionality between Windows NT and Windows 95, chances are you may have some conditional code tucked into your application. Which operating system your application is currently running under could determine whether the code runs.

For example, you may have code which uses the Security API that runs only under Windows NT. The code you are using to check the version of the operating system may be the code contained in the Knowledge Base article #Q92395, "Determining System Version from a Win32-based Application." This article is helpful, but it was written before the shell update release was created. So it doesn’t give you the whole picture when determining whether you are running Windows NT SUR.

You could make a call to either GetVersion or GetVersionEx. GetVersionEx is the preferred call (it’s Win32-specific), but if you need to check for 16-bit versions of Windows, you need to call GetVersion. However, if you call GetVersion and interpret the return value incorrectly, you could run into problems:

You might make Windows 95-specific calls when you shouldn’t.

You might believe that you have dynamically linked to the wrong version of KERNEL32. Windows NT and Windows 95 run different versions of KERNEL32.DLL. As a result, if you incorrectly determine the version of the operating system you are running, you may expect functionality that is not present or is different.

Using GetVersionEx to Determine the Operating System Version

So, how should you check for the operating system version? Call GetVersionEx and check the dwPlatformId member of the OSVERSIONINFO structure. The value should be interpreted as follows:

    Table 1. Interpreting the OSVERSIONINFO dwPlatformId field.

Other interesting fields in the OSVERSIONINFO structure are the dwMajorVersion and dwMinorVersion members. Table 2 shows you how to interpret these fields. Remember to check both fields to ensure which version of the operating system (and thus which features are supported) you are running.

    Table 2. Determining whether you are running on Windows NT with the new shell.

Using GetVersion to Determine to Operating System Version

Let’s say that you still want to call GetVersion. What should you do? If you are running Windows NT SUR build 1209, you will see the following:

HIWORD(ReturnVal) = 1209 // the build number
LOBYTE(LOWORD(ReturnVal)) = 4
HIBYTE(LOWORD(ReturnVal)) = 0

You need to check both bytes (the high byte and the low byte) to ensure that you are running under version 4.0. You also need to explicitly mask off the two high bits. You can interpret the values as follows:

    Table 3. Interpreting the return value from GetVersion.

What About TAPI?

It is presently planned that the shell update release of Windows NT will support the Telephony API (TAPI). If your application supports TAPI and you would like to determine the version of the operating system that you are running, use the lineNegotiateAPIVersion function. This function will allow you to know which version you are running without the necessity of calling GetVersion or GetVersionEx.

Windows NT SUR and DLL Redistribution

If your application was built using the Visual C++ development system and the Microsoft Foundation Class Library (MFC), you may need to redistribute a number of supporting dynamic-link libraries (DLLs). Some developers have noticed that most installations of Windows 95 already have most or all of these DLLs installed. This is due to the fact that many of the applets that come with Windows 95 are MFC applications. Systems that have other MFC applications installed may also have the MFC DLLs installed on the system.

If you install the shell update release of Windows NT, and have no other applications installed, your system will not, by default, have the MFC DLLs installed. The Windows NT shell applets do not use the MFC DLLs and, as a result, Windows NT does not install them. You will need to install the correct version of the MFC DLLs yourself. Be careful about the version; if you have just your end-user copy of the DLLs, they may overwrite existing DLLs. So you should provide an installation routine that checks the version of DLLs and only copies over DLLs as necessary. Also, ensure that you are redistributing the C runtime DLL, MSVCRT20.DLL.

Wasn’t That Easy?

Not rocket science, but these factoids are stuff you need to know. Have fun with the new shell on Windows NT.

Yesterday, Developer Technology writer Nancy Winnick Cluts wrote this article, polished off another chapter of her new novel, appeared on Letterman, testified before a Congressional committee, and got home in time to pick up Nicholas—the world’s most beautiful little boy—and assemble an exquisite dinner. She might sleep in tomorrow.

As with any update of an operating system, a couple of gotchas have surfaced during early beta testing of NT SUR.

Because of subtle differences in supported functionality between Windows NT and Windows 95, you may have conditional code tucked into your application.

If your application was built using Visual C++ and MFC, you may need to redistribute a number of supporting DLLs.