Re: Windows Resource Limits (was Re: Pathfinding)

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Sun, 2004-05-09 at 03:37, Hans Ronne wrote:
> 
> Since the problem was with Tk84.dll, you could also test if Tk83.dll works
> with the original Win95. 

I had considered this, but I don't know whether it is worth regressing
the Tk version on behalf of the likely non-existent Win95 user base. My
guess is that most of the remaining Win95 "user base" consists of
retirees who had it set up with dial-up networking on cheap, old
Packard-Hells 7 or 8 years ago by their grandchildren before they went
off to college. Or corporate employees whose lethargic, incompetent IT
departments haven't yet got around to updating their "standard
workstation" distribution yet. These segments probably aren't
particularly interested in Xconq (at least not on their Win95
platforms).

> Otherwise, I think anybody still running Win95 out
> there should have updated, but then again, if you don't update the OS
> itself for 10 years, perhaps you don't care about service packs either ...

Or Xconq...

Or the security vulnerabilities of having an unpatched Win95 connected
to the Internet...

> One solution would be to get rid of terrain images altogether on pre-NT
> systems and only use solid colors. But this seems like a draconian fix when
> most games work fine.

Agreed. We should try to avoid this.

> There is not much info about this problem on the web, but here are some
> links I found:

Yes, avoiding memory leaks seems to be the theme:

http://wiki.tcl.tk/3731

since Windows apparently isn't smart enough to track and dealloc GDI
memory used by window components when the master window/thread quits.

However (I haven't looked at the graphics code yet), my guess is that
one particular window (the map widget) is hogging the GDI memory.
Perhaps we could implement some sort of swapper, where we set a high
water threshold for the amount of GDI mem to consume? If we need
anything past that threshold, we start freeing up some of earlier
allocations by "swapping" them out to the app's normal heap memory. We
would have to tag these pieces with their "swap" status and always check
the tags before trying to use them (to see if they needed to be swapped
back in to GDI memory). I don't whether this is feasible or not; I have
been deliberately avoiding looking at that code since I am not really
into graphics stuff.

Eric