NeXTSTEP

NeXTSTEP

Web site: (not active)
Origin: USA
Category:
Desktop environment:
Architecture: Intel x86, Motorola 68000, SPARC, PA-RISC
Based on: UNIX
Wikipedia: NeXTSTEP
Media: Install
The last version | Released: 4.2 Pre-release 2 | September 1997

NeXTSTEP – an object-oriented, multitasking operating system created by NeXT Computer, Inc. a company founded in 1985 by Apple Computer co-founder Steve Jobs.

This system was created on the base of Mach microkernel and BSD Unix system code. NeXTStep was oriented to work in a graphical environment. It had a very well-prepared, intuitive user interface, based on object-oriented architecture, quite different from both the most popular then Microsoft Windows 3.1 and Mac OS. The visualization engine was based on Postscript, which on one hand made it very demanding in terms of hardware (considerable demand for memory) and on other hand an ideal solution for industrial and designer workstations.

NeXTSTEP 1.0 was released 18 September 1989 after a couple of hits in 1986, and last Release 3.3 in early 1995, and previously worked only on the Motorola 68000 CPU family (especially the original black boxes) and the generic IBM compatible x86/Intel, Sun SPARC , and HP PA-RISC. About the time 3.2 releases NeXT teamed up with Sun Microsystems to develop OpenStep, cross-platform implementation of the standard (for Sun Solaris, Microsoft Windows, and NeXT Mach kernel version) based on NEXTSTEP 3.2.

In February 1997, after the purchase of NeXT by Apple, it became the source of the popular operating systems macOS, iOS, watchOS, and tvOS.

The NeXTSTEP screenshot’s author: Gürkan Sengün; source: Wikipedia; Licnese: GNU GPL.

Download

No download is available.
md5sum:

 

GNOSIS

null

Web site: cis.upenn.edu/~KeyKOS/Gnosis/Gnosis.html (not active)
Origin: USA
Category: Server
Desktop environment: CLI
Architecture: IBM ?
Based on: Independent
Wikipedia: GNOSIS
Media: Install
The last version | Released: ? | ?

GNOSIS (Great New Operating System In the Sky) – an example of a completely different kind of operating system. Gnosis was developed by TYMSHARE as a proprietary control program and it also developed proprietary application packages to run on it. GNOSIS was based on the research of Norman Hardy, Dale E. Jordan, Bill Frantz, Charlie Landau, Jay Jonekait, et al. McDonnell Douglas bought Tymshare, Inc. and then sold it in 1984 to Key Logic.

Programs under Gnosis are built out of protection domains with firewalls between them. Domains are small, simple, and cheap.
Domains communicate through doors in the firewalls, called capabilities. Capabilities are a simple, uniform, efficient means of representing authority.

There are several significant factors which make it possible.

* First, and foremost, the Gnosis concept of distinct domains without implicit interactions between them results in simpler programs. Because of this, we have had to spend a great deal of time designing the interfaces between these domains to insure that adequate function exists in each; but perhaps even that is a benefit since we will know exactly how the system goes together. The basic design of Gnosis will ensure that no compromises to the design occur during the implementation.

* Second, because individual components are completely isolated from each other, except for the prescribed interfaces, it is a simple matter to implement each domain independently of the remainder of the operating system. Very little scaffolding is required. We went to install the CMS editor in Gnosis and noted all of the things we thought ought to be there as co-requisites, things like a command language to call the editor, a file system, a loader, catalog facilities, and so on. To our surprise, we discovered that we didn’t need any of those facilities. We could just connect the editor directly to the terminal handler and test it. This made development go much quicker.

* Third, we have been able to coexist with, and take advantage of, CMS during the early going. We expect to use CMS services for quite some while for compiling programs and so forth. Thus our “critical mass” of code is very much smaller that it would otherwise be.

* Fourth, the basic design of Gnosis allows us to write most of the operating system as user code, which means we will be able to eliminate a lot of duplication of effort in terms of testing tools, etc. The system will also be much simpler because all of the details of the hardware are masked in the kernel. Consequently no domain programmer need ever deal with them, which makes the domains simpler, and also greatly reduces the impact of any hardware changes. We have tended to follow the advice of Fred Brooks in the Mythical Man-month, where he suggests “be prepared to throw the first one away.” We have implemented each domain with the simplest possible algorithms in order to test the design. Later we will have to discard many of these domains and rewrite them with high performance algorithms which obey the same interface specifications. Most of these first attempt domains can be implemented In a matter of days.

* Last, but certainly not least, we have a relatively high technology “office of the future” system called AUGMENT which we are using to keep all of our design notes as well as our user documentation. The use of this system,will save us a significant amount of labor as we develop a user community over the next several years.

The combination of these facilities has made it possible for us to implement a great deal of function very quickly. As Norm mentioned earlier, we have only just started running our first domains recently. Yet we expect to be able to have a significant online database application operational within a year.

Download

No download is available.
md5sum:

 

KeyKOS

null

