On Mar 28, 4:48 pm, an...@[EMAIL PROTECTED]
(Anton Ertl)
wrote:
> In any case, there is no reason to make the Memory Allocation wordset
> a second-class citizen for programs.
Dynamically allocated memory is ... uhm, dynamically allocated?
I don't see how its unusual for statically allocated memory to be
loaded from an image and dynamically allocated memory to be created by
an initialization process.
I would, indeed, be surprised if the existing practice that was
standardized in ALLOCATE provided any such entitlement to sup****t
libraries for applications that the memory allocation wordset would
infer which allocated memory would managed by the initializing routine
when starting a system image and which allocated memory would require
auto-initialization.
However, what I expect from a SAVESYSTEM is to get my codespace and
ALLOTted dataspace back as it was when SAVESYSTEM executed, and to
have a hook into the initialization routine that runs when the image
is reloaded.
Indeed, Camel for Z80 and CP/M only have the hook for the
initialization routine and the ability to re****t the parameter to hand
to the CP/M SAVE command. So there, the argument that SAVESYSTEM
should automagically infer which allocated memory requires system
sup****t for the initialization capabilities omitted from the creating
application is not an argument with the Brad Rodriguez, but an
argument with Gary Kildall.
> However, in the present case (objects.fs), no user has asked for that
> favour since objects.fs exists (since 1996), and it seems to me that
> Doug Hoffman is not interested in using objects.fs seriously, he is
> only complaining about this "serious problem"
The validity of Doug Hoffman's argument on this point is independent
of the broader argument in which it is couched and, indeed, of whether
or not he makes it because he is seriously interested in using
object.fs.
|
