Writing an OS for PC (fwd)
Mon, 29 May 1995 20:31:07 +0200 (MET DST)
David Logan <firstname.lastname@example.org> posted a message in
comp.os.research about his pet OS project. I proposed he join us,
and here is his answer (my answer back in next tunes post)...
>From email@example.com Sat May 27 19:31:17 1995
Received-Date: Sat, 27 May 95 19:31:17 +0200
Date: 27 May 95 13:29:47 EDT
From: David Logan <firstname.lastname@example.org>
Subject: Writing an OS for PC
-----BEGIN PGP SIGNED MESSAGE-----
Hi! I don't know at this point if I'm interested in helping you work on your
operating system. This being said primarily due to the fact that I don't know
what kinds of plans you have. Allow me to provide the letter that I am
providing to people who believe they are interested in helping me. If it
sounds interesting to you, perhaps we can talk some more. Thanks!
Hello, and thanks for the reply. Every OS designed has to be based off of
something, I guess. (Or multiple somethings). Let me see if I can sum up some
of what I'm trying to do.
1. Of course, true preemptive multitasking.
2. Of course, true 32-bit programming.
3. Refrain from HUGE amounts of memory required to run the OS, like some
other OS's that I know. Keep in mind that this may conflict with the
goals below. However, if it does, then the goals below become the
priority, because at least lots of functionality comes from the size.
Now for some of the things that I want that most other OS's don't have.
1. VERY extensive error recovery and error handling.
a. The OS itself NEVER crashes unless some PL0 task trashes me BEYOND
REPAIR. (This implies an attempt to repair and recover).
b. All tasks, all functions are given the opportunity to recover/repair
their own errors instead of just being killed.
c. Dumps, traces, etc. of where tasks came from, where they went, what
happened, how everything looks, etc. for problem resolution when
something does go badly.
One of the things that has pissed me off no end is that no PC OS even
comes close to having problem determiniation aids outside of a single-step
debugger. In this area, I'm working on using concepts that come from IBM's MVS
operating system. (You'll notice that several ideas come from there).
2. Reportability and accountability. I want to know what my machine is
doing, why, when, how long, and who is causing it.
Note here, that the likelyhood of this OS being designed for "home use" is
probably about 1%. (Less, probably). Again, the concepts are being based off
the mainframe OS. The idea came from my LAN admin (at work) telling me that
he couldn't report on anywhere near the types of things that I can (in the
3. Support for multiprocessing. I'm including as much code as I can for
multiple processor support.
Obviously, for a while a lot of the MP code will just be anchored (i.e. just
a RET statement), but as much as I can include and support for future use I am
User programs, intermediate 3rd party products, administrator-written user
or OS code, etc. can be very versatile, using the system in whatever ways they
need or would like. Good networking capability, excellent (as much as possible
with the Intel hardware support) cross-memory services, etc.
5. There's more, but it has escaped me for the moment. If we talk again
based on this letter, I'm sure you'll hear some more ideas.
Keep in mind that I don't believe I am a mainframe bigot. I've been an
expert in both mainframe and PC's for years and years. However, also keep in
mind that IBM has been developing high performance, multitasking,
multiprocessing operating systems for years, and their ideas, concepts, and
implementations are quite good. If we can figure out how to implement those
same concepts (as in error handling, recording/tracking, task versatility,
etc.), it has the capability to provide businesses with a full featured,
reliable, usable, excellent OS. Especially as PC's evolve in power and
Specifically, some of the things that I have in the plans or are working on
1. Only two selectors in the GDT are static (also only 2 in the LDT).
The 2nd is the selector to the Common Memory Area in the GDT, the Local
Memory Area in the LDT (OS reserved virtual storage).
2. OS memory can be fixed or pageable. It can also be protected or
non-protected. The selectors themselves are DPL3, allowing user tasks to
read most of OS storage, but not modify it (based on page table R/W bit).
Obviously, some things must reside in protected storage (U/S bit = S),
like network buffers, security package control blocks, etc.
3. An address space (or sets of segment/page tables) are not related to a
task (or TSS). Multiple tasks can be run under an "address space".
4. Recovery/termination. Any task can make an operating system call at any
time to establish an "error recovery" routine to be called in the event
of an error. This routine can correct/bypass the error, and request the
OS retry the origional routine, or continue the termination process.
Required in all OS routines, especially in global ones that can be done
under any TSS. Also required in any tasks/address spaces that would hang
the system in the event of a failure.
5. Special environments for the double fault, NMI, and stack fault handlers.
Make EVERY effort to protect these tasks code/control blocks so in the
event of a serious failure, the system doesn't hang. These routines will
support dumping of the system for problem resolution. (Dumping of all or
parts of the system are supported in all cases, initiated either by the
OS or a user task. It's just that these three tasks are very critical to
recovery of the OS, and at least problem resolution if recovery is
impossible). The stack fault handler becomes "special" only in the event
that a stack fault occurs on a PL0 stack.
6. A million others, but these should give you a taste of what I'm reaching
If you're still interested after reading this book, let me know! I'd be glad
to hear new ideas, implementation concepts, and even willing to help code!
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
(end of forwarded message)
-- , , _ v ~ ^ --
-- Fare -- email@example.com -- Francois-Rene Rideau -- +)ang-Vu Ban --
-- ' / . --
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"