> From: Mouse
>> simulating a segmented machine on a non-segmented machine, i.e. one
>> with large unidirectional addresses (segmented being a
>> bi-directionally addressed machine) - [...]
> Hm, "unidirectional" and "bidirectional" are terms I'm having trouble
> figuring
On 03/16/2016 10:29 AM, Mouse wrote:
> That doesn't help [...]
You're right. I was thinking of stack overruns, not general buffer
overruns. Just need to stop programming in C for that last one.
>> Also, Multics stacks grow upward -- great for protection against
>> buffer overrun attacks, but a pain in a modern architecture.
> Sorry, I don't follow that? Why does the stack growth direction make
> a difference? It's just a convention, isn't it, which direction is
> 'push' and which is 'po
> From: Mouse
> Well, what was the largest virtual memory space available on various
> machines?
I have thought, on occasion, about simulating a segmented machine on a
non-segmented machine, i.e. one with large unidirectional addresses (segmented
being a bi-directionally addressed mac
On 03/17/2016 11:59 AM, Noel Chiappa wrote:
> > Each segment
> > is in it's own address space; any memory reference was, per force, a
> > segment number and offset.
>
> In this last sentence, is that referring to Multics?
>
> If so, that is exactly how the x86 _hardware_ works,
He mi
>> As for buffer overruns, the point there is that a buffer overrun
>> clobbers memory addressed higher than the buffer. If the stack
>> grows down, this can overwrite stack frames and/or callers' locals.
>> If the stack grows up, all it can overwrite is locals for the
>> current frame and unused
> From: David Bridgham
> how the GE processor mapped each segment to physical memory on its own
> while the x86 maps the segments into a single 2^32 byte linear address
> space first and then maps that to physical memory.
Oh, right, I remember there was a 4GB limit on physical mem
On 03/16/2016 09:55 AM, Mouse wrote:
> As for buffer overruns, the point there is that a buffer overrun
> clobbers memory addressed higher than the buffer. If the stack grows
> down, this can overwrite stack frames and/or callers' locals. If the
> stack grows up, all it can overwrite is locals f
On Wed, Mar 16, 2016 at 6:19 AM, Noel Chiappa
wrote:
> > From: Charles Anthony
>
> > I desperately want to port Multics to a modern architecture
>
> Funny you should mention this! Dave Bridgham and my 'other' project (other
> than the QSIC) is something called iMucs, which is a Multics-li
> I have thought, on occasion, about simulating a segmented machine on
> a non-segmented machine, i.e. one with large unidirectional addresses
> (segmented being a bi-directionally addressed machine) - [...]
Hm, "unidirectional" and "bidirectional" are terms I'm having trouble
figuring out the mea
> From: Charles Anthony
> Slightly at cross purposes here; I was speaking of porting Multics; you
> are speaking of writing a Multics like OS. I was opining that I don't
> think that porting would work due to Multics reliance on very specific
> VM features.
Yes; my un-stated a
> From: Mouse
> As for buffer overruns, the point there is that a buffer overrun
> clobbers memory addressed higher than the buffer. If the stack grows
> down, this can overwrite stack frames and/or callers' locals.
Oh, right. Du! Buffers typically grow upward, no matter which
> From: Charles Anthony
> I desperately want to port Multics to a modern architecture
Funny you should mention this! Dave Bridgham and my 'other' project (other
than the QSIC) is something called iMucs, which is a Multics-like OS for
Intel x86 machines.
The reason for the x86 machines is
mån 2016-03-14 klockan 13:38 -0400 skrev Mouse:
> > There is one axis along which I concede that things have advanced
> > since Multics, which is away from monolithic kernels -
>
> Whether that is an advance or a regression depends on your priorities.
> I see good arguments each way.
>
> > But t
On Mon, Mar 14, 2016 at 10:38 AM, Mouse wrote:
>
> Now that 64-bit address space is becoming common, eight megs of RAM is
> ignorably small, and multi-level page tables are common, this looks a
> lot less impossible. I've been tempted to build something of the
> source, but I never got to use re
> There is one axis along which I concede that things have advanced
> since Multics, which is away from monolithic kernels -
Whether that is an advance or a regression depends on your priorities.
I see good arguments each way.
> But the complete structing of the system around a segmented,
> singl
> From: Charles Anthony
> I get bloody impressed just watching it on the emulator; doing it in a
> production environment must have been spectacular.
Even though I never did do any programming on Multics myself (I had an
account on the MIT system, and logged in a bit), I still feel th
On Sun, Mar 13, 2016 at 10:11 AM, Michael Thompson <
michael.99.thomp...@gmail.com> wrote:
> >
> > Date: Sat, 12 Mar 2016 07:27:18 -0800
> > From: Charles Anthony
> > Subject: Re: Honneywell multics? from panels. the inline phots in this
> > mes
>
> Date: Sat, 12 Mar 2016 07:27:18 -0800
> From: Charles Anthony
> Subject: Re: Honneywell multics? from panels. the inline phots in this
> message folks -smecc
>
> The panels labeled IOM are Input Output Managers; they connected the SCUs
> to peripheral devi
:27
To: Dave G4UGM
Cc: Ed Sharpe ; j...@jwsss.com; space...@gmail.com;
jwsm...@jwsss.com; General Discussion: On-Topic and Off-Topic Posts
; Kevin Monceaux ;
heal...@aracnet.com; couryhouse.sm...@gmail.com
Subject: Re: Honneywell multics? from panels. the inline phots in this message
folks -smecc
On Sat, Mar 12, 2016 at 10:27 AM, Dave Wade wrote:
> Copied back to the main list….
>
>
>
> OK on the L66 machines I worked on we always kept the doors closed, there
> was an application, can’t remember its name, we ran on a VDU by the system
> console that displayed the Job Queues, State of Acti
On Sat, Mar 12, 2016 at 12:32 PM, Noel Chiappa
wrote:
> > From: Charles Anthony
>
> > The enormous number of configuration switches is due to the extreme
> > modularity of the system. ... Each bank could taken out of service
>
> The really amazing thing (considering the vintage) was
> From: Charles Anthony
> The enormous number of configuration switches is due to the extreme
> modularity of the system. ... Each bank could taken out of service
The really amazing thing (considering the vintage) was that that
reconfiguration could be done with the power on, and the
On Sat, Mar 12, 2016 at 6:44 AM, Dave G4UGM wrote:
> The panels would be pretty much un-used Unlike 360 panels these were
> hidden behind doors for most of the time. Assuming the work the same on a
> Multics box as on a regular L66/DPS box the only time they were really used
> was if you split a
; cctalk@classiccmp.org; ke...@rawfeddogs.net;
heal...@aracnet.com; couryho...@aol.com; couryhouse.sm...@gmail.com
Subject: Honneywell multics? from panels. the inline phots in this message
folks -smecc
ok sent to all the people cc on the multics stuff.. will not go though on
main listserv
25 matches
Mail list logo
