Application Compatibility Checklist for Microsoft(R) Windows[TM] version 3.1

Created: March 20, 1992

ABSTRACT

To make Windows version 3.1 better and more robust than Windows version 3.0, Microsoft enhanced and improved many Windows features. Although every effort was made to ensure compatibility with Windows version 3.0 applications, some enhancements may affect their operation—especially if an application uses features in an undocumented fashion or relies on invalid assumptions about the behavior of Windows. This document identifies the enhancements that may affect existing Windows version 3.0 applications and explains how you can determine whether your application will run successfully under Windows version 3.1.

Introduction

To make Windows version 3.1 better and more robust than Windows version 3.0, Microsoft enhanced and improved many Windows features. Although every effort was made to ensure compatibility with Windows version 3.0 applications, some enhancements may affect their operation—especially if an application uses features in an undocumented fashion or relies on invalid assumptions about the behavior of Windows.

Microsoft is eager to help you resolve any compatibility problems you may encounter. This document identifies the enhancements that may affect existing Windows version 3.0 applications and explains how you can determine whether your application will run successfully under Windows version 3.1.

Please read each section carefully and use the checklist at the end of this document to ensure that you have carried out the recommended tests. As you complete each test, mark on the checklist whether your application passed or failed the test. If your application failed a test, please supply comments that will help Microsoft determine the cause of the compatibility problem. If you choose not to carry out a test, please indicate why in the comments section.

When you complete the checklist, return it to Microsoft. Mailing information is included with the checklist. If your application has compatibility problems, Microsoft will contact you.

Application Installation Programs

Enhancements to the Program Manager’s group file format and extensions to the PROGMAN.INI file may affect your application’s installation program.

Potential Problem

Your installation program may not correctly add your application’s icon to Program Manager or may not correctly save your application’s PROGMAN.INI settings.

Tests

Run your installation program in each of the following applicable environments:

MS-DOSÒ

MS-DOS command prompt under Windows version 3.1

Windows using the Run command in the Program Manager’s File menu

Windows Setup

Windows version 3.1 Setup is easier to use, faster, more robust, and capable of detecting more hardware and network configurations than was Windows version 3.0 Setup. Special attention was given to the need to upgrade from Windows version 3.0 while maintaining existing group files and WIN.INI settings.

Potential Problem

Setup may fail to correctly preserve your application’s program group files and WIN.INI settings.

Test

Use Setup to install Windows version 3.1 on a computer on which both Windows version 3.0 and your application are already installed. After installation, be sure that your application’s WIN.INI settings are correct and that your application runs properly.

Shell Application

This section applies only to applications that replace the standard Windows shell application, Program Manager. The shell application (as specified by the shell setting in the SYSTEM.INI file) is no longer guaranteed to be the first process.

Potential Problem

An application that assumes it is the shell only when it is the first process will not exit Windows correctly when terminated.

Test

Make your application the shell by specifying your application’s executable file name with the shell setting in the SYSTEM.INI file. Exit Windows and be sure Windows terminates correctly.

Solution

Your application must determine whether it is the shell by doing the following:

1.Check the number of processes running when it starts.

2.If more than one process is running, check the shell setting in the SYSTEM.INI file.

Windows Shell Applications

Enhancements to the Program Manager, File Manager, Print Manager, and Control Panel may affect your application.

Drag and Drop

Drag and drop was reimplemented, and Windows now exports the drag-drop functions and message (WM_DROPFILES).

Potential Problem

An application that reverse-engineered the Windows version 3.0 drag-drop protocol may encounter difficulties.

Tests

1.Drag a file from File Manager to your application. Be sure your application opens the proper file.

2.Drag a file associated with your application to Print Manager. Be sure your application opens and prints the proper file.

System Colors

Windows now provides more system colors and user preferences. Users can select separate colors for active and inactive title bar text, button face, button shadow, button text, button highlight, disabled text, highlight, and highlighted text. Different wallpapers and color schemes were added, and the default color scheme is changed.

Potential Problem

An application may not use all colors correctly.

Test

Display your application’s windows, dialog boxes, and controls, and check the colors of the active and inactive title bar text, button face, button shadow, button text, button highlight, disabled text, highlight, and highlighted text colors. Use the Control Panel to set each of the following system color schemes:

System colors set to default.

System colors set to a nondefault color scheme, such as Arizona.

System colors set to a random scheme in which you set colors individually. (Don’t use the predefined color schemes.)

Cardfile and Write Files

The Cardfile file format is changed, and both Cardfile and Write documents can now contain embedded OLE objects.

Potential Problem

Any application that makes assumptions about Cardfile and Write file formats may not be able to read or write to these files correctly.

Tests

1.Use your application to create Cardfile or Write files. Use Windows version 3.1 Cardfile and Write to open and view the files.

2.2Use Windows version 3.1 Cardfile and Write to create files containing OLE objects. Be sure your application can open and read the files.

Other Considerations

Path searching is enhanced. When trying to load DLLs, Windows searches directories in the following order: current directory, Windows directory, System directory, application directory, path. The application directory is new for Windows version 3.1.

Title fonts for Program Manager and desktop icons are changed, and icon titles can now wrap.

More than one printer can now be installed on a port.

Control Panel’s font installation is enhanced.

Program Manager automatically reconnects network drives and devices when Windows is restarted.

File Manager is entirely new for Windows version 3.1. File Manager includes an interface that lets applications add menu items to the File Manager menu by using a File Manager extension library.

Control Panel now provides an interface for adding new Control Panel applets and icons.

The Startup group contains applications that load whenever Windows is started. For backward compatibility, the load line in the WIN.INI file is still supported.

The [Intl] section in the WIN.INI file is enhanced. More date formats and currency symbols are available.

Desktop spacing can now be changed by a new setting in the WIN.INI file and by the SystemParametersInfo function.

Multimedia and Sound

Windows version 3.1 includes multimedia and sound drivers. Most of these enhancements should affect only applications that use the sound functions. Applications that use unusual drivers, such as fax machine applications, should also test to be sure the sound drivers don’t interfere.

MS-DOS Sound Applications

Potential Problem

Some MS-DOS applications that use audio cards, such as SoundBlaster, may not run correctly in virtual machines or may run incorrectly after Windows terminates.

Test

Carry out each of the following steps. Be sure your application runs correctly as you complete each step:

1.Run the MS-DOS application in a virtual machine.

2.Exit Windows and run your application under MS-DOS.

Windows Sound Applications

Potential Problem

Although Windows sound functions are 100% backward compatible, some Windows applications may not function properly with the new functions.

Test

Run your application and try all the sound capabilities.

Unusual Drivers

Potential Problem

Applications requiring unusual drivers, such as WinFax, may not be compatible with multimedia extensions.

Test

Run your application and try the functions of your application that the driver supplies.

Window Management

The window management (USER module) enhancements may affect Windows version 3.0 applications. To test this, perform as many operations as possible that will move, size, scroll, and repaint your application windows. The following sections list a few basic methods to try, but also try as many other methods as possible.

In some cases, Windows version 3.1 will ensure compatibility with existing Windows version 3.0 applications by supporting both the Windows versions 3.0 and 3.1 implementations. If an application’s Windows version as set by Resource Compiler (RC) is 3.0, Windows version 3.1 carries out the Windows version 3.0 implementation; that is, the Windows version 3.1 enhancement has no impact on an existing Windows version 3.0 application. However, if a Windows version 3.0 application’s Windows version is changed to 3.1 without corresponding changes to the application code, the application may encounter problems wherever Windows version 3.1 carries out the 3.1 implementation.

Moving and Sizing

For Windows version 3.0 applications, the SetWindowPos function assumes that SWP_NOMOVE and SWP_NOSIZE are set if SWP_HIDEWINDOW or SWP_SHOWWINDOW were set. Thus, hiding and showing a window and changing its size and position are not possible in an atomic operation. Windows version 3.1 applications are not so limited.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may make unnecessary calls to SetWindowPos.

In a Windows version 3.0 application, if you call SetWindowPos with SWP_SHOWWINDOW when the window is already visible, SetWindowPos always causes the entire window to be redrawn. This also affects the operation of ShowWindow. In a Windows version 3.1 application, a call to SetWindowPos with SWP_SHOWWINDOW on a window that is already visible will not redraw (unless other areas must be updated as a result of a size, move, or z-order operation specified in addition to SWP_SHOWWINDOW).

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on redrawing on each call to SetWindowPos with SWP_SHOWWINDOW set.

MoveWindow is shorthand for a call to SetWindowPos with the SWP_NOZORDER and SWP_NOACTIVATE flags set. If the MoveWindow fRedraw parameter is FALSE, then SWP_NOREDRAW is also set. In a Windows version 3.0 application, when MoveWindow is called on a top-level window with fRedraw set to FALSE, Windows calls SetWindowPos without setting the SWP_NOREDRAW flag and then calls ValidateRect to prevent the client area from repainting. However, WM_NCPAINT and WM_ERASEBKGND messages will have been sent, even though fRedraw was FALSE. In a Windows version 3.1 application, MoveWindow no longer makes this special case.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on receiving WM_NCPAINT and WM_ERASEBKGND messages after a call to MoveWindow.

In a Windows version 3.0 application, Windows always redraws a window’s frame completely when the window is moved or sized. In a Windows version 3.1 application, Windows no longer redraws a window’s frame completely in all cases. For example, the following code sequence will not redraw the window border:

MoveWindow(hwnd, ..., FALSE);

.

.

.

InvalidateRect(hwnd, NULL, TRUE);

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may have an incomplete window frame if it depends on Windows redrawing the frame completely after moving and sizing.

Tests

1.Start your application in its default state. Maximize and minimize it; be sure it paints correctly after each operation.

