Does anyone know of any operating system that used static memory partitioning: contiguous physical memory allocation with one process per partition, one partition per process, partitions generated at build time, and existing independently of being used/not used?

I am particularly interested in systems that required that all partitions were of the same [fixed] size. Were there any such systems?

  • 2
    What's the definition of fixed-size memory partitioning? Anything with virtual memory effectively partitions the address space into fixed buckets of the page size. Does that count?
    – Tommy
    Feb 19, 2020 at 20:49
  • 2
    @DYZ I'm not going to put in the last "needs details or clariity" vote that would close this question to give you a chance to update it, but as it is now, this question is far too vague. Please edit it to make it more clear what you mean, and especially the relationship between physical and virtual memory that you're talking about.
    – cjs
    Feb 20, 2020 at 0:31
  • 2
    Someone should mention OS/360 MFT. Seems like @ralfzahn's department? I suppose the Fixed Tasks required Fixed Partitions. Feb 20, 2020 at 1:32
  • 3
    @DYZ - your link to an explanation of 'fixed memory partitioning' points out partitions need not have the same size; your question wants the same size. I have ignored that stipulation in my answer; in my actual experience, partitions sizes are individually set as needed, though the sizes (and base addresses) are then 'fixed' as long as the partition exists. Feb 20, 2020 at 1:39
  • 3
    Somewhat. But I've never heard of a system where the partitions had to be the same size. Why would anyone implement it that way? Also, to my mind the OS needs to implement partitions as an actual thing (maybe under some other name) rather than having the simple characteristic that you load a program into the amount of memory it needs, which some of the replies seem to be about. Maybe the test is - the partition is capable of existence independent of it being used. Feb 21, 2020 at 2:56

7 Answers 7


The RSX-11 {D/M/M-PLUS/S} family of operating systems, running on PDP-11 minicomputers, divided real memory into partitions. Partitions were mostly set up at system generation time; you could define partitions in a running system, but that was less common.

The RSX-11 family were a reimplementation, on the 16-bit PDP-11, of RSX-15 on the 18-bit PDP-15, so many of the ideas were carried over from there. This includes partitioning of memory.

To quote from the RSX-15 exec manual,

Partitions and SYSTEM COMMON Blocks are fixed at system configuration time and cannot be altered at run time. Tasks are built to execute in specific partitions, and, any number of Tasks may be built to execute in the same. partition.

This to me is the essential feature of partitioning - they are relatively static memory allocations, certainly not created 'on demand' as programs start executing.

I'm much more familiar with the PDP-11 systems, but the principle is the same. One important fact is that smaller 11's may not have memory management hardware (and thus had no more than 28K words memory).

This means that tasks (a term used for both the program-on-disk and program-in-executions) needed to be built for the address they'd be loaded at. That meant in turn that in practical terms you'd need to define a set of useful base addresses, which is to say, to partition memory. You'd create one partition for every task you wanted to be running and in memory simultaneously. You then had to decide at task-build time ("link time" in other operating systems) which partition a task would execute in, and the task builder would base the task for that address.

Example: you'd create partitions A, B, C, and D - this would allow 4 tasks to be in memory at the same time; the exact mix that was possible depended on which tasks were built for each partition: A, B, C or D.

The system could checkpoint (swap out) a task to permit a higher-priority task to be loaded into a particular partition. However, one task at most was 'in' a partition at any point in time. (And the partition still existed when no tasks were in it).

Mapped RSX-11M (i.e., running on a PDP-11 with memory management hardware and thus capable of having more memory) also allowed fixed memory partitioning, and required it to some degree, though since tasks started at virtual 0, there was no need to build a task for a particular partition.

But it was still good practice to dedicate partitions for certain uses, as (for example) you could avoid the memory fragmentation that would result if you loaded device drivers into the same partition used for user tasks -- the driver would be immovable once loaded.

It was also somewhat common to dedicate partitions for high-priority tasks, for example the file system ACP (handled file actions except for the actual read-write calls) might get its own partition to avoid fighting for memory with user tasks.

It was however not a necessity to partition memory in a fine-grained manner in such a system. Typically, "most" of memory was allocated to a general partition, which could, as a partition-definition option, be dynamically sliced up into subpartitions (one per task) to meet the need for whatever was currently executing -- i.e., it worked like you expect non-paged systems to work, each task got a contiguous piece of memory that matched its size requirements.

So: partitions had a fixed size, but partitions could optionally be allowed to be split into dynamically-allocated subpartitions.

Here's part of the partition layout from a running RSX-11M-Plus system (a large-PDP-11 system, but it's all I have handy). Partitions and subpartitions appear in real-memory order.

SECPOL 117734 00200400 00200000 SEC POOL
SYSPAR 117670 00400400 00205400 MAIN  
       117624 00400400 00115300 RO COM !DIR11M!
       117434 00515700 00005200 TASK   <...LDR>
       117230 00523100 00033300 TASK   <MCR...>
       117024 00556400 00010500 TASK   [TKTN  ]
       116620 00567100 00003200 TASK   [SHF...]
       116414 00572300 00013500 TASK   [RCT...]
DRVPAR 116334 00606000 00173000 MAIN  
       116270 00606000 00006600 RO COM !TTEXT !
       116204 00614600 00020600 RO COM !TTCOM !
       116120 00635400 00034200 DRIVER (TT:)
       115450 00671600 00001300 DRIVER (DK:)
       110560 00777300 00001500 DRIVER (RD:)
GEN    110514 01001000 15777000 MAIN  
       110450 01001000 00002000 RO COM !DYCOM !
       025544 01003000 00007500 TASK   <PMT...>

All of the partitions (SECPOL, SYSPAR, DRVPAR, GEN) are fixed-size paritions. SECPOL is a memory pool for the OS; SYSPAR is for system-critical tasks and the directives (syscalls); DRVPAR is for drivers; and GEN is for everything else. The partition sizes are determined - with user input - at system generation time.

The numerical columns are (as far as I recall) address of the partition control block, base of partition, length of partition. All in octal, since we only have 8 fingers.

Each of those partitions is dynamically divided into subpartitions by the OS as objects (drivers, tasks, etc.) are loaded into the partitions.


The PDP-8 is a 12-bit computer.  As such it has a word and pointer size of 12-bits — meaning it can access 4k words using a single word pointer.

Later models added bank switching (KM8E) and 3 extra address lines so that up to 32k words (8x4k) words could be populated, now having 15 address lines.  (Core memory boards, 4k words each, you could see each bit!)

The TSS/8 operating system gave each program/process one of the 4k banks, regardless of program size (i.e. whether smaller or larger than 4k).  The OS did not allow user programs to use bank switching, so they ran as if there was only 4k in the machine — though they did have the benefit of system calls whose implementation did not take space in the user's 4k.

The operating system occupied two 4k banks, and the others were available for running processes.  The operating system could suspend a process to disc, so a system with 16k, for example, could have (the operating system, plus) two memory-resident user processes and some number more suspended on disc.

If a program didn't need the full 4k there was no way to release that back to another program.

Programs that needed more storage could use disc, rather manually.  When the program was running file handle #0 referred to the program itself (much like stdin/stdout in unix), so that additional code and/or data could be fairly easily read or written using a system call.

You got 4k, full stop — there was no allocating (or releasing) additional memory.  The 4k you got was a complete bank (so in terms of 15-bit addresses the lower 12-bits of the bank's address were 0's, i.e. 4k aligned) — the banks were effectively partitioned in advance.

  • I'm somewhat aware of TSS/8 memory handling (hey, it's even running on my PiDP-8 right now) but I don't really see an explicit concept of "partitions" manifested in the OS. Feb 21, 2020 at 3:00
  • KM8E option provided for up to 7 additional 4k core memory boards to be added. Each board held an entire 12-bit address space, addresses 0000 through 7777(octal). TSS/8 ran programs/processes one per board -- the boards "partition" the memory.
    – Erik Eidt
    Feb 21, 2020 at 16:18
  • KM8E added two 3-bit registers to the hardware. The first of these 3-bit registers selected the board to use for instruction fetches and the second of the 3-bit registers selected the board to use for data reads & writes. Unlike the 8086 with its 16-bit segment registers, there's no way to have a 12-bit address space on a PDP-8 that isn't 4k aligned -- you always get one whole board. There's no memory protection other than being denied access to modify those 3-bit registers.
    – Erik Eidt
    Feb 21, 2020 at 16:18
  • This feels qualitatively different to a system where real memory is sliced up 'arbitrarily' by the admin to meet the installation's needs. I'd call the -8 system paged memory, with page size = 4K, number of pages in address space = 1. Feb 21, 2020 at 17:32
  • @another-dave, certainly! Maybe also that 4k processes are baked into the TSS/8 system (in part, due to the nature of the KM8E hardware).
    – Erik Eidt
    Feb 21, 2020 at 17:57

During the heyday of the Intel 80386, there were many operating systems that relied on that CPU's virtual 8086 mode to multitask programs that were written for x86 real-mode.

By allowing real-mode programs to transparently use the segmented, 20-bit address space that they expected, these Operating Systems provided a fixed-size memory partition to each real-mode application. This partitioning was done under the control of the monitor running in protected mode, so the memory pages were fully protected from other applications while appearing to each application as if it had access to its full 20-bit memory space. So, it was a full virtual machine partitioning, but the partitions appeared as a fixed memory size to the multitasking applications.

  • 2
    Surely that's only if you assume that the contained programs don't use EMS or XMS?
    – Tommy
    Feb 19, 2020 at 21:29
  • @Tommy The assumption is that the OS is providing a strict real-mode container. Use cases that allow real-mode applications to access additional backing store through an API doesn't really change the memory model they inherit from their real-mode container.
    – Brian H
    Feb 19, 2020 at 21:37
  • 1
    @BrianH both EMS and XMS are strictly real-mode technologies, as distinct from e.g. DPMI. XMS especially just provides an interface to copy chunks from a secondary RAM store in and out of conventional memory. EMS pages rather than copying. However, anything protected mode with virtual 8086s will usually offer EMS and XMS by manipulating the page table. So your strictly real-mode container using strictly real-mode technologies will end up using arbitrary distinct chunks of the full memory space.
    – Tommy
    Feb 19, 2020 at 21:41
  • 2
    @Tommy I think that's just a logical vs. physical argument. If the OP wants to stipulate that there is no logical view of memory held by the OS and distinct from a physical view assigned to each application, then let OP so stipulate.
    – Brian H
    Feb 19, 2020 at 21:45
  • 1
    @BrianH I think you've persuaded me; another way to spin it would be: XMS and EMS provide access to another pool of memory, but they don't end up gifting extra segments to an application if a segment is understood to be a full standard 20-bit 8086 address space (or a 640kb-limited version thereof).
    – Tommy
    Feb 19, 2020 at 21:53

The Acorn MOS, as deployed in the BBC Micro, offers built-in support for paged ROMs. Paged ROMs have a fixed 16kb window in the address space, and amongst other things may contain filing systems, languages or other programs.

A BBC or Electron fitted with more than one paged ROM will therefore have a fixed 16kb ROM window in which the current application sits, and the user may opt to exit that program and switch to another. Or, if one of the other ROMs is a filing system or the interpreted language that an application is written in, the MOS will do it automatically as required.

The following has been ruled an impermissible example since a program may simultaneously occupy more than one segment, but is preserved for posterity:

Classic Mac OS applications are divided into 16kb segments and a jump table. Code within a segment uses PC-relative addressing and jumps; to get to code in another segment it uses the jump table, which is dynamically reprogrammed to redirect into the segment loader as and when segments are unloaded. So it's a lot like a virtual memory subsystem except that there's no automatic address translation, and no automatic page faults. Developers just have to follow the rules.

As a result, Classic Mac OS uses fixed-size memory partitioning for application code.

  • 1
    @DYZ You may want to describe what you're looking for, especially what exactly is your definition of 'fixed-size' ad what criteria are used to judge.
    – Raffzahn
    Feb 19, 2020 at 21:12
  • 1
    @DYZ nothing spans a segment. It's simply that, if room allows, then a single program might be given multiple segments. But each segment is a standalone island.
    – Tommy
    Feb 19, 2020 at 21:25
  • 1
    @DYZ yes, that's why I responded to the concept of "spanning BETWEEN segments". There is never a single continuous piece of data, or a subroutine, that spans BETWEEN segments. Never once will the program counter run off the end of one segment and into the beginning of another.
    – Tommy
    Feb 19, 2020 at 21:27
  • 1
    @DYZ if a program currently has parts in RAM segments 0 and 2, you'd confuse a lot of people if you said "the program spans BETWEEN segments 0 and 2", so I definitely think you want to emphasise the 'more than one' aspect over the between/spanning, should anybody else be similarly confused.
    – Tommy
    Feb 19, 2020 at 21:34
  • 2
    @DYZ If it's a standard term, then you might be able to add quite a lot links to it, don't you? Tommy is for sure a well informed fellow and you're comment about 'speaking the same language' does show that you might recognise the issue. Keep in mind, this is RC.SE, were every term has to be taken in context, as it's about times and machines before actual canon was formed. As of now the question does not meet basic quality criteria.
    – Raffzahn
    Feb 19, 2020 at 21:39

The definition to which you linked is very specific, and you put a further constraint on it that the partitions must all be the same size (the definition to which you linked makes it clear they need not be; the example they give uses four "blocks," which I assume they feel is another word for "partition," of three different sizes).

The CDC 6600 is definitely not fixed by your definition, and technically not even by the source definition, since the sizes of partitions could vary as processes came and went (e.g., one large area used by one process could be used by two smaller processes later), and fragmentation could be avoided by stopping a process, copying it to a different range of locations in physical memory, and continuing the process. It probably is thus "variable partitioning" (mentioned but not really defined in the source), since processes are "contiguous" in both the actual meaning of the word and by their definition of that as "loaded entirely in main memory."

I wouldn't, however, rely on your source as any sort of indication that what they described ever even existed, much less as a good taxonomy of actual systems; the source seems to be both overly vague and lacking in any sort of references.

I leave the detailed description of the CDC 6600 here in case it's useful in developing better taxonomies and/or questions.

The CDC 6600 had a memory remapping and protection system where each process got a contiguious area of memory starting at virtual address 0 and of arbitrary size less than or equal to main memory. Multiple processes were thus possible, but each always started at virtual address 0 and the physical memory allocated was a singal contiguous block. From Wikipedia:

User programs are restricted to use only a contiguous area of main memory. The portion of memory to which an executing program has access is controlled by the RA (Relative Address) and FL (Field Length) registers which are not accessible to the user program. When a user program tries to read or write a word in central memory at address a, the processor will first verify that a is between 0 and FL-1. If it is, the processor accesses the word in central memory at address RA+a. This process is known as base-bound relocation; each user program sees core memory as a contiguous block words with length FL, starting with address 0; in fact the program may be anywhere in the physical memory. Using this technique, each user program can be moved ("relocated") in main memory by the operating system, as long as the RA register reflects its position in memory. A user program which attempts to access memory outside the allowed range (that is, with an address which is not less than FL) will trigger an interrupt, and will be terminated by the operating system. When this happens, the operating system may create a core dump which records the contents of the program's memory and registers in a file, allowing the developer of the program a means to know what happened. Note the distinction with virtual memory systems; in this case, the entirety of a process's addressable space must be in core memory, must be contiguous, and its size cannot be larger than the real memory capacity.


I used an operating system with a MODCOMP minicomputer c. 1978 that had fixed partitioning. I believe it was the MAX III operating system and a MODCOMP II computer. During system build, you created partitions for foreground and real-time processes. The foreground partitions you could use for program development; the background partitions were for the real-time programs. They were fixed size (but not necessarily the same size).

I think that which program ran in the background partition or partitions was set during build time. To change program you had to rebuild.

  • You mean all partitions had the same size, right?
    – DYZ
    Feb 21, 2020 at 21:43
  • @DYZ Oh, I did not. They were usually differently sized. I'm sorry, I missed that requirement in your question. Feb 21, 2020 at 21:44
  • It was not a requirement. I am just curious whether it happened at all.
    – DYZ
    Feb 21, 2020 at 22:01
  • 1
    I found this manual which seems to be the machine in question. On page I-5 it says the OS with realtime/program dev ability is "MAX III" (MAX II is apparently batch). No software manuals available on bitsavers, though. Feb 21, 2020 at 23:19
  • @another-dave Good find. I think you're right, it must have been MAX III. Feb 21, 2020 at 23:23

Here's another off the road candidate: DoubleDuty for the TRS-80 Model 4

It split the 128 KiB main RAM of a full fitted Model 4 into two 64 KiB partitions, each able to run a stand alone application, plus a 16 KiB partition with just DOS.

enter image description here

(Catalogue scan taken from the Radio Shack Catalog Archive)

  • 1977, though - it's a bit of a latecomer :-) Feb 23, 2020 at 19:47
  • @another-dave The program published 1985. Not only a latecomer, but a real oddity as well. But yeah, micros re-invented almost everything over and over again. IT just came to my mind yesterday, and it surprisingly fits this questions odd narrative.
    – Raffzahn
    Feb 23, 2020 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .