Martin, I put both your responses together to consolidate this thread.

Mike.


"Martin 53N 1W" <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message
news:LnsZc.220$GC4.104@newsfe1-gui.ntli.net...

Martin 53N 1W wrote:

Michael D. Ober wrote:

[...]

Actually, since Windows shares read-only executable images in
memory and

[...]

image is from the save .EXE file.  As a general rule, SETI Driver only

uses

a single CLI executable.  The Windows Task Manager doesn't show this,

That's a nice optimisation for that special case. Certainly good for
s@h. Not sure how often it can otherwise be taken advantage of on home
computers. Very useful for servers running multiple copies of some one
service... just like the s@h example...

however.  Windows does other performance tricks such as not writing
 read-only pages to the swap file.  Instead, it simply discards
them and then re-reads them back from the original location on
disk, thus saving a disk write when the EXE's physical memory is
needed for other processes or data. I assume that all modern OS's,
including Linux, do this as well.

An obvious 'quick' Windows tweak for performance.

Interesting.

Don't know all of the linux optimisations that are done. However I would
doubt that such a 'bolt-on' optimisation would be accepted. The linux
developers are very thorough and would follow a 'consistent' approach
with strict kernel divisions that are robust across all platforms and
all configurations.

This really isn't a "bolt-on" optimization.  It's actually a very simple and
elegant solution to how to reduce the amount of physical memory is required
to run multiple copies of the same program and is heavily used in the
timesharing mainframe world.  The reality is that the two .EXE optimaztions
(shared memory images and reread from the .exe) work together to reduce OS
and memory overhead, allowing more time to respond to the user and more free
memory for instance data.  The fact that Unix and Linux allow the programmer
to do specify this can be seen as both positive and negative.  On the
positive side, the programmer gets more control.  On the negative side, it's
one more thing the programmer needs to think about.  The windows file naming
system was derived from Unix in MS-DOS 2.0.

I got that last bit wrong (:-((

The true case is summarised in this email just now:

###
Linux and modern Unices page off the pure code parts of the actual
executable files - they do not copy unmodified pages into the swap
file.  Windows copied Unix.
###

The actual lineages for this feature are MIT's Project MAC which developed
MULTICS.  Bell Labs simplified MULTICS into UNIX, and in the process, threw
away a lot of security that has been restored in the last decade.
Linux was derived conceptually from Unix.  Digital Equipment Corportation's
(DEC) VMS, also took it's Virtual Memory Manager from MULTICS.  Microsoft
used VMS concepts for memory management and Unix concepts for the file
system.  The concept of sharing executable images based on the image name
came directly from VMS, not Unix.  Thus it's safe to say that the concept of
a sharing the .EXE based on file name isn't derived from Unix, but rather,
VMS.  Also, the concept of not swapping read-only pages of executables
actually was developed at MIT between 1963 and 1970.  By the way, K&R were
both researchers on Project MAC before Bell Labs pulled out to develop Unix.

 From discussions just now, linux already does the two above mentioned
memory useage optimisations.

Aside: There is a deep 'debate' in full flow at the moment on
news:linux.kernel about the name spaces (naming system) for all file
systems and for presenting a robust consistent and useable interface for
all requirements. A new file system is being developed which is now
forcing issues that have been patched over since file systems began...
Good stuff.

I hope so.  Maybe this will get Microsoft off its corporate butt and
actually develop NTFS into a fully relational, searchable, and attribute
driven file system.  NTFS has had the hooks for these features since NT 3.1,
but MS hasn't bothered to implement them

(There's lots more besides...)

It sounds like all modern OS's, Linux, Windows, Unix, and, yes, even VMS,
are converging in their feature sets, security, and robustness.  VMS is
currently the hands down champ for security and robustness, but then it's
been around longer than any of the others.  Feature sets are a toss up.
There hasn't been a real technological breakthrough development in Operating
Systems since the mid 70s.  Virtual Memory Managers were developed before
then.  XEROC's Palo Alto Research Center (PARC) developed the ethernet,
client/server architecture, distributed computing, page description
languages (Postscript), and the GUI (with rodent) between 1973 and 1975.
The first computer worm was developed in 1978 at PARC as well.  (For a PARC
history, see http://www.parc.xerox.com/about/history/default.html)  TCP/IP
was developed in the early 70s by BBN as part of a US DoD project to develop
a survivable communications structures.

Mike.

Regards,
Martin

-- 
----------   OS? What's that?!
- Martin -   To most people, "Operating System" is unknown & strange.
- 53N 1W -   Mandrake 10.0.1 GNU Linux
----------   http://www.mandrakelinux.com/en-gb/concept.php3