Page 3 of 3

Re: Part 13

Posted: Sat Dec 22, 2018 12:30 am
by admin
#381 From: "Gregory L. Marx" <gregory.marx@...>
Date: Tue Mar 12, 2002 1:40 pm
Subject: Re: Kernel/mikrokernel architecture chekmarx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Mon, 11 Mar 2002 08:51:34 -0800 (PST), Lynn H. Maxson wrote:

<snip>

>You may take this as my commitment to participate in the kernel
>development, first in its documentation and design and then in its
>coding. Others may begin their coding as their impatience
>demands.<g>

Thank you for a wonderfully informative post !!!

Gregory L. Marx
(who's just a lurker ... Has never programmed professionally beyond some Arev
(Pick) projects ... Who will probably never program again
professionally due to his current job as a System Administrator, but REALLY
REALLY enjoyed the sound logic presented in this post)

Re: Part 13

Posted: Sat Dec 22, 2018 12:30 am
by admin
#382 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Mar 12, 2002 7:11 pm
Subject: Re: Kernel/mikrokernel architecture lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Gregory L. Marx writes:
"Thank you for a wonderfully informative post !!!"

Thank you. We'll see who else shares your opinion. I haven't
heard of PICK in some time. Interesting.

Re: Part 13

Posted: Sat Dec 22, 2018 12:31 am
by admin
#383 From: "Gregory L. Marx" <gregory.marx@...>
Date: Wed Mar 13, 2002 1:59 am
Subject: Re: Kernel/mikrokernel architecture chekmarx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Tue, 12 Mar 2002 08:11:17 -0800 (PST), Lynn H. Maxson wrote:

>Gregory L. Marx writes:
>"Thank you for a wonderfully informative post !!!"
>
>Thank you. We'll see who else shares your opinion. I haven't
>heard of PICK in some time. Interesting.

I used to just note it as AREV ... but someone would always come back with
"What's AREV ???"
So I now I just specify PICK since that's what AREV was based/modeled after ...
Even though the DOS version runs fine I'm still trying to find the OS/2 version
of AREV ...

Greg

Re: Part 13

Posted: Sat Dec 22, 2018 12:32 am
by admin
#384 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Mar 13, 2002 6:45 pm
Subject: Re: Kernel/mikrokernel architecture lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


John Martin (JMA) writes:
" ... I doubt we will get a large enough team to build YAK (yet
another kernel) and there are lots of team out there that are
building kernels. Why not reuse what they are doing ..."

Apparently only Gregory L. Marx thought my previous response in
this area was worthwhile. In this instance I do not know when
large enough is large enough. I do know it is a much larger
number when it is a layer adapted to multiple kernels.

Frankly I don't know why there are lots of teams building kernels
unless they have nothing better to do with their time or feel in
some manner it looks good on their resume. I do know that it is
possible to build a kernel which is second to none. It doesn't
make much sense to me to build one to any other standard. No one
I've read in this list believes that all kernels are created
equal.

So therefore why not have a better OS/2 than OS/2, Linux than
Linux, and Windows than Windows? Why not have it in a single
package for much the same reason it became the slogan for OS/2
2.0?

Re: Part 13

Posted: Sat Dec 22, 2018 12:32 am
by admin
#385 From: "JMA" <mail@...>
Date: Thu Mar 14, 2002 1:35 am
Subject: Re: Kernel/mikrokernel architecture mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Wed, 13 Mar 2002 07:45:58 -0800 (PST), Lynn H. Maxson wrote:

>John Martin (JMA) writes:
>" ... I doubt we will get a large enough team to build YAK (yet
>another kernel) and there are lots of team out there that are
>building kernels. Why not reuse what they are doing ..."
>
>Apparently only Gregory L. Marx thought my previous response in
>this area was worthwhile. In this instance I do not know when
>large enough is large enough. I do know it is a much larger
>number when it is a layer adapted to multiple kernels.
>
Are you saying that its easier to build "a kernel which is second to none"
than graft the CPAPI ontop differnet kernels ?


>Frankly I don't know why there are lots of teams building kernels
>unless they have nothing better to do with their time or feel in
>some manner it looks good on their resume. I do know that it is
>possible to build a kernel which is second to none.
>
I'm not trying to stop anyone to build "a kernel which is second to none".
But osFree is about something else, building a OS/2 clone.

>It doesn't
>make much sense to me to build one to any other standard. No one
>I've read in this list believes that all kernels are created
>equal.
>
>So therefore why not have a better OS/2 than OS/2, Linux than
>Linux, and Windows than Windows? Why not have it in a single
>package for much the same reason it became the slogan for OS/2
>2.0?
>
Sure, sounds really nice. But Windows is not just a kernel nor are
Linux just a kernel.
And, any kernel to be used by anyone needs drivers. Either you enable
the "kernel which is second to none" to load all sorts of drivers from
other drivers or someone has to write all the drivers.





Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================

Re: Part 13

Posted: Sat Dec 22, 2018 12:33 am
by admin
#386 From: "Lynn H. Maxson" <lmaxson@...>
Date: Thu Mar 14, 2002 7:19 am
Subject: Re: Kernel/mikrokernel architecture lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


John Martin writes:
"... Are you saying that its easier to build "a kernel which is
second to none" than graft the CPAPI ontop differnet kernels ?
..."

If by different you mean more than one, then most certainly yes.
If by different you mean only one, e.g. Linux, then it's a closer
call as the effort is about equal with a slight edge to the
"second to none".<g> However, there's no doubt about which
produces the better result with respect to future development.

We have in these discussions done comparisons between OS/2 and the
various Microsoft incarnations, specifically NT and Win 2000, and
Linux which comes off particularly poor, and BeOS which gets high
marks. We've had the example of OS/2 on the PPC in terms of a
microkernel implementation. We've discussed MACH, Darwin (OS X),
and other implementations. These OSes are not identical, equal,
or equivalent.

We cannot create an OS/2 clone that does not accept those
applications, utilities, etc. which run currently. That says at a
minimum we must support the OS/2 CPAPI. We must support the names
of the APIs, their parameter set and order, and the rules
governing their behavior. This is functional equivalence. Only
three possible changes are available to us: increase performance,
decrease resource usage specfically internal and external storage,
and increase quality (RAS--Reliability, Availability, Service).
If we do only that, we will have a better OS/2 than OS/2, i.e.
that sourced from IBM.

However, nothing dictates that we cannot at the same time increase
functionality, provide a supplemental set of APIs adding new
function and perhaps replacing existing. Then we will have an
even better OS/2.

However better we make our open source product, we will not have
solved either the application and driver issues. Remember that
the responsible parties for both of these are third-party hardware
(driver) and software (application) vendors. It does us little
good to solve one problem through open source providing a better
OS/2 if we do not at the same time solve the other two situations.

If we put the OS/2 CPAPI as an application layer on Linux, we have
chosen the lesser alternative for driver and application support.
Clearly placing the OS/2 CPAPI as an application layer on Windows
offers a better solution in terms of driver and application
support. One is probably technically as easy as the other.

However, you have deficiencies in Linux and in Windows that
restrict the possibilities in an OS/2 CPAPI layer. You end up
with something less than OS/2 and yet incapable of using (through
the CPAPI interface) the something more that might exist in the
underlying host. So why does anyone not understand the tendency
toward products like the Virtual PC and VMWare, which are
deliberate (and expensive) attempts to not layer one CPAPI on top
of the other.

So why is something like the microkernel so tempting? Why have a
lowest API functional level acting as a common denominator to
multiple OS personalities (OS/2, Linux, Windows, BeOS). It means
not only having backward compatibility with these "legacy" OSes,
but having a "forward" compatibility with something not possible
with any. So you protect existing investments while providing an
extended environment for future investments.

Having some experience with IBM's 8100 DPPX operating system, I
have some idea of supporting a dynamic environment in which
functions like drivers (and their supported hardware) are enabled
and disabled, taken offline and brought online, without the need
to re-ipl. I see no reason not to extend this form of resource
allocation to support assigning different hardware resources to
the exclusive use of guest OS personalities. Portions of this
capability exist in IBM's VM operating system.

The point is that there is a lot of work involved in producing a
kernel whether second to none or not. It's about the same about
of work. So why opt for less than the best? In the time it takes
to do this the Linuxes and Windows will be changing as well. So
why not choose at point of GA (General Availability) to be equal
to or better than those choices on their on home turf, their own
kernels.

If I want to encourage Linux volunteers to participate in this
effort, to have the second to none endpoint, then why would I not
want them to use their Linux expertise to increase Linux
capabilities in this environment? If in fact it leads early on to
the conclusion that it is a better Linux than Linux, I would fully
expect to see current Linux development collapse and be absorbed
into this effort.

That leaves only Windows (and to a lesser degree BeOS). I see no
reason why we cannot take the expertise arising from the ODIN
project and transfer it into a Windows personality based on the
same microkernel. That will require far less effort than ours to
produce an OS/2 personality. If we have a superior, i.e. second
to none, set of lowest level APIs, we will not only have an open
source for Windows, but the ability to produce a better Windows
than Windows, not to mention the fact that it will bring Microsoft
crashing down.

"I'm not trying to stop anyone to build "a kernel which is second
to none". But osFree is about something else, building a OS/2
clone."

You have this concept of a "floating" OS/2 CPAPI, which you can
transparently and seamlessly attach on top of a (or any
Intel-based) host OS. If you have this, you believe you have an
OS/2 clone without an OS/2 kernel or without having to write one.
You leave yourself open that you do not have OS/2 driver support
per se, but a layer above the driver support of the host OS. If
by the "different" from earlier you have multiple OS hosts, then
you have multiple driver support layers independently developed
and maintained as changes to the host occur.

Now why is it do you think that something like the Virtual PC and
VMWare regardless of cost work and something that has been in
development for an equal length of time like ODIN is still beta?
The answer doesn't lie in the amount of resources available to
ODIN. The answer is it is easier to develop and maintain a
horizontal layered set of

Re: Part 13

Posted: Sat Dec 22, 2018 12:34 am
by admin
#387 Re: [osFree] Kernel/mikrokernel architecture
Expand Messages

JMA
Mar 13, 2002
On Wed, 13 Mar 2002 20:19:05 -0800 (PST), Lynn H. Maxson wrote:

>John Martin writes:
>"... Are you saying that its easier to build "a kernel which is
>second to none" than graft the CPAPI ontop differnet kernels ?
>..."
>
>If by different you mean more than one, then most certainly yes.
>If by different you mean only one, e.g. Linux, then it's a closer
>call as the effort is about equal with a slight edge to the
>"second to none".<g> However, there's no doubt about which
>produces the better result with respect to future development.
>

Nice that you think this. As a developer with some familarity with
the CPAPI and some knowledge in kernels (though I have never
developed one myself) I simply cannot agree. You say its easy
to do a great kernel - a piece of software that depends on hardware
services and must support drivers from other oses - compared to
a very wellknown CPAPI that is built to be hardware independant.

Also you somehow think that OS/2 has lots of unique features that
would it hard or almost impossible to implement the CPAPI ontop
of other (less capable ?) kernels.
Ask most lowlevel OS/2 developers and they will tell you the OS/2
kernel is "an old hack".


>Only three possible changes are available to us: increase performance,
>decrease resource usage specfically internal and external storage,
>and increase quality (RAS--Reliability, Availability, Service).
>If we do only that, we will have a better OS/2 than OS/2, i.e.
>that sourced from IBM.
>

We are out to create an opensource clone and thats the only place to
start. If we plan for a wiz-bang system people will have lost interest
before it leaves the planning stages - just go back to FreeOS and look.

The first release of a opensource clone will be slower and less featured
that OS/2 is today. IBM has spend enormous funds on developing and
enhancing OS/2 through the years. And as many parts of the system
are getting old they benefit from the ever increasing speed enhancement
in hardware.

No method of planning nor developing can ever replace money and time.


>However better we make our open source product, we will not have
>solved either the application and driver issues. Remember that
>the responsible parties for both of these are third-party hardware
>(driver) and software (application) vendors. It does us little
>good to solve one problem through open source providing a better
>OS/2 if we do not at the same time solve the other two situations.
>

Its up to the open source OS developer to ensure there are drivers
and applications for a new OS. If you assume that developers will
come running asking for a chance to develop drivers and application
for your new OS you are dead wrong.


