ANT is an Operating System (thereafter OS), being written as a personal hobby project. It's inspired by the Microsoft Windows NT family, but it is not trying to be a strictly following clone of it, not to mention being binary compatible with it, that would be just infeasible for a hobby project. As stated above, it's a hobby and desire to recreate NT and WinAPI was a result (or expression) of liking this OS and API, not of will to "compete", "fight", "replace" and anything similar, coming from dictionary of those, that see in software development "ideology and politics" (or, rather, religion).
ANT is going to be a modular kernel, with modules (drivers) for handling peripherals or providing extended functionality or abstracting, running in kernel mode (as a rule). Executable images are in the Portable Executable format (PE) (for both OS and user mode executables). For architectures, where the PE format is not available with the current compilers, the ELF format is considered, as a temporary solution; for now (2021 ‐ 2023) using ELF is only plans.
It is a multiuser, general purpose OS for desktop, desktop-like, server, mobile and, possibly, other use cases. Multithreading, with preemptive thread dispatching. Supporting Symmetric Multiprocessor (SMP) and Heterogenous Multiprocessor (HMP).
Configuration data of OS components and programs are stored in the Registry, a hierarchical database, similar to conventional File Systems (FSs), but such one, that gives to variables (file analogs) typified cells as storage units, whereas for file systems, a file — is always a non-typified container. In the registry, there are keys, directory analogs, and variables and the latter have a type, which means, that their values can only belong to the set, defined by the type. This allows for providing a more efficient way of handling configuration data. For example a program wouldn't need to parse text files with configurations on every init, instead, it would pull out from the registry either a single binary variable, say a 64 bit integer, of even a whole composite structure and these data would be ready for use without parsing. This fine grained structure, together with the corresponding programming interface for accessing it, gives to the OS and programs a unified, efficient and convenient mechanism for storing their configurational data. And in addition, very important, the Registry engine, Configurational Manager, provides logging on the registry, for both data and metadata (i.e. registry structure), what guarantees registry integrity and protection from corruptions, caused by abruptive interruptions of the registry operations (dirty shutdowns e.g.).
Physically, Registry consists of a set of special files — hives, each of which contains a Registry branch (subtree). Registry is shown as a single tree, made up of these branches. Thus, following the analogy with FS, hives are volume (disk) analogs, and the Registry tree is an analog of a monolithic FS tree on systems, that inherit this file data representation style, — so called Unix style. Ant, as Windows, uses this approach for Registry, but does a different method for file data. In it, a volume tree is shown on its own, turning the view into a forest of trees, with a tree per each volume (disk). These trees get distinguished by assigning an identifier (e.g. a letter) for the root directory of a volume (disk), see the next paragraph for Ant specifics. This is so called DOS style of file data representation and for them, it seems to be more convenient, than the monolithic one, because data hierarchy, shown in the DOS style, is shown clearer and closer to reality. For Registry, on the other hand, a unified tree, seems a normal way to go. However, worth noting, that possibility of representing Registry as a forest needs further investigation, maybe this variant will seem more reasonable here as well.
Plans are to implement the internal Registry format as in Windows, to be seen how it turns out, though.
Ant, as already said, uses DOS style for file data representation. Difference from Windows is that identifiers for disks are not just latin alphabet letters, but numbers, encoded as numerical literals in base 36 system, built upon the [0 - 9, A - Z] set. Maximal ordering (literal length in characters) is planned to be 3 or 4. This allows for avoiding the identifier exhaustion situation, where the number of disks is greater, than the number of letters, because with order 3 literals, we have limit in 363, what is 46656 items and with order 4 literals, it's 364, which is 1679616 — more, than enough, plus, it's easy to extend if necessary. The old DOS scheme is fully compatible with this one. Correct values run from 0 to ZZZ (46655) for 3-literals, 0 to ZZZZ (1679615) for the 4-literals. Leading zeros and letter case don't matter. Here is an example of correct identifiers, using 4-literals:
Yee is the System Root directory, analog of Windows' Windows directory, Ant is where all the kernel mode executables go, so it's not exact analog of the Windows' System32. The last 2, by the way, point to the same valume and use one of a few identifiers, reserved by the system. In this case, it's for the Uefi system partition. Traditionally, Boot Volume, the OS home, gets the C letter.
Is written mostly in C, plus some assembler. The first target architectures are x86 and arm. There were also intentions to include mips and ppc to the target list, but the situations prevented them to become reality. riscv architecture was being considered as well, since Single Board Computers (SBCs) and even PC-likes with it started to appear (26.05.2021). But then, in 2022 ‐ 2023, everything except x64 and arm64 was abandoned. Read this article for a more detailed retrospective.
The primary firmware is Uefi. Potential other firmwares considered were legacy x86 Bios, Open Firmware, and, in tough cases, — a "firmwareless", plain uboot environment, without any services, exposed to the OS Loader (OSL). Again, read the Target Park and Firmware Environment page, to know in a more detail about the targets and firmware environments, what was left as target, what was discontinued and why.
Also, ANT has a strong emphasize on supporting several Environment Subsystems (ESS), that is — having the ability to run programs, written for various execution environments, API sets (standards). The main subjects are WinAPI and Posix. More on this on ANT Goals page, because it's a large topic on its own, in short, the primary one, AntAPI, is WinAPI-like. It's needed for example for every GUI program; Posix ESS is going to be CUI only. Actually, the Posix standard doesn't cover graphical interfaces. There is no intention to port anything graphical from Unix clones.
Planned is to have a robust packaging system, or Installation Framework.
For avoiding the abysmal clutter, inevitably appearing without an organized,
well defined mechanism to handle myriads of applications and their data,
users install. Also, for fighting the bloat, accompanying the aforementioned
mess, rising from many times duplicating the same things,
installed by different parties as dependencies over and over and over.
This framework should be powerful and user friendly simultaneously.
Which, of course, clearly reveals, — it's not an easy task.
Sketchy depicting, the user, for installing something, needs to get
the "package" of that thing, from the trusted source, and go through
installing it, using a well defined utility set, be it CUI or GUI.
The thing, wanting to be installed, needs to prepare the package the
defined way, claiming what it is and what it depends on. The framework
will define if everything is OK with it and register it in its database.
Packages should also provide users with convenient, and required even,
things like an easy to use installation process, ability to customize
the installation, ability to install several versions of the package,
or choice of users for whom this package to install. It shouldn't be just a dumb
Obviously, this topic asks for its own page (which will be added later, when this framework is something more mature, than blurry babbling about it).