RP,

Thanks for the memory and handle tips. Where's the next day service 
though? :)  (just funning)

I would disagree conditionally about one thing and that is about not 
needing to lock a handle anymore, as my PICT handles take off much much 
worse in OSX than they did in pre-x.

Some of it may be that the purgeable flag makes for faster purge in X, 
but I also seemed to suffer non-resource Pictures being lost as well. 
I'll need to do more research about that one. Unless you meant only 
those that are being dereferenced.

What else is bad in X but works ok in Classic/older:

Setting an FSSpec to 0 = Quit Quit Quit

Like:
myFSSpec = 0....

also, passing 0 to a FN's FSSpec parameter which has an FSSpec 
parameter expecting an FSSpec, not a 0...boom is the result.

It's a weird universe.

I had a bad issue with Poke crashing also, as some source I was using 
passed an address to a FN as simply 'offset', but not using an @offset 
for the pass. The code worked fine in OS 9.2 in the next FN where a 
return value was poked, but poking the same in OSX caused a crash. Easy 
fix though, I just added an @ to the poked.

Question:

> Handle blocks cannot be resized smaller:
>  h = fn NewHandle( 1000000 )
>  SetHandleSize( h, 10 )
> The 'official' size of the block as reported by GetHandleSize is 10. 
> The remaining 999990 bytes have not, however been disposed of 
> (returned to the free pool). You can still read from and write to that 
> memory.

This memory -is- deallocated after the initiating handle is disposed 
though, correct?

rc


On Tuesday, July 15, 2003, at 07:03  AM, Robert Purves wrote:

>
> On Sunday, June 29, 2003, Robert Covington wrote:
>
>> In my PPC version of whatever App, I check for Mem(_MaxAvail) and if 
>> it's lacking, I cancel certain operations...
>> However, in OSX, this returns a non-correct number it would seem 
>> (perhaps the sum of my DIM System statements)
>> How does OSX handle memory?
>
>
> Memory in OS X
> --------------
>
> Virtual memory is always on.
>
> Memory allocation in the Size resource is ignored. The FB^3 statement
>   dim system 1000000
> has no effect.
>
> Each application has a huge virtual address space reserved for it 
> (nominally 4 GB, but in practice about 3.6 GB). This program, which 
> allocates itself 3 x 10^9 bytes, runs without error:
>   dim as Ptr   p
>   dim as long  j
>   for j = 1 to 3000
>     p = fn NewPtr( 1000000 ) // or h = fn NewHandle( 1000000 )
>     if ( p == 0 ) then stop "Out of memory"
>   next
>
> It is extremely rare for NewPtr or NewHandle to fail.
>
> Both mem( _maxAvail ) and mem( _freeBytes ) return a meaningless 
> constant value such as 20971520. They, and the corresponding toolbox 
> functions MaxMem and FreeMem, are useless.
>
> Existing handle blocks are unaffected by calls to Memory Manager 
> functions:
>  NewPtr
>  NewHandle
>  DisposePtr
>  DisposeHandle
> These functions do not 'move memory' in the old pre-OS X way.
>
> CompactMem, PurgeMem and MoveHHi do nothing.
>
> A pointer obtained by dereferencing a handle remains valid, unless the 
> handle is disposed of, or SetHandleSize is called on the handle (see 
> below).
>
> There is no point in locking or unlocking a handle:
>   HLock( h ) // useless
>   p = [h] // de-reference handle
>   ... // do stuff with the pointer p
>   HUnlock( h ) // useless
>
> and no point in saving the handle state and restoring it later:
>   dim as byte  hState
>   hstate = fn HGetState( h ) // useless
>   HLock( h ) // useless
>   p = [h] // de-reference handle
>   ... // do stuff with the pointer p
>   HSetState( h, hstate ) // useless
>
> Handle blocks behave much like pointer blocks, and there is little 
> reason to use them, except for compatibility with old code and with 
> pre-OS X toolbox routines that return or require a handle (such as 
> GetResource, Munger...). If you have a choice of allocating memory 
> with NewHandle and NewPtr, use NewPtr because pointer blocks carry 
> less overhead.
>
> Handle blocks can be resized larger in the usual way:
>   h = fn NewHandle( 10 )
>   SetHandleSize( h, 1000000 )
> Note that SetHandleSize may allocate a new memory block, copy the 
> original handle contents into it, then free the original block (thus 
> invalidating a pointer dereferenced from h).
>
> Handle blocks cannot be resized smaller:
>  h = fn NewHandle( 1000000 )
>  SetHandleSize( h, 10 )
> The 'official' size of the block as reported by GetHandleSize is 10. 
> The remaining 999990 bytes have not, however been disposed of 
> (returned to the free pool). You can still read from and write to that 
> memory.
>
> Memory leaks are difficult to detect.
>
>
> Robert P.
>
>
> --
> To unsubscribe, send ANY message to 
> <futurebasic-unsubscribe@...>
>