>However, you have deficiencies in Linux and in Windows that
>restrict the possibilities in an OS/2 CPAPI layer. You end up
>with something less than OS/2 and yet incapable of using (through
>the CPAPI interface) the something more that might exist in the
>underlying host. So why does anyone not understand the tendency
>toward products like the Virtual PC and VMWare, which are
>deliberate (and expensive) attempts to not layer one CPAPI on top
>of the other.
>

You cannot technically compare a product like VPC or VMWARE
to a proposion to place a CPAPI layer ontop another kernel.
Or are we talking marketing ?


>So why is something like the microkernel so tempting? Why have a
>lowest API functional level acting as a common denominator to
>multiple OS personalities (OS/2, Linux, Windows, BeOS). It means
>not only having backward compatibility with these "legacy" OSes,
>but having a "forward" compatibility with something not possible
>with any. So you protect existing investments while providing an
>extended environment for future investments.
>

Please read up on what a microkernel does !


>The point is that there is a lot of work involved in producing a
>kernel whether second to none or not. It's about the same about
>of work. So why opt for less than the best? In the time it takes
>to do this the Linuxes and Windows will be changing as well. So
>why not choose at point of GA (General Availability) to be equal
>to or better than those choices on their on home turf, their own
>kernels.
>

OK, you opt to set a GA where the kernel will be better at running
Windows apps than Windows is. With the right development
methods and aiming at the starts we could easily beat Microsofts
hoards of money and developers - right ?


>If I want to encourage Linux volunteers to participate in this
>effort, to have the second to none endpoint, then why would I not
>want them to use their Linux expertise to increase Linux
>capabilities in this environment? If in fact it leads early on to
>the conclusion that it is a better Linux than Linux, I would fully
>expect to see current Linux development collapse and be absorbed
>into this effort.
>
>That leaves only Windows (and to a lesser degree BeOS). I see no
>reason why we cannot take the expertise arising from the ODIN
>project and transfer it into a Windows personality based on the
>same microkernel.
>

Now you are contradiction yourself. By placing a CPAPI layer ontop
another kernel than OS/2 you say I opt for a less than optimal solution.
Now you say that Linux and Windows (poss. BeOS) developers will
flock around your proposed os since it will be so much better that what
they have today. How are you going to ensure that four operating
systems get a perfect kernel that matches there "CPAPI's so good
that its better than their existion solutions.

To do this you either have to write in support for many different OS'es
in the kernel or you have to make OS layers that maps to a generic
set of kernel support. And you will come up with things that would
conflict between the "personalities". What OS to prefere then ?

IBM did spend in excess of $100 million on OS/2 for PPC and were
not able to get more that acceptable performance for their main
personality. And thats after they stepped down from the WPOS
multiple personalities plans.

And IBM was not dumb (at least not the development team).


>That will require far less effort than ours to
>produce an OS/2 personality. If we have a superior, i.e. second
>to none, set of lowest level APIs, we will not only have an open
>source for Windows, but the ability to produce a better Windows
>than Windows, not to mention the fact that it will bring Microsoft
>crashing down.
>

Get real, Windows is not at its current place due to good or bad
kernel services.


>"I'm not trying to stop anyone to build "a kernel which is second
>to none". But osFree is about something else, building a OS/2
>clone."
>

<SNIP>

>You leave yourself open that you do not have OS/2 driver support
>per se, but a layer above the driver support of the host OS. If
>by the "different" from earlier you have multiple OS hosts, then
>you have multiple driver support layers independently developed
>and maintained as changes to the host occur.
>

Maintained by someone else. Thats why leaving kernel development
to people that have the time and knowledge is so interesting.
If osFree was build to run on the os/A kernel and os/A started dwindling
we would be able to move to os/B or os/C relativly easy. If we build
our own kernel we have to ensure its has all the drivers.

This is simple economics. Time and money is not on our side.


>Now why is it do you think that something like the Virtual PC and
>VMWare regardless of cost work and something that has been in
>development for an equal length of time like ODIN is still beta?
>The answer doesn't lie in the amount of resources available to
>ODIN. The answer is it is easier to develop and maintain a
>horizontal layered set of OSes, e.g. the microkernel, Virtual PC,
>and VMWare, than a vertically layered set.
>

OK, please compare the few ODIN developers that do their work at
spare time with companies that have many fulltime employees.
But that not that important since thay are doing quite different
things. Building a hardware PC in software cannot be compared
with supporting the user mode API of a huge operating system.


