I had idea of a new operating system design. I had considered both low
level and high level stuff.

It is intended to be a specification that multiple independent
implementations can be made, on same or different computers. It could
also be possible to make an implementation that can run on other operating systems (similar than Inferno). Furthermore, this design must be fully documented, that it can be understood, without the system design being
too complicated (e.g. WWW is too complicated).

Some things found in modern computer designs are no good and so should
not be used, including UEFI, HDMI, USB, Unicode, systemd, etc.

It is using capability-based security with proxy capabilities. All I/O functions (except Yield and Quit) require a capability. Capabilities can
be passed in messages, through other capabilities, to other processes. A process will not know if the capability is the right one since any
capability can be given, including a proxy capability or one that does something else; this can be useful for many purposes including testing, implementing your own security features outside of the kernel, redirecting
a program's audio or video output, implementing a high-level "translator"
to allow programs to access each other's data, and more.

(Note that if a process no longer has any access to any capabilities
(because it discarded all of them or because the capability depends on processes which are no longer running), and the process is not being
debugged by another process, then the process can be terminated since it
has nothing to do.)

Operations on capabilities include: Send, Receive, Map (to map a capability into memory (usually, this will be a capability to request allocation of memory); some types of computers may have restrictions in some cases), Wait (for one or more capabilities to be ready; if you want a time limit, add a timer capability into the set of capabilities to wait for), Lock (you can atomically lock/unlock multiple resources simultaneously if wanted so that
if one cannot be locked then nothing is locked, although note that some combinations might not be possible), Transaction (you can have a single transaction on multiple resources, in case you want atomic commit of all resources in the transaction at once), Discard (lose access to the
capability, possibly allowing resources to be freed by the system).

The file system is unusual. Some of its features include:

* There are no file names and no directory hierarchies, other than the
system root directory with 256 numbered entries (it is possible that some entries are vacant; this system root is mainly used for low-level stuff
such as the kernel, the init process, data relating to links between file systems (e.g. external disks), etc).

* It uses journaling file system, that unfinished write transactions will
not corrupt the system.

* The only attribute of a file is the system attribute, which is used for
files that need low-level access such as the kernel itself (to simplify
loading the kernel and drivers).

* Each file consists of several streams, each assigned to a 32-bit stream
ID number within that file (the numbers 0 to 255 have meanings defined by
the specification, while higher numbers can be used for your own use). A
stream can contain, in addition to bytes, links to other files (which are treated differently than plain bytes by the file system, although of course internally they are all bytes in the disk).

* Links can be either to a specific version only (so that the file linked
to is effectively read-only) or to whatever version will be current when accessed. If it is accessed and written to and there are also links to the specific version, then it is copy-on-write, so that the links that are not
to that specific version will link to the changed file and the link that
is to the old version will link to the unchanged file.

The system may also have emulators; if an emulator is installed then you
can even run programs written for this operating system but for a different computer with a different instruction set, and it will still run (but will probably run less efficiently) (for example, programs for x86-64 will also
run on RISC-V and vice-versa). Message format and other formats for communication and interchange will use common endianness etc so that the programs can work together regardless of the instruction set in use.

There is a common file format for most kinds of data, and is also used in
the command shell as well as GUI. It is a structured data file and may
include such things as:

* Text document, including TRON character codes, strong, emphasis,
furigana, text directions, etc.

* Diagrams and raster graphics.

* Data tables, including lists, key/value tables, and more general tables.

* Matrices and zoned spreadsheets. (A "zoned spreadsheet" is divided into rectangular zones, each of which contains cells. Absolute references are references to zones (although a reference can be a combination of absolute
and relative), and a zone usually will share its attributes among its cells (e.g. a formula or formatting may be automatically included in its cells
if it is resized).)

* Audio.

* Time series; other data can be included at specified relative time (for example, this can be used for animations, timed captions, etc).

* MIDI and IMIDI. (This would commonly be placed inside of a time series,
to specify the time that notes should be played, although it is not
mandatory; you can put any kind of block inside of any kind of block.)

* Hyperlinks and transclusions. (This involves the inherent linking in the hypertext file system.)

* Tagged data; e.g. you can mark some text as being a date/time or being
a linear measurement, or something else. For example, you can then program
the computer to automatically convert the time zone or units of measurement
or to display a menu of the actions that are available for that type of
data (which new ones may be installed (and/or written) by the user; one
example would be to set an alarm for the specified date/time).

* Extension blocks, that you can include data (or references to other
streams of this or other files), other than the usual formats. In this
way, any kinds of data can be stored, and with the help of translators, programs (including the command shell) can even use each other's data.

* Nearly any kind of data can include any other one, too.

Because the command shell and GUI also use this, it also means that you can easily copy and move data between programs (including between command-line
and GUI), and interoperability is improved.

In addition to C programming, the system includes a programming language
which is also usable as the command-line shell but also can be used to
write other programs. This programming language has some similar ideas and
uses than NuShell, but there are also many differences.

Perhaps the data types of the command shell programming language might be (although there might be more than just these, and some of these might be
found to be unnecessary if it is actually made):

* Numeric types: integer (probably 64-bits, or possibly unlimited),
floating (perhaps 64-bits IEEE), character (a TRON-32 codepoint), boolean
(only zero (false) or one (true)), timestamp (a signed number of seconds (excluding leap seconds) from January 1, 1985, 00:00:00, UTC, and an
optional 32-bit number of nanoseconds (which can exceed one billion during
a leap second)), UUID.

* String types: byte string, mixed string (can contain capabilities and
links as well as bytes), rich string (a mixed string which is interpreted
as the common data format so it can include formatted text and others),
message string (a rich string used as a message to send to or receive from
a capability).

* Compound types: list, matrix, dictionary, typed array, table.

* Other types: link, capability, function, continuation, extension (can be
used for stuff other than the built-in stuff).

This programming language will include the functions to connect programs together (similar than UNIX pipes, but capabilities are also possible),
do batch operations and queries (similar than SQL in some ways), manipulate data, access devices and capabilities, run programs, etc. The command shell
and GUI can be worked together, too. (The common operations should not use
a too long syntax, because the common operation of the system should be
usable without having to type a lot of commands just to do one thing.)

A POSIX compatibility layer is possible, which is just a user program like
any other (not anything that the kernel knows about), so C programs can
call the POSIX compatibility library which will implement its functions
in terms of proxy capabilities, etc. However, the programs which are
designed specifically for this system do not need it and can work in a
better way with more improved interoperability. (Combining them may also
be possible, e.g. if you want to port a program and modify only parts of
it to work better with the rest of the system; perhaps this will be done
parts at a time so that eventually it will be fully ported.)

I have some other ideas too, which I may write about later. Also, if you
have any comments (including, what will it be called), questions, and/or complaints, please write a follow-up message with your comments, questions, complaints, etc.

(Some of the other ideas, which may be written about later, include: accessibility features, package management, soft real-time, GUI design,
system distributions and suggested software to be included, interchange
file formats, synchronization, etc. It may also include further
elaborations about things mentioned in this article.)

--
Don't laugh at the moon when it is day time in France.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)