delorie.com/archives/browse.cgi | search |
Xref: | news-dnh.mv.net comp.os.msdos.djgpp:374 |
Path: | news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!newshost.lanl.gov!newshost!egdorf |
From: | egdorf AT zaphod DOT lanl DOT gov (Skip Egdorf) |
Newsgroups: | comp.os.msdos.djgpp |
Subject: | Re: Mapping files to memory? |
Date: | 13 Jun 1995 16:48:02 GMT |
Organization: | Los Alamos National Laboratory |
Lines: | 15 |
References: | <DA45p3 DOT CMy AT jade DOT mv DOT net> |
Nntp-Posting-Host: | zaphod.lanl.gov |
To: | djgpp AT sun DOT soe DOT clarkson DOT edu |
Dj-Gateway: | from newsgroup comp.os.msdos.djgpp |
In article <DA45p3 DOT CMy AT jade DOT mv DOT net> kagel AT quasar DOT bloomberg DOT com writes: For those not familiar with memory mapped I/O: I believe the facility first appeared on DEC10 and DEC20 systems under TOPS10/20. Ahhh, the nit-pick of the day. This was (as with so much in so many systems) inspired by Multics, where memory mapping was the norm. Segments (files on multics) were just parts of your virtual memory that could be made visible by mapping them. Lots of systems have lifted memory mapping because it is such a "right thing" for so many problems. Multics just did it in a more complete way because it was a basic concept from the beginning. Skip Egdorf hwe AT lanl DOT gov
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |