WinFSR 2.1 by Fran Finnegan (76244,145) Copyright (c) 1991-92 Finnegan O'Malley & Company Inc. All Rights Reserved. First Published in PC Magazine, November 12, 1991. ------------------------------------------------------------------------------- MONITORING FREE SYSTEM RESOURCES: Use WINFSR.EXE to keep a constant eye on your Free System Resources in Windows 3.x. ------------------------------------------------------------------------------- MONITORING FREE SYSTEM RESOURCES If you execute the Help About command in the Program Manager or File Manager (or the File About command in the MS-DOS Executive), Windows pops up a dialog box that displays the amount of Free System Resources (FSR) available to your system. You may ask: What are Free System Resources and why should I care? FSR are really nothing. Literally. They are not resource objects lurking within Windows waiting to be used, nor are they a reference to the System Resources described on page 494 of the Windows User's Guide. Free System Resources is just a fancy name for the amount of free local memory, expressed as a percentage, that's available to two key Windows components: the Graphics Device Interface (GDI.EXE) and the User Interface (USER.EXE) These two modules plus the Kernel module (KERNEL.EXE, KRNL286.EXE or KRNL386.EXE, depending on whether you're in Real, Standard or 386 Enhanced mode) comprise the Dynamic Link Libraries (DLLs) that are the heart and soul of Windows. But why should you care? Simple: without FSR you can not run Windows applications. As you do run Windows applications, they use up available FSR. If you run a number of big Windows applications (such as Excel and Word for Windows) at the same time, you may run out of FSR and lock up your machine. No matter how much free system or global memory you have (historically the constraint faced by users), I guarantee you that someday you'll run out of FSR as you run more and more applications concurrently. The management of the FSR rests with the USER and GDI modules mentioned above. These DLLs each contain multiple executable-code segments and a single default data segment (so-called local memory of the DLL). The Intel 80x86 architecture constrains these segments to a maximum size of 64K bytes. The single default data segments of GDI and USER are used by Windows for performance reasons: Accessing objects in these data segments with "near" pointers is relatively fast. Since Windows stores many objects (such as windows, dialog boxes, controls, icons, cursors, bitmaps, menus, pens, and brushes) in the data segments of GDI and USER, the 64K local-memory limit becomes a significant and easy-to- reach constraint if you run a lot of Windows applications concurrently. So instead of a DOS 640K barrier, we now have a Windows 64K barrier. It's disheartening to think that a 486 machine with 16MB of real global memory running in 386 Enhanced mode can not run one copy of Word for Windows and five copies of Excel without hitting the wall imposed by compatibility with the over- ten-year-old 8086/8088 chip! The fifth or sixth copy of Excel will probably lock up your machine, forcing a cold re-boot. You would lose anything you hadn't saved, and without constantly remembering to check the FSR, you wouldn't even see it coming! It might be helpful to know how much FSR your applications use. You can experiment by running Program Manager's Help About command before and after you launch an application. If you start up Windows with nothing but Program Manager running, you will see that your FSR percentage is about 75-80%. (The actual number may be greater, depending on how many icons you have displayed in Program Manager; each of these icons takes up some FSR.) You'll find that running Word for Windows consumes 8% of FSR. The first copy of Excel requires 18% of FSR while subsequent invocations use up 12%. Experimenting with your applications to see which ones hog FSR may be helpful. But the solution to this problem is for Microsoft to move some of the objects stored within the 64K default data segments of GDI and USER out into global memory. For example, in Windows 3.1 they have moved menus out of USER's data segment and stored them in global memory. The FSR problem is still with us in Windows 3.1, but to a lesser degree. Since the FSR constraint will be with us for a while, we might as well be able to monitor it. Unfortunately, Microsoft does not document how the FSR percentage is calculated. As such, it's taken independent Windows applications developers about a year to figure it out. The key to calculating FSR lies in an undocumented Windows 3.0 call: extern DWORD FAR PASCAL GetHeapSpaces(HANDLE hModule); This function is exported by the Kernel modules as ordinal 138. (Because it's undocumented, application developers would have to explicitly import this function in their .DEF files.) It accepts a handle to a module, the sort of which you would get with the call: GetModuleHandle("USER"); GetHeapSpaces returns a DWORD in which the low word is the number of bytes of free local heap space and the high word is the number of bytes of maximum local heap space. (Both values take into account local heaps that have not been physically expanded to the 64K limit.) Dividing the low word by the high word and multiplying the result by 100 yields the percentage of free local memory for the requested module. Since the FSR value used is the minimum of the GDI and USER values, this calculation must be performed twice. Armed with this knowledge, I've written a small utility named WINFSR, which allows you to watch your FSR without having to open the About boxes. WINFSR constantly monitors the FSR value and displays the percentage in an icon. You can also display a larger dialog box containing the FSR value, as well as the USER and GDI values. WINFSR.EXE and WINFSR.ZIP (which contains the source code shown in Figure 1) can be downloaded from PC MagNet. The logic of WINFSR is pretty straightforward. It's made up of only three C functions. An iconic window and a dialog box are created to display the results of the FSR calculation. The calculation is then performed once each second (on a WM_TIMER message), and the displays are updated if the FSR's components change. If you want to just keep an eye on the FSR percentage, you can select the OK button on the dialog box to hide it; only the stand-alone icon will remain on-screen. To unhide the box, click on the icon to bring up the System menu and choose Restore or Maximize. Since Windows or applications or both will most-likely crash if FSR gets too close to 0% , the dialog box serves as a warning mechanism. By default, the dialog box will re-appear if FSR gets below 20%. At this point, you should probably save any open files or close some applications. If you would rather be warned at a different percentage, say 10%, you should add the following section to your WIN.INI file: [WinFSR] %=10 The %=x line determines the trigger point at which the dialog box will be re- displayed. Watching the dialog box can be instructional to Windows application developers. For example, they can use it to see if they leave any undeleted objects in GDI by comparing the GDI usage values from before and after their applications run. Windows application developers should note that Windows 3.1 will have a documented function to get the FSR number, although its name hasn't been finalized at the time I'm writing this. WINFSR will have be updated to use the proper functions depending on your version of Windows. ------------------------------------------------------------------------------- OPENING WINDOWS Share your Windows experiences with Fran Finnegan; we'll pay you $50 for any tip we print. Mail your contribution on a disk, with a printout, to Windows, PC Magazine, One Park Avenue, New York, NY 10016, or e-mail it (re: PC Magazine) to: PC MagNet: 76244,145; MCI Mail: Fran Finnegan; BIX: franfinnegan; GEnie: finnegan; Internet: finnegan@well.sf.ca.us.