Re: LZ: Delete Strings in ASM?

Subject: Re: LZ: Delete Strings in ASM?
From: barrym <barrym@neosoft.com>
Date: Wed, 25 Sep 1996 20:05:17 -0500 (CDT)
In-Reply-To: <32495217.223539@pilot.msu.edu>
On Wed, 25 Sep 1996, Mel Tsai wrote:


> On Wed, 25 Sep 1996 08:09:12 -0500 (CDT), you wrote:
> >On Wed, 25 Sep 1996, Mel Tsai wrote:
> >
> >> Actually, it is possible.  The program would be complex, however.  You
> >> would first need to make sure your program was located in a lower
> >> memory position, otherwise it may get moved and all of a sudden the
> >> program crashes (I'm not sure when this will occur).  One solution
> >> would be to move your program to the graph memory, move programs, and
> >> then go back to your main program.  Probably the most difficult
> >> aspect, however, is knowing which variables you must update, i.e. free
> >> memory, vat and memory pointers, checksum, and of course moving the
> >> entire memory down.  One thing I did notice is that the ROM doesn't
> >> totally delete a file.  I deleted a zshell program, loaded hexview,
> >> and fragments of the program were still in memory.  I'm not sure what
> >> exactly happens.
> > 
> >The same thing is true on most computers, both in memory and
> >on disk.  There are pointers that tell the system where things
> >are and they can delete these things by removing the pointers
> >to them.
> >
> >That's why, after you delete a file on a pc, you can use the
> >UNDELETE command to get it back.  In this case the pointer
> >is in the directory, which is just a table of files and
> >information about them.  The DEL command marks that directory
> >entry as deleted and then it's done its work.  The mark is
> >placed in the first character of the name, which is why you
> >have to give the first letter to the undelete command, since
> >it's been lost.
> >
> >If you're a MAC user you probably won't understand this, but
> >then, MAC users aren't supposed to understand computers.  :)
> >
> 
> 
> Actually, the only reason why clusters don't get physically deleted on
> disk is because of speed (also so you can undelete them).  If you
> actually deleted the cluster on an MSDOS system, it would take as long
> to delete a file as it would to copy it.  This will be the same
> principle I'm using for my expander.  Now, even the slowest RAM chips
> are hundreds of times faster than a hard disk, so there's no reason
> why the TI shouldn't physically write 0's to the location.  There's no
> undelete function, it makes no sense.  Granted, it is "easier" to just
> delete the pointer, but then your memory would get fragmented, which
> you don't want to happen.  This is where my understanding of the
> memory stops, because I know the memory doesn't get fragmented, yet
> variables are still present in memory after they're deleted.  I guess
> that if the var is in the highest position in memory, it just deletes
> the pointer and leaves it alone.  If it's between two variables, it
> will have to move them.
 
If you 0 out the variables, it'll be fast as you say, but what will it
accomplish?


I'm just guessing now, but when the 85 moves variables around, it
probably updates all the pointers to them and doesn't bother to
erase them at their old locations.  To do so would probably serve
no purpose.  This is a fairly common approach to memory and disk
management.  I've been told, I don't remember by who, that the Mac
does in fact erase memory when a program is unloaded.  I'm not sure
if it's true.  It is true of highly secure computer systems.  This
is required by the middle level and above government security systems
and by a lot of companies as well.


Lotus Notes, which has very high security features (it was originally
written for the govt) erases itself from memory when it unloads.


Barry
References:
From: