Years ago, the Windows SDK (Software Development Kit) shipped with an applet named SHAKER.EXE. This applet simply ran around allocating and releasing memory blocks. When and what it actually allocated or released was random!
What was it for, then? Well, before the days of protect mode and virtual memory addressing, you could access any arbitrary memory location through a simple pointer (using C as a programming language, of course). Often, and erroneously, these pointers would be stored in nonrefreshed static variables as an application yielded control to the operating system. This access—or similar access—would cause the problems for which SHAKER.EXE was used to try to uncover.
In between handling one event and a subsequent one, Windows could move (as it can now) both your code and data around. If you’d used a static pointer to, say, point to some data, you’d quickly discover that it was no longer pointing to what you intended. (Modern virtual addressing methods make this problem go away.) So what was the point of SHAKER.EXE? It turned out that, back then, even though your application was being naughty and had stored a static pointer, you didn’t know it most of the time; the Windows memory manager hadn’t, between your handling of two events, moved your data around. The bottom line was that you didn’t really know you had a problem until memory moved, and on your machine, that rarely, if ever, happened! Customers, however, did see the problem because they were running both your application and others and had loaded their systems to a point where the memory manager, to accommodate everyone, was starting to move memory blocks around. The whole thing, as someone at the time pointed out, was pretty much like attempting to hold a party in a small closet. Initially, everyone had plenty of room. As more people arrived and the closet filled up, however, some of the guests were bound to get their feet stepped on sooner or later! SHAKER.EXE literally shook the operating system on the developer’s machine until something fell off!
OK, so why the history lesson? Basically, the lesson is a good one and one we can still use. In fact, an associated application, named STRESS.EXE, still ships in Visual C++. (See Figure 1-5.) (STRESS.EXE is available for Windows 95 only, not for Windows NT.)
Figure 1-5 Stress me (STRESS.EXE)
Like SHAKER.EXE, STRESS.EXE is used to make the operating system appear more loaded/busy than it actually is. For example, by using STRESS.EXE you can allocate all of your machine’s free memory, making it look really loaded.
Tools such as STRESS.EXE can present your code with a more realistic, perhaps even hostile, environment in which to work. Such conditions can cause many hidden problems to rise to the surface—problems you can fix at that point instead of later in response to a client’s frustrated phone call. I’d certainly recommend using them.