2.Move your application as far right and left as you can in small increments, watching for repaint problems each time you stop moving.

3.Resize your application using the mouse to drag the border.

Painting

In Windows version 3.1, window management is substantially optimized to avoid unnecessary redrawing and flashing. Applications that depend in subtle ways on when (and if) WM_NCPAINT, WM_ERASEBKGND, and WM_PAINT messages are sent may have incompatibilities. Windows version 3.0 frequently sent these messages redundantly to windows and sometimes sent them to invisible windows. One of the most apparent visual results of these optimizations is that a window’s nonclient area is not always repainted completely when a window is sized or moved. Some attempt has been made to ensure compatibility, but some differences still cannot be backward compatible and achieve the significant performance and visual advantages.

In a Windows version 3.0 application, sending the WM_SETREDRAW message with wParam set to FALSE to a window that had an update area does not validate the window. The update area is still present after a WM_SETREDRAW message with wParam set to TRUE. In a Windows version 3.1 application, WM_SETREDRAW with wParam set to FALSE validates the window completely to ensure that the window does not receive any WM_PAINT messages while it is invisible. This does not apply to edit controls, list boxes, and combo boxes because their WM_SETREDRAW messages are handled in a special-case manner.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on retaining the update area after a WM_SETREDRAW message.

In a Windows version 3.0 application, when InvalidateRect or InvalidateRgn is called with NULL to invalidate the entire window, all child windows are also completely invalidated—regardless of whether the child window is outside the parent’s client area (that is, invisible). This results in WM_PAINT messages being sent to windows that don’t require them. In a Windows version 3.1 application, only windows that are actually visible within a parent’s client area receive update regions and therefore WM_PAINT messages.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on its child windows receiving WM_PAINT messages even when invisible.

In a Windows version 3.0 application, Windows sends a WM_SETVISIBLE message immediately after sending the WM_SHOWWINDOW message. In a Windows version 3.1 application, Windows does not send the WM_SETVISIBLE message—WM_SETVISIBLE is obsolete for Windows version 3.1.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on receiving the WM_SETVISIBLE message.

In a Windows version 3.0 application, if BeginPaint is called on a window that has a class icon, the function returns a window DC. This is different from the GetDC function that returns a client DC with no visible region. In a Windows version 3.1 application, BeginPaint and GetDC both return a client DC with no visible region.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it depends on receiving a window DC from BeginPaint.

If a Windows version 3.0 application responds with FALSE to a WM_ERASEBKGND message sent during any operation other than BeginPaint (such as SetWindowPos), another WM_ERASEBKGND message is sent when the application calls BeginPaint. If a Windows version 3.1 application responds with FALSE, no second WM_ERASEBKGND message is sent, but BeginPaint sets the fErase member of the PAINTSTRUCT structure to TRUE.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it does not check the fErase member after calling BeginPaint.

In Windows version 3.0, the various controls call the UpdateWindow function at inappropriate times, such as on receiving a WM_SETFOCUS message, and at other times when changing the internal state. This often leads to strange looking displays, as controls draw all or part of themselves at odd times. In Windows version 3.1, the controls do not call UpdateWindow as often, which speeds up and improves the appearance of window repainting.

Potential Problem

Some controls may not get redrawn properly if they are moved or hidden before they get a chance to process a WM_PAINT message.

Tests

1.Minimize your application, and start another application. Restore your application. Be sure it paints correctly.

2.Start your application with another Windows application, such as one of the accessories. Bring the other application to the foreground, covering your application. Switch back to your application. Be sure it painted correctly.

3.Start several applications. Use ALT+TAB to switch between them. Be sure your application repaints correctly.

Scrolling

In a Windows version 3.0 application, the ScrollWindow function has a number of bugs associated with scrolling a window that had any invalid area. Frequently, the update region that results after the scrolling operation is not properly calculated. In a Windows version 3.1 application, ScrollWindows calculates the update region correctly.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it works around the Windows version 3.0 bugs.

Test

Run your application and try a variety of scrolling operations.

Multiple-Document Interface (MDI)

For Windows version 3.0 applications, MDI is completely compatible with Windows version 3.0. For Windows version 3.1 applications, MDI has been enhanced. In particular, specifying the low-order style bit (MDIS_ALLCHILDSTYLES) when creating an MDICLIENT window enables the new Windows version 3.1 MDI capabilities for that window. This gives applications control over all MDI child window styles and allows for hidden windows.

Potential Problem

Any Windows version 3.0 application whose version number is changed to 3.1 may encounter problems if it unintentionally sets the low-order style bit when creating an MDICLIENT window.

Windows Hooks

In Windows version 3.0, three hook functions are available: SetWindowsHook, UnhookWindowsHook, and DefHookProc. In Windows version 3.1, three more powerful functions replace these functions: SetWindowsHookEx, UnhookWindowsHookEx, and CallNextHookEx. Microsoft strongly recommends that a Windows version 3.1 application use the new functions. The old functions are still supported for backward compatibility.

