Far and near pointers on the 80286 and later
|
Prev: The 6809 and 680xx instruction sets
Next: DANGER DANGER THIRD DAY CPU FAN FAILURE DANGER DANGER
From: Anne & Lynn Wheeler on 30 Mar 2010 14:53 Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > At the same time there were various milspec security development stuff > that were also being required for critical financial infrastructures > ... stuff like 2167A ... which also took something like ten times the > effort of what might be considered well-designed, well-implemented, > well-tested application (and then re-applied for any > enhancement/changes). re: http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later http://www.garlic.com/~lynn/2010g.html#15 Far and near pointers on the 80286 and later http://www.garlic.com/~lynn/2010g.html#16 Far and near pointers on the 80286 and later wasn't a member ... but did get invited to some of their meetings ... somewhat favorite of mine from their website ... courtesy of the wayback machine: http://web.archive.org/web/20001018151708/http://www.software.org/quagmire/frampapr/frampapr.html -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: jmfbahciv on 31 Mar 2010 07:37 nmm1(a)cam.ac.uk wrote: > In article <hosqpu41t4u(a)news7.newsguy.com>, jmfbahciv <jmfbahciv(a)aol> wrote: >> There is nothing, I repeat NOTHING, more instructive than working >> on a functional system. It's a computer biz law that, what you >> expect to happen, will not happen; the corollary is that the >> opposite of what you expect to happen will happen. Only >> those who have done OS development for many releases will >> understand this one. > > Not at all. I have never done that, but I have done such things > as implement fully-functional language run-time systems (including > exception handling, non-trivial I/O and associated recovery). That's almost an OS with a lot of "user-cruft" eliminated ;-). > I am VERY familiar with that principle, and it holds true even > after 40+ years experience .... Man! It would drive JMF and TW bonkers. > >> ARe you really sure that MULTICs doesn't have old tricks >> which have to be relearned and reimplemented again? I'm >> not. I'm sure of the opposite. > > I don't object to people reinventing the wheel, but I do wish they > would get the number of sides right! ROTFLMAO. Yea. That's a much better way of expressing it. > > That is especially true as people attempt to use Unix derivatives > (including Microsoft ones, of course) for servers. Mainframes had > lots of defects, but avoided many of the current ones. That's because they didn't work so the asspects never got shipped. Nowadays, no OS development cycle seems to have time to find these things out. Our monitor development cycles were around 2 years with limited interim releases (LIRs) shipped to support new hardware. /BAH
From: Bill Davidsen on 8 Apr 2010 18:21 George Neuner wrote: > On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote: > >> George Neuner wrote: >> >>> Leaving aside why anyone would _want_ to bring back Multics ... >> To study how to make an OS secure from the beginning project plan >> to the last edit for shipping? > > Ok, but there are other secure systems to study such as Amoeba and > EROS. They are more modern than Multics, and in particular, were > designed to be distributed. > > I don't mind anyone studying Multic - there is plenty to learn from it > (including what not to do) ... but I would be against trying to revive > it as a working operating system. > One of the things which separated MULTICS from most other operating systems was the way in which rings were used. Many operating systems use (or mostly use) only two rings, similarly to the "master mode" and "slave mode" of 1960's computers. By putting things like libraries and privileged linked programs (terminology escapes me, it's been ~40 years) in rings, access could be more nuanced.
From: Tim McCaffrey on 8 Apr 2010 18:51 In article <hplktn$jac$1(a)news.eternal-september.org>, davidsen(a)tmr.com says... > >George Neuner wrote: >> On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote: >> >>> George Neuner wrote: >>> >>>> Leaving aside why anyone would _want_ to bring back Multics ... >>> To study how to make an OS secure from the beginning project plan >>> to the last edit for shipping? >> >> Ok, but there are other secure systems to study such as Amoeba and >> EROS. They are more modern than Multics, and in particular, were >> designed to be distributed. >> >> I don't mind anyone studying Multic - there is plenty to learn from it >> (including what not to do) ... but I would be against trying to revive >> it as a working operating system. >> >One of the things which separated MULTICS from most other operating systems was >the way in which rings were used. Many operating systems use (or mostly use) >only two rings, similarly to the "master mode" and "slave mode" of 1960's >computers. By putting things like libraries and privileged linked programs >(terminology escapes me, it's been ~40 years) in rings, access could be more >nuanced. Well, the CDC Cyber 180 series (and NOS/VE) did something similar. - Tim
From: Peter Flass on 9 Apr 2010 07:57
Tim McCaffrey wrote: > In article <hplktn$jac$1(a)news.eternal-september.org>, davidsen(a)tmr.com says... >> George Neuner wrote: >>> On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote: >>> >>>> George Neuner wrote: >>>> >>>>> Leaving aside why anyone would _want_ to bring back Multics ... >>>> To study how to make an OS secure from the beginning project plan >>>> to the last edit for shipping? >>> Ok, but there are other secure systems to study such as Amoeba and >>> EROS. They are more modern than Multics, and in particular, were >>> designed to be distributed. >>> >>> I don't mind anyone studying Multic - there is plenty to learn from it >>> (including what not to do) ... but I would be against trying to revive >>> it as a working operating system. >>> >> One of the things which separated MULTICS from most other operating systems > was >> the way in which rings were used. Many operating systems use (or mostly use) >> only two rings, similarly to the "master mode" and "slave mode" of 1960's >> computers. By putting things like libraries and privileged linked programs >> (terminology escapes me, it's been ~40 years) in rings, access could be more >> nuanced. > > Well, the CDC Cyber 180 series (and NOS/VE) did something similar. > OS/2 uses three: one for the kernel, one for drivers, etc., and the third for user programs. |