Application Version Marking in Windows 95

• Microsoft Win32 Application Programming Interface (API) included with:

      - Microsoft Windows 95 version 4.0
  

SUMMARY

Applications designed for Windows 95, whether 16- or 32-bit, should be marked for Windows version 4.0 so they receive the full benefit of new user interface features in Windows 95. Applications marked as being designed for earlier versions of Windows will display behavior consistent with the Windows version 3.1 user interface, which is not always identical to Windows 95 behavior.

Executables marked for Windows version 4.0 will load on Windows 95, Windows NT version 3.5, Win32s version 1.15, and later versions, but not on earlier versions.

NOTE: This article deals solely with marking executable files as compatible with a particular Windows version. This is different from the version resources (VS_VERSION_INFO) that may be contained in an executable.

MORE INFORMATION

The Microsoft Visual C++ version 2.1 linker defaults to marking executables for Windows version 4.0 while the version 2.0 linker defaults to 3.1. The Books Online section "Appendix B: Link Reference" incorrectly states that versions 2.1 and 2.2 default to a subsystem of 3.10. To override the default, the Microsoft Visual C++ linkers accept the following syntax for the /SUBSYSTEM option:

   /SUBSYSTEM:WINDOWS,4.0

You may need to perform a full link for this to take effect, but subsequent incremental linking with this switch will work correctly.

To mark a 16-bit executable as Windows version 4.0 compatible, use the 16-bit resource compiler (RC.EXE) from the Windows 95 SDK to bind the resources into the executable file. By default, this version of RC marks the executable for version 4.0, but this can be overridden by using the -30 or -31 switch.

An application will display several behavioral differences depending on which Windows version the application is compatible with:

1. All standard control windows owned by a version 4.0 application are drawn with a chiseled 3D look. To obtain the same effect for dialogs owned by a version 3.1 application, use the DS_3DLOOK dialog style. This style is ignored if the application is run on Windows platforms other than Windows 95. The dialog style DS_3DLOOK is not defined in the standard WINRES.H. Therefore, to use this style, you must define it as

         #define DS_3DLOOK 0x0004L
   

   and or DS_3DLOOK into the STYLE line of each dialog in the project's .RC file. NOTE: Editing a dialog template using the resource editor removes this DS_3DLOOK style bit.

   NOTE: This symbol will be defined in a future release of Visual C++. At that time, you will get the error "symbol redefined". At that point, you can remove your definition of DS_3DLOOK.

2. Thunks created using the Windows 95 SDK Thunk Compiler will not work unless the 16-bit thunk DLL is marked for version 4.0.

3. Windows version 3.1 allowed 16-bit applications to share GDI resources such as font or bitmap handles. For backwards compatibility, Windows 95 does not clean up objects left undeleted by a 16-bit version 3.x application when that application terminates because these objects may be in use by another application. Instead, such objects remain valid as long as there are any 16-bit applications running. When all 16-bit applications are closed, these objects are freed.

   On the other hand, is is assumed that 16-bit version 4.0 applications follow the Windows 95 guidelines, and do not share objects. Thus, all objects owned by a 16-bit version 4.0-based application are freed when the application terminates.

   Win32-based applications cannot freely share GDI objects, so all owned objects are freed when a Win32-based application terminates regardless of the version of the application.

4. New window messages, such as WM_STYLECHANGED, are only sent to windows owned by a version 4.0 application.

5. Printer DCs are reset during StartPage() in applications marked with version 4.0