On Tue 09 Mar, Raab, Andreas wrote:
> Tim,
> 
> > A _much_ better solution would be to find some way to convince Windows to
> > return memory chunks with higher addresses.
> I can do this - all I'd have to do is to dig up the GNU (or some other)
> malloc implementation that allows me to supply a custom sbrk().
That would be great, if it can be done without too much trouble. It would
provide for having objects of any class that are non-moving, allocatable from
either Squeak or C code and lockable (in case the Ccode wants to keep them even
when Sq has no further references).
 
> PS. I'm still not convinced that Windows is the only platform where this
> might be a problem ;-)
You may well be right, but I haven't run across another case yet. IIRC this was
a problem for PPS in a similar way, back when we were doing ObjectWorks 4.0 -
and again only Windows (3.0 in that case!) was a problem.


AND;
On Tue 09 Mar, Stephen Pair wrote:
> > Another
> > route to getting much of the functionality that
> > this provides might be
> > a decent memory proxy setup, perhaps using the weak pointers
> > stuff to free it.
> > Anybody done that?
> 
> I created an ExternalByteArray class that does it.  Maybe I could find
> sometime to dig it up and clean it up this weekend if anyone is interested.
> It shares ByteArray's protocol and uses finalization to free the external
> memory.
>
This would solve my immediate problem (actually, the stuff I have does, but
until and unless Andreas can deal with the above, it's not portable and that is
not acceptable to my mind) and might solve a simialr problem Andreas was
talking about recently. The main problem with any sort of proxy is that prims
like BitBlt would need some ugly mods to allow their use as Bitmaps or
whatever. However, for OS resource handle type doodahs they're great.


tim

-- 
Useful random insult:- A .22 caliber intellect in a .357 Magnum world.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>