Pro-POS started in late 2001, as an effort to design and implement a new, better operating system, from scratch, and as a collaborative effort of a community of dreamers, designers, and developers.
That effort has failed. Now, more than two years later, we are still the same people who started this project in the first time, plus no more than one or two "acquaintance" contributors.
We stand true to our mission statement, "if we fail, we will start over, and try even harder". As of 2004-01-14, Pro-POS has been restarted, with several changes to how we intend this to work out. For those who knew the previous effort, here is a list of changes to the modus operandi.
Spin-off Project: PDCLib
Pro-POS has spun off a derivative project:
PDCLib aims at creating a C99 compliant, cross-platform C library in the Public Domain, for the benefit of any projects that don't want to get involved with the various POSIX dependencies, compiler dependencies, or license issues of existing C library implementations.
Potential later spin-offs include a POSIX layer for PDCLib and a Public Domain C++ Library.
FirstStep under Public Domain
Contributors occassionally have voiced concerns about the proprietary nature of the "Perfection" project. To make our FirstStep experimental kernel interesting for them, but without taking away the option of applying the lessons learned to "Perfection", FirstStep is placed under Public Domain.
POS Design no longer discussion-based
The pre-2004 Pro-POS efforts attempted to come up with a high-level system design by mutual agreement. This did not work out: Too diverse were the opinions of what contributed a "perfect" operating system.
The discussion forum proved to be a serious drag to the project: Too easy to jump in with strong opinions (quite often re-opening subjects that already were discussed to death), and too easy to vanish without a trace when asked to do serious design, coding, or maintenance work.
Thus, design will henceforth be done by "benign dictatorship" of the CoreTeam. We will hopefully be able to paint a bigger picture more clearly, so that you - the visitors of this page - can get a good idea on what our OS would look like if it were finished today.
Of course, we will constantly revise our design. While the communication of the CoreTeam will be done by non-public channels, we are always open to suggestions and constructive criticism. Read up on POS Design, check out the FrequentlyAskedQuestions, and if you think we've overlooked something, ContactUs.
License
As you might have noted while reading above chapter, PDCLib and FirstStep are placed in the Public Domain. This will hopefully make those two spin-offs a valuable option for as wide an audience as possible - especially those not interested in our OS, but rather an OS of their own.
See LicenseReasoning.
Language
Included from PosDesign/Language
Originally, we intended to write everything in full-fledged C++ - including enabling exceptions, standard library, and everything in kernel space. This would still be our preferred path, since it would allow us to use the very same semantics in kernel space as in user space.
However, this would have required quite some pioneering, since the use of full-fledged C++ in kernel space is sparsely tried and not at all documented in a way useful to us. Considering the currently available "active" manpower (one, give or take one...), that was a show-stopper.
Yet still, we would prefer the additional "syntactic suggar" that C++ would offer us, so the kernel will be written in a subset of the language.
No extra run-time support (no exceptions, no RTTI)
It was next to impossible to find precise information of what is required in terms of run-time support. Most people just accept that the support is there in user space, and leave the gory details to the compiler builders who aren't exactly known for writing tutorials.
No C++ Standard Library
Using full-fledged C++ would have required us to provide a standard library first, either ported or reimplemented. We will use a different approach. Starting with a C standard library (pdclib) only, we will implement only those parts of the C++ standard library, as we go, that directly benefit our kernel code. If we need a map, we will implement one that functions like specified by the standard, as far as required. That means that our "kernel map" might not have all the features of a standard map, but what features there are are handled like defined by the standard. (The idea is to make it easier for Pro-POS newcomers with C++ experience to understand our code.)
No external C++ interfaces
The kernel will use C++ only internally, with all interfaces defined in standard C, to ease interfacing of other popular languages in user space. (The original idea was something in the Object Broker ballpark, which we felt was a bit too esoteric to use in such a central point of the system.)