Hi Frank,

MS>> without C++; an OOP oriented language like C++ just keeps things
MS>> less cluttered by hiding the details.

FA>> Yeah,but those derived structures are driving me bananas.;-)

FA> C'mon, you were supposed to laugh at this, there are no derived 
FA> structures.:-) 

Oh. Ha ha ha! :) Is that better? ;-) 

As I said, I know almost nothing about C++.

FA> Although in C++ a struct is treated as a class methink.

Fine. In E there is no such distinction.

MS>> Fair enough.  FWIW, I'm almost totally ignorant of C++, but I have

FA> Classes can be derived from a base class.This means that you can have 
FA> a number of classes having access to the base class' even though the 
FA> variables there may be private.
FA> (not sure about protected, haven't touched C++ for a while). 

Pretty much the same as in E.

MS>> Interesting...  I wonder what it'd do on my Amiga...  :) I've
MS>> seen PC programmers talking about "the heap" and I guess it's
MS>> where malloc() gets its memory, but the rest is a mystery.
MS>> Memory allocation is more anarchic over here.  :)

FA>> It would still have to return handles of blocks to the program's
FA>> RTL ?
MS>> I'm not exactly clear on what you mean by the program's RTL.
FA> The Run Time Library.

Oops! I was having a temporary memory lapse. :) 

FA> Most DOS calls are handled by it, if you disassemble a DOS exe you'll 
FA> see a lot of mov ah 30h
FA>              int 21h 
FA>              cmp ??.. 

If you say so... it looks nothing like Motorola assembler.

FA> Because the RTL has to determine what platform you're running on, 
FA> so it can use the appropriate DOS function and variables.           
                       
FA> For instance in asm you would go straight to DOS and grab a chunk, but
FA> it's my belief that a routine in the Borland RTL intercepts all alloc
FA> calls and builds an internal memory table, so non standard stuff like 
FA> heapwalk() can function. 

I'm so glad that my OS isn't like this.

MS>> There are several varieties of memory allocation in the Amiga OS, as
MS>> well as the standard allocation functions provided by the compiler.
MS>> If I use malloc() or AllocVec(), then I can find the blocksize at a
MS>> negative offset from the returned pointer.  OTOH, if I use

FA> Yeah, i though i could too, but when i used a different compiler it didn't
FA> work.(Pacific to be exact.)  

MS>> called AllocRemember, which returns size & other information via a
MS>> structure double pointer.

FA> Hm, DOS must be a bit more senile. 
FA> I've read/tested the DOS memory functions now a few(hundred?) times, but i 
FA> can't find any reliable way of finding out the size. After it allocates 
FA> it just returns the number of blocks and the size is history from there 
FA> on. It still bugs me, there HAS TO BE a table within DOS somewhere !       

Good luck finding it. And thanks for giving me yet another reason why I
shouldn't learn about your DOS. :)

Michael Stapleton of Graphic Bits
@EOT:

--- Msged/AM 4.00