>None of the other choices, however, come close to the microkernel
>in terms of functionality, performance, resource usage,
>reliability, and maintainability. It is "integrated" from the
>get-go, not some "add-on" functionality. The object then is to
>choose the microkernel, choose the set of lowest level APIs, and
>implement them second to none.
>

Please read up on this.
You simply dont just build a microkernel and place personalities
ontop of that. A mk is just a small layer to hide the hardware from
the real kernel.


Your suggested method of software development would fit very
well into a CPAPI clonage method. This API and the API's above
is well known and well documented. This means everything could
be documented and quite well typed out before a single line of
code is written.
Doing the same with a kernel supposed to support a OS/2
personality (with ample speed and compatibility) needs
intricate knowledge on how the OS/2 kernel works. How outside
(or even inside IBM) has that ?






Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================

Re: Part 13

Posted: Sat Dec 22, 2018 12:35 am
by admin
#388 Re: [osFree] Kernel/mikrokernel architecture
Expand Messages

Lynn H. Maxson
Mar 14, 2002
John Martin (JMA) writes:
"... Please read up on what a microkernel does ! ..."

You raise a host of issues. It's hard to select one from the
remainder fall into line. Let's try it with this one.

What does a microkernel do. We agree that it "isolates" the
higher level functions from the hardware. I think we also agree
that it provides a form of "software isolation", e.g. IPC
(Inter-Process Communication). In all likelihood we agree the
microkernel provides the lowest level APIs (functions) ultimately
required by the higher level layer represented by the CPAPI.

Now ultimately any software application (and an OS is simply
another software application) has a logical hierarchy of APIs
governing its behavior...even if the only API is itself. We have
a main routine, in our instance a particular set of CPAPIs, which
in turn requires calling on sub-routines which in turn call on
other sub-routines until we reach a set of sub-routines with only
calls to other sub-routines at their, the lowest layer.

It makes no difference how you represent this hierarchy of routine
and sub-routines visually, you have a path from every leaf (lowest
level sub-routine) to one or more highest level root routines.
You can safely say then that this lowest level set of leaves
represents the minimal number of sub-routines necessary for the
proper support of all higher level routines and sub-routines. As
a minimal number within an OS kernel it represents a microkernel.

That's what a microkernel is logically. What it is physically
depends upon its implementation. Obviously we have a choice in
doing that. To me a microkernel is a set of lowest level APIs
which supports the development of all higher level up to the CPAPI
and through it to the higher level APIs invoked by applications.

So my definition, my view of what constitutes a microkernel, is a
logical view, not a physical one, an implementation, like the
various MACH forms or any other. What a microkernel does
(logically) and how it does it (physically) are two different
sides to the same coin.

Thus if you take the CPAPIs of different OSes, e.g. Linux, OS/2,
BeOS, and Windows, for an Intel platform and you apply the
decomposition of each to its lowest level APIs, you will have in
the aggregate the set of all lowest level APIs, the microkernel,
necessary to support them all.

I don't presume that all OSes are created equal. I do do presume
that if they support or could support the same functional set of
applications that they at least have a considerable degree of
overlap, particularly at the lowest or microkernel level. So it
is not surprising given the number of different OSes written over
the years that portions of its APIs and their internal processing
are "old hacks".

I don't know that OS/2 is that "unique". I don't really care. I
do know that I prefer it to other OSes, but that sometimes I have
to forego my preference in order to have particular driver or
application support. As they all seem based, at least within my
sphere of interest, on the Intel platform I see no reason why on a
single system I need to be restricted to exclusively executing one
OS instead of several concurrently. In other words a "super OS"
which supports other OSes as concurrent applications.

Among other things that "super OS" will allow me to control what
the "guest" OSes see as their physical environment, e.g. devices,
with the ability to re-allocate the physics as the need arises.
This functionality exists as part of IBM's VM operating system. I
see no reason to not incorporate some of that function here.

"... You cannot technically compare a product like VPC or VMWARE
to a proposion to place a CPAPI layer ontop another kernel.
Or are we talking marketing ? ..."

Yes, I can because they differ technically. I can compare the
effect, particularly with respect to ongoing development and
maintenance. Neither requires physical modification of an
executable OS nor any changes of logic below the CPAPI layer to
map into the host kernel. You cannot place a CPAPI layer on top
of another kernel without changing at least the internal logic and
APIs due to the differences in API name, number, order, and type
of parameters, and functionality between it and the CPAPIs
"native" kernel. You must do and maintain these changes for each
host kernel you select. It's not marketing which says that in
terms of overall effort VPC and VMWare offer a technical advantage
relative to ongoing development and maintenance of the internal
processing logic supporting the CPAPI layer across multiple host
OSes.

"... OK, you opt to set a GA where the kernel will be better at
running Windows apps than Windows is. With the right development
methods and aiming at the starts we could easily beat Microsofts
hoards of money and developers - right ? ..."

Yes.<g> And IBM as well. I'm not arguing that they have hoards
of both, but I will argue that they require them due to their
methods of implementation in turn due to the limitations, the
restrictions, of their tools. If you want to play their game
their way, then you too will require hoards.

As I don't have the hoards nor the means to attract them except
over an extended period of time, in the interim I have to do more
with less. It's an issue of productivity, yours, mine, and
whoever else decides to join in this venture. That productivity
lies largely in the tools we use. They determine how large our
hoard must be to do X amount of work in Y time.

I will tell you that the one tool I don't want to use is a batch
compiler. I don't care if it is free, it costs too much. I will
tell you that the edit-compile-execute paradigm of each as
separate, sequential, processes is less than optimum. It doesn't
take much to see that I prefer an interactive interpreter, one,
which gives me immediate syntax, semantic, and completeness
results for each input statement, and, two, offers me the option
to compile separate executables from the same source.

That tool doesn't exist today. I don't want to get into that
argument which is a separate discussion. What I do want to
emphasize is that I haven't attacked this in any piecemeal
fashion. Instead I have attacked it systemically, bringing all
the pieces into a seamless whole. Basically the approach is to do
more with software and less with people. If sufficiently
successful, if you bring that number down significantly, say to
1/200th of the number currently, then not only do the hoards of
people disappear, the money necessary to support them, but also
the organizations relying on them, e.g. Microsoft.

When a hoard ceases to be an advantage by becoming a disadvantage,
when large numbers is an economical handicap, then small numbers
will prevail, resulting in the large adopting (in order to
survive) the business model of the small. However, this is a
separate issue from one of design of a microkernel supporting an
existing set of OS personalities (CPAPIs) and their writing.

"... Now you are contradiction yourself. By placing a CPAPI layer
ontop another kernel than OS/2 you say I opt for a less than
optimal solution. Now you say that Linux and Windows (poss. BeOS)
developers will flock around your proposed os since it will be so
much better that what they have today. How are you going to ensure
that four operating systems get a perfect kernel that matches
there "CPAPI's so good that its better than their existion
solutions.

To do this you either have to write in support for many different
OS'es in the kernel or you have to make OS layers that maps to a
generic set of kernel support. And you will come up with things
that would conflict between the "personalities". What OS to
prefere then ? ..."

Well, if I get caught in a contradiction, I will have to admit to
it. However, first you have to catch me.<g>

Can I have a generic set of lowest level APIs that match existing
OS CPAPIs perfectly? Yes. I have to do no more than aggregate
the set of lowest level APIs for each. To the degree that they
differ the aggregate, which is now available to each, exceeds the
existing OS functionality. So, yes, the OS personality (the
remainder of the kernel) will not have to map to a new lowest
level, which may frequently be no more than name change.

You see, where can these different OSes differ to account for
advantages and disadvantages (deficiencies) of one over the other
that appears in these discussions? It is either in the interface
(and thus functional) possibilities of the APIs or in their
internal logic. If I grant the "constancy" of a specific CPAPI to
protect existing application investments, then improvements either
lie in the underlying logic or in increasing its set of APIs to
take advantage of newer functionality. Certainly this is easier
for any OS personality if the functionality is already supported
at the lowest level.

If you assume (as I do) that a vast amount of intellect (the
application of intelligence) has already created a large body of
knowledge, much of which has been empirically proven, then you
have no reason to believe that some sort of gap or break exists
between various proposed microkernels (lowest level APIs) and
different CPAPIs.

You have no reason, for example, to believe that the microkernel
that IBM used in OS/2 for the PPC was not sufficient functionally
as in fact it was. Just because IBM aborted this effort for other
than technical reasons does not mean the same microkernel would
not suffice for Linux, Windows, and BeOS. Frankly we don't give a
damn about how IBM did the inbetween APIs. If we have the lowest
level and the CPAPI level, then we can produce an optimum
inbetween set of APIs. We're not even sure that IBM did that.

This approach doesn't favor OS/2 over any other OS. It doesn't
disallow our continued use of OS/2 while providing access to
applications and drivers written for other OSes. It doesn't say
that one is better than another, only that a particular
implementation is best. It does say that what is available to one
is in some manner available to all.

I am a happy, contented OS/2 user with less reliance today on
non-OS/2 applications than previously. I still have my standby
DOS apps whose vendors has long since disappeared. I expect this
200MHz Pentium Pro system (and the two others exactly like it)
will last longer than I do and that this reliable OS/2 will
continue to run long after I do as well.

So I don't feel the need freeos or osfree to the extent that
others do to escape the yolk of IBM or Microsoft. I've
escaped.<g> But if someone is really interested in a no
compromise, high-performance, low resource usage, highest quality,
highest reliability, universal OS, be aware that it certainly is
possible. Though it doesn't particularly speak to any special
need of mine, except possibly intellectually, I'm more than
willing to participate and show that it is possible to have the
best without compromise.

Re: Part 13

Posted: Sat Dec 22, 2018 12:36 am
by admin
#389 Re: [osFree] # 29 - a kernel which is second to none
Expand Messages

Seth
Mar 14, 2002

> From: "Lynn H. Maxson" <lmaxson@...>
>Subject: Re: Kernel/mikrokernel architecture
>

edt edit edit

>
>Apparently only Gregory L. Marx thought my previous response in
>this area was worthwhile. In this instance I do not know when
>large enough is large enough. I do know it is a much larger
>number when it is a layer adapted to multiple kernels.

This discussion is way above my head - but I liked what I read
from Lynn Maxson about doing all the hard work upfront and
letting the tools do code writing.

edit edit edit

>I do know that it is
>possible to build a kernel which is second to none. It doesn't
>make much sense to me to build one to any other standard. No one
>I've read in this list believes that all kernels are created
>equal.

This is my expertise. I am an end-user. I would buy an OS that
was a better OS/2 than OS/2. And I don't mean one that changes
the fundamental way OS/2 behaves. But one that keeps the best
parts, and improves the weaker parts. A clone of OS/2 that is
better than the original - why not? It would be the OS/2 we
would have had if IBM had done things differently. Maybe even
better, since some things would be looked at with wisedom of
hindsight.

For **commercial** success, it must be able to run MS Office
flavour of the month. Until an alternative OS does that, it
will always be relegated to the "niche" market, and an academic
exercise. Build an OS that can run Office (even a year old
version) and you have an opening into the small/mid size
business market. Teh market that will pay for support. Capture
even the percent of desktops that Linux has, and you will
rejuvenate the OS/ 2 App market. Put together just the
framework of a technologically advanced OS, and you will get
some Linux developers interested. Put together an OS that runs
Windows, Linux, and OS/2 applications and you have a potential
commercial success. I am sure there are a number of Linux
developers who would love to have a 2nd chance at an OS, now
that they have learned what works and what doesn't.

And the best part is - if I understand Intellectual Property
laws - if it isn't an attempt to recreate OS/2 itself, then many
of the otherwise excluded IBMers can participate.

>
>So therefore why not have a better OS/2 than OS/2, Linux than
>Linux, and Windows than Windows? Why not have it in a single
>package for much the same reason it became the slogan for OS/2
>2.0?


Why not indeed?

Seth

(more message edited out)

Re: Part 13

Posted: Sat Dec 22, 2018 12:37 am
by admin
#390 Re: [osFree] Kernel/mikrokernel architecture
Expand Messages

JMA
Mar 14, 2002
On Thu, 14 Mar 2002 09:12:59 -0800 (PST), Lynn H. Maxson wrote:

