From Newsgroup: alt.folklore.computers

On 18 May 2026 17:34:00 +0100 (BST), Theo wrote:

John Ames <commodorejohn@gmail.com> wrote:

[...]

Computer Concepts products for the Archimedes had an interesting take on
it.
You had separate editors for equations, tables, etc which were
standalone apps. When you wanted to insert a new table, it would spin
up the table editor app and let you edit it, and insert the table back
into the document when you saved it.

The neat trick was that their file formats were based on extensions of a generic vector graphics format that was common across the OS.
Extensibility was a supported part of the original design, a bit like
HTML (but a binary format).

That meant apps could trivially display those tables, equations, etc
even if they didn't know anything about the metadata.

You could only
properly edit them in the respective app, although it was possible to
open them in the standard vector editor - I think the editor would
propagate the extended tags but not know how to modify them

I could see this getting so confusing for new users, they would find *A* solution that "works" but ultimatly have to have a power user show them
how to edit a table properly rather than editing it in a vector app
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Mon, 3 Aug 2026 23:24:50 -0000 (UTC), Jeffrey Bagely wrote:

I could see this getting so confusing for new users, they would find
*A* solution that "works" but ultimatly have to have a power user
show them how to edit a table properly rather than editing it in a
vector app

A common feature of the rCLdocument-centricrCY model was that the user
didnrCOt have to know about different rCLappsrCY. They just had a rCLdocumentrCY, which contained multiple parts of different types. The
fact that these parts needed different back-end code modules/apps/plugins/whatever to handle them was not something the
user had to worry about: just click within a part, and the appropriate
editor comes to life to handle whatever the user wants to do to that
part.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Mon, 3 Aug 2026 23:53:34 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 3 Aug 2026 23:24:50 -0000 (UTC), Jeffrey Bagely wrote:

I could see this getting so confusing for new users, they would find
*A* solution that "works" but ultimatly have to have a power user show
them how to edit a table properly rather than editing it in a vector
app

A common feature of the rCLdocument-centricrCY model was that the user didnrCOt have to know about different rCLappsrCY. They just had a rCLdocumentrCY,
which contained multiple parts of different types. The fact that these
parts needed different back-end code modules/apps/plugins/whatever to
handle them was not something the user had to worry about: just click
within a part, and the appropriate editor comes to life to handle
whatever the user wants to do to that part.

I think the definition of "document" is getting muddied up here. From what
the OP seems to have stated, the delineation between a "document" and what
I will call a "Composite Doc" is that a "document" is a single file for
each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types" being contained (i.e. Spreadsheet data mixed in with regular rich text).


From what @Theo was saying I think, if I understand correctly, is that
there was a "Composite Doc" which had the ability to open each "part" in
its own dedicated "part" editor for full editing capabilities for that
part's data type, but was not strictly necessary. Say, if there wasn't a
full editor for that part's data type (spreadsheet) then the "Composite
Doc" Processor would open that part in something like a vector editor that
had partial or tangential editing capabilites for that "part" data type.

So, our spreadsheet in our regular rich document is opened for editing in
a vector editor, because on this system the spreadsheet, images and rich
text all share the same vector backend but, only the spreadsheet
application can manipulate the spreadsheet part in a user friendly
spreadsheet type of way.


This is where my thinking came from when I wrote the above regarding new
users and their struggles to find solutions by discovering "weird
machines" within the design.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Tue, 4 Aug 2026 00:48:34 -0000 (UTC), Jeffrey Bagely wrote:

On Mon, 3 Aug 2026 23:53:34 -0000 (UTC), Lawrence DrCOOliveiro wrote:

I think the definition of "document" is getting muddied up here.
From what the OP seems to have stated, the delineation between a
"document" and what I will call a "Composite Doc" is that a
"document" is a single file for each type of data handled for that
file type's application.

A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).

rCLDocrCY is just short for rCLdocumentrCY.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Tue, 4 Aug 2026 02:56:02 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Tue, 4 Aug 2026 00:48:34 -0000 (UTC), Jeffrey Bagely wrote:

On Mon, 3 Aug 2026 23:53:34 -0000 (UTC), Lawrence DrCOOliveiro wrote:

I think the definition of "document" is getting muddied up here. From
what the OP seems to have stated, the delineation between a "document"
and what I will call a "Composite Doc" is that a "document" is a single
file for each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).

rCLDocrCY is just short for rCLdocumentrCY.

Yes
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

I think the definition of "document" is getting muddied up here. From what the OP seems to have stated, the delineation between a "document" and what
I will call a "Composite Doc" is that a "document" is a single file for
each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types" being contained (i.e. Spreadsheet data mixed in with regular rich text).

How the data is stored on disc is orthogonal to how the editing works.
They're just bags of bits; how you organise the bags of bits is a design decision.

From what @Theo was saying I think, if I understand correctly, is that
there was a "Composite Doc" which had the ability to open each "part" in
its own dedicated "part" editor for full editing capabilities for that part's data type, but was not strictly necessary. Say, if there wasn't a full editor for that part's data type (spreadsheet) then the "Composite
Doc" Processor would open that part in something like a vector editor that had partial or tangential editing capabilites for that "part" data type.

So, our spreadsheet in our regular rich document is opened for editing in
a vector editor, because on this system the spreadsheet, images and rich text all share the same vector backend but, only the spreadsheet
application can manipulate the spreadsheet part in a user friendly spreadsheet type of way.

The way Computer Concepts did it used a few tricks:

1. On the Archimedes, applications were a directory whose name started with the ! symbol. Roughly the same as how MacOS has Something.app application bundles which are just directories. (! was chosen as it's first in ASCII sorting)

2. Their 'documents' were stored as applications, where double clicking
them (opening the app) would open them in the overarching editor (eg word processor). Inside the application directory were various files making up
the inclusions (tables, equations, drawings, bitmap images, etc).


3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know
whether a regular file is a drawing or a JPEG from the filetype rather than
the extension.

3. Their OLE implementation used the vector drawing file format with extra extensions for the table/equation/etc metadata. The files were typed with their rich format (eg Equation, Table). By changing the filetype to vector
you could open them in the standard vector drawing program (!Draw) if you wanted.

(in later versions they switched to more conventional single-file documents
and used temporary files for pulling out and editing the inclusions)

4. The renderer for these documents just displayed them as vector
graphics (ie the renderer could display documents it didn't have the editor for)

5. When editing the doc, you could just click on the image, equation or
table and it would open in the appropriate editor. If you didn't have the editor you couldn't edit it, but you could still view it. If you 'saved'
the table/equation/etc in this editor (you were prompted if you tried to
close it) it would update in the parent document.

6. RISC OS' desktop was designed a bit like the Unix philosophy - small programs each doing one thing well, with easy drag and drop between them.
So it wasn't unusual to have lots of windows open for editing different
things. It wasn't like the Mac/Windows idea where you have one heavy app
which seemingly takes over the machine. That means it wasn't confusing that the equation editing window happened to be owned by the equation editing app that was different from the word processor app - it was just another window and, aside from a few clues, you didn't really notice. When you finished editing you closed the window and 'saved' the sub-document, which updated
the master document.

This is where my thinking came from when I wrote the above regarding new users and their struggles to find solutions by discovering "weird
machines" within the design.

I would suggest that is more the flaw of OSes like MacOS and Windows which
are designed to hold you in large heavy corporate apps running fullscreen, rather than an ecosystem of small apps all on the screen at once. In the latter case, what would be a dialog from an application like Word can
instead be a separate app launched on demand alongside whatever you were
doing, and you wouldn't need to know it was actually a separate app
underneath.

Now, arguably doing editing in a separate window is more awkward than editing-in-place. But actually, although I don't think it was ever implemented, RISC OS is capable of doing editing-in-place too. All you had
to do was some window management so that scrolling of the parent window also moved or obscured a borderless sub-editor window. If you scroll the
equation off the screen, the editor window disappears. If you scroll it
back, it's moved and resized to where it would be in the document. As RISC
OS uses context-sensitive menus you can click the Menu mouse button over the equation and get the equation editor's menu, while if you click it over the main document you get the main editor's menu.

This kind of window resizing shenanigans is something apps do all the time
if they have say a tool pane, which is often implemented as a separate
window whose position is updated every time the document window is moved or resized. So, with a bit of cooperation from both sides, it would not be
hard to do.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Theo <theom+news@chiark.greenend.org.uk> writes:

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know >whether a regular file is a drawing or a JPEG from the filetype rather than >the extension.

This is not new. It was common in the 60's and 70's mainframe and
minicomputer operating systems.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 10/05/2026 23:53, Lawrence DrCOOliveiro wrote:

I remember back in the 1990s, there was this great push to promote a rCLdocument-centricrCY approach to architecting desktop applications, as opposed to the traditional rCLapplication-centricrCY way.

In the traditional way, each document was managed by a single
controlling application. Thus, you had word-processing documents
managed by a word-processing app, spreadsheet documents managed by a spreadsheet app, etc. To create a new document of the right type, you
had to launch the right app.

In the new way, a document could be a composite of rCLpartsrCY, which
could have different types of structured content. E.g. you could have
a word-processing part and a spreadsheet part within the same
document. Clicking inside the word-processing part would activate,
behind the scenes, the relevant set of code that would previously have
been a separate word-processing app, but which now lived within a
single common process context associated with that document. Click
inside the spreadsheet part, and that activates the spreadsheet code.

The key point about all this being that the code handlers for those
different rCLpartsrCY could be created by entirely different software vendors, and sold separately. So you didnrCOt have to buy a single all-singing, all-dancing application suite from a single vendor, you
would (in theory) be able to pick and choose from various competing alternatives on a much more granular basis.

The way Microsoft bundles Office it does not make financial sense to buy separate apps.

Did all this turn out to be too complex for users to manage?

I think its more they don't see the need!

Or was it

merely killed by the usual war-of-competing-proprietary-standards,
with Microsoft in one corner with its OLE 2.0 architecture, and Apple
in the other with OpenDoc?

Apple killed OpenDoc in 1997 so nearly 10 years ago apparently for
performance issues. So we are now in the situation where OLE works on
Windows but there is no equivalent on MacOs so if you send a compound document.

Dave

Dave

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

I think the definition of "document" is getting muddied up here. From
what the OP seems to have stated, the delineation between a "document"
and what I will call a "Composite Doc" is that a "document" is a single
file for each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).

How the data is stored on disc is orthogonal to how the editing works. They're just bags of bits; how you organise the bags of bits is a design decision.

Ahh, I thought you were specifically talking about the structure of
documents. I find that if everything is in it's separate file and a
document preparation system is designed to work that way, it is much more enjoyable to work with. Say templating with LaTex for reporting based off
of CSV files and making graphs. Just nicer to work with and can also apply version control. No proprietary all encompassing binary formats like docx

The way Computer Concepts did it used a few tricks:

1. On the Archimedes, applications were a directory whose name started
with the ! symbol. Roughly the same as how MacOS has Something.app application bundles which are just directories. (! was chosen as it's
first in ASCII sorting)

So you are talking about not only applications that could be global to the system for use by the application (not saying this is how the archimedes worked) but also a set of utils built for a specific software product in
its own isolated bundle/package that all worked cohesively to serve as a document preparation toolkit which happened to be really well integrated.

2. Their 'documents' were stored as applications, where double clicking
them (opening the app) would open them in the overarching editor (eg
word processor). Inside the application directory were various files
making up the inclusions (tables, equations, drawings, bitmap images,
etc).

Are you saying that the document that you may be preparing is shared in
the same directory as the software used to write it? That seems a bit odd
to me. Nice an encapsulated but wouldn't that mean every user generated docuemnt carries the whole set of binary utils with it as well?

3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know whether a regular file is a drawing or a JPEG from the filetype rather
than the extension.

I wish this was the case still, rather than extensions as you mention or memorizing and hoping to find magic numbers. Would make sorting through filesystem data a bit easier and reassuring when restoring from backups.

3. Their OLE implementation used the vector drawing file format with
extra extensions for the table/equation/etc metadata. The files were
typed with their rich format (eg Equation, Table). By changing the
filetype to vector you could open them in the standard vector drawing
program (!Draw) if you wanted.

(in later versions they switched to more conventional single-file
documents and used temporary files for pulling out and editing the inclusions)

4. The renderer for these documents just displayed them as vector
graphics (ie the renderer could display documents it didn't have the
editor for)

5. When editing the doc, you could just click on the image, equation or table and it would open in the appropriate editor. If you didn't have
the editor you couldn't edit it, but you could still view it. If you
'saved' the table/equation/etc in this editor (you were prompted if you
tried to close it) it would update in the parent document.

6. RISC OS' desktop was designed a bit like the Unix philosophy - small programs each doing one thing well, with easy drag and drop between
them. So it wasn't unusual to have lots of windows open for editing
different things. It wasn't like the Mac/Windows idea where you have
one heavy app which seemingly takes over the machine. That means it
wasn't confusing that the equation editing window happened to be owned
by the equation editing app that was different from the word processor
app - it was just another window and, aside from a few clues, you didn't really notice. When you finished editing you closed the window and
'saved' the sub-document, which updated the master document.

This is starting to make WAY more sense now that you putting more plainly here. It was the case where you could utilize specialized small programs
that generated a vector drawing, just following lets say a 'table' ruleset (how you are allowed to draw) which then could be interpreted by the word processor as any general vector to display within the document.

I now also see why you specifically say that the organization of data
doesn't matter in the context of an isolated system like this because all would be operating on and stroing data in the 'universal way'

This is where my thinking came from when I wrote the above regarding
new users and their struggles to find solutions by discovering "weird
machines" within the design.

I would suggest that is more the flaw of OSes like MacOS and Windows
which are designed to hold you in large heavy corporate apps running fullscreen, rather than an ecosystem of small apps all on the screen at
once. In the latter case, what would be a dialog from an application
like Word can instead be a separate app launched on demand alongside
whatever you were doing, and you wouldn't need to know it was actually a separate app underneath.

I would also like to say that creating features for a piece of software
that overlap is somewhat bad practice. What I mean is that for a
functional (maths variety) kind of thinker there should really be one
right (developer blessed) way to do a particular function. Now that
doesn't mean that there is a limit to any particular feature but that the cross cutting (interfering is probably a better term here, not sure)
aspects of a program's design should be kept to a minimum.

An example is in MS Excel today, there are multiple ways to provide alternative colors for a table, conditional coloring, or converting the
range into a proper structured table selected with a particular color scheme/pattern. In fact the fact that in a spreadsheet program you can
define a 'stronger' table within a tabular environment is something that
most users don't even grasp because it seems like they already arrived to
the correct (best?) solution to their tabular problems by opening MS
Excel!

Its this set of features stumbling over each other within single
applications that do the most damage in regards to this werid machines
problem they seem to all have.

Perhaps software shouldn't necessarily expect to work like how humans
think but that humans should realize that they are using a computer and
should first learn how to use one if it is necessary (think like how a computer works). Much like I wouldn't feel comfortable with a person
driving a car who didn't know what the accelerator or breaks are or what
they did in reference to the vehicle.

But its a lot to ask from people I know, especially since most still can't figure out how to drive even now.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

I think the definition of "document" is getting muddied up here. From
what the OP seems to have stated, the delineation between a "document"
and what I will call a "Composite Doc" is that a "document" is a single
file for each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).

How the data is stored on disc is orthogonal to how the editing works. They're just bags of bits; how you organise the bags of bits is a design decision.

Ahh, I thought you were specifically talking about the structure of documents. I find that if everything is in it's separate file and a
document preparation system is designed to work that way, it is much more enjoyable to work with. Say templating with LaTex for reporting based off
of CSV files and making graphs. Just nicer to work with and can also apply version control. No proprietary all encompassing binary formats like docx

The way Computer Concepts did it used a few tricks:

1. On the Archimedes, applications were a directory whose name started with the ! symbol. Roughly the same as how MacOS has Something.app application bundles which are just directories. (! was chosen as it's first in ASCII sorting)

So you are talking about not only applications that could be global to the system for use by the application (not saying this is how the archimedes worked) but also a set of utils built for a specific software product in
its own isolated bundle/package that all worked cohesively to serve as a document preparation toolkit which happened to be really well integrated.

No, merely that documents were stored each in their own file bundle that happened to reuse the way application file bundles worked. In RISC OS application bundles are just a fancy directory, they can (and do) live
anywhere on any filesystem. What makes an application? Most it has its own icon (a Sprites file inside the directory) and it has an action that runs
when you double click it. In this case that was a script that started the editor and told it to open this document. That made its behaviour to the
user that what they'd expect from a single file (except the ! prefix).

This is mostly tangential, but it meant a 'document' could be a cohesive
bundle of files that appeared to the user to be one object, rather than
having to be packed into a single file. It's relevant because inside the document bundle were the individual document elements (text, images, tables, equations, etc) which retained their native filetyping. You could just open the document bundle (shift-double-click the application) and find the
document elements inside.

Of course, such ideas were later popularised with standards like docx
(OOXML), where the document 'file' is actually represented by a zipfile containing a bundle of component files.

2. Their 'documents' were stored as applications, where double clicking them (opening the app) would open them in the overarching editor (eg
word processor). Inside the application directory were various files making up the inclusions (tables, equations, drawings, bitmap images,
etc).

Are you saying that the document that you may be preparing is shared in
the same directory as the software used to write it? That seems a bit odd
to me. Nice an encapsulated but wouldn't that mean every user generated docuemnt carries the whole set of binary utils with it as well?

No, they were separate. In general there was no on-disc organisation
imposed, so the pieces could live wherever you wanted them. (Including on removable discs which may or may not be present)

(there's a mechanism by which the first time you open a folder containing
an application, it can register itself with the system and make it
available to open file types it knows about. This can also be pre-loaded at boot time)

3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know whether a regular file is a drawing or a JPEG from the filetype rather
than the extension.

I wish this was the case still, rather than extensions as you mention or memorizing and hoping to find magic numbers. Would make sorting through filesystem data a bit easier and reassuring when restoring from backups.

Some filesystems can have extended metadata for this, although I can't think
of anything that widely uses it. It gets a bit hairy when
you consider the mappings of extensions to MIME types, which are typically
what people mean by filetypes today - this mapping is not a bijection.

This is starting to make WAY more sense now that you putting more plainly here. It was the case where you could utilize specialized small programs that generated a vector drawing, just following lets say a 'table' ruleset (how you are allowed to draw) which then could be interpreted by the word processor as any general vector to display within the document.

I now also see why you specifically say that the organization of data doesn't matter in the context of an isolated system like this because all would be operating on and stroing data in the 'universal way'

With something like OOXML or ODF you can still do the same thing, eg if I
make a wordprocessor doc with a JPEG in it I can unzip the .docx or .odt and find the JPEG inside the bundle.

In Libreoffice, if I open the file and right click on the JPEG I can 'open
in external tool'. For me that opens it in Gwenview. Suppose I rotate the JPEG, save and close it - the image in the document is now updated. LO is using a temporary JPEG file for that (I can't access the file in the original .odt without first unpacking it) but otherwise it's the same process.

The idea of having 'hidden' metadata is also not uncommon today - eg in HTML where the browser ignores tags it doesn't understand and can nevertheless render the page. If you open the HTML in something that does understand the extra tags then it can do something different with the document.

I would also like to say that creating features for a piece of software
that overlap is somewhat bad practice. What I mean is that for a
functional (maths variety) kind of thinker there should really be one
right (developer blessed) way to do a particular function. Now that
doesn't mean that there is a limit to any particular feature but that the cross cutting (interfering is probably a better term here, not sure)
aspects of a program's design should be kept to a minimum.

An example is in MS Excel today, there are multiple ways to provide alternative colors for a table, conditional coloring, or converting the range into a proper structured table selected with a particular color scheme/pattern. In fact the fact that in a spreadsheet program you can define a 'stronger' table within a tabular environment is something that most users don't even grasp because it seems like they already arrived to the correct (best?) solution to their tabular problems by opening MS
Excel!

Its this set of features stumbling over each other within single applications that do the most damage in regards to this werid machines problem they seem to all have.

I'd say this is a result of application featureitis. Because you can't
easily share functionality, every app ends up with its own table editor,
even if one app (Excel) does it better than others (Word, OneNote).
Sometimes there is a reason for that (aesthetics, simplicity,
interconnection), but often not (eg it would be very handy to be able to put
a spreadsheet-powered table in my OneNote files instead of the dumb tables
they implement). This is also why these monolthic apps get bloated, because they need to include the code for every feature everyone could possibly
want.

With the Unix philosophy, it may be more complicated to learn but you build
up an ecosystem of swappable parts - if you don't like the app that does one job, swap it out for another app that does the same job better. You don't
end up with the monoculture where you get locked into Word for everything,
even if some sub-feature is better done by an independent app.

Perhaps software shouldn't necessarily expect to work like how humans
think but that humans should realize that they are using a computer and should first learn how to use one if it is necessary (think like how a computer works). Much like I wouldn't feel comfortable with a person
driving a car who didn't know what the accelerator or breaks are or what they did in reference to the vehicle.

But its a lot to ask from people I know, especially since most still can't figure out how to drive even now.

Much of this is still learned behaviour. I always say that 'intuitive' is
just (deliberate) technobabble for 'works like something you've used
before'. You still had to learn that first thing - no-one was born knowing
how to use dialog boxes.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Tue, 4 Aug 2026 21:31:15 -0000 (UTC), Jeffrey Bagely wrote:

I find that if everything is in it's separate file and a document
preparation system is designed to work that way, it is much more
enjoyable to work with. Say templating with LaTex for reporting
based off of CSV files and making graphs. Just nicer to work with
and can also apply version control.

What you really mean there is rCLeverything should be a *text* filerCY.
Text files certainly work well with version control. That I can agree
with.

No proprietary all encompassing binary formats like docx

Fun fact: docx (ISO 29500) and ODF (ISO 26300) are both just .zip
files at heart. Unzip them, and you should find some text files (XML,
mainly) for the main content, plus binaries for things like images.
So, a lot of that works fine with version control. And then you can
zip the components back together to recreate the original document.

At least, ODF works this way; I havenrCOt looked at any actual DOCX
files to be sure.

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

3. RISC OS gives each file 12-bit 'filetype' metadata, so you can
know whether a regular file is a drawing or a JPEG from the
filetype rather than the extension.

I wish this was the case still, rather than extensions as you
mention or memorizing and hoping to find magic numbers.

We *do* have MIME types, you know. These are actual human-readable
strings, not cryptic integer codes.

And yes, there are Linux filesystems that let you attach such things
to files as additional attribute metadata.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

6. RISC OS' desktop was designed a bit like the Unix philosophy -
small programs each doing one thing well, with easy drag and drop
between them. So it wasn't unusual to have lots of windows open for
editing different things. It wasn't like the Mac/Windows idea where
you have one heavy app which seemingly takes over the machine.

Ah, but then, you have all these Mac fans who claim that their macOS
is rCLUnixrCY. How do you reconcile that?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 00:29:25 -0000 (UTC), Lawrence DrCOOliveiro wrote:

What you really mean there is rCLeverything should be a *text* filerCY.
Text files certainly work well with version control. That I can agree
with.

I view small images and sub 5Mb binaries as fully version controllable as
long as there is either some form of managerial or technical file locking.
Or only a single person (aka you alone) will be making changes to those binaries. Merging is not really possible there but merging is somewhat a manual process any ways if you happen to have conflicting changes in text files (which for binaries always happens!)

No proprietary all encompassing binary formats like docx

Fun fact: docx (ISO 29500) and ODF (ISO 26300) are both just .zip files
at heart. Unzip them, and you should find some text files (XML, mainly)
for the main content, plus binaries for things like images. So, a lot of
that works fine with version control. And then you can zip the
components back together to recreate the original document.

At least, ODF works this way; I havenrCOt looked at any actual DOCX files
to be sure.

I actually forgot about this fact, thanks for the reminder!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 00:31:45 -0000 (UTC), Lawrence DrCOOliveiro wrote:

Ah, but then, you have all these Mac fans who claim that their macOS is rCLUnixrCY. How do you reconcile that?

The philosophy must be maintained by the developers, this means the
philosophy of Unix style programs is just as important as those who
develop in it's style. Which means that some of their tools may be "Unix"
but most are not.

In addtion I found this snippet from the wikipedia page for the MacOS
Kernel that directly states that it isn't Unix LOL!

```
XNU ("X is Not Unix") is the computer operating system (OS) kernel
developed at Apple Inc. since December 1996 for use in the Mac OS X (now macOS) operating system and released as free and open-source software as
part of the Darwin OS, which, in addition to being the basis for macOS, is also the basis for iOS, iPadOS, watchOS, visionOS, and tvOS.[2]
```
https://en.wikipedia.org/wiki/XNU
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 03:22:27 -0000 (UTC), Jeffrey Bagely wrote:

On Wed, 5 Aug 2026 00:31:45 -0000 (UTC), Lawrence DrCOOliveiro wrote:

Ah, but then, you have all these Mac fans who claim that their macOS is
rCLUnixrCY. How do you reconcile that?

The philosophy must be maintained by the developers, this means the philosophy of Unix style programs is just as important as those who
develop in it's style. Which means that some of their tools may be
"Unix" but most are not.

In addtion I found this snippet from the wikipedia page for the MacOS
Kernel that directly states that it isn't Unix LOL!

```
XNU ("X is Not Unix") is the computer operating system (OS) kernel
developed at Apple Inc. since December 1996 for use in the Mac OS X (now macOS) operating system and released as free and open-source software as
part of the Darwin OS, which, in addition to being the basis for macOS,
is also the basis for iOS, iPadOS, watchOS, visionOS, and tvOS.[2]
```
https://en.wikipedia.org/wiki/XNU

I looked a little further down and it turns out that the following is also stated.

```
macOS achieved UNIX certification in 2007 with the release of Mac OS X
10.5 Leopard[7] under the Single UNIX Specification (SUS) by The Open Group.[8] Despite this, Apple retained the original 'XNU' name, which
stands for 'X is Not Unix,' a relic from its NeXTSTEP origins before macOS
was UNIX-certified. This has led to confusion, as the name suggests that
XNU is separate from UNIX, even though macOS, as a whole, is officially recognized as a UNIX operating system.
```
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 03:18:38 -0000 (UTC), Jeffrey Bagely wrote:

On Wed, 5 Aug 2026 00:29:25 -0000 (UTC), Lawrence DrCOOliveiro wrote:

What you really mean there is rCLeverything should be a *text* filerCY.
Text files certainly work well with version control. That I can
agree with.

I view small images and sub 5Mb binaries as fully version
controllable as long as there is either some form of managerial or
technical file locking. Or only a single person (aka you alone) will
be making changes to those binaries. Merging is not really possible
there but merging is somewhat a manual process any ways if you
happen to have conflicting changes in text files (which for binaries
always happens!)

Linus Torvalds described his typical workday with the Linux kernel and
Git in a talk at Google some years ago <https://www.youtube.com/watch?v=4XpnKHJAok8>.

One thing about the Git version control system is that it takes most
of the drama out of merging: instead of being a hit-or-miss process,
it becomes something that can be handled routinely. Yes you do get
conflicts every now and then, but it actually helps with figuring
those out a lot of the time, instead of just dropping everything on
the floor.

But this only works with text files; with binary data -- forget it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

6. RISC OS' desktop was designed a bit like the Unix philosophy -
small programs each doing one thing well, with easy drag and drop
between them. So it wasn't unusual to have lots of windows open for
editing different things. It wasn't like the Mac/Windows idea where
you have one heavy app which seemingly takes over the machine.

Ah, but then, you have all these Mac fans who claim that their macOS
is rCLUnixrCY. How do you reconcile that?

UNIX (TM) != 'the Unix philosophy'.

MacOS is UNIX (TM) certified at the system call level. UNIX certification doesn't touch the GUI.

RISC OS is not Unix (probably wouldn't pass certification even with UnixLib) but the GUI borrows certain ideas from how Unix programs work together on
the command line. In philosophy only, the mechanics are wildly different.

Apples and albatroses.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 05 Aug 2026 18:46:59 +0100 (BST), Theo wrote:

RISC OS is not Unix (probably wouldn't pass certification even with
UnixLib) but the GUI borrows certain ideas from how Unix programs
work together on the command line.

HererCOs a subtle question: how exactly is the command line implemented
at the kernel level?

In a Unix-type system, the command line is passed as the rCLargument
vectorrCY (you may be familiar with the rCLargvrCY that you see as an
argument to the main() of a C program). Whereas in Windows (and its
precursor MS-DOS), you have the simple string buffer inherited from
CP/M from the 8-bit era, which in turn copied it from the DEC
operating systems that came before.

The difference is, trying to pass multiple command-line arguments in a
simple string buffer requires the use of shell-style escaping
conventions, even when no shell is involved. Whereas on Unix-type
systems, it is easy (and common) for one program to directly invoke
another, passing the argument vector directly, without having to worry
about escaping any characters that might be interpreted specially by a
shell -- because you donrCOt need to go through a shell.

So, which way does RISC OS do it?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 21:38:49 -0000 (UTC), Lawrence DrCOOliveiro wrote:

trying to pass multiple command-line arguments in a
simple string buffer requires the use of shell-style escaping
conventions, even when no shell is involved. Whereas on Unix-type
systems, it is easy (and common) for one program to directly invoke
another, passing the argument vector directly, without having to worry
about escaping any characters that might be interpreted specially by a
shell -- because you donrCOt need to go through a shell.

This is outside the realm of my understanding but why would a string
buffer need escaping at all? Especially without a shell?

I just don't quite understand how that would work if there isn't an interpreter between invoker and invoked? Assuming the kernel doesn't do parsing of the argument string, I wouldn't understand why it would ever
need to.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Wed, 5 Aug 2026 21:55:28 -0000 (UTC), Jeffrey Bagely wrote:

This is outside the realm of my understanding but why would a string
buffer need escaping at all? Especially without a shell?

Because you want to pass separate command-line arguments. A command
line typically consists of multiple words/arguments/options. With the
Unix system, you have a ready-made mechanism for passing an array of
separate words direct from one program to another, but with Windows
you donrCOt.

I just don't quite understand how that would work if there isn't an interpreter between invoker and invoked?

The thing with the Windows-style simple string buffer is, you always
have to pretend there is such an interpreter, even when there isnrCOt.

So how does RISC OS do it?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Theo wrote:

MacOS is UNIX (TM) certified at the system call level.

A couple of nit-picks:

1. It's UNIX(R) not UNIX(TM).

2. UNIX(R) certification is at the C library function level (including
ones that are commonly implemented as system calls - the standard does
not distinguish between library functions and system calls), and also
at the C language and shell command levels.

For more info see https://www.opengroup.org/openbrand/docs/UNIX03_Certification_Guide.html

(That's the old UNIX 03 guide, since MacOS is certified to UNIX 03, not
the later UNIX V7 one; just change "03" to "V7" to see the latter.)
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

On Wed, 5 Aug 2026 21:55:28 -0000 (UTC), Jeffrey Bagely wrote:

This is outside the realm of my understanding but why would a string
buffer need escaping at all? Especially without a shell?

Because you want to pass separate command-line arguments. A command
line typically consists of multiple words/arguments/options. With the
Unix system, you have a ready-made mechanism for passing an array of
separate words direct from one program to another, but with Windows
you donrCOt.

Jeffrey Bagely is likely thinking the other system would also assume 0-terminated strings so that one could just copy over the array from its beginning to its last byte without having to copy string by string
looking inside to see where each of them terminate.

If that's so, an answer that would satisfy him here is why such system
doesn't assume that or doesn't work that way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Thu, 6 Aug 2026 13:54:56 +0100, Geoff Clare wrote:

1. It's UNIX(R) not UNIX(TM).

This is the 21st century. We can write rCLUNIX-<rCY and rCLUNIXraorCY now. At least on 21st-century operating systems.

So why does ApplerCOs OS still call its kernel rCLXNUrCY?

rCLXNUrCY = rCLXNUrCOs Not UNIXrCY.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On 05 Aug 2026 18:46:59 +0100 (BST), Theo wrote:

RISC OS is not Unix (probably wouldn't pass certification even with UnixLib) but the GUI borrows certain ideas from how Unix programs
work together on the command line.

HererCOs a subtle question: how exactly is the command line implemented
at the kernel level?

In a Unix-type system, the command line is passed as the rCLargument vectorrCY (you may be familiar with the rCLargvrCY that you see as an argument to the main() of a C program). Whereas in Windows (and its
precursor MS-DOS), you have the simple string buffer inherited from
CP/M from the 8-bit era, which in turn copied it from the DEC
operating systems that came before.

The difference is, trying to pass multiple command-line arguments in a
simple string buffer requires the use of shell-style escaping
conventions, even when no shell is involved. Whereas on Unix-type
systems, it is easy (and common) for one program to directly invoke
another, passing the argument vector directly, without having to worry
about escaping any characters that might be interpreted specially by a
shell -- because you donrCOt need to go through a shell.

So, which way does RISC OS do it?

You call the SWI (syscall) OS_GetEnv and get back a single string buffer of
the command (as well as your RAM size and timestamp).

You can call OS_ReadArgs to parse the string if you like (and many do), but that's just a helper function. That provides quote handling - you can optionally apply more advanced 'GS translations'.

There's no shell because RISC OS doesn't have shells.

https://www.riscosopen.org/wiki/documentation/show/OS_GetEnv https://www.riscosopen.org/wiki/documentation/show/OS_ReadArgs https://www.riscosopen.org/wiki/documentation/show/OS_ReadArgs%20Input%20String https://www.riscosopen.org/wiki/documentation/show/GS%20Translations

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro wrote:

So why does ApplerCOs OS still call its kernel rCLXNUrCY?

rCLXNUrCY = rCLXNUrCOs Not UNIXrCY.

Because there's no reason to change it?

Taken as a logical statement, it is true that XNU is not UNIX.
That's because XNU is just a kernel, but a UNIX system requires
a C library and compiler, plus a shell and a bunch of utilities.
I.e. XNU is a proper subset of a UNIX system; it is not itself
a UNIX system.
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 07 Aug 2026 13:17:50 +0100, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

So why does ApplerCOs OS still call its kernel rCLXNUrCY?

rCLXNUrCY = rCLXNUrCOs Not UNIXrCY.

Because there's no reason to change it?

Taken as a logical statement, it is true that XNU is not UNIX. That's
because XNU is just a kernel, but a UNIX system requires a C library and compiler, plus a shell and a bunch of utilities.
I.e. XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.

I'm afraid Lawrence is getting confused in his dotage.

He is conflating it with XINU (XINU Is Not UNIX), a real embdedded
operating system.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 07 Aug 2026 10:16:21 +0100 (BST), Theo wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

So, which way does RISC OS do it?

You call the SWI (syscall) OS_GetEnv and get back a single string
buffer of the command (as well as your RAM size and timestamp).

You can call OS_ReadArgs to parse the string if you like (and many
do), but that's just a helper function. That provides quote handling
- you can optionally apply more advanced 'GS translations'.

There's no shell because RISC OS doesn't have shells.

You donrCOt have a rCLshellrCY, but you still have to pass command lines
around as though a shell were involved.

Does the phrase rCLworst of both worldsrCY come to mind ... ?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 07 Aug 2026 13:17:50 +0100, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

So why does ApplerCOs OS still call its kernel rCLXNUrCY?

rCLXNUrCY = rCLXNUrCOs Not UNIXrCY.

Because there's no reason to change it?

Taken as a logical statement, it is true that XNU is not UNIX. That's because XNU is just a kernel, but a UNIX system requires a C library and compiler, plus a shell and a bunch of utilities.
I.e. XNU is a proper subset of a UNIX system; it is not itself a UNIX system.

I'm afraid Lawrence is getting confused in his dotage.

He is conflating it with XINU (XINU Is Not UNIX), a real embdedded
operating system.

Both are 'X not UNIX':
https://en.wikipedia.org/wiki/XNU
https://en.wikipedia.org/wiki/Xinu

Apple use XNU, not Xinu. Lawrence is correct in saying that XNU is just a kernel - Apple use parts of the FreeBSD userland.

'XNU' wasn't UNIX back when it was part of the NeXTSTEP OS in the 80s. But
it has since become part of the UNIX certified macOS. It's also used in the the not-certified iOS, watchOS, tvOS, etc.

Xinu seems mostly used for teaching, although also by a few companies
(mostly in the 90s).

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Theo <theom+news@chiark.greenend.org.uk> writes:

Bob Eager <throwaway0008@eager.cx> wrote:

[ snip ]

He is conflating it with XINU (XINU Is Not UNIX), a real embdedded operating >> system.

Both are 'X not UNIX':
https://en.wikipedia.org/wiki/XNU
https://en.wikipedia.org/wiki/Xinu

Apple use XNU, not Xinu. Lawrence is correct in saying that XNU is just a kernel - Apple use parts of the FreeBSD userland.

'XNU' wasn't UNIX back when it was part of the NeXTSTEP OS in the 80s. But it has since become part of the UNIX certified macOS. It's also used in the the not-certified iOS, watchOS, tvOS, etc.

Xinu seems mostly used for teaching, although also by a few companies (mostly in the 90s).

Including, BION[*], 'cisco Systems (as the spelling was at the time) when they began moving business data processing off the DEC-20s.

[*] Cf. "Ripley's".
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 7 Aug 2026 21:46:34 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

There's no shell because RISC OS doesn't have shells.

You donrCOt have a rCLshellrCY, but you still have to pass command lines around as though a shell were involved.

Does the phrase rCLworst of both worldsrCY come to mind ... ?

I'm not sure where the idea that RISC OS doesn't have a CLI comes from,
it most certainly does. As regards the original question, per the docs
for OS_GetEnv the command line is passed in as a whole null-terminated
string.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

John Ames <commodorejohn@gmail.com> wrote:

On Fri, 7 Aug 2026 21:46:34 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

There's no shell because RISC OS doesn't have shells.

You donrCOt have a rCLshellrCY, but you still have to pass command lines around as though a shell were involved.

Does the phrase rCLworst of both worldsrCY come to mind ... ?

I'm not sure where the idea that RISC OS doesn't have a CLI comes from,
it most certainly does. As regards the original question, per the docs
for OS_GetEnv the command line is passed in as a whole null-terminated string.

Nobody said RISC OS doesn't have a CLI. Lawrence was talking about a Unix shell in the context of 'shell escaping', ie passing command lines through
one program which launches another.

RISC OS doesn't have the model where one process is used to launch other processes; for one thing it doesn't have a process model. Programs are
launched directly by the kernel, and if one program runs another then the
first is replaced.

There's a hack used by Acorn's version of 'make' where it launches other programs by first copying itself to higher memory addresses, running the
child program, and then shuffling itself down again. This is horrible, and only allows one child program (ie child 2 can be run but it terminates child
1 - you can't return to child 1 after child 2 exits). It's just enough for simple Makefiles where you're just running the compiler, linker or whatever.

But RISC OS has multitasking, so obviously it can run multiple programs at once? Yes it can, and this hack is only slightly less horrible.

The Window Manager (aka the Wimp, which runs in kernel mode, like all other 'relocatable modules') can do some page table footwork to swap one program
out for another - like what 'make' can do, only using hardware support.
That's half of 'context switching' taken care of. But the Wimp doesn't
preempt programs - they just yield by calling the SWI Wimp_Poll. When the
Wimp is called in that way, it swaps the page table for the next application and returns control into that app. If an app doesn't yield it has full
control of the machine forever (ie everything locks up). [There is a way to terminate such programs, but the result is often messy if as haven't
cleaned up properly]

On top of that hack there's another one. There's also another module called 'TaskWindow'. That starts a normal command line program as a desktop application but sets timers to preempt it - and on the timer it calls
Wimp_Poll to yield on its behalf. Result is something that feels like a
Unix process (it runs in a window happily with other apps, doesn't freeze
the machine if it takes lots of CPU, and you can compile Unix command line programs to run in it) but it isn't a Unix process under the hood. In particular, just like the native CLI, when one command line program calls another the first program is terminated. You have to explicitly launch
other TaskWindows if you want them to coexist, and that's something you need
to implement yourself if you want that. Somebody did compile bash once, but without the ability to launch other programs it's pretty useless.

Because there's no process mechanism according to the Unix model, the idea
of a shell process for launching other programs (and passing command
arguments) doesn't exist. The native CLI does happen to be called ShellCLI
but it's not a shell in the Unix model, it's merely a way to run one program
at a time. So Lawrence's concerns about escaping parameters aren't really relevant.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 7 Aug 2026 13:17:50 +0100, Geoff Clare wrote:

Taken as a logical statement, it is true that XNU is not UNIX.
That's because XNU is just a kernel, but a UNIX system requires a C
library and compiler, plus a shell and a bunch of utilities. I.e.
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.

So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a non-UNIX kernel?

Contrast that with Linux, where the UNIX support is native to the
kernel itself.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To Document-CentricComp
By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to alt.folklore.computers on Thu Aug 13 2026 23:23:21

XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.

So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a non-UNIX kernel?

Contrast that with Linux, where the UNIX support is native to the

You all keep capitalizing it like it's an acronym. What does UNIX stand for? --- Synchronet 3.16c-Win32 NewsLink 1.103
MutinyBBS - telnet : mutinybbs.com:2332 - ssh : mutinybbs.com:2232
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To
Document-CentricComp By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to
alt.folklore.computers on Thu Aug 13 2026 23:23:21

XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.

So Apple+o|c|us +o|c-uUNIX+o|c-N is implemented as an emulation layer on top
of a non-UNIX kernel?

Contrast that with Linux, where the UNIX support is native to the

You all keep capitalizing it like it's an acronym. What does UNIX stand
for?

The all-caps is what appears in the original documents from Bell Labs, so
I guess it's correct.

It's a play on words - the original word being MULTICS.

(your sig is broken; it should be <dash><dash><space><newline>)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro wrote:

So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a non-UNIX kernel?

The terms "UNIX kernel" and "non-UNIX kernel" are meaningless in the
context of the UNIX trademark, because the Single UNIX Specification
does not specify anything about the kernel, only the C language, some
C libraries, the shell, and some utilities.

What matters is the behaviour of those things that applications and
users experience, not the technical details of how they are implemented
at lower levels.
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX stand for?

It's not an acronym. We are capitalizing it because we are discussing
the trademark, which is UNIX-<.

See https://www.opengroup.org/trademarks which says (point 3 under
"Rules for Proper Trademark Usage"):

Trademarks are not acronyms; they should not be spelled out,
abbreviated, or used by themselves within parentheses or brackets.
Always spell and capitalize the Trademarks exactly as they are shown
in our Trademarks list above.
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 8/13/26 22:38, Phigan wrote:

To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To Document-CentricComp
By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to alt.folklore.computers on Thu Aug 13 2026 23:23:21

> > XNU is a proper subset of a UNIX system; it is not itself a UNIX
> > system.
>
> So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a
> non-UNIX kernel?
>
> Contrast that with Linux, where the UNIX support is native to the

You all keep capitalizing it like it's an acronym. What does UNIX stand for?

Unified Netwetworked Interface eXecutive

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX stand
for?

The all-caps is what appears in the original documents from Bell Labs, so
I guess it's correct.

It's a play on words - the original word being MULTICS.

Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.

Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.
--
/~\ Charlie Gibbs | In this world there are
\ / <cgibbs@kltpzyxm.invalid> | two kinds of people:
X I'm really at ac.dekanfrus | 1. Those who can extrapolate
/ \ if you read it the right way. | from incomplete data.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX stand
for?

The all-caps is what appears in the original documents from Bell Labs, so >> I guess it's correct.

It's a play on words - the original word being MULTICS.

Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.

Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.

Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB
printed documentation) and noted as a trademark.

And later, when AT&T spun the UNIX folks into UNIX
Systems Laboratories (USL), UNIX was always in upper-case.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 8/14/26 14:18, Charlie Gibbs wrote:

On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX stand
for?

The all-caps is what appears in the original documents from Bell Labs, so
I guess it's correct.

It's a play on words - the original word being MULTICS.

Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.

Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.

Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now. Shortly, thanks to the hard
work of some genuises - not me (and some help from Claude) the new
version will shortly be available with TCP/IP support - mostly the
original Honeywell code, scrounged up from pieces, with the missing
routing piece newly written
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 14 Aug 2026 20:52:35 -0700, Peter Flass wrote:

Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now.

ThererCOs an early-1980s brochure for it on Bitsavers. Considering how
many years that was after it was developed, I think it still compared respectably against anything else you could buy at that time -- like
having built-in graphics and DBMS, among other features.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

At Fri, 14 Aug 2026 13:29:06 +0100, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX
stand for?

It's not an acronym. We are capitalizing it because we are discussing
the trademark, which is UNIX-<.

See https://www.opengroup.org/trademarks which says (point 3 under
"Rules for Proper Trademark Usage"):

Trademarks are not acronyms; they should not be spelled out,
abbreviated, or used by themselves within parentheses or
brackets. Always spell and capitalize the Trademarks exactly as
they are shown in our Trademarks list above.

(I used to hammer Lawrence with this until he stopped talking to
me. ;) )

"UNIX(r)" is the trademark. "Unix" describes a class of operating
systems that used to be called "*nixes" (or some such similar terms).

So if you ask me -- and I know you didn't -- "Unix" is now
a kind of shorthand for what could now be described -- if
I'm not mistaken -- as "POSIX operating systems".

Therefore Linux is a Unix, but isn't UNIX(r) without certification.

(MacOS is a Unix _and_ it's UNIX(r)...for varying values of
compliance.)

Finally, it's pretty clear nowadays that the provenance of the
source in the kernel doesn't matter, since MacOS runs on the
Darwin kernel: if I'm not mistaken, that's based on FreeBSD on the
Mach microkernel.
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.2.0-rc7 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
"Disclaimer: Written by a highly caffeinated mammal."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 14/08/2026 1:38 PM, Phigan wrote:

To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To Document-CentricComp
By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to alt.folklore.computers on Thu Aug 13 2026 23:23:21

> > XNU is a proper subset of a UNIX system; it is not itself a UNIX
> > system.
>
> So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a
> non-UNIX kernel?
>
> Contrast that with Linux, where the UNIX support is native to the

You all keep capitalizing it like it's an acronym. What does UNIX stand for? --- Synchronet 3.16c-Win32 NewsLink 1.103
MutinyBBS - telnet : mutinybbs.com:2332 - ssh : mutinybbs.com:2232

I thought it was /United Nations/, planet IX. Admittedly, that's in the
Dune universe, and I don't recall Princess Irulan writing about any uni-
ted nations on planet IX.


Have a nice day of prognostications!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 15/08/2026 11:52 AM, Peter Flass wrote:

On 8/14/26 14:18, Charlie Gibbs wrote:

On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX stand >>>> for?

The all-caps is what appears in the original documents from Bell
Labs, so
I guess it's correct.

It's a play on words - the original word being MULTICS.

Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.

Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.

Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now. Shortly, thanks to the hard
work of some genuises - not me (and some help from Claude) the new
version will shortly be available with TCP/IP support - mostly the
original Honeywell code, scrounged up from pieces, with the missing
routing piece newly written

That's indeed good news. Never mind the Lawrence Language Generator,
he's always spouting nonsense.

I definitely should try out some of the public access Multics systems,
one of these days.


Happy Multics!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 14/08/2026 7:23 AM, Lawrence DrCOOliveiro wrote:

On Fri, 7 Aug 2026 13:17:50 +0100, Geoff Clare wrote:

Taken as a logical statement, it is true that XNU is not UNIX.
That's because XNU is just a kernel, but a UNIX system requires a C
library and compiler, plus a shell and a bunch of utilities. I.e.
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.

So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a non-UNIX kernel?

Contrast that with Linux, where the UNIX support is native to the
kernel itself.

Lawrence, Lawrence, Lawrence. Yet again you know nothing. You really
should try hitting the fruit vendor's kernel with direct system calls in assembly. Then you'd know it's exactly the same -- more or less -- as
the FreeBSD system calls, albeit with different syscall numbers.


This is covered extensively on the interwebs, and I wish you happy hunt-
ing!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 05/08/2026 7:19 AM, Theo wrote:

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:

Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:

I think the definition of "document" is getting muddied up here. From
what the OP seems to have stated, the delineation between a "document" >>>> and what I will call a "Composite Doc" is that a "document" is a single >>>> file for each type of data handled for that file type's application.

A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).

How the data is stored on disc is orthogonal to how the editing works.
They're just bags of bits; how you organise the bags of bits is a design >>> decision.

Ahh, I thought you were specifically talking about the structure of
documents. I find that if everything is in it's separate file and a
document preparation system is designed to work that way, it is much more
enjoyable to work with. Say templating with LaTex for reporting based off
of CSV files and making graphs. Just nicer to work with and can also apply >> version control. No proprietary all encompassing binary formats like docx

The way Computer Concepts did it used a few tricks:

1. On the Archimedes, applications were a directory whose name started
with the ! symbol. Roughly the same as how MacOS has Something.app
application bundles which are just directories. (! was chosen as it's
first in ASCII sorting)

So you are talking about not only applications that could be global to the >> system for use by the application (not saying this is how the archimedes
worked) but also a set of utils built for a specific software product in
its own isolated bundle/package that all worked cohesively to serve as a
document preparation toolkit which happened to be really well integrated.

No, merely that documents were stored each in their own file bundle that happened to reuse the way application file bundles worked. In RISC OS application bundles are just a fancy directory, they can (and do) live anywhere on any filesystem. What makes an application? Most it has its own icon (a Sprites file inside the directory) and it has an action that runs when you double click it. In this case that was a script that started the editor and told it to open this document. That made its behaviour to the user that what they'd expect from a single file (except the ! prefix).

This is mostly tangential, but it meant a 'document' could be a cohesive bundle of files that appeared to the user to be one object, rather than having to be packed into a single file. It's relevant because inside the document bundle were the individual document elements (text, images, tables, equations, etc) which retained their native filetyping. You could just open the document bundle (shift-double-click the application) and find the document elements inside.

Of course, such ideas were later popularised with standards like docx (OOXML), where the document 'file' is actually represented by a zipfile containing a bundle of component files.

2. Their 'documents' were stored as applications, where double clicking >>> them (opening the app) would open them in the overarching editor (eg
word processor). Inside the application directory were various files
making up the inclusions (tables, equations, drawings, bitmap images,
etc).

Are you saying that the document that you may be preparing is shared in
the same directory as the software used to write it? That seems a bit odd
to me. Nice an encapsulated but wouldn't that mean every user generated
docuemnt carries the whole set of binary utils with it as well?

No, they were separate. In general there was no on-disc organisation imposed, so the pieces could live wherever you wanted them. (Including on removable discs which may or may not be present)

(there's a mechanism by which the first time you open a folder containing
an application, it can register itself with the system and make it
available to open file types it knows about. This can also be pre-loaded at boot time)

3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know
whether a regular file is a drawing or a JPEG from the filetype rather
than the extension.

I wish this was the case still, rather than extensions as you mention or
memorizing and hoping to find magic numbers. Would make sorting through
filesystem data a bit easier and reassuring when restoring from backups.

Some filesystems can have extended metadata for this, although I can't think of anything that widely uses it. It gets a bit hairy when
you consider the mappings of extensions to MIME types, which are typically what people mean by filetypes today - this mapping is not a bijection.

This is starting to make WAY more sense now that you putting more plainly
here. It was the case where you could utilize specialized small programs
that generated a vector drawing, just following lets say a 'table' ruleset >> (how you are allowed to draw) which then could be interpreted by the word
processor as any general vector to display within the document.

I now also see why you specifically say that the organization of data
doesn't matter in the context of an isolated system like this because all
would be operating on and stroing data in the 'universal way'

With something like OOXML or ODF you can still do the same thing, eg if I make a wordprocessor doc with a JPEG in it I can unzip the .docx or .odt and find the JPEG inside the bundle.

In Libreoffice, if I open the file and right click on the JPEG I can 'open
in external tool'. For me that opens it in Gwenview. Suppose I rotate the JPEG, save and close it - the image in the document is now updated. LO is using a temporary JPEG file for that (I can't access the file in the original .odt without first unpacking it) but otherwise it's the same process.

The idea of having 'hidden' metadata is also not uncommon today - eg in HTML where the browser ignores tags it doesn't understand and can nevertheless render the page. If you open the HTML in something that does understand the extra tags then it can do something different with the document.

I would also like to say that creating features for a piece of software
that overlap is somewhat bad practice. What I mean is that for a
functional (maths variety) kind of thinker there should really be one
right (developer blessed) way to do a particular function. Now that
doesn't mean that there is a limit to any particular feature but that the
cross cutting (interfering is probably a better term here, not sure)
aspects of a program's design should be kept to a minimum.

An example is in MS Excel today, there are multiple ways to provide
alternative colors for a table, conditional coloring, or converting the
range into a proper structured table selected with a particular color
scheme/pattern. In fact the fact that in a spreadsheet program you can
define a 'stronger' table within a tabular environment is something that
most users don't even grasp because it seems like they already arrived to
the correct (best?) solution to their tabular problems by opening MS
Excel!

Its this set of features stumbling over each other within single
applications that do the most damage in regards to this werid machines
problem they seem to all have.

I'd say this is a result of application featureitis. Because you can't easily share functionality, every app ends up with its own table editor,
even if one app (Excel) does it better than others (Word, OneNote).
Sometimes there is a reason for that (aesthetics, simplicity, interconnection), but often not (eg it would be very handy to be able to put a spreadsheet-powered table in my OneNote files instead of the dumb tables they implement). This is also why these monolthic apps get bloated, because they need to include the code for every feature everyone could possibly
want.

With the Unix philosophy, it may be more complicated to learn but you build up an ecosystem of swappable parts - if you don't like the app that does one job, swap it out for another app that does the same job better. You don't end up with the monoculture where you get locked into Word for everything, even if some sub-feature is better done by an independent app.

Perhaps software shouldn't necessarily expect to work like how humans
think but that humans should realize that they are using a computer and
should first learn how to use one if it is necessary (think like how a
computer works). Much like I wouldn't feel comfortable with a person
driving a car who didn't know what the accelerator or breaks are or what
they did in reference to the vehicle.

But its a lot to ask from people I know, especially since most still can't >> figure out how to drive even now.

Much of this is still learned behaviour. I always say that 'intuitive' is just (deliberate) technobabble for 'works like something you've used
before'. You still had to learn that first thing - no-one was born knowing how to use dialog boxes.

Dear Theo,

I like to use BeOS as an example of this. People have been trained,
quite extensively, since 1995 to use an X to close an application win-
dow. It took me help from I.R.C. to figure out the [] in the tab thing
on top of the window is an /active/ button. Admittedly, that was some-
thing like twenty-or-more years ago, and now I don't have to learn it
again, but I did have to learn it once; that not every operating system
follows the /Microsoft/ tradition.

Which still has the double-click-the-small-icon-in-the-upper-left-corner
as /close/, despite the X being touted as the /close/ button.

I've also noticed, that to a lot of people /intuitive/ means what they
know, and nothing can convince them otherwise. There is no talking to
these people, in my experience, about how all of this needs to be learn-
ed in the first place, and /intuitive/ is just "what I know" in terms of human-computer user interfaces.


And next time I boot up my RISC OS machine, I'm probably going to have
to read the user manual all over again, because I never spent much time
on it. Hopefully that changes in the near future.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 8/16/26 06:36, Johann 'Myrkraverk' Oskarsson wrote:

On 15/08/2026 11:52 AM, Peter Flass wrote:

On 8/14/26 14:18, Charlie Gibbs wrote:

On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:

On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:

You all keep capitalizing it like it's an acronym. What does UNIX
stand
for?

The all-caps is what appears in the original documents from Bell
Labs, so
I guess it's correct.

It's a play on words - the original word being MULTICS.

Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.

Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.

Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now. Shortly, thanks to the hard
work of some genuises - not me (and some help from Claude) the new
version will shortly be available with TCP/IP support - mostly the
original Honeywell code, scrounged up from pieces, with the missing
routing piece newly written

That's indeed good news.-a Never mind the Lawrence Language Generator,
he's always spouting nonsense.

I definitely should try out some of the public access Multics systems,
one of these days.

I bought a Rasperry Pi 3 (used, about $30) and installed Multics on it.
It sits running on a corner of my desk and I can telnet into it whenever
I want.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

To: Peter Flass
Re: Re: UNIX certification (was: Whatever Happened ToDocument-CentricComp
By: Peter Flass to alt.folklore.computers on Fri Aug 14 2026 07:31:20

Unified Netwetworked Interface eXecutive

The Public Electronic Networked Informatin System runs on one of those.
--- Synchronet 3.16c-Win32 NewsLink 1.103
MutinyBBS - telnet : mutinybbs.com:2332 - ssh : mutinybbs.com:2232
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB
printed documentation) and noted as a trademark.

And later, when AT&T spun the UNIX folks into UNIX
Systems Laboratories (USL), UNIX was always in upper-case.

Goes back to at least V7, and the official rendering seems to have
been small caps, not upper case. See tmac.s.

De
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Fri, 14 Aug 2026 13:20:38 +0100, Geoff Clare wrote:

Lawrence DrCOOliveiro wrote:

So ApplerCOs rCLUNIXrCY is implemented as an emulation layer on top of a
non-UNIX kernel?

What matters is the behaviour of those things that applications and
users experience, not the technical details of how they are
implemented at lower levels.

So ApplerCOs rCLUNIXrCY should be sufficient to run software supposedly designed for rCLUNIXrCY, should it not?

Yet most of that software seems targeted at Linux, not macOS. To the
point where Apple (like Microsoft) needs to include the option to run
a Linux kernel in a bag on the side of macOS now, to get access to it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Sun, 16 Aug 2026 21:33:41 +0000, Dennis Boone wrote:

Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB printed
documentation) and noted as a trademark.

And later, when AT&T spun the UNIX folks into UNIX Systems
Laboratories (USL), UNIX was always in upper-case.

Goes back to at least V7, and the official rendering seems to have been
small caps, not upper case. See tmac.s.

And V6. Also on Mini-UNIX (for which I have original printed docs)
--- Synchronet 3.22a-Linux NewsLink 1.2