andreww591

DG/UX for x86, CTOS, AOS, and RDOS are already included.

I hadn't included the R1000 emulator because originally they emulated it at the logic gate level and it literally took a week to boot. It looks like they now have a more traditional instruction-level emulator that is supposedly comparable to the real hardware in speed, so I guess I should try to install that.

I think a major reason that no AS/400 emulator exists is because people are afraid of IBM sending them a C&D, although I'm not sure if IBM would care all that much if somebody wrote an emulator for IMPI AS/400s. Those haven't been supported for well over 2 decades AFAIK.

I do know somebody is slowly working on S/32 and S/34 emulators, but they haven't shared either because both apparently are still somewhat flaky. Hopefully they release them at some point. The entire midrange/office computer category is very under-preserved. The only such machines represented in the OS museum currently are HP3000 and S/3.

I've never seen images anywhere for NonStop, VOS, or NIROS, nor do emulators exist for the original hardware they ran on. Later versions of NonStop and VOS run on x86, but I'm not sure if they run under virtualization.

Yeah, I should probably add screenshots of earlier versions of those (or in the case of Domain/OS, screenshots of dm).

Rather than just another name for Domain/OS, Domain/IX was actually a Unix compatibility layer that was an add-on product for pre-SR10 AEGIS versions, with SR10 merging it into the base OS (pre-SR10 had no built-in Unix compatibility).

AFAIK even though it's usually associated more with HP-UX, VUE actually originated at Apollo before HP bought them, although I'm not sure if they ever actually released it before the acquisition.

Sorry for the issues with downloads from earlier. The server I was trying to host it on had a failing disk. I now have torrents up, and the direct download links are to archive.org.

I've now added some torrents to the download page (using archive.org as a web seed).

Helios unfortunately isn't yet included. Last time I checked the Transputer emulator doesn't support the special Helios I/O server protocol, which is different from the one that the usual occam software used. It's on my long list of emulators/OSes to fix/finish though.

Several older versions of VMS are included, with the latest being 7.3 for Alpha.

Multiple versions and variants of OS-9 are included. There are images for NitrOS-9 on CoCo and Dragon, several ports of OS-9/6809, OS-9/68K 2.4 for X68000, and OS-9000/x86 6.1.

PC/IX 1.0, AIX PS/2 1.3, and AIX/6000 4.3.3 are included; I just didn't post any screenshots of them.

I wish I could do that, but there are a lot of emulators that don't have web versions, and the launcher and related scripts are very heavily dependent on a Unix-like OS and there is no way to port them to JS (a completely separate launcher and scripts would have to be written).

It sucks that there's no good way to port Linux directly to WASM UML-style, since WASM insists on implementing memory safety at the bytecode level with no way to bypass it. There is a very limited port, but it doesn't support paging. Not all the emulators would run on a full-featured WASM port if one existed, but that could be dealt with by just using user-mode QEMU to run whichever ones are x86-only.

I haven't yet included a full list, but I guess I could include one.

All of those OSes you mentioned are included. BTRON isn't a single OS, but a small family of OSes based on a common specification (just like Unix is); the OS museum includes the demo 1B/V3 and Chokanji 4. The FOSS BTRON implementation you're thinking of is almost certainly B-free/EOTA, which is also included. EOTA never actually implemented BTRON proper before it got abandoned. It basically just ended up being like a Unix based on an ITRON kernel.

Documentation for some OSes is included, although I've focused more on user/administrator documentation over developer documentation. It would probably be a good idea to include developer documentation though.

I've thought about making individual images available for download, but many of them are dependent on particular emulator versions and/or the common launch scripts so it isn't quite that simple.

Yeah, they're very common. Some emulators like QEMU and MAME have many different versions included in order to deal with regressions.

TOPS-20 4.1 and 7.1 are both included.

I'm not aware of any fully working TENEX images unfortunately. There are partial images, but last time I checked they weren't in a state that was even remotely usable.

The vast majority were downloaded. A few I got when I exchanged compilation DVDs with someone in Finland in 2006 and 2009 (I uploaded the images on those to BetaArchive back then and they've made their way onto various other sites). The only ones that I have that were installed from images I dumped from original media that hadn't been previously shared were LynxOS 4.0 and MaxOS Linux (not to be confused with macOS, it was an obscure early-2000s commercial Slackware fork from a company that was semi-local to me; the CD was given to me back then by somebody at a long-defunct local computer store).

The last version of TempleOS is included, but I installed it myself, and I didn't bother to include most of the images that I just installed by myself in the credits.

I'm also planning to add earlier versions as well as the later forks at some point.

Several different SIMH forks are included, along with a lot of other emulators; there are well over 150 different emulators, with some having multiple versions and variants present to handle things like regressions related to specific OSes.

Nested virtualization for certain x86 OSes running in QEMU is supported, although you will have to enable it manually (VirtualBox has a checkbox for this in its settings). For VMs that support it, the QEMU launch scripts will automatically use KVM if available and fall back to TCG if nested virtualization isn't enabled.

NetWare 4.11 and 6.5 are included, but just don't have any screenshots on the site (the screenshots are not exhaustive at all and just a small sampling of what's there).

And even though there weren't very many 286 protected-mode OSes there were still several of them, with the OS museum including:

1B/V3 (a Japanese OS with an object-oriented desktop and extensive compound document support, part of the TRON project) Microport SysV/AT Prologue TwinServer (an obscure French OS that originated on 8080/Z80) Multiple versions of OS/2 1.x QNX 2.21 QNX 4.0 IBM PC XENIX

1B and TwinServer are especially notable since they were maintained as 286 OSes long after x86-32 machines had made 286 machines completely obsolete; the last versions apparently being in 1997 for 1B and 2002 for TwinServer (although the last version of TwinServer has some limited support for 32-bit code, it can still run on a 286)

That was Voyetra Audiostation, and I definitely remember having it on the Packard Bell 486 that was my family's first computer (which was already obsolete when we got it, since we got the cheapest machine they had; it was on clearance sale). While I do have Windows 3.10 and 3.11 for Workgroups images, I don't (yet) have one with Audiostation. I have sometimes thought about trying to find the closest PB master CD ISO to the one that came with that machine and install it, but just haven't gotten around to doing that yet (still got lots of other stuff to install).

I've heard of custom shells for Windows before, but not that specific one

I've got Pick PC R83 V3.1 included. The screenshots on the front page are a very small sampling of what's there.

Yeah, I'd definitely like to see older versions of AEGIS as well

Yeah, MAME has had working Apollo emulation since around 2010. Domain/OS is definitely pretty odd. You could almost mistake SR10 for a normal functional Unix if you use the SysV or BSD universes rather than the AEGIS one, but while it is clearly Unix-like, it's also quite Multics-like as well and is pretty distinct from the typical functional Unix family.

I don't think I've heard of an alternate shell/launcher like that before. Do you remember what it was called?

At least for certain types of OSes, it should be relatively easy to get most of Linux's hardware support by porting LKL (https://github.com/lkl/linux) and adding appropriate hooks to access hardware.

Of course, your custom kernel will still have to have some of its own code to support core platform/chipset devices, but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers).

Also, it probably wouldn't work so well for typical monolithic kernels, but it should work decently on something that has user-mode driver support.

I'm a little bit skeptical as to how successful a hard fork of Linux that only differs from the mainline kernel by having a bit more Rust code actually would be.

If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.

What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.

IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.

Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.

https://gitlab.com/uxrt/uxrt-toplevel

Like I said, it's not meant to be a "Rust OS" and will incorporate a lot of C code still (and various other languages as well). I doubt that the kernel will ever get completely rewritten in Rust, although eventually some Rust code might get added (once I break up the giant kernel lock I am thinking I'll use the same locking library I'm using in the process server, so that would add some Rust code to the kernel). I don't see a lot of point to rewriting the kernel since it's probably not going to see lots of new code being added all the time and is generally pretty limited as to what it includes (I'm not quite as reluctant to add stuff to the kernel as the seL4 developers are, but I still am going to try avoiding it unless there's no other good way to do something).

Redox has several of what I consider to be questionable design/implementation decisions. I explained a couple of them in a previous comment (the limited filesystem namespace and IPC models and the lack of real-time support). Some other things include the weak implementation of locking (it uses pure spinlocks instead of something like the adaptive queue-based locking that I'm using in the process server), a rather limited heap allocator that doesn't support growing/shrinking the heap or custom object sizes for slabs (the heap allocator I'm using is a derivative of the same one that Redox uses but it's been heavily enhanced with support for shrinking/growing the heap and custom slab sizes), and the rather boilerplatey implementation of some of the libraries (for example fork() is implemented as a library function that copies process context through a filesystem-based API, but rather than having object-oriented wrappers on top of the filesystem for the various state objects that it's manipulating, the fork() implementation directly invokes open(), read(), and write() a lot).

Redox's IPC is a fair bit weaker of a design than that of QNX or my seL4-derived kernel. It works sort of like that of QNX in that it has direct copying of messages between address spaces and RPC-like semantics with direct context switch from sender to receiver and back, but it is more limited and implemented in a slower way. Also, there seems to be no consideration for real-time performance at all.

Outside the core IPC model, the namespace model is also more limited than that of QNX; QNX allows multiple servers of a given type mounted anywhere within a namespace, whereas Redox's scheme-based namespace model only allows a single server of a given type per namespace, mounted on a fixed top-level prefix.

Basically I'm trying to write a better Linux than Linux and a better QNX than QNX, at least for certain use cases that is. At least initially, my primary focus is on workstation/enthusiast desktops and higher-end embedded systems (some types of servers, especially ones where high security is important, are also a focus as well but maybe not quite as much for now). Pure consumer desktops aren't really much of a priority; the goal is to make something that's approachable but definitely not dumbed down. Almost every day I see people complaining about mainstream OSes and I think there's an opportunity for an OS that's cleaner and more integrated than Linux and has various advanced features not found in Linux, but still tries to maintain a high degree of compatibility with it. I'm not really trying to clone QNX or Linux 1:1, but I am trying to maintain similar enough semantics to allow easy implementation of compatibility layers for both systems.

At the moment I have a working microkernel and an incomplete process server with a partially-implemented VFS but no support for running regular user processes. Currently I am working on some of the first special filesystems built into the process server (specifically an early log/console device at the moment).

The kernel is a hard fork of seL4 (the biggest addition at the moment is a preliminary implementation of QNX-style arbitrary-length arbitrary-address message copying); I've forked it because seL4 is focused on lower-end static embedded systems, and full verification of just the kernel isn't really particularly useful for a dynamic OS when all of the servers are unverified. The process server is written in Rust, and it's likely most of the other low-level servers will be as well, although I'm not really writing a "Rust OS" as such. Many of the basic utilities will most likely be BSD-derived, and some of the higher-level desktop-related stuff may be written in various other languages (haven't completely decided there).

It's not completely "legacy-free", nor is it purely capability-oriented, but I'm writing a QNX-like OS (https://gitlab.com/uxrt/uxrt-toplevel) based on a kernel forked from seL4 with a preference for servers written in safer languages. Even though it is going to be fairly Unix-like it will diverge from conventional Unix in a number of ways and either discard or demote quite a few legacy Unix features. For example, there will be no support for reversion to the traditional Unix security model in the core OS, with the base VFS implementing a security model based on a mix of per-process ACLs and capability transfers, and on top of that there will be a role-based access control model (there will be a fakeroot-type compatibility layer that simulates traditional Unix security within an environment constrained by the native security model). I don't think there's a good way to make a purely capability-oriented general-purpose OS since as soon as you have a way to look up files by human-readable names instead of capabilities your OS is no longer purely capability-oriented.

IMO most of the issues with typical Unix-like OSes are more due to specific outdated architectural features rather than the Unix API or shell environment. A lot of what could be done with a completely new OS could instead be done by designing a Unix-like OS for extensibility by reducing the core API down to a small set of file calls that act as an IPC transport layer and name service and then building everything on top of that, building object-oriented wrapper libraries on top of the filesystem, and reimplementing the traditional Unix APIs outside the core filesystem ones on top of the newer APIs. Existing applications could be ported to such a system incrementally rather than having to do everything all at once or relegate them to some kind of limited "penalty box" compatibility layer (and any binary compatibility layer for Linux or other conventional Unices would integrate better into such a system than into something completely new).