Re: 7.5 release? - How you can help

[Juergen Ruehle <j dot ruehle at bmiag dot de>]

Hans Ronne writes:
 > 3. Fix the memory problems on Windows. This is the big  one. Several game
 > modules crash under Windows 98, probably due to the limit on the GDI
 > resource memory. In fact, after I updated the game modules, adding some
 > more images to imf.dir, every single game crashes under Windows 98 (this is
 > one reason why I haven't checked in these updates yet).
 > 
 > I don't think it is acceptable for a release version of Xconq to crash with
 > 100% certainty on what is still one of the biggest installed platforms
 > worldwide, even if it works fine everywhere else. However, I'm not sure
 > what to do about it. I guess we could rewrite the imaging code so that it
 > uses less memory, possibly fix some leaks, but this is quite some work. And
 > it would probably only fix things until the next game module update adds
 > even more images.
 > 
 > I would therefore be very interested to hear if there are any known
 > shortcuts or hacks to deal with the GDI resource problem. It is after all a
 > well-known limitation in Windows 98 that many programmers must have
 > stumbled on before.

AFAICT (from some debugging sessions on the Win95 installation I use
to play games) the situation is as follows:

 - Tk (and/or xconq win32 glue code?) grabs GDI resources on image
   creation (and the GDI heap is restricted to 64k or something in
   Win9x because of Win3.1 compatability; this restriction does not
   exist in NT)

 - when the resources are exhausted image creation fails (i.e produces
   a warning and returns null)

 - when this null image is used somewhere xconq crashes

Unfortunately I'm not familiar with neither Tk images on windows,
xconq image handling, nor the xconq image drawing code. But it seems
like fixing the resource requirements altogether would require changes
to Tk. That leaves fixing the crashes on null images as a first step
which will probably result in a seriously degraded display on Win9x,
but is a good idea anyway, because one can probably create the same
crash by some other means. In a further phase it could be evaluated
whether it is actually neccessary to have all the images instantiated
all the time and what kind of performance impact there is to
instantiating the images on demand.

But I'm completely out of my depth here, so this might be complete
****.

jr