Combining Ideas on Resource Allocation

Peter Coffee: Readers offer ideas for keeping memory-hogging applications in check.

Many readers shared their reactions to last weeks epistle on the need for more restraint in resource use by applications. Comments fell into three distinct groups.

First, and most reproving, were the reminders I received about the proper role of the operating system. As I told reader Lou Solomon, Senior Technical Manager at Intercounty Clearance Corp., "Mea culpa. Sometimes I forget that desktop operating systems should actually be written as operating systems, instead of as program loaders and device managers with bundled applications and GUI shells." Bounds on resource use, warnings of anomalous situations and containment of application failures are jobs that the OS should do—no question.

In practice, though, I tend to think of the operating system as the contractor that runs my computer, while relying on utility products such as Norton SystemWorks to be the equivalent of an auditor. (I confess that this metaphor isnt nearly as reassuring as it used to be, in the wake of the Enron fiasco.) Moreover, since I talk primarily with application developers, I tend to think in terms of what developers individually can do, instead of what infrastructure providers should do. One could call that lighting a candle instead of cursing the darkness, or one could call it an example of declaring that darkness is now the standard—instead of changing the light bulb. The problem is, we cant get at the light bulb, although we do have the option of ripping out the fixture and putting in something thats brighter, safer, and more efficient.

Sad to say, these readers werent hopeful that users would embrace more rigorous operating system facilities: One reminded me that the manual memory allocations for Macintosh applications were widely reviled as more primitive than Windows hands-off behavior. Yes, but its only the Windows user who functions in hands-off mode: Windows certainly has its own hands on users wallets as it demands ever more resources for the same core set of enterprise tasks.

The second group of reader letters offered further examples of the problem. I heard about system monitoring utilities that cluttered disks with tens of thousands (really!) of zero-length files, streaming media services that generate gigabytes (yes, I mean that literally as well) of cached content, browsers whose cache-clear commands dont work, and enough other horror stories to relieve any doubt about the pervasive carelessness of end-user software.

What struck me about these stories was the difficulty that people had in finding out where their problems lay. It reminded me of a panic-stricken call that I got this past weekend from a user who wanted to move data from one machine to another, migrating in the process from one application to another with a similar function. Her problem was that she had no idea of what file her application was using to store the data—or in what form. Her "projects" folder contained a bakers dozen of files with arbitrary, application-generated names and mysterious file name extensions.

I talked her through the process of using the Windows file search utility to locate the files that had been modified that day, and sorting by modification time stamp to identify the candidate files; we then cracked them open, one by one, with WordPad until we found the lengthy memo entries that she was hoping not to retype. A few manual cleanup operations finished the job and produced clean, cut-and-paste-able text.

Whats the connection between this incident and our present concern with careless applications? I found myself wondering if I could easily automate the interaction between an application and the Find utility so that, upon quitting an application, I would see a list of the files that had been created or changed by that session. If you know of anything like this thats available off the shelf, Id appreciate a pointer. It seems like something that could uncover a host of nasty behaviors before they become showstoppers.

Finally, I got reader comments that recommended specific software choices to reduce Win9x resource problems. The Opera browser, for example, which in fact Im already using, was recommended for its superior management of multiple concurrent browser sessions. (If you havent seen version 6.0, go download it now from At the top of the list, though, was one strong recommendation: Stop using Win9x.

As I told the readers who made that suggestion, Ill stop when eWEEKs readers (or rather, the users supported by eWEEKs readers) are themselves ready and able to leave Win9x behind. When I spoke, though, a few months ago with a subset of our Corporate Partner advisory board about their timeline for any general upgrade to Windows XP, they told me that they have far too many applications and devices that demand Windows 98 for them to be able to banish it from their realms—no matter how dearly theyd like to do so.

Im currently looking into the use of virtual machines, with Connectix Virtual PC or VMware Workstation, to host a Win98 session on a machine running Windows 2000. Im hopeful, but my optimism is guarded. In the meantime, I have Win98 on the laptop that I use at work: I want to see the problems firsthand.

At home, though, Ive made the move to Win2K Pro—and Im thinking of shifting the family to Mac OS X. If you dont mind my asking, whats in your family room? Whats on your enterprise desktops? And what do you think will be in those places a year from now?

Thanks for all your letters: keep them coming.

E-mail eWEEK Technology Editor Peter Coffee