🚀 go-pugleaf

In <4cj2ft$7s3@clarknet.clark.net>, kunzd@clark.net (Dave Kunz - Litton) writes:
>: I had the same problem, and fixed it the same way. I just have one question
>: for those of you who have installed Fixpack 16 - do you have a problem with
>: your mouse pointer being unstable now? For example, if you're using PMPatrol
>: 4.0 and pass the pointer over the status bar, does your it SOMETIMES get
>: stuck with the big PMPatrol mouse pointer?
>:
>Yes.  For me, it seems to be linked to web explorer and ocasionally
>winos2.  Sometimes it gets bad and simply won't change properly.
>Shutting down the desktop usually fixes it (kill the 2nd pmshell process).

	The only cursor problem I've had has been while using the Web Explorer.
Basically, what happens for me, is that the cursor shape that appears when a link
is being pointed to stays, no matter where on the Web Explorer it goes.  If I move
the cursor off of the Web Explorer, it goes back to the cursor set that I've chosen,
and when I point to a link, it starts all over again.  <shrug>

	Regarding the Web Explorer memory problem, about which several people
have been going back and forth with me, I did try the page that was suggested,
and I did, indeed, have my machine run out of swap space and crash.
Unfortunately, I've had similar experiences with pages, in the past, with earlier
versions of the Web Explorer.  However, that could happen with any other
program(s) that eat up memory to the point that your system runs out of space.
You could try the COMMIT parameter, on the MEMMAN line in your config.sys file.
This particular parameter causes the swap manager to commit a page of swap
space for every page of memory that every program opens.  While this will cause
your swap file to grow, extensively, it also is shown to make sure that if you have
a parameter on that MEMMAN line to determine a minimum free space left on your
swap partition, it will stop growing at that point, providing additional crash
protection.  Below is an excerpt from CNFGINFO, the config.sys analyzer:

 <<=NEW PARAMETER=>>  A new parameter with version 2.1 is COMMIT.
 With this parameter included, OS/2 will allocate space in the swap
 file whenever a program commits memory, i.e., a page in the swap file
 is allocated for every page of memory committed by a program, even
 if the data never actually gets swapped out.  Your system should be
 more stable, but it will be slower also, since your swap file will
 grown when it doesn't have to.  If you use this parameter, increase
 the size of your SWAPPER.DAT file (see SWAPPATH line below) by
 the amount of memory you are likely to use when using the COMMIT
 parameter.  Most people "in-the-know" suggest that COMMIT not be
 used unless it is required by 16-bit OS/2 applications.

 <<=TIP=>>  You can also use the COMMIT parameter another way.
 Without COMMIT set, the minimum free noted in you SWAPPATH
 specified the point at which OS/2 gives you a message warning that
 your disk space is running low.  When you set COMMIT, the minimum
 free value noted in your SWAPPATH statement becomes the amount of
 hard disk space that will always remain free on the swap file
 partition.  Thus, with COMMIT set, you can never run out of disk
 space on your swap file partition.
	
	In any event, outside of that particular incident, I still have my swap file
shrink back down as my system usage goes back down.  What some people don't
realize is that the swap file doesn't necessarily shrink as soon as a program is
closed.  Below, see another excerpt from CNFGINFO:

 <<=NOTE=>>  Your swap file will grow (in 1MB increments), but it
 also shrinks when two conditions are met.  One, when the amount
 of free space in the swap file is greater than 1.5MB, the swap
 file will be compressed during system idle time.  (It will not
 shrink if there is a constant "hit" on the drive by a program such
 as a swap file monitor.)  Two, during the compression, free space
 is moved to the end of the swap file.  When this free space at the
 end of the swap file exceeds 1MB, the swap file will be shrunk.

 <<=NOTE=>>  See the discussion of the new COMMIT parameter for the
 MEMMAN config.sys line including the <<=TIP=>>.

	You can't expect to see your swap file shrink, instantaneously, just
because you've closed a program.  You have to give your system time to compress
the data in the swap file, removing the fragmentation, then to shrink that swap
file, based on the amount of unused swap space, after your programs have closed
and stopped making use of the swap file.

Mike "Freakdog" Burger
Sysop, the Dog Pound BBS, (215) 946-5573
mburger@k2nesoft.com
freakdog@netaxs.com
http://www.k2nesoft.com/~mburger