In Windows version 3.0, an application or a DLL that installs a hook must maintain the hook chain. In Windows version 3.1, Windows maintains the hook chains. As a result, subtle changes in the interface may affect Windows version 3.0 applications. Furthermore, Windows version 3.1 no longer allows applications and DLLs to enumerate all the functions in a hook chain. In particular, Windows version 3.1 no longer supports the HC_GETLPLPFN, HC_LPLPFNNEXT, and HC_LPFNNEXT values for the DefHookProc function.

In Windows version 3.0, SetWindowsHook returns a pointer to the next hook function. In Windows version 3.1, SetWindowsHook does not return a pointer; instead, it returns a 32-bit value that identifies the next hook function.

Potential Problem

An application that attempts to call the next hook function by using the return value from SetWindowsHook as a function address will cause a GP fault.

In Windows version 3.0, Windows passes negative hook values to hook functions when unhooking a hook. These negative values are for Windows internal use only. In Windows version 3.1, Windows does not pass negative hook values to hook functions; it uses another method to unhook a hook.

Potential Problem

An application’s hook function fails if it depends on receiving negative hook codes to carry out specific tasks.

A Windows version 3.0 application can unhook a hook function by passing the address of the next hook function to the SetWindowsHook function. In Windows version 3.1, passing the address of the next hook function causes a RIP in the Windows version 3.1 debugging version.

In Windows version 3.0, SetWindowsHook never fails and so never returns an error value. In Windows version 3.1, SetWindowsHook can fail, and when it does, it returns the error value –1L.

Parameter Validation

Windows strictly checks parameters passed to its functions before using them. In a Windows version 3.0 application, Windows works around many validation errors and lets the function or application continue to function. In a Windows version 3.1 application, many of these errors cause the functions to fail, and the developer must ensure that structures and parameters are passed correctly.

For example, in Windows version 3.0, if an application passes NULL as the hInstance parameter to CreateWindowEx, Windows maps the handle to the stack segment. In Windows version 3.1, the function returns an error value.

The SDK release notes describe this in more detail. In some cases, the system may reject valid parameters incorrectly and cause applications to misbehave. Microsoft plans to fix any such occurrences.

Undeleted Object Notifications

In Windows version 3.1, any GDI or USER object left allocated when an application terminates results in a warning to the debug terminal. Windows version 3.1 does not automatically free these objects—the application must free them. These warnings usually imply a memory leakage—running and terminating an offending application eventually uses up all available memory.

In some cases applications (and DLLs) allocate objects that are intended to stay around longer than the application that created them. This occurs frequently in shared DLLs that share GDI objects such as bitmaps and brushes among their many clients. In such cases, ignore the warnings at the debug terminal.

Potential Problem

Applications can eventually use up available memory, which seriously degrades system performance.

Test

Use Program Manager to check memory usage before and after running your application. Follow these steps:

1.Choose the About command in Program Manager’s Help menu. Record the amount of available memory and resources.

2.Run your application and carry out enough tasks to ensure that one or more objects are created. Terminate your application.

3.Choose the About command again and compare available memory and resources. Be sure these values have not dropped.

4.Repeat this procedure several times, and check available memory and resources each time.

Menu Implementation

Windows version 3.1 has enhanced menu management. In particular, the TrackPopupMenu function allows additional parameters, and Windows stores application menu data in a separate heap, expanding the number of windows that may exist.

In Windows version 3.0 applications, Windows sends a WM_COMMAND message using the SendMessage function. In Windows version 3.1 applications, Windows sends the message using the PostMessage function, preventing the potential for overflowing a stack when dealing with pop-up menus.

RegisterClass

In Windows version 3.0, Windows fails to free the window-class background brush properly when deleting the class. In Windows version 3.1, Windows frees the brush when either a Windows version 3.0 or 3.1 application terminates.

Potential Problem

A multiple-instance application that deletes the background brush may unintentionally delete a brush when other instances of the application are running.

Topmost Window

A new window attribute allows a window to be placed on top of all other windows, even when the owning application is not active. If multiple applications have topmost windows, the topmost window is ordered the same as owning applications.

Also, a topmost window, its owners, and all windows it owns stay together as windows are moved around. Thus, if you bring an owned dialog window to the top, its owner is also brought forward so that it stays immediately below the dialog box.

Potential Problem

Applications that depend on being able to have windows of other applications between their main window and a dialog box may encounter problems. For example, a setup program that starts Notepad and then brings up a dialog box causes Notepad to be positioned behind the dialog box owner. The solution is to create the dialog box without an owner (a window may not be owned by a window of another application).

Potential Problem

Any application that relies on having an unobstructed client area when active may encounter problems because the active window cannot be guaranteed to be on top. Thus, the active window may not have a rectangular clipping region because a topmost window may be on top of it. Calling BitBlt with a window or screen DC as the source (which is not recommended in any case) may copy bits belonging to the topmost window.