Web site: cap-lore.com/CapTheory/KK/
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: IBM S/370, IBM Mainframe
Based on: GNOSIS
Wikipedia: KeyKOS
Media: Install
The last version | Released: ? | ?

KeyKOS – an operating environment for S/370 computers which provides a high level of security, reliability, performance, and productivity. It allows emulation of other environments such as VM, MVS, and POSIX.

When Tymshare started work on KeyKOS in the early 1970s, there were solid business requirements justifying the project. With the price of main storage dropping, applications were too tightly bound to disk storage. Because Tymshare’s systems were accessed from around the world, continuous operation was a requirement. Existing systems were prone to failure from many causes, both hardware and software. They did not recover from these failures gracefully. These systems required significant operator intervention in both normal operation and during recovery. They did not provide the security needed to allow competing organizations to share programs and data in a controlled manner where it made economic and social sense.

Because of these deficiencies, Tymshare decided its best option was to build a system of its own. This system had a number of design goals including: high security, high reliability, economical processing of high transaction volumes, and enhanced productivity for managers, programmers, users, operators, and hardware.

KeyKOS provides persistent virtual address spaces where programs may keep data. The system caches frequently referenced data in main storage. When several processes are accessing the same data, for example the CMS “S” disk, the data blocks involved are likely to already in main storage, improving access times. Only one copy will be maintained in main storage, improving storage utilization. Persistent virtual storage allows the kernel to globally optimize disk arm movement and rotational latency. The KeyKOS implementation also provides complete separation of physical and logical DASD management. No unprivileged program is aware of the type or configuration of real DASD in the system.

KeyKOS has a system-wide checkpoint which periodically saves the state of the entire system. If a system outage occurs, the system will restart from the last checkpoint with all data and processes in a consistent state as of that checkpoint. The KeyTXF transaction processing system will recover database updates to the point of failure. Should a CPU fail, the DASD can be shared with or switched to a backup CPU to quickly restore service by restarting from the last checkpoint.

Data mirroring stores multiple copies of data for reliability and performance. The KeyKOS system continues to operate if a mirrored disk fails. When the disk is repaired, or a replacement disk is formatted and brought online, the mirrored data is automatically restored to that disk. Performance is enhanced by having several paths to a particular piece of data. The full function of the system is available in essentially any S/370 computer language. A standard invocation protocol permits high level languages to invoke low level function and low level languages to invoke high level function, enhancing the usefulness of all languages.

The KeyKOS system is designed for unattended operation. The only common operator functions are mounting tapes and servicing the printer.

The KeyKOS system is designed for continuous operation. Full system backup dumps may be taken while the system is running. When a dump has completed, the backup tapes contain an image of all data and processes in the system at a consistent instant of time. avoiding inconsistency in the data. These “tape checkpoints” are conceptually independent of the physical DASD type or configuration. They may be restored to different physical devices if necessary.

KeyKOS/370 runs on System/370-compatible single processor CPUs. It currently supports 3330, 3350, and 3380 count key data format disks and 3370 FBA format disks. System software includes the context switcher and two command systems.

Copyright © 1985, 1987, 1988, 1990 Key Logic. All rights reserved.
Permission to reproduce and redistribute this document in paper or electronic form is hereby granted, provided that this copyright notice remains intact.

KeyKOS is a predecessor of the EROS and its successors are CapROS and Coyotos operating systems.

Download

No download is available.
md5sum:

 

EROS

null

Web site: www.eros-os.org (not active)
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: x86
Based on: KeyKOS
Wikipedia: EROS
Media: Install
The last version | Released: 1.1 | April 18, 2001

EROS (Extremely Reliable Operating System) – an operating system being implemented at the University of Pennsylvania, as a clean-room reconstruction of an earlier system, KeyKOS. The system merges some very old ideas in operating systems with some newer ideas about performance and resource management. The result is a small, secure, real-time operating system that provides orthogonal persistence.

EROS is a pure capability system. Authority in the system is conveyed exclusivly by secure capabilities, down to the granularity of individual pages.

The EROS kernel itself is implemented using multiple kernel-mode threads. This improves the performance of EROS drivers, makes them simpler to code, and greatly simplifies the design of the kernel. In addition, it enables selected kernel functionality to be preempted by higher priority user activities.

Because EROS processes are persistent, processes can hold authorities in their own right rather than inheriting them from the user. This enables a rich variety of options for security and access control that are impossible in systems lacking persistent processes.

EROS developed beginning in 1991 by The EROS Group, LLC., the Johns Hopkins University, and the University of Pennsylvania. Features include automatic data and process persistence, some preliminary real-time support, and capability-based security. EROS is purely a research operating system, and was never deployed in real world use. As of 2005, development has stopped in favor of two successor systems, CapROS and Coyotos.

The project founder is Jonathan Shapiro. He is also the driving force behind Coyotos, which is an “evolutionary step” beyond the EROS operating system.

Download

No download is available.
md5sum:

 

GRVTYFLLSOS

null

Web site: sourceforge.net/projects/grvtyfllsos.dan-c-occupational-research.p/
Origin: ?
Category: Desktop
Desktop environment: CLI
Architecture: x86
Based on: MikeOS
Wikipedia:
Media: Live
The last version | Released: ? | October 14, 2017

GRVTYFLLSOS – an open-source, written in assembly language, MikeOS based operating system. This project is designed to replicate a functional version of the operating system contained in Ford Pines’ laptop from Gravity Falls.

It is very small in size and exported in a floppy format.
Can be used in emulators such as virtualbox.

Download

GRVTYFLLSOS i386 120KB.zip
md5sum: efa884882e0008338730b663799cd9e8

 

ZeX/OS

ZeX/OS

Web site: zexos.org (not active)
Origin: Czech ?
Category: Desktop
Desktop environment: GUI
Architecture: x86
Based on: Independent ?
Wikipedia:
Media: Live
The last version | Released: 0.6.4 | June 26, 2009

ZeX/OS – a simple operating system written in C and assembly languages and published under GNU/GPL license version 3.

ZeX/OS provides you many different apps you can use everyday. There are favorite apps like irc client, netcat client, email client, web client, web server, text editor, music player, remote control server, some games, calculator, graphical user interface, etc.

Features:
– Archs: x86, x86_64, ARM
– Mode (i386): protected
– Supports: preemptive multitasking, shell, commands, multitty, paging, networking, graphical environment, 2D and 3D (OpenGL) graphics
– Drivers: built-in (floppy, video, keyboard, rs232, lba, vga, vesa, pci, mouse, speaker, pcnet32, rtl8029, rtl8139. rtl8169, AC’97)
– Apps: elf executable (irc, websrv, webcl, nc, wm, openchess, im, telnetd, sh, imgshow, zde, zjab, zasm, ..), built-in (fdisk, hdcat ..)
– Filesystem: zexfs, fat12, fat16, iso9660, ext2, vfs, znfs
– Networking: ipv6, ipv4, tcp, udp, icmp, arp, ndp, dns, ips, tunnel broker, unix

Administrator account:
login name: root
Password: root

Guest account:
Login name: guest
Password: guest

The project developer is Tomas Jedrzejek.

Download

ZeX/OS 0.6.4 i386 1.15MB.iso
md5sum: 3263b85c0cf006a663072efba2c727d1

 

ZachOS

ZachOS

Web site: zachos.sourceforge.io
Origin: ?
Category: Desktop
Desktop environment: TUI
Architecture: x86
Based on: MikeOS
Wikipedia:
Media: Live
The last version | Released: ? | April 4, 2014

ZachOS – a small, open-source, MikeOS based 16 Bit X86 operating system. The goal is to create an OS that was very small in size but fun to use at the same time.

The developer wanted to remove all the complex layers of abstraction that are present in the Operating Systems of today such as Graphical Interfaces and Networking etc etc and just have a simple OS that loads programs.

Download

ZachOS (source code + ISO) i386 220KB.zip
md5sum: 5557a8b7264e33b7101f983a06335aff

 

LorenOS

null

Web site: sourceforge.net/projects/lorenos/
Origin: ?
Category: Desktop
Desktop environment: CLI
Architecture: x86
Based on: MikeOS
Wikipedia:
Media: Live
The last version | Released: 2.0 | May 8, 2014

LorenOS – a simple x86 basic operating system, based on MikeOS and written in the assembly language. LorenOS is an educational project.

Download

LorenOS 2.0 i386 19KB.tar.gz
md5sum: a91ac768ade5d89f712032a3978215bf

 

StarlungOS

StarlungOS

Web site: sourceforge.net/projects/starlungos/
Origin: USA
Category: Desktop
Desktop environment: TUI
Architecture: x86
Based on: MikeOS
Wikipedia:
Media: Live
The last version | Released: 14 | December 29, 2014

StarlungOS – a simple but complex OS based on MikeOS. It includes user configurable programs and an easy to use interface.

Features:
– User configurable interface
– Many command line features
– User editable programs
– Great software support

The project developer is John Roper.

 

mattOS

null

Web site: sourceforge.net/projects/mattos/
Origin: ?
Category: Desktop
Desktop environment: CLI
Architecture: x86
Based on: MikeOS
Wikipedia:
Media: Live
The last version | Released: ? | November 21, 2010

mattOS – a simple x86 assembly operating system based on MikeOS. It’s goal is to have lots of features.

The system is loaded from the floppy/CD, by BOOTLOAD.BIN, as KERNEL.BIN. First we have the system call vectors, which start at a static point for programs to jump to. Following that is the main kernel code and then additional system call code is included.

The system bootloader is based on a free boot loader by E Dehling. It scans the FAT12 floppy for KERNEL.BIN (the MikeOS kernel), loads it and executes it. This must grow no larger than 512 bytes (one sector), with the final two bytes being the boot signature (AA55h). Note that in FAT12, a cluster is the same as a sector: 512 bytes.

Username: root
Password: root

Download

mattOS source code 39KB.tar.bz2
md5sum: 9aa4cf92180e6f1d87b6be68cd513f76
mattOS i386 1.4MB.flp
md5sum: a25057f07b7d7406bde73884e955bffe