>John Martin (JMA) writes:
>"... Please read up on what a microkernel does ! ..."
>
>You raise a host of issues. It's hard to select one from the
>remainder fall into line. Let's try it with this one.
>
>What does a microkernel do. We agree that it "isolates" the
>higher level functions from the hardware. I think we also agree
>that it provides a form of "software isolation", e.g. IPC
>(Inter-Process Communication). In all likelihood we agree the
>microkernel provides the lowest level APIs (functions) ultimately
>required by the higher level layer represented by the CPAPI.
>

Well you seem to miss the kernel itself thats between the mk
and the user mode layer (in OS/2 cpapi).
Sure you could put IPC in the microkernel (in what way does IPC
mean "software isolation" ?) but a mk is about hardware isolation.


<SNIP>

>You can safely say then that this lowest level set of leaves
>represents the minimal number of sub-routines necessary for the
>proper support of all higher level routines and sub-routines. As
>a minimal number within an OS kernel it represents a microkernel.
>

No, a microkernel is there to hide the hardware differences from the
real kernel. For example OS/2 PPC ran on both PPC and Intel and
the mk part was there to hide the differences between the intel
processor and PPC processors from the kernel.

You may use another definition of a mk but that would only help to
confuse people.


>"... You cannot technically compare a product like VPC or VMWARE
>to a proposion to place a CPAPI layer ontop another kernel.
>Or are we talking marketing ? ..."
>
>Yes, I can because they differ technically. I can compare the
>effect, particularly with respect to ongoing development and
>maintenance. Neither requires physical modification of an
>executable OS nor any changes of logic below the CPAPI layer to
>map into the host kernel.
>

So you compare their differences ?

VPC simulates hardware, Odin and a CPAPI layer lives ontop of
an existion OS (software).

How would this relate to "write the whole thing including the OS"
versis "write an OS plugin ontop an existing kernel".


>You cannot place a CPAPI layer on top
>of another kernel without changing at least the internal logic and
>APIs due to the differences in API name, number, order, and type
>of parameters, and functionality between it and the CPAPIs
>"native" kernel. You must do and maintain these changes for each
>host kernel you select. It's not marketing which says that in
>terms of overall effort VPC and VMWare offer a technical advantage
>relative to ongoing development and maintenance of the internal
>processing logic supporting the CPAPI layer across multiple host
>OSes.
>

VPC runs an existing OS on a hardware emulation (done in software).
To run Windows NT applications on VPC you have to load the full
Windows NT package inside VPC.

Now, I do agree that running your shrinkwrapped OS/2 ontop VPC
offers advantages compared to doing your own OS or placing a
usermode layer on another OS.

But VPC is about legacy support. It will never allow you to change
anything since it runs binary copies of an existing OS.

As long as your only interest is legacy support then VPC is great.
If you want to change anything VPC is out of the question.



>"... OK, you opt to set a GA where the kernel will be better at
>running Windows apps than Windows is. With the right development
>methods and aiming at the starts we could easily beat Microsofts
>hoards of money and developers - right ? ..."
>
>Yes.<g> And IBM as well. I'm not arguing that they have hoards
>of both, but I will argue that they require them due to their
>methods of implementation in turn due to the limitations, the
>restrictions, of their tools. If you want to play their game
>their way, then you too will require hoards.
>

This is rubbish. So there is a much better way to develop software
around and the biggest companies in the world dont use it.
Now why dont they use it ?

Neither IBM nor MS are dumb, there has to be a catch.


>So I don't feel the need freeos or osfree to the extent that
>others do to escape the yolk of IBM or Microsoft. I've
>escaped.<g> But if someone is really interested in a no
>compromise, high-performance, low resource usage, highest quality,
>highest reliability, universal OS, be aware that it certainly is
>possible. Though it doesn't particularly speak to any special
>need of mine, except possibly intellectually, I'm more than
>willing to participate and show that it is possible to have the
>best without compromise.
>

Sure its possible. But my needs are more modest. Whatever
wiz-bang kernel we develop will not help building a PM or
WPS clone faster. For underlying stuff they use the CPAPI
and it would not matter if this CPAPI was grafted ontop
another OS, ontop of the OS you suggest nor ontop of
the binary Warp distro, it still has to be developed.

Please join the FreeOS group and do the wiz-bang kernel
and later we can join forces to place osFree ontop of
that kernel.








Sincerely

JMA
Development and Consulting

John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================