Tests

1.Examine your application code, and be sure there are no dependencies on client area visibility when your application is active.

2.Start the Clock application, and set it to be the topmost window. Run your application and several others. Use ALT+TAB to switch between applications, and be sure your application repaints correctly.

TrueType

Although Windows version 3.1 includes support that seamlessly integrates TrueTypeÒ fonts into existing applications, problems with fonts can occur for Windows version 3.0 applications that assume bitmap fonts are always available, that Helv and Tms Rmn are always available, and that font sizes are limited. Be sure to thoroughly check fonts in your application, including files and dialogs. Also, because TrueType provides more fonts at more sizes and in more styles, Windows version 3.1 may consume both printer and global memory faster than Windows version 3.0 did. Check your applications with systems and printers that have limited memory.

Helv and Tms Rmn Fonts

MS Sans Serif replaces Helv, and MS Serif replaces Tms Rmn. To support Windows version 3.0 applications that use the Helv and Tms Rmn fonts, the [FontSubstitutes] section in the WIN.INI file maps Helv to MS Sans Serif and Tms Rmn to MS Serif by default. It also maps Times to Times New RomanÒ and HelveticaÒ to ArialÒ.

Potential Problem

Applications that hardcode a search for Helv or Tms Rmn may encounter difficulties after not finding these fonts.

Test

Examine your application code and be sure there are no dependencies on the font names Helv and Tms Rmn.

Font Enumeration

Applications should test to ensure that TrueType fonts are enumerated correctly and that they encounter no unexpected font mapping, such as might occur when a TrueType font substitutes for another font and line spacing changes and/or documents reflow.

Windows continues to support and is fully backward compatible with ATM, FaceliftÔ, and Intellifont for Windows. Applications using these other font technologies should encounter no problems.

TrueType Only Checked

Windows version 3.0 applications may behave unexpectedly if the user has set the Show Only TrueType Fonts In Applications check box using Control Panel.

Potential Problem

An application may fail to locate any fonts if only TrueType fonts are present.

Test

In Control Panel, choose Fonts, select TrueType, and select Show Only TrueType Fonts In Applications.

Check the font dialog in your application. It should list all the TrueType fonts and should not list non-TrueType fonts.

Font Sizes

TrueType supports a wide variety of sizes for all TrueType fonts. In Windows version 3.1, an application usually gets the requested size if it requests a very small or very large font.

Potential Problem

An application that checks for the smallest or largest font by setting the nHeight parameter in CreateFont to an extreme value will not get the expected results.

Test

Check fonts in dialog boxes, tool bars, and sample files for your application. Be sure they are all readable.

FontSubstitutes

The [FontSubstitutes] section may cause the GetTextFace function to return a facename that the EnumFonts function does not enumerate. This is done so that an application that asks for Helv (and expects Helv) gets a font named Helv.

Potential Problem

An application that expects matching facenames from the EnumFonts and GetTextFace functions may encounter mismatches.

Test

Check the application code and be sure there are no dependencies on GetTextFace and EnumFonts matching.

ABC-Spaced Fonts

Potential Problem

ABC-spaced fonts can lead to misplaced cursors, highlights that do not encompass all the text on a line, “pieces” of characters left behind after screen updates, and unexpected clipping of fonts on printers (when a character goes outside the printable area).

Tests

1.Create a document in your application that contains characters close to the edge of the screen and the printable margins. Scroll the document, checking for characters (or pieces of characters) left behind.

2.Highlight text. Be sure the highlight encompasses all characters and that no part of any character (especially the first and last characters) is left out.

3.Print the document. Be sure that no characters are clipped at the edges of the printable region.

Third-Party Type Manager Problems

Potential Problem

Be sure to try your application with ATM, Facelift, or Intellifont for Windows fonts installed. Do not install more that one of these font managers at a time. Skip this test if your application does not work with these font managers under Windows version 3.0a.

Tests

1.Create a document under Windows version 3.0a using a type manager (such as ATM), bitmap, and device fonts. Look at the document under Windows version 3.1, and be sure the screen appears the same.

2.Print the document with Windows versions 3.0a and 3.1, and be sure the output is identical.

Font Enumeration

Windows version 3.0 applications sometimes create multiple instances of a single font or font family. In particular, some applications handle fonts that a nonraster printer enumerates as different from fonts enumerated for the display, even if the names are the same. TrueType fonts with the same name are identical regardless of the output device. Some Windows version 3.0 applications assume that scalable fonts cannot be available on nonscaling devices. In such cases, the applications intentionally enumerate a single size for every TrueType font even though other sizes are available. Furthermore, some applications assume that bold, italic, and bold italic are always simulated from regular fonts. This is not true with TrueType fonts.

Potential Problem

An application may create multiple instances of the same font.

Tests

1.If your application assumed that scalable fonts could not print on nonscalable devices, such as a PCLÒ printer, it will have problems enumerating fonts. Check the font dialog and sizes listed for TrueType fonts. Many sizes for each TrueType font should be listed.

2.TrueType fonts are shipped in regular, bold, italic, and bold italic. This can cause problems for applications that assumed styles were always simulated. Check the font dialog to be sure that each font is listed only once.

3.TrueType fonts appear for both printer and screen. This causes problems for applications that assume printer and screen fonts are always different. Select a nonraster printer (for example, PCL) and check the font dialog to be sure each font is listed only once.

Mixing Device, Bitmap, and TrueType Fonts

In Windows version 3.1, some fonts, such as the Symbol font, may be supported by a TrueType font, a GDI bitmap font, and a device-specific font. Applications can get unexpected results when printing waterfalls. For example, a Symbol waterfall to a dot matrix printer intermixes the Symbol bitmap with TrueType Symbol. Because no Symbol font is designed for dot matrix resolution, the results can be spectacularly ugly.

Potential Problem

Printing may mix device, bitmap, and TrueType fonts, causing unacceptable output.

Test

Create a document with a nonscalable printer installed, using a device font and a TrueType font. Both fonts must have the same name. Print.

Desktop Publishing and International Characters

Windows version 3.1 includes 22 new international and desktop publishing characters. Unfortunately, these new characters appear only in TrueType fonts; the bitmap fonts do not have them.

Potential Problem

Changing to a bitmap font causes the new characters to appear as “blots.” Some applications may remap the character code range (128 to 159).

Tests

1.Use a TrueType font to create a document using the desktop publishing and international characters. Be sure the characters appear correctly on the screen.

2.Select a bitmap font, and then change to a TrueType font. Be sure the characters still appear correctly.

3.Print the document. Be sure the printout is correct.

4.Using the Character Map applet in the Accessories group of Program Manager, use a TrueType font to copy the desktop publishing characters to the Clipboard and paste them into your application. Be sure the characters appear correctly.

Note The desktop publishing characters will not be available to dialog boxes that use bitmap fonts exclusively (such as the Find and Replace dialogs).

Text Rotation

Although Windows version 3.0 can rotate vector and device fonts, under certain mapping modes it rotates these fonts differently. For compatibility, Windows version 3.1 also rotates fonts differently. However, an application can override this default behavior and direct Windows version 3.1 to rotate all fonts the same by setting the CLIP_LH_ANGLES bit in the lfClipPrecision member of the LOGFONT structure. When this bit is set, Windows version 3.1 rotates all fonts using the same left-hand rule as Windows version 3.0 uses to rotate device fonts.

Other Considerations

Some applications do not request point sizes correctly. For bitmap fonts, the results are acceptable because only these fonts have a limited range of sizes available. For TrueType fonts, output can be unacceptable because any size requested is available.

Applications sometimes set the tmCharWidth to request specific fonts, but Windows now stretches or compresses a TrueType font to match the requested width. Some applications make assumptions that work for bitmaps in many cases but that lead to squashed or clipped lines with TrueType fonts.

Windows version 3.1 adds 13 or more fonts to the default list. Some applications may break when more fonts of more types in more styles are enumerated. They do not have test cases that can account for the additional fonts.

Enhanced-mode Windows

COMM Driver

Performance and functionality of the Windows version 3.1 COMM driver are improved as follows:

COMM.DRV provides its own interrupt handling in Enhanced mode. In Windows version 3.0, the virtual communication device (VCD) provided the interrupt routine so that interrupts for Windows applications could be handled at ring 0. In Windows version 3.1, a new function allows COMM.DRV to register its own ring-0 handler, ensuring that all communications code exists in COMM.DRV. The VCD can still support COMM drivers that are compatible with Windows version 3.0 by adding the SYSTEM.INI switch COMMDRV30=TRUE in the [386ENH] section.

Both COMM.DRV and VCD read the COMxBASE and COMxIRQ settings in the SYSTEM.INI file to determine the base addresses and IRQs for COM3 and COM4; reading values written into the BIOS data area is no longer required. Although for compatibility these settings are in the [386ENH] section, COMM.DRV also examines them when running in Standard mode.

COMM.DRV supports the FIFO on 16550A UARTs. By default, COMM.DRV enables the FIFO if the FIFO is available, but the user can disable the FIFO by using the COMxFIFO setting in the [386ENH] section of the SYSTEM.INI file.

COMM.DRV baud rate is limited only by machine capability, so communication applications need not limit baud rates to 19200. Some users do have hardware capable of faster rates, and they don’t like being stuck with an artificial limit.

Potential Problem

Changes to COMM.DRV could affect any application that uses the communications driver.

Test

You can test most changes to COMM.DRV by sending and receiving data in your application at various baud rates.

Virtual Printer Device

The standard setup no longer includes the virtual printer device (VPD). In Windows version 3.0, the VPD detects contention between multiple VMs attempting to access the same LPT port. To detect contention, VPD traps I/O for LPT ports, which creates too much overhead for devices that use LPT ports, such as network adapters, SCSI adapters, and external hard disks. Windows version 3.1 eliminates the overhead by not installing the VPD.

