Path: utzoo!mnetor!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!jsp
From: jsp@sp7040.UUCP (John Peters)
Newsgroups: comp.sys.atari.st
Subject: Re: preloading programs
Message-ID: <375@sp7040.UUCP>
Date: 27 Apr 88 03:26:58 GMT
References: <8804141742.AA01455@decwrl.dec.com> <693@ast.cs.vu.nl> <390@uvicctr.UUCP>
Organization: Unisys, Salt Lake City, UT
Lines: 66
Summary: memory resident programs

In article <390@uvicctr.UUCP>, collinge@uvicctr.UUCP (Doug Collinge) writes:
> Someone said that OS9 68k is capable of "preloading" commands; that is,
> loading some programs into memory and executing them there when invoked
> rather than loading them from disk.  This seems to be yet another
> excellent idea incorporated in OS9 that no-one else seems to have
> thought of.  I have always hated RAMdisks on the conceptual ground that
> any program loaded from RAMdisk occupies twice the memory that it needs
> - half for the executing image and half for the copy in the RAMdisk.
> (Yes, of course I use one...)  Temporary files in RAMdisk are also
> stupid (the filesystem should handle this need in its buffering scheme)
> but less so, since only the data in the buffers is duplicated.
> Preloading commands eliminates the major stupidity and seems extremely easy
> to implement in any shell.  Which brings me to my question:
> 
> How difficult would it be to hack this into Gulaam?  Perhaps pm would
> be kind enough to consider this in a future release.  Or maybe he has a
> hard disk and doesn't care, in which case he might allow someone else
> to put it in for the rest of us.  Maybe someone could point out this
> note to him if he doesn't see it.
> 
> I love Gulaam and use it all the time.

This would not be an easy hack.  This is not a good idea on any system that
does not swap or page.  What happens when you run out of memory.  Remember
when people thought 2k bytes would never be all used up.  Well I have
already run into memory problems on accation (on the 1040ST) with MT-shell,
a 100k ram disk, 30k of print spool buffer and acash installed when the c
(MWC that is) tried to compile a large source file.  What if the editor had
been left in memory.  No thanks.  As for systems that provide the capability
to leave executable text (UNIX terminology) as memory resident you just have
to look at any real operating system.  On UNIX if the sticky bit is set on a
file then it stays resident after the first time it is involked.  This is 
typacle of programs such as vi, ls, pwd and others that are often executed.
On the VMS operating system this capabilty has been taken quite a bit further.
As part of its real time facilitys, the user can make a system call that tells
the O.S. to lock it in memory or increase the total available memory for that
program (non pagable that is).  You can even tell it whit segments of memory
you can swap and which it can't.  This is not a new concept but it will
take a system that is much more sophisticated that TOS can ever dream of
being.  However, I expect that it is implemented in Idris.  The redeming
factor for the ST is the emminent release of Minix for it.  There are allready
ports of it for the PC that are swapping and paging kernels and I can see
it implemented for the ST as a locigal extension.  Then such thing will be
possible to the average St user.  Since Minix does not use the ROM's at any
time after the boot cycle, the ST with it's more standardized hardware
should provide a platform for Minix that will make it easy to port applications
to.  Mybe we can soon have the "sticky bit" on it also.

I realize that I have rambled somewhat.  That is the result of being in my
last quarter of school and working too much at the same time.  The ST is
a great hardware platform that has suffered from a lack of operating system.
Most of the question and grips I've seen on the net has stemed from this cause.
I don't agree with Ataris marketing, but I realize that the only way to change
things is for the users to do it themselves.  That is why I like the idea of
Minix.  Basically for free you get a real operating system and the ability
to extend it (i.e. Source Code).  This will be an environment that will allow 
porting of much of the public domain unix software without major rewrite.
Try doing something with TOS's file system, what a drag.

Well enough of building for Minix.  Hopefully by mid summer I'll see large
numbers of requests for a "comp.os.minix.st" group and we can continue
this discussion there.

				--  Johnnie  --


What do you mean the last backup was in 1984?