Revived: RSRE Flex; and questions

[Tom Stepleton]

Greetings! By kind recommendation of Ben Laurie, I've joined this group. I'm a newcomer to capability systems, and yet I've been using one for a few months now: Flex, developed in the late '70s and throughout the 1980s at the Royal Signals and Radar Establishment in Malvern, England. Flex runs on my balky PERQ 2T2 workstation (and also in emulation, but real hardware is more fun) after some months chasing down 8" floppy disks and old MFM hard drives from across the country, and it's been a delight to explore.

I'll soon be giving a talk about Flex at a large outdoor festival for geeks, and while the venue is not academic per se, I hope to give a well-researched talk. This means that I need to enrich my understanding of capability systems, develop my knowledge of Flex's contemporaries (I've found Hank Levy's book as a starting point), and also identify the intellectual and social trends surrounding capability system developments of the time. The talk will be recorded and I would prefer to avoid any of you shouting at me through your screens if you see it!

I'd be grateful for any suggestions of resources (or views of your own) that could help me learn more, particularly for the intellectual and social trends (as I find the systems themselves are comparatively better-documented). Another seemingly more obscure thing that would be helpful to have resources for is information on the user interfaces people built for capability systems. Flex's mouse-enabled interface is distinctive and seems like an effort to realise capabilities as tangible artifacts for users to handle, and I wonder if other systems tried to do similar things.

As I don't believe Flex is much known, I can try to offer a capsule description now. I've collected some papers and technical notes by RSRE staff that will do a better job than this at https://mg-1.uk/flex/flex.html . I suspect what's here will betray my incomplete understanding of capability systems. But here goes:

------ Flex in a (big) nutshell

Flex (as manifested on the PERQ) is a (mostly) one-user-at-a-time multitasking OS that supports multiple user accounts. It runs atop a stack-based hardware architecture that makes use of specially-tagged pointers...

...and a single "accumulator-ish" register U. Both U and all stack entries can hold data items of (conceptually) any size, including strings and vectors, and exceptions can be generated by the hardware in the case of type errors or out-of-bounds accesses (among other things). Garbage collection is based on reference counting and is handled in hardware (above, "shaky"=weak, "firm"=strong).

Flex's user interface is exclusively a screen-filling hypertext (nb: term used with caution given present company) editor with an integrated command interpreter (hitting a special key interprets and executes the current line of otherwise-normal hypertext as a command). Hyperlinks, which are called "cartouches" in Flex, are visual representations of capabilities. Graphics may be embedded in documents (but are seldom found). Curiously, no Flex documentation I have ever found makes use of the word "hypertext" or "hyperlink". (Also, for my talk, I wonder if it may be important for me to be able to compare and contrast this experience with that of using a Lisp machine, which I know little about.)

Closures are a foundational context to Flex, similar in importance to files for Unix. They are first-class values (and in Flex parlance they are called "procedures"). There isn't really a notion of standalone binaries in Flex: there are only compiled procedures which you can either call from other code as normal or invoke in the command interpreter (where they are referenced via a capability, which of course is depicted as a cartouche). Logging into Flex as a user is accomplished by using the command interpreter to execute a procedure whose name is your username: the closure of this procedure contains all of your data which you access in normal usage. Logging out amounts to terminating this procedure and returning to the root document.

Flex's system language is Algol 68. Ada and Pascal compilers were developed later on but not necessarily to supersede it. (Declaring use of a module in Algol 68 source code is accomplished by placing a cartouche that refers to the module at the top of a source file.) Type safety is enforced throughout Flex and typechecking is applied to user commands.

Flex does not have a filesystem with names per se: there are just typed data items that are retained because some procedure somewhere has a capability that refers to them. If the user wants something resembling a hierarchical filesystem, it is up to them to make a hierarchy of documents containing cartouches referring to their "file" resources. Additionally, Flex makes use of write-once approaches to durable storage: "modifying" a stored item (e.g. a document) means writing the modified item to disk and allowing predecessor versions to be garbage collected. To make sure it's not turtles all the way down, a user's procedure will contain in its closure a persisted dictionary containing a few root items/documents; evaluating one of the names in the dictionary with the command interpreter will turn it into a cartouche representing the capability associated to that name.

------ Some questions I'm hoping to learn more about

(there are more, but I'm attempting to elide the basics and also to avoid re-kindling old debates...)

It would be great to know if anyone here has any knowledge of or experience with Flex, though I expect odds are slim. I do wonder if it had any influence on other systems, or if anyone knows what its direct influences were likely to be. My papers don't have much to say on this latter point.

Given what I've described above, I'd be interested to know what about Flex might seem unique. I gather that some concepts like the no-names filesystem and the use of closures may have been shared, so I suspect that much of the novelty lies in the interface, but I don't know. (CAP used Algol 68 too, so that's not unique...)

I'm wondering if there were other capability systems for personal or workstation usage at the time --- AFAICT, most (like CAP) were larger time-sharing systems; Plessey System 250 was for real-time control I gather. Perhaps then iMAX 432?

Finally: we are working with the current stewards of RSRE's IP to see if we can secure permission to release Flex to the public. RSRE shared Flex with universities and labs, and the terms of that sharing are evidently key information in this process. If anyone has hints as to how on earth to track down an example agreement (perhaps somebody here knows somebody?), I'd love to know. Additionally, Flex's floating point and maths code was made by what's now nAG, and so any suggestions of helpful contacts there would be most welcome, should anyone have them.

------

Well, this has been a long message, but I hope it is at least of some interest to folks here. As I've mentioned, it's been most rewarding to recover and explore Flex, and I'm looking forward to giving my talk in July.

Many thanks,

--T

[William ML Leslie]

On Fri, 5 Jun 2026 at 12:47, Tom Stepleton <step...@gmail.com> wrote:

Greetings! By kind recommendation of Ben Laurie, I've joined this group. I'm a newcomer to capability systems, and yet I've been using one for a few months now: Flex, developed in the late '70s and throughout the 1980s at the Royal Signals and Radar Establishment in Malvern, England. Flex runs on my balky PERQ 2T2 workstation (and also in emulation, but real hardware is more fun) after some months chasing down 8" floppy disks and old MFM hard drives from across the country, and it's been a delight to explore.

I'll soon be giving a talk about Flex at a large outdoor festival for geeks, and while the venue is not academic per se, I hope to give a well-researched talk. This means that I need to enrich my understanding of capability systems, develop my knowledge of Flex's contemporaries (I've found Hank Levy's book as a starting point), and also identify the intellectual and social trends surrounding capability system developments of the time. The talk will be recorded and I would prefer to avoid any of you shouting at me through your screens if you see it!

I'd be grateful for any suggestions of resources (or views of your own) that could help me learn more, particularly for the intellectual and social trends (as I find the systems themselves are comparatively better-documented). Another seemingly more obscure thing that would be helpful to have resources for is information on the user interfaces people built for capability systems. Flex's mouse-enabled interface is distinctive and seems like an effort to realise capabilities as tangible artifacts for users to handle, and I wonder if other systems tried to do similar things.

Welcome Tom, great to have you here!  Flex sounds like it was lovingly built, good to see it escaping the RSRE.

I have it on my todo-list to dig into Tendra's TDF at some point, which looks a bit like prior art for WASM or inferno.

 

Flex's user interface is exclusively a screen-filling hypertext (nb: term used with caution given present company) editor with an integrated command interpreter (hitting a special key interprets and executes the current line of otherwise-normal hypertext as a command). Hyperlinks, which are called "cartouches" in Flex, are visual representations of capabilities. Graphics may be embedded in documents (but are seldom found). Curiously, no Flex documentation I have ever found makes use of the word "hypertext" or "hyperlink". (Also, for my talk, I wonder if it may be important for me to be able to compare and contrast this experience with that of using a Lisp machine, which I know little about.)

This is wild, I have to check this out.  I have a lot to learn, it seems.  I usually think of Ka-Ping Yee's "Secure Interaction Design" as the go-to reference on capability UI, and the best citation that paper gives to prior secure UI work is something called Adage, cited as:

M. E. Zurko, R. Simon, and T. Sanfilippo. A User-Centered, Modular
Authorization Service Built on an RBAC Foundation. In Proceedings of IEEE
Symposium on Research in Security and Privacy (May 1999), p. 57–71.

Yee's website, http://zesty.ca/ , is mysteriously down.

If you do want to study lisp machines from a UI perspective, I recommend you don't ignore Medley InterLisp like I did.  Genera is lovely, but Xerox PARC were pushing boundaries on interactivity.

Flex's system language is Algol 68. Ada and Pascal compilers were developed later on but not necessarily to supersede it. (Declaring use of a module in Algol 68 source code is accomplished by placing a cartouche that refers to the module at the top of a source file.) Type safety is enforced throughout Flex and typechecking is applied to user commands.

This - as a way to use modules - makes so much sense.

 

Given what I've described above, I'd be interested to know what about Flex might seem unique. I gather that some concepts like the no-names filesystem and the use of closures may have been shared, so I suspect that much of the novelty lies in the interface, but I don't know. (CAP used Algol 68 too, so that's not unique...)

I think you're on the right track.  I'm not sure how far back the concept of a single-level store goes but it does seem natural in a capability system.  There are plenty of capability systems that didn't expose capabilities to the user, for example, it seems that KeyKOS (for the IBM System/370) looked like MVS to its users, and BiiN and the System/38 family were similar.

Well, this has been a long message, but I hope it is at least of some interest to folks here. As I've mentioned, it's been most rewarding to recover and explore Flex, and I'm looking forward to giving my talk in July.

Stoked.

--

William ML Leslie

Still has no idea what he is doing.

[John Carlson]

Be sure to check out E Monkey Engine for UI.

John 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hHZ%3DHqj6iD5coW4AuR3gzHAAb3N87-SkkD52Mbua4%3DG2Q%40mail.gmail.com.

[Matt Rice]

On Thu, Jun 4, 2026 at 7:47 PM Tom Stepleton <step...@gmail.com> wrote:

Greetings! By kind recommendation of Ben Laurie, I've joined this group. I'm a newcomer to capability systems, and yet I've been using one for a few months now: Flex, developed in the late '70s and throughout the 1980s at the Royal Signals and Radar Establishment in Malvern, England. Flex runs on my balky PERQ 2T2 workstation (and also in emulation, but real hardware is more fun) after some months chasing down 8" floppy disks and old MFM hard drives from across the country, and it's been a delight to explore.

I'll soon be giving a talk about Flex at a large outdoor festival for geeks, and while the venue is not academic per se, I hope to give a well-researched talk. This means that I need to enrich my understanding of capability systems, develop my knowledge of Flex's contemporaries (I've found Hank Levy's book as a starting point), and also identify the intellectual and social trends surrounding capability system developments of the time. The talk will be recorded and I would prefer to avoid any of you shouting at me through your screens if you see it!

I'd be grateful for any suggestions of resources (or views of your own) that could help me learn more, particularly for the intellectual and social trends (as I find the systems themselves are comparatively better-documented). Another seemingly more obscure thing that would be helpful to have resources for is information on the user interfaces people built for capability systems.

The Eros trusted window system paper.

https://www.usenix.org/conference/13th-usenix-security-symposium/design-eros-trusted-window-system

Seems like genode is another capability system with a graphical interface, not so familiar with drops and scout

but at least the nitpicker links should be relevant.

https://www.genode-labs.com/products/graphical-user-interfaces?lang=en

I know William had already mentioned Ka-Ping Yee's paper, User interaction design for secure systems.

Thought I would include a link though. https://dl.acm.org/doi/10.5555/646280.687663

Those were the three things that came to mind anyways.

 Flex's mouse-enabled interface is distinctive and seems like an effort to realise capabilities as tangible artifacts for users to handle, and I wonder if other systems tried to do similar things.

As I don't believe Flex is much known, I can try to offer a capsule description now. I've collected some papers and technical notes by RSRE staff that will do a better job than this at https://mg-1.uk/flex/flex.html . I suspect what's here will betray my incomplete understanding of capability systems. But here goes:

------ Flex in a (big) nutshell

Flex (as manifested on the PERQ) is a (mostly) one-user-at-a-time multitasking OS that supports multiple user accounts. It runs atop a stack-based hardware architecture that makes use of specially-tagged pointers...

...and a single "accumulator-ish" register U. Both U and all stack entries can hold data items of (conceptually) any size, including strings and vectors, and exceptions can be generated by the hardware in the case of type errors or out-of-bounds accesses (among other things). Garbage collection is based on reference counting and is handled in hardware (above, "shaky"=weak, "firm"=strong).

Flex's user interface is exclusively a screen-filling hypertext (nb: term used with caution given present company) editor with an integrated command interpreter (hitting a special key interprets and executes the current line of otherwise-normal hypertext as a command). Hyperlinks, which are called "cartouches" in Flex, are visual representations of capabilities. Graphics may be embedded in documents (but are seldom found). Curiously, no Flex documentation I have ever found makes use of the word "hypertext" or "hyperlink". (Also, for my talk, I wonder if it may be important for me to be able to compare and contrast this experience with that of using a Lisp machine, which I know little about.)

Closures are a foundational context to Flex, similar in importance to files for Unix. They are first-class values (and in Flex parlance they are called "procedures"). There isn't really a notion of standalone binaries in Flex: there are only compiled procedures which you can either call from other code as normal or invoke in the command interpreter (where they are referenced via a capability, which of course is depicted as a cartouche). Logging into Flex as a user is accomplished by using the command interpreter to execute a procedure whose name is your username: the closure of this procedure contains all of your data which you access in normal usage. Logging out amounts to terminating this procedure and returning to the root document.

Flex's system language is Algol 68. Ada and Pascal compilers were developed later on but not necessarily to supersede it. (Declaring use of a module in Algol 68 source code is accomplished by placing a cartouche that refers to the module at the top of a source file.) Type safety is enforced throughout Flex and typechecking is applied to user commands.

Flex does not have a filesystem with names per se: there are just typed data items that are retained because some procedure somewhere has a capability that refers to them. If the user wants something resembling a hierarchical filesystem, it is up to them to make a hierarchy of documents containing cartouches referring to their "file" resources. Additionally, Flex makes use of write-once approaches to durable storage: "modifying" a stored item (e.g. a document) means writing the modified item to disk and allowing predecessor versions to be garbage collected. To make sure it's not turtles all the way down, a user's procedure will contain in its closure a persisted dictionary containing a few root items/documents; evaluating one of the names in the dictionary with the command interpreter will turn it into a cartouche representing the capability associated to that name.

------ Some questions I'm hoping to learn more about

(there are more, but I'm attempting to elide the basics and also to avoid re-kindling old debates...)

It would be great to know if anyone here has any knowledge of or experience with Flex, though I expect odds are slim. I do wonder if it had any influence on other systems, or if anyone knows what its direct influences were likely to be. My papers don't have much to say on this latter point.

Given what I've described above, I'd be interested to know what about Flex might seem unique. I gather that some concepts like the no-names filesystem and the use of closures may have been shared, so I suspect that much of the novelty lies in the interface, but I don't know. (CAP used Algol 68 too, so that's not unique...)

I'm wondering if there were other capability systems for personal or workstation usage at the time --- AFAICT, most (like CAP) were larger time-sharing systems; Plessey System 250 was for real-time control I gather. Perhaps then iMAX 432?

Finally: we are working with the current stewards of RSRE's IP to see if we can secure permission to release Flex to the public. RSRE shared Flex with universities and labs, and the terms of that sharing are evidently key information in this process. If anyone has hints as to how on earth to track down an example agreement (perhaps somebody here knows somebody?), I'd love to know. Additionally, Flex's floating point and maths code was made by what's now nAG, and so any suggestions of helpful contacts there would be most welcome, should anyone have them.

------

Well, this has been a long message, but I hope it is at least of some interest to folks here. As I've mentioned, it's been most rewarding to recover and explore Flex, and I'm looking forward to giving my talk in July.

Many thanks,

--T

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/c50e49eb-4456-4898-8258-66732d55dcaen%40googlegroups.com.

[Alan Karp]

I don't know if this user interface is what you're looking for, https://shiftleft.com/mirrors//www.hpl.hp.com/techreports/2009/HPL-2009-53.pdf.  It's for an application, not an OS desktop.

--------------
Alan Karp

On Thu, Jun 4, 2026 at 7:47 PM Tom Stepleton <step...@gmail.com> wrote:

--

[William ML Leslie]

These are all resources from the 90s and later.  What is remarkable is Flex had these properties in the 70s.  What could we be missing?

--

William ML Leslie

Missing Charlie and Bill?

[Tom Stepleton]

Thanks for the remarks and the welcome! I appreciate these resources and context.

As a minor and fairly inconsequential note on dates: Flex may have run in limited form in the late '70s and had probably not achieved something like its final UX until a few years into the '80s.

In re Flex running at all regardless of UX, this whitepaper from 1979 expresses hope that a dedicated multi-user Flex machine (built under contract by Logica) will be operational in 1980, while indicating that a single-user "laboratory model" is already operational. This paper suggests that the laboratory model (like the Logica system that followed) would have been an Am2900 bit-slice-based machine. It also describes a third Flex implementation that ran on something called GEMINI, which was apparently a microcode-programmable auxiliary computer that you fitted into a PDP-11. (Momentary digression:) The idea with GEMINI seems to have been that if you had a factory that used a much older computer for process control, you could program a GEMINI to emulate that system and keep using your old factory equipment. The Flex folks at RSRE must have found this convenient for development, and I expect it would have made the transition to the PERQ workstation and its programmable microcode seem fairly natural.

1982 brings the first description I can find of a mechanism that starts to be like Flex's "cartouches", This whitepaper describes the Curt command interpreter, which is much the same as used on the PERQ, but lives on its own in the bottom two lines of 80-column terminals attached to the Logica machine. Curt expressions which have been evaluated are underlined to indicate that the text now represents the result of the evaluation, but evaluating or naming this result (or carrying out some other operation) now requires calling another procedure; you can't click on it or otherwise treat in in a way that feels like following a link. In that respect it's much the same as saying as typing "less mydocument.txt" to see a document in a modern shell.

From here there is a gap in my resources until 1985, by which time Flex appears to be well-established on PERQ, with its interface fully matured. RSRE are distributing copies outside of its lab. Flex's developers took great advantage of the hypertext (again used tentatively) nature of the interface on PERQ, as essentially all of the tutorial and technical documentation beyond installation instructions is online within the system. This is found in pages like this one, where the cartouches are the rectangles, and where you can open their destination documents (or reveal their values for certain other data types) with the mouse:

As you might expect, it has been difficult to come up with ways to export all of this documentation onto a modern machine! The "easiest hardest way" would probably be to reverse-engineer the filestore and the structure of the documents (called "Edfiles" in Flex) and then extract the documentation from disk images.

In any case, in PERQ Flex, you can evaluate any line in the display with the Curt interpreter by pressing a special key. And if you don't want to muss the document you're writing, pressing a different key will split the screen to produce a separate temporary editor window for ad-hoc worc. You can then copy and paste text, cartouches, etc. that you make there into other windows.

Thanks again to all,

--T

--
You received this message because you are subscribed to a topic in the Google Groups "cap-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cap-talk/0TZ1jNn-tB0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hGey2dRfCEu2ZzLcc2mZrRyrgu_wj_BnvHwdx%3Du6ZtfMA%40mail.gmail.com.