Potential Problem

Although changes to the virtual printer device installation should not affect applications, Windows version 3.1 cannot detect the rare case of two applications attempting to print through the same port at the same time.

Virtual DMA Device

In Windows version 3.1, VDMAD supports auto-initialize DMA as long as the region being used can be locked and does not have alignment problems. This means that TSRs and device drivers can use auto-initialize DMA with global memory. VDMAD also deals with DMA globally rather than through VM. This means that most global users (network, disk, and so on) no longer need a separate virtual device to coordinate their DMA activity when they set up DMA transfers using hardware interrupts. Finally, all bugs in the virtual DMA services implementation have been fixed; relying on private versions of VDMAD is no longer necessary.

Potential Problem

Changes to the VDMAD may affect applications that include their own version of VDMAD.

Test

If your application has a custom VDMAD, thoroughly test the application with the new VDMAD. Also, be sure that your installation program does not overwrite the device=*VDMAD setting in the SYSTEM.INI file.

Virtual Timer Device

In Windows version 3.1, the virtual timer device (VTD) does not trap the I/O ports used for accessing the system timer chip. This allows more MS-DOS software to run better in VMs because I/O trapping adds significant overhead. The VTD keeps timing in sync by watching other activity, for example, by counting hardware interrupts that are not passed to the BIOS. Thus, the VTD does not prevent applications from reprogramming the timer to different rates. The TrapTimerPorts setting was added to the SYSTEM.INI file to revert to Windows version 3.0 compatible behavior if problems do occur because of this change.

Potential Problem

Changes to the virtual timer device may affect your non-Windows application.

Test

Start several other non-Windows applications, and then start your non-Windows application and check for timer problems. If problems arise, set the TrapTimerPorts setting in SYSTEM.INI and try the tests again.

Virtual Display Device

In Windows version 3.1, the standard virtual display device (VDD) for VGA is modified to demand page video memory. Thus, you can run graphical MS-DOS applications in a window or in the background on VGA systems. This VDD must track video memory usage, so it is not compatible with any of the super VGA display drivers that must access more than 256K of video memory. To run these display drivers, a user must use either the VDD provided by the display adapter manufacturer or the VDDVGA30.386, which is included with Windows version 3.1. Demand paging of video memory may break TSRs that worked with Windows version 3.0. The difference is that the VDD virtualizes access to video memory; in Windows version 3.0 the display driver had full reign over memory.

Potential Problem

Changes to the video device driver may affect applications that work directly with video memory and TSRs.

Test

Start your application or TSR in one or more virtual machines, and then switch between virtual machines, watching for problems with the display.

FastDisk (WDCTL)

FastDisk allows specific virtual devices (currently WDCTL) to access secondary storage devices directly. WDCTL supports Western Digital and compatible controllers. This device speeds up disk activity and allows demand paging of running VMs.

Test

FastDisk should not affect any applications. Be sure you are running it while testing your application.

Printing

Most of the printing changes can be tested by printing documents from your application with Windows versions 3.0a and 3.1 and comparing the output. Try to print documents that represent the types of images your application is capable of printing. You must test with the printers listed below; you should try others.

PostScriptÒ

LaserJetÒ II

LaserJet III

Dot matrix

Renamed Printers

The printer names have been renamed, and your application could have problems with an upgrade if your application or documents referred to a specific printer. For example, if your application explicitly looks for the printer name “PCL/HP LaserJet,” it will no longer find this name. Note that renaming the printer does not affect soft fonts.

Test

Bring a document created with your Windows version 3.0a application to Windows version 3.1 and print it. Be sure there are no error messages and that it prints correctly.

PostScript Driver

The GETEXTENTABLE escape has been removed.

Test

Check you application code for this escape.

Universal Printer Driver

In Windows version 3.1, with the exception of PostScript and a few other printer drivers, most printer drivers are based on Universal Printer Driver technology. This technology provides uniform support and behavior for drivers in areas such as font mapping, color mapping, escapes, and ExtDeviceMode and DeviceCapabilities functions. It also makes DIB support available for dot matrix printers.

Applications can now rely on the values that the DeviceCapabilities function returns to design their print dialog.

PCL 4 Driver

The PCL driver changed in the following ways:

Default resolution is 300 dpi for Windows version 3.1. In Windows version 3.0, it was 75 dpi.

The driver no longer requires a separate text band when printing at 300 dpi if there is enough free memory for a full-page band.

The driver clips text vertically using the following formula:

if (y + lpFont->dfInternalLeading < rcClip.top || y >=

rcClip.bottom)

return 0;

The driver automatically tracks memory. If you encounter an out-of-memory error, be sure you set memory configuration correctly. If the memory configuration is correct but the document still generates out-of-memory errors (even though it prints under Windows version 3.0), please send an electronic copy of the document when you return the checklist.

The following escapes are removed:

EXT_DEVICE_CAPS

EXTTEXTOUT

FLUSHOUTPUT

GETEXTENTABLE

GETFACENAME

GETSETPAPERORIENT (new ResetDC function provides the same functionality)

GETTECHNOLOGY

SETALLJUSTVALUES

The following escapes still exist for compatibility, but we recommend that you get the same information by using the DeviceCapabilities function.

Printer settings are now saved in the WIN.INI file under the [device,port] section instead of under the [driver,port] section. For example, the WIN.INI file may now contain an [HP LaserJet IIP,LPT1] setting instead of [HPPCL,LPT1]. This implies that more than one printer within a driver can be connected to the same port at the same time while each retains its own settings.

A new [PrinterAliases] section in WIN.INI supports custom printer names.

The installation of HP/PCL soft fonts and external cartridges doesn’t change—the information is still saved under the [driver,port] section. Thus, if you install a soft font on LPT1, all HP laser printers connected to LPT1 see this soft font.

In Windows version 3.0, HPPCL.DRV has GDI simulate a bold typeface for a device font if a bold version is not available; the Windows version 3.1 driver does not.

Applications that rely on the Windows version 3.0 driver to always enumerate the first full-page text band and subsequent graphics bands should remove this dependency. The Windows version 3.1 driver can put text into graphics bands and can put graphics into the first band.

Other Dot-Matrix Printer Drivers

Dot-matrix drivers changed as follows:

Printable regions increased on many dot matrix drivers.

Color support was added for FujitsuÒ and NECÒ drivers.

Some resolutions changed on some drivers. Removed “odd” aspect ratios and put in aspect ratios closer to 1: for example, NEC24.DRV changed 60 x 180 to 120 x 180.

Because of black and white printer driver dependency on the screen, some changes may be the result of screen driver changes.

Applications should test for color DIB printing using a color driver.

Other Core Enhancements

Most core enhancements affect applications only if they made assumptions about internal structures or internal operations. Most of the testing for this section involves looking at the changes and reviewing the code for your application. Below is a list of the things you need to look for.

An application making assumptions about internal data structures.

An application building its own selectors.

Press CTRL+ALT+DELETE while your application is running. Be sure Windows continues to function after your application terminates.

There are the following changes:

Structure of kernel internal memory objects has changed. Applications that made assumptions regarding these internal structures will most likely be broken. TOOLHELP.DLL has been added to Windows version 3.1, which provides a documented interface for accessing internal data.

Kernel now runs at ring 3 (instead of ring 1 as in Windows version 3.0) to prevent ill-behaved applications from relying on the relationship between handles and selectors. This does not affect the I/O privilege level (IOPL) of applications and drivers.

GP Fault Cleanup. If one application GP faults, Windows cleans up its internal state and allows the system to continue running after terminating that application.

Local CTRL+ALT+DELETE. Users can kill a single Windows application or a single VM by pressing CTRL+ALT+DELETE. The rest of the system should continue running.

Watson and Continue button. Dr. Watson is included but not installed by default. If the user installs Dr. Watson, this application reports and logs data on application error. For some GP faults, Dr. Watson gives the user the option to continue running the application, resetting the instruction pointer (IP) register to the instruction following the GP fault. Pressing the Continue button bypasses GP faults until the next task switch.

Real mode is removed.

We correctly reflect floating point exceptions to virtual mode, allowing applications that use their own floating point packages to work correctly. Kernel correctly saves and restores the state of floating point interrupt functions, allowing WIN87EM.DLL to coexist with other floating point emulators.

UMB mechanisms defined for XMS are supported, allowing software such as EMM386, 386-MaxÔ, and QemmÔ to load networks and other devices in HIMEM. Windows is fully backward compatible with versions 5.x and 6.x of Qemm and 386-Max.

Smartdrive 4

Windows version 3.1 includes a new high-performance disk cache. Applications should test with this disk cache enabled (Setup enables this by default) to ensure that no side effects occur.

Tests

1.Read files from disk.

2.Write files to disk.

3.If your application uses the floppy drive or can read and write files to the floppy drive, try those operations with caching enabled on the floppy.

CheckList

Application Name:

Version:

Date of Shipment of Application:

Company Name:

Company Address:

Company Representative*:

Phone #:

Fax #:

* Please give the name of the person who Microsoft should contact with information regarding the test results or problems.

General Instructions

Try each of the operations listed for each section, if they apply to your application. Include a description of the operations you tried in the Comments section. Also include information about why you didn’t try an operation if this is the case.

Application Installation Programs

Comments:

Windows Setup

Comments:

Shell Application

Comments:

Windows Shell Applications

Comments:

Multimedia and Sound

Comments:

Window Management

Comments:

TrueType

Comments:

Enhanced-mode Windows

Comments:

Printing

Please include the documents you printed when returning this form to Microsoft.

Comments:

Smartdrive 4

Comments:

Local CTRL+ALT+DELETE

Comments: