By Karen Kenworthy
Click Here to see a
6.60KB bitmap image of artwork
which goes with this article, entitled:
Hire a Hack
LEGEND HAS IT Microsoft's Windows developers work behind the scenes to make trouble for popular third-party applications. Many believe our friend in Redmond adds code to each Windows release to cause subtle problems for competing apps. In fact, there's a persistent rumor that one development team's motto was "Windows isn't done until [insert your favorite non-Microsoft app here] won't run."
If you look closely, though, you'll find Microsoft works very hard to support older apps. Some evidence
is in the Windows 3.1x and Win95 configuration file WIN.INI. Under the section [Compatibility], you'll find a series of mysterious lines, each of which starts with some text, followed by an equal sign. Next comes a 32-bit number, expressed in the C language's hexadecimal notation (the hex digits are preceded by "0x").
The result looks like this:
What do these lines mean? The text entries are the names of programs that have trouble working correctly with the current version of Windows. Usually, these names are the same as the program's disk file name (without the .EXE extension), but they're actually the program's "internal" name-a name the program's author assigns and embeds in the .EXE file.
Look closely at your own WIN.INI file, and you'll see some interesting, familiar names in the [Compatibility] section. These names are just the beginning. The 32-bit numbers that follow them are even more interesting.
During development, it's not uncommon to find several existing applications that don't work correctly under the new Windows version. Sometimes bugs within Windows cause these incompatibilities, and the programmers fix these bugs before the final version ships.
But occasionally, an older application is the culprit. In this case, problems may be harder to solve. An application may exploit a Windows feature that Microsoft has changed or removed. Or a small side effect of a Windows change may affect an application's behavior, causing anything from quirky screen updating to a spectacular program crash.
Because no Windows bug is at fault, you'd think Windows programmers would pass the buck. They could say the application program caused the problem, and the program's author must provide the fix. And sometimes they do just that. But Microsoft knows you expect your applications to work with each new Windows version. If they don't, Microsoft will take the heat. After all, the application worked before, and now it fails-and the only thing that changed is Windows.
That's why Windows' programmers write "hacks." Hacks are small bits of code that allow programs to handle special situations and solve the occasional problem. The hack's code lies dormant until the problem it's designed to solve is detected. Once activated, it works around the problem.
Which brings me back to those 32-bit numbers in WIN.INI's [Compatibility] section. Each bit in the number represents a particular hack within Windows. If the bit is set to 1, the corresponding hack is activated, allowing the associated older application to run correctly. Windows contains 32 hacks, each of which solves a common compatibility problem. The bits tell Windows which hacks each incompatible application needs.
In order to make use of these hacks, you'll need a little-known program that lets you enable them. It's called MkCompat.exe, and it's located in Windows 95's \Windows\System directory (unfortunately, Microsoft didn't ship this program with earlier Windows versions). Windows developers used this program to create the original entries in your WIN.INI files. But you can run the program by selecting Start/Run.
Within the resulting Make Compatible window you'll see a number of checkboxes. Alongside each checkbox is a short description of one of Windows' compatibility hacks. If you place a mark inside a checkbox, you enable the corresponding hack; clear it and you disable the hack.
From the program's File menu, choose the application the hack will affect. Saving your settings creates or modifies a program's WIN.INI entry. The File menu has one other interesting choice, Advanced Options. This expands the list of hacks to all 32, instead of just the five most frequently needed ones.
Now that you know how to enable hacks, you need to learn a bit about them. Unfortunately, Microsoft doesn't make this easy. Other than a couple of short paragraphs in the Windows 95 Resource Kit, there is no publicly available documentation describing the hacks. In fact, I've been told there's no documentation of the hacks within Microsoft either, other than Windows source code.
Nevertheless, I've been able to piece together some information. Here's a brief description of some common hacks. Experiment with them, and you should be able to use MkCompat to solve some nagging compatibility problems.
Don't spool to enhanced metafiles. Win95 introduced a new print spool format called enhanced metafile.
The OS converts data produced by a printing program into enhanced metafile format and temporarily stores it on disk ("spools"), before sending it to the printer. Some programs that perform low-level access of this data stream will have trouble (anything from garbled output to program crashes) when running under Win95. Enabling this hack prevents the generation of enhanced metafiles.
Give application more stack space. The stack is an area of RAM an application uses to store small amounts of data temporarily. It's also where much of the communication between Windows and applications takes place. As Windows evolves, the information communicated increases, sometimes overflowing the space the application has allocated to the stack. Stack overflows can cause all manner of program crashes and bizarre behavior. This hack increases the size of the program's stack.
Lie about printer device mode size. Applications learn about the printers attached to your computer by asking Windows for a block of data known as a DEVMODE. It includes the printer's maximum paper size, possible orientations (landscape or portrait), printing resolution and whether it can print in color. Over the years, the DEVMODE block has grown to allow for more information. Windows will tell a program the current size of DEVMODE blocks, if asked. But not all programs keep up with the times. They assume Windows will always report its original DEVMODE block size. The result can be a program that doesn't recognize the presence of a particular printer, misunderstands the printer's features or crashes. This hack causes Windows to report the original DEVMODE size and return an old-style DEVMODE block.
Lie about Windows' version number. Many programs require features that weren't available in early versions of Windows. For instance, an application may require TrueType fonts, which didn't appear until Windows 3.1. As a precaution, these programs determine the Windows version that's installed on your machine, and they refuse to run if the version is too old. Unfortunately, some programs bobble this simple task, and inadvertently refuse to run if the version of Windows is too new. To placate these programs, this hack causes Windows to report an incorrect Windows version.
You may be wondering how Windows knows which version to report. Some programs are compatible with version 3.0 or higher, for instance, while others require at least version 3.1. The answer is simple. Inside each Windows .EXE file is a block of information about the program, including the Windows version for which it was designed. With this hack enabled, Windows examines the block and reports whichever version makes the application feel most at home.
Win 3.1 style controls. What we call buttons, checkboxes, edit boxes, option buttons and so on, Windows programmers call controls. Win95 brought the first significant changes in the capabilities of these controls in years, adding features and expanding capacities. For most programs, these changes are painless and provide the program with nice, free enhancements. But a few programs stumble over the new controls. For those, Windows developed this hack, which causes the controls to behave as they did under Windows 3.1x.
Mirror fonts in WIN.INI. If asked, Windows tells a program which fonts are available. But some programs bypass Windows and look for themselves. Under Win95, these nosy programs may come to the (incorrect) conclusion that no files are installed, because Win95 no longer tracks installed fonts via WIN.INI entries. Instead, it keeps all font files in a special directory (\Windows\Fonts). To determine which fonts are installed, Win95 simply examines the directory's contents. Without this hack enabled, programs that look for font entries in WIN.INI won't find any. Enabling it causes Windows to keep a copy of its font information in WIN.INI, so these older applications can continue to function.
Windows 3.1 palette behavior. Enable this hack if your application displays incorrect colors. It causes Win95 to revert to Windows 3.1x's way of managing the screen's palette, the set of colors that can be displayed simultaneously.
These, and the two dozen other hacks I haven't discussed, should give you a glimpse of MkCompat's power. The next time an older application fails to behave under a new Windows version, try MkCompat. Feel free to experiment-hacks are as easy to disable as they are to enable. With a little luck, you just may give an old app a new lease on life.
Contributing Editor Karen Kenworthy is the author of Visual Basic for Applications, Revealed! (Prima Publishing, 1994) and the manager of WINDOWS Magazine forums on America Online and CompuServe. Contact Karen in the "Power Windows" topic of these areas. Click Here to find the e-mail IDs for our editors, who can put you in touch with this author.