Lit. Buffer overruns 1713

Can we snip out the cross-post? I don't think the crypts care about this flavor of stuff

In our development world, it was often important to distinguish what code of the operating system we were talking about. The monitor was the part of the OS that was always core resident and did not take up a job slot. The development guys often were doing both the monitor work and the user program work and talking about the functions of each had to be in shorthand form. So the GALAXY developer would have monitor, GALAXY, PULSAR, QUASAR, ORION, and the most important which I can't recall. Now GALAXY was said usually in the context of all programs that ran under a job slot vs. the monitor.

Not quite. This may be implementation and hardware specific. The monitor ran in exec mode and user mode which had different hardware protections invoked. Whenever JMF need the end protection a user would have, he would cause his monitor code to run "in behalf of the user". Another side effect is that the user job would get charged for the computer resources. Things that were done at exec level were interrupting handling. I don't know but I also suspect that a lot of the raw device and controller handling would be done in exec mode.

It gets swapped out if the other program has more priority.

Another reason some code needs hard locations written into it, is when a device places info at a particular address and the program has to use that info to do its work.

alt.sys.pdp10 newsgroup is the best place. On your little box you can run this and see how all kinds of hardware worked. PDP-11s, PDP-10s, VAXes, I think there's some IBM stuff. With the 11s, you can run whatever OSes were developed for that platform. DEC had 10(?) of them. Customers probably developed more.

TOPS-10 (before it was called that) did shuffling before it would do swapping.

And if the OS is a general purpose timesharing, the choices of who to run and who not to run has a lot of fairness rules that always have exceptions.

All valid choices. You can also reduce your core request and work with a smaller address space. You can go off and do some other work and come back later. Or you could tell the monitor to give you an interrupt when the core is available. Or you could resubmit yourself to a better wall-clock time when the resources are available.

It all depends on what the program is supposed to be doing.

Or, as in this thread, they don't know what it means. Errors are the way the OS communicates with a program when it doesn't have any knowledge about what that program is supposed to do. This is a security feature.

The overcommit, if done correctly, would only slow the processing, not kill it in nefarious ways.

It's possible I'm that one. :-)

Somebody else will have to answer this. The -10s had administrative hooks so that a sysadmin could fine tune the loads for his system.

Anything coming off a production line is full of trade-offs. Take a look at your checkbook. The line items have gazillions of tradeoffs hidden behind the expenditure.

I worked with a gal once who had a wise saying: Every decision means that you've given up something.

The -11 OSes did a fine job. So did the -8s. 1620s did fine (1620s are my only IBM experience).

It's more than annoying because the design is to not defend itself.

Oh, good. You got through mess :-). Yes, the special case is that p=0.

BAH

Subtract a hundred and four for e-mail.