OSDev.org

Hi there
Sorry I don't want to take up too much on the forum, thanks for the fast replies to my last post.
Most of what I can find uses UNIX as an OS example, I'm assuming Windows isn't used due to it being closed source and for legal reasons etc.
However most OS's seem to either be UNIX-like or Windows NT. Are there any other types of OS?

Whats the difference between UNIX and Windows NT?

What does the OS have to have, or be able to do to have its own category?
Thanks again

RDOS doesn't fit in any of the categories. It was developped to have its own native API, which could emulate both DOS, DOS-extender, Win16, Win32, and Posix-compliant systems. There have been emulator-APIs that could run DOS applications as well as Win16 and Win32-console applications, and there have been some work on porting GCC and LIBC which isn't complete. RDOS for instance both support the CreateProcess interface of Win32, and the fork interface of Unix. It can use both ELF and PE as an executable format by use of an image loader abstraction. Today, it mostly uses a variant of PE for native applications written with OpenWatcom.

So it is definitely possible to write OSes that are natively neither Windows nor Unix.

Yo:

If it implements the POSIX API natively and doesn't add any major, original APIs beyond that, it is a unix clone; if it implements the NT API natively and doesn't add any major, original APIs beyond that, it is an NT clone

--Peace out
gravaera

There are a couple different aspects that define the 'type' of operating system. The two most orthogonal components are the internal architecture of the OS and the userspace API it presents.

Examples of OS architectures are monolithic kernels (original UNIXes), modular monolithic kernels (Linux), 'hybrid' kernels (NT, apparently), first generation microkernels (Mach, XNU), second-generation microkernels (MINIX, QNX, L4, etc.), etc. We have a section in the wiki on this: http://wiki.osdev.org/Kernels. Different designs mostly have different scalability, stability, performance, and maintainability properties, but don't really change how the OS appears to operate.

An OS can present one or more userspace APIs, which are what programs running under the OS see. Examples of this are the POSIX (i.e. *nix) API and Win32 API. Most people here seem to either support POSIX, because it's widely used, well documented, and open, or create their own unique API to fit their OS' design. It's entirely possible to (mostly) abstract the userspace API from the rest of the design and even support multiple different APIs at the same time; you could consider something like Wine to be an example of this under Linux and Cygwin to be an example of this under NT/Windows.

However most OS's seem to either be UNIX-like or Windows NT.

Actually, only UNIX is generally cloned - and there are indeed quite a few of them. The Windows API itself is rarely cloned because it's rather bloated in comparison - and besides ReactOS (and Wine, which isn't an OS) there aren't any notable implementations. There are however several L4-inspired projects around, as well as several independent microkernel implementations.

Excluding the hello world OSes and other stillbirths (most people trying to clone windows can't code), the actual hobbyist distribution would very roughly be 50-50 between unix clones and non-unix-non-windows designs.

NickJohnson wrote:An OS can present one or more userspace APIs, which are what programs running under the OS see. Examples of this are the POSIX (i.e. *nix) API and Win32 API.

I would necesarily call any of these for native. The Win32 API is typically created with a set of DLL-files in userspace, and can be implemented with a variety of underlaying native APIs. The POSIX API is typically created in the C library, and thus can also be built on top of many native APIs.

The old DOS int 21h interface OTOH is more like a native interface.

rdos wrote:The POSIX API is typically created in the C library

Bull. Posix defines the entire system, from system calls to applications. The API calls that are typical of unix actually have 1:1 mappings to actual system calls on linux and various other unices.

In other words, you can talk a subset of posix directly to the linux kernel.

I would say that there is a clear definition of any OS' native API: the one all the others call down to! For most POSIX OSes it's.. well.. quite clearly POSIX. For Windows its quite clearly the NT Native API.

So if I was to create my own OS with a unique API this would then be unique and not classed as UNIX like?

What I am currently looking at and practicing with is based on UNIX at the moment.
In theory could you have an OS without an API as such? Obviously programs wouldn't run on the software and it could be classed as a pointless endeavor.
Could an OS be created that booted, controlled the hardware etc and just looped through a single built in function, such as adding 1 every second for 20 seconds and then shutting down?

Sorry for the strange question I am just curious into some of this stuff (and obviously from what I can tell know one spends time writing about these things, as it is.... seemingly pointless).

Would this class as an OS or something else?
Also would any such techniques be used in the past before high-level computing languages existed?

Many thanks

eskimo456 wrote:So if I was to create my own OS with a unique API this would then be unique and not classed as UNIX like?

Precisely

Owen wrote:I would say that there is a clear definition of any OS' native API: the one all the others call down to! For most POSIX OSes it's.. well.. quite clearly POSIX. For Windows its quite clearly the NT Native API.

Thing is, the API all the others call down to doesn't need to be visible to userspace: it can consist entirely of functions internal to the kernel.

I'd generally say that it's best to divide an OS up into about three different parts: The userspace API(s), the hardware management layer (drivers, page table management, etc), and the user interface (which is what the non-technical end-user will identify as "the OS").

When multiple userspace APIs are present on a system, one is generally implemented in-kernel, with the others being provided by userspace processes that call the in-kernel API (a la Wine), but there's no reason you can't have multiple API's all implemented in kernel and interacting with the hardware management and UI layers directly.

eskimo456 wrote: However most OS's seem to either be UNIX-like or Windows NT. Are there any other types of OS?

TRON, OS/2, BeOS and various different DOS

Thing is, the API all the others call down to doesn't need to be visible to userspace: it can consist entirely of functions internal to the kernel.

No, if something consists of internal (not exported) functions then it is not an interface, as in the 'I' in API.

JamesM wrote:

Thing is, the API all the others call down to doesn't need to be visible to userspace: it can consist entirely of functions internal to the kernel.

No, if something consists of internal (not exported) functions then it is not an interface, as in the 'I' in API.

Granted, but it just strengthens the point I was making, that if you implement multiple syscall APIs, you don't have to have one "native" API with the rest all being implemented by code in userspace calling the native API.

(That said, with a modular kernel it does make sense to talk an API made of kernel-internal functions: namely the functions that are exposed to modules but not to userspace, and in a system with multiple userspace APIs, the userspace APIs could be implemented as modules that use such a kernelspace API as a back end).

EDIT: Actually it's probably better to call such an interface an MPI, as it's not really used for Applications.