Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Magnus Hammerin <magnush@***.LIU.SE>
Subject: Strip, languages, and reality.
Date: Thu, 22 Jul 1993 10:21:58 +0200
Since we have started looking at reality on this stripping matter I
think I shall point out another thing that hasn't been discussed.

Ok, lets say I have written a program (which I actually has :-). It is
written in C on a sun. I compile it with -O4, ie very optimized. Its
compiled size is about 180k, if I strip it I get it down to about
163k, that is a reduction in size of about 10%, so strip removes more
than just symbol tables used for debugging, it removes relocation bits
and stuff like that also.

Then I start the program. WOW it has allocated 1.7M of memory. Then I
use the program a little, read some images, display them, calculate a
little... OHHH NOOOO it has allocated 7.2M of memory!!!

So, what has happend? Well, to start with, the program is dynamically
linked, so it wont actually load any libraries until it is run.
Secondly I use dynamic allocation of memory. And IMHO that is how it
will be done 60 years from now. So this thing about program sizes in
ShadowRun is a simplification of how it will work in the future.

What I am trying to say is, we can't look at how it is today, ie
compare with reality, when we decide if there should be a strip
program or not.

-Magnus.

--
-------------------------------------------------------------------------------
email: magnush@***.liu.se ! Dept. of Electrical Engineering
snail: Magnus Hammerin ! University of Linkoping, Sweden
Elauto, ISY +----------------------------------------------
S-581 83 LINKOPING ! Why use desktop publishing programs when
Sweden ! there is POSTSCRIPT!?!
Message no. 2
From: Todd Montgomery <tmont@****.WVU.EDU>
Subject: Strip, languages, and reality.
Date: Thu, 22 Jul 1993 10:14:16 -0400
I am busy but I would like to make a statement.

> From: Magnus Hammerin <magnush@***.LIU.SE>

> So, what has happend? Well, to start with, the program is dynamically
> linked, so it wont actually load any libraries until it is run.
> Secondly I use dynamic allocation of memory. And IMHO that is how it
> will be done 60 years from now. So this thing about program sizes in
> ShadowRun is a simplification of how it will work in the future.
>
> What I am trying to say is, we can't look at how it is today, ie
> compare with reality, when we decide if there should be a strip
> program or not.

The dynamic linking takes up memory more or less like what Hayden is
trying to do with strip. Or at least it seems to me like it is. Perhaps
it would be better from the Tools I made up to include such an option.
Like this: Programs can be compiled to be DLL (Dynamic Link Libraries (
I stole this from MS_Windows)). With this a suite of Utilities, which
have been properly designed, can use the DLL as a place to store sets of
functions/routines/resources. This would cut the size of the Utilities by
much as ?. This ? would be proportional to the amount of functions/routines/
resources that are fairly common and would be also an indication of
the DLLs size. Of course the DLL file would have to be in active memory,
and it really would not pay off unless several utilities were configured to
use it.

BTW-1: I think what others have said may be correct. Trying to use what we
know today to base this into SR terms may be wrong. It may be too limiting.
What kinds of advances in compilers would we see. Stuff like Object Vision,
or Visual Basic, or even some of the NeXT stuff may become more pronounced.
And after all, do we really know what these programs are made up like?

BTW-2: The first SE process models did not come into existence until mid 70's
and was not adopted as even useful until mid 80's. So the Info on the
Mac OS, while be something I did not know about, really does not apply to
SE very much. If you want some really good stuff on SE check out the
tech reports at ftp.sei.cmu.edu in the pub/documents directory or the
stuff at vfi.paramax.com. Both of these have various case studies of real
SE practices with several documents describing languages used.

-- Quiktek
-- Todd Montgomery
tmont@****.wvu.edu
tmont@***.wvu.edu
un032507@*******.wvnet.edu
Message no. 3
From: Magnus Hammerin <magnush@***.LIU.SE>
Subject: Re: Strip, languages, and reality.
Date: Thu, 22 Jul 1993 17:08:43 +0200
>>>>> Todd writes:

TM> I am busy but I would like to make a statement.

MH> From: Magnus Hammerin <magnush@***.LIU.SE>

MH> So, what has happend? Well, to start with, the program is dynamically
MH> linked, so it wont actually load any libraries until it is run.

TM> Programs can be compiled to be DLL (Dynamic Link Libraries (
TM> I stole this from MS_Windows)). With this a suite of Utilities, which
TM> have been properly designed, can use the DLL as a place to store sets of
TM> functions/routines/resources. This would cut the size of the Utilities by
TM> much as ?. This ? would be proportional to the amount of functions/routines/
TM> resources that are fairly common and would be also an indication of
TM> the DLLs size. Of course the DLL file would have to be in active memory,
TM> and it really would not pay off unless several utilities were configured to
TM> use it.

Ok I know I said we shouldn't relate to how it is today, but even
though you have compiled it with dynamic libraries, it doesn't mean
that you "share" the libraries in memory. The only thing you gain is
that the files become smaller on disk.

What I think you is describing is routines that are built into the OS.
That are shared among different processes. But the problem with that
is that the OS (MPCP maybe?) takes lotsa memory (like they seem to
have done with Solaris, an OS that takes 5M when just rebooted
*sigh*).

TM> BTW-1: I think what others have said may be correct. Trying to use what we
TM> know today to base this into SR terms may be wrong. It may be too limiting.
TM> What kinds of advances in compilers would we see. Stuff like Object Vision,
TM> or Visual Basic, or even some of the NeXT stuff may become more pronounced.
TM> And after all, do we really know what these programs are made up like?

Maybe we aren't using compilers. Maybe the computers aren't Touring
(sp?) machines anymore. The problem is that we don't know s**t of what
will happen in the future. So either we stick to the rules as they are
or we let our imagination flow, and invent a utility that cuts the
size of programs in half. And another utility that can simulate all
known Masking utilities :-)

TM> -- Quiktek
TM> -- Todd Montgomery

-Magnus.

--
-------------------------------------------------------------------------------
email: magnush@***.liu.se ! Dept. of Electrical Engineering
snail: Magnus Hammerin ! University of Linkoping, Sweden
Elauto, ISY +----------------------------------------------
S-581 83 LINKOPING ! Why use desktop publishing programs when
Sweden ! there is POSTSCRIPT!?!
Message no. 4
From: Todd Montgomery <tmont@****.WVU.EDU>
Subject: Re: Strip, languages, and reality.
Date: Thu, 22 Jul 1993 11:17:56 -0400
> From: Magnus Hammerin <magnush@***.LIU.SE>
>
> Ok I know I said we shouldn't relate to how it is today, but even
> though you have compiled it with dynamic libraries, it doesn't mean
> that you "share" the libraries in memory. The only thing you gain is
> that the files become smaller on disk.
>
> What I think you is describing is routines that are built into the OS.
> That are shared among different processes. But the problem with that
> is that the OS (MPCP maybe?) takes lotsa memory (like they seem to
> have done with Solaris, an OS that takes 5M when just rebooted
> *sigh*).

DLLs in MS-Windows work EXACTLY like this. And that is where I took them
from. They are separately compiled applications which are not runnable.
They hold functions for various things and are sharable across aapplications.
An example is the Visual Basic Runtime DLL. Any program written in Visual
Basic can share the library even if they are running concurrently. And
these DLLs are not built into the WIndows system.

Regular DLs though work like you mentioned. Examples: Turbo Vision
and Graphics Library for Borland C++.

--
-- Todd Montgomery
tmont@****.wvu.edu
tmont@***.wvu.edu
un032507@*******.wvnet.edu

Further Reading

If you enjoyed reading about Strip, languages, and reality., you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.

Thwap!