#641 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Mar 4, 2003 5:28 pm
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I would normally not reply to a post here on osFree as I have
opted for "lurker status" only. The difference between
Freeos and osFree as I understand it depends on which side of
the OS/2 APIs you stand, above the APIs (osFree) or below
(Freeos). That difference grew out of the discussion
revolving about which kernel approach to use, a microkernel
or a layered approach in this instance above Linux.
I'm hoping that the experience of VPC, Lindows, Codeweavers,
WINE, and ODIN, all of which essentially take a layered
approach, would cause a reconsideration of the microkernel.
My only unresolved question of the microkernel revolves
around the issue of presentation services, given the different
GUIs of the OS personalities. Once that is resolved to my
satisfaction I fully intend to pursue developing an OS/2 kernel
based upon a microkernel.
At that point I will look in more detail at the ReactOS effort.
In the meantime I am pursuing improving the emx-gcc toolset
in terms of ease of use, enhanced functionality, and reduction
of separate tools through integration. As this is occurring
within a SCOUG programming group results will appear from
that website (www.scoug.com) and ongoing discussion
through the scoug-programming mailing list.
I think we are experiencing one of challenges to open source,
that of creating and sustaining momentum in a volunteer
effort. We are fortunate for those projects which have
progressed thus far.
Part 22 - Jan 26 2003
Re: Part 22
#642 From: Ben Ravago <ben.ravago@...>
Date: Tue Mar 4, 2003 6:04 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> Once that is resolved to my satisfaction I fully intend to pursue
> developing an OS/2 kernel based upon a microkernel.
Have you taken a look at the L4 microkernel. There seems to be
some movement there. See www.l4ka.org (there are other projects
as well). I'm waiting to see what framework they'll come up
with for device drivers. Other projects (l4-hurd) have suggestions
on this.
Date: Tue Mar 4, 2003 6:04 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> Once that is resolved to my satisfaction I fully intend to pursue
> developing an OS/2 kernel based upon a microkernel.
Have you taken a look at the L4 microkernel. There seems to be
some movement there. See www.l4ka.org (there are other projects
as well). I'm waiting to see what framework they'll come up
with for device drivers. Other projects (l4-hurd) have suggestions
on this.
Re: Part 22
#643 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Mar 4, 2003 6:54 pm
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"Have you taken a look at the L4 microkernel. There seems to
be some movement there. See www.l4ka.org (there are other
projects as well). I'm waiting to see what framework they'll
come up with for device drivers. Other projects (l4-hurd) have
suggestions on this. ..."
I have bookmarked the site and will pursue it further. As
stated earlier I have no doubts about the microkernel and
haven't since IBM introduced OS/2 for the PPC. In studying the
architecture I have no doubt it will support any OS personality
and multiple personalities concurrently. I have doubts about
the presentation services, those which supply the GUI
interface. How do you present them in native form
concurrently?
Moreover I don't believe in getting people started down a path
which they can neither complete nor sustain. The industry
has been plagued by its inability to have software maintain
pace with the dynamics of the user environment. You can
through essentially unlimited amounts of money and people at
it without maintaining pace. Among other reasons IBM
dropped back its support of OS/2 because its investment in
money and people cost more than in revenue it produced.
Open source has neither the funds nor the fulltime people to
maintain the pace of closed source, which itself cannot
maintain pace with the dynamics.
The problem lies with the tool set. The same tool set that we
use for productivity also restricts its level that we can
achieve. Both open source and closed source have the same
tool set available. Neither regardless of money or people can
maintain pace with the dynamics of the user environment.
For that reason it doesn't do me or anyone else any good to
know that a certain approach like the microkernel plus
multiple OS personalities works, if, one, I can't get it to work
within a reasonable (and competitive) time interval, and, two,
if I can get it to work but cannot sustain it competitively to
maintain pace with user dynamics.
Microsoft can't do it. IBM can't do it. Linux can't do it. UNIX
can't do it. Take your choice of enterprise IT staffs: they
can't do it. They all have increasing backlogs of changes.
"Increasing" means that they fall further and further behind.
For open source with parttime volunteer resources you simply
compound the problem. If unlimited money and people cannot
do the job, having less of either means falling behind faster.
You can surf the internet to your heart's content. You find
hundreds and thousands of projects all hitting the same
productivity barrier.
I want open source to succeed competitively against closed on
the basis of something other than the price charged the end
user: free. To do that its productivity has to increase
significantly. The problem is that any increase it effects
applies equally to closed source. Continuing to increase
productivity for either open or closed source means lowering
the cost of software, of making it more affordable, i.e. closer
to free. It also means at some point of keeping pace with the
dynamics of the environment.
At the moment I'm focused on improving the tool set,
beginning with emx-gcc.
Date: Tue Mar 4, 2003 6:54 pm
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"Have you taken a look at the L4 microkernel. There seems to
be some movement there. See www.l4ka.org (there are other
projects as well). I'm waiting to see what framework they'll
come up with for device drivers. Other projects (l4-hurd) have
suggestions on this. ..."
I have bookmarked the site and will pursue it further. As
stated earlier I have no doubts about the microkernel and
haven't since IBM introduced OS/2 for the PPC. In studying the
architecture I have no doubt it will support any OS personality
and multiple personalities concurrently. I have doubts about
the presentation services, those which supply the GUI
interface. How do you present them in native form
concurrently?
Moreover I don't believe in getting people started down a path
which they can neither complete nor sustain. The industry
has been plagued by its inability to have software maintain
pace with the dynamics of the user environment. You can
through essentially unlimited amounts of money and people at
it without maintaining pace. Among other reasons IBM
dropped back its support of OS/2 because its investment in
money and people cost more than in revenue it produced.
Open source has neither the funds nor the fulltime people to
maintain the pace of closed source, which itself cannot
maintain pace with the dynamics.
The problem lies with the tool set. The same tool set that we
use for productivity also restricts its level that we can
achieve. Both open source and closed source have the same
tool set available. Neither regardless of money or people can
maintain pace with the dynamics of the user environment.
For that reason it doesn't do me or anyone else any good to
know that a certain approach like the microkernel plus
multiple OS personalities works, if, one, I can't get it to work
within a reasonable (and competitive) time interval, and, two,
if I can get it to work but cannot sustain it competitively to
maintain pace with user dynamics.
Microsoft can't do it. IBM can't do it. Linux can't do it. UNIX
can't do it. Take your choice of enterprise IT staffs: they
can't do it. They all have increasing backlogs of changes.
"Increasing" means that they fall further and further behind.
For open source with parttime volunteer resources you simply
compound the problem. If unlimited money and people cannot
do the job, having less of either means falling behind faster.
You can surf the internet to your heart's content. You find
hundreds and thousands of projects all hitting the same
productivity barrier.
I want open source to succeed competitively against closed on
the basis of something other than the price charged the end
user: free. To do that its productivity has to increase
significantly. The problem is that any increase it effects
applies equally to closed source. Continuing to increase
productivity for either open or closed source means lowering
the cost of software, of making it more affordable, i.e. closer
to free. It also means at some point of keeping pace with the
dynamics of the environment.
At the moment I'm focused on improving the tool set,
beginning with emx-gcc.
Re: Part 22
#644 From: Ben Ravago <ben.ravago@...>
Date: Tue Mar 4, 2003 8:43 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> I have doubts about the presentation services,
> those which supply the GUI interface. How do
> you present them in native form concurrently?
I'm not sure what you mean by "native form".
As for L4, since it's just the microkernel
there isn't an internal GUI service. The
various L4 projects also don't seem to have
a preference. The Linux oriented ones will
probably just start an X-server. A similar
approach would probably be appropriate in a
mk environment; something that might be called
a "Human Interface" server (not necessarily X).
Also, the l4hurd link is http://www.nongnu.org/l4hurd.
There are references here to some work being done
on a "Device Driver Environment".
I agree with you about the toolchain thing. There are a lot of
readily available technologies on the net and if it really was
just "a small matter of programming", then lots of things
would be done already. It's like a mosaic: there are lots of
bits and pieces lying around, it's the gluing them together
that takes time.
Date: Tue Mar 4, 2003 8:43 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> I have doubts about the presentation services,
> those which supply the GUI interface. How do
> you present them in native form concurrently?
I'm not sure what you mean by "native form".
As for L4, since it's just the microkernel
there isn't an internal GUI service. The
various L4 projects also don't seem to have
a preference. The Linux oriented ones will
probably just start an X-server. A similar
approach would probably be appropriate in a
mk environment; something that might be called
a "Human Interface" server (not necessarily X).
Also, the l4hurd link is http://www.nongnu.org/l4hurd.
There are references here to some work being done
on a "Device Driver Environment".
I agree with you about the toolchain thing. There are a lot of
readily available technologies on the net and if it really was
just "a small matter of programming", then lots of things
would be done already. It's like a mosaic: there are lots of
bits and pieces lying around, it's the gluing them together
that takes time.
Re: Part 22
#645 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Mar 4, 2003 10:02 pm
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I'm not sure what you mean by "native form".
As for L4, since it's just the microkernel
there isn't an internal GUI service. The
various L4 projects also don't seem to have
a preference. ..."
The operative word in operating system is "system", which
implies a whole at least equal to if not greater than the sum
of its parts. It makes no sense to me for other than the
experience gained to tackle a piece of the project without
some reasonable assurance of it as a whole. The goal here
lies in succeeding. Specifically the goal with the mk lies with
providing a common environment to have multiple OS
personalities executing concurrently through a common GUI
interface, the presentation services.
Every example you offer deals with the one issue of the mk
or kernel, but studiously avoids the other. Yet both are
needed if either is to work successfully. It does no good to
offer a common internal kernel, the microkernel, that will
support multiple OS personalities, if in fact the presentation
services will not.
The question remains open as we have yet to have a project
get to the point of providing multiple OS personalities with
different GUI requirements. Someone may have demonstrated
it with Linux (or UNIX) on an Intel platform with either OS/2 or
Windows. I have seen no evidence of that.
Niggling at the back of my mind lies IBM's experience with
OS/2 for the PPC. It's not clear to me whether or not the
source code was 100% IBM and why they did not offer a Intel
version of it. More to the point, if you cannot resolve the
presentation services issues, then you don't need a
microkernel as in practice you cannot execute multiple OS
personalities concurrently. In short why develop something
which allows a capability you cannot in practice achieve?
"I agree with you about the toolchain thing. There are a lot
of readily available technologies on the net and if it really
was just "a small matter of programming", then lots of things
would be done already. It's like a mosaic: there are lots of
bits and pieces lying around, it's the gluing them together
that takes time."
Actually it's not that difficult in terms of programming. You
end up with one tool in one language with no ability to impose
proprietary functions, source, or interfaces. That means
every vendor has to produce the same product and remain
competitive in terms of functional capability. When IBM tried a
lesser attempt with AD/Cycle among the supposedly
"cooperating" set of vendors, every one of them waited for a
competitor to cut his throat first.<g>
If you have a well-defined process with a single set of
seamless interfaces among its activities, you don't need more
than a single user interface with more than one tool. If you
can take an editor and convert it into a "smart" editor
providing syntax checking with colorization, it is but a step to
provide full semantic checking, and then code generation.
That's what an interpreter does now. What an interpreter
doesn't produce is standalone executable code. It ought to be
clear that if you can "tell" an editor whether or not to
perform syntax and semantic checking, when it comes to code
generation you ought to be able to tell it what form of
executable you desire, interpretive or standalone. You have
code generators for either.
If you take your C compiler, make it multiple pass instead of
single, you eliminate a lot of unnecessary statement writings.
If you take the same compiler, allow it to accept multiple
external procedures on input, then you eliminate the need for
internal procedures entirely. Furthermore with these two
changes you can, one, input the procedures in any order as
the software through the internal API reference pattern will
determine the hierarchy, and, two input an unlimited number
of "main" procedures, thus compile an entire application
system of programs as a single unit of work.
This last eliminates the need to synchronize global changes
manually through a set of compiles. It also means that you
have all source for all programs within the scope of semantic
analysis at the same time. It also means that you can have a
visual output of each "main" routine hierarchy.
Moreover if you allow the software to organize the source,
the common activity within the completeness proof of logic
programming, once organized internally you can then produce
all the output forms say of UML. That means you do not
require a separate source for each UML form you maintain.
The point is you will find no vendor, not even IBM with its
purchase of Rational software and its tools, taking it to this
level. To do so would be committing enterprise suicide. You
will not only fail to make a profit, but you will at the same
automatically decrease your marketplace.
That's why I submit that no vendor can make a profit offering
such a tool; only users in using it. Thus users should become
their own tool vendor, guaranteeing that each gains from the
open source contributions from another.
The reason it hasn't happened is not any excessive effort in
doing it, but the economic consequences occurring after
delivery. Those economic consequences spell disaster for the
vendors however they profit the users. You do not go into
business to have your actions take you out of it.<g>
Date: Tue Mar 4, 2003 10:02 pm
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I'm not sure what you mean by "native form".
As for L4, since it's just the microkernel
there isn't an internal GUI service. The
various L4 projects also don't seem to have
a preference. ..."
The operative word in operating system is "system", which
implies a whole at least equal to if not greater than the sum
of its parts. It makes no sense to me for other than the
experience gained to tackle a piece of the project without
some reasonable assurance of it as a whole. The goal here
lies in succeeding. Specifically the goal with the mk lies with
providing a common environment to have multiple OS
personalities executing concurrently through a common GUI
interface, the presentation services.
Every example you offer deals with the one issue of the mk
or kernel, but studiously avoids the other. Yet both are
needed if either is to work successfully. It does no good to
offer a common internal kernel, the microkernel, that will
support multiple OS personalities, if in fact the presentation
services will not.
The question remains open as we have yet to have a project
get to the point of providing multiple OS personalities with
different GUI requirements. Someone may have demonstrated
it with Linux (or UNIX) on an Intel platform with either OS/2 or
Windows. I have seen no evidence of that.
Niggling at the back of my mind lies IBM's experience with
OS/2 for the PPC. It's not clear to me whether or not the
source code was 100% IBM and why they did not offer a Intel
version of it. More to the point, if you cannot resolve the
presentation services issues, then you don't need a
microkernel as in practice you cannot execute multiple OS
personalities concurrently. In short why develop something
which allows a capability you cannot in practice achieve?
"I agree with you about the toolchain thing. There are a lot
of readily available technologies on the net and if it really
was just "a small matter of programming", then lots of things
would be done already. It's like a mosaic: there are lots of
bits and pieces lying around, it's the gluing them together
that takes time."
Actually it's not that difficult in terms of programming. You
end up with one tool in one language with no ability to impose
proprietary functions, source, or interfaces. That means
every vendor has to produce the same product and remain
competitive in terms of functional capability. When IBM tried a
lesser attempt with AD/Cycle among the supposedly
"cooperating" set of vendors, every one of them waited for a
competitor to cut his throat first.<g>
If you have a well-defined process with a single set of
seamless interfaces among its activities, you don't need more
than a single user interface with more than one tool. If you
can take an editor and convert it into a "smart" editor
providing syntax checking with colorization, it is but a step to
provide full semantic checking, and then code generation.
That's what an interpreter does now. What an interpreter
doesn't produce is standalone executable code. It ought to be
clear that if you can "tell" an editor whether or not to
perform syntax and semantic checking, when it comes to code
generation you ought to be able to tell it what form of
executable you desire, interpretive or standalone. You have
code generators for either.
If you take your C compiler, make it multiple pass instead of
single, you eliminate a lot of unnecessary statement writings.
If you take the same compiler, allow it to accept multiple
external procedures on input, then you eliminate the need for
internal procedures entirely. Furthermore with these two
changes you can, one, input the procedures in any order as
the software through the internal API reference pattern will
determine the hierarchy, and, two input an unlimited number
of "main" procedures, thus compile an entire application
system of programs as a single unit of work.
This last eliminates the need to synchronize global changes
manually through a set of compiles. It also means that you
have all source for all programs within the scope of semantic
analysis at the same time. It also means that you can have a
visual output of each "main" routine hierarchy.
Moreover if you allow the software to organize the source,
the common activity within the completeness proof of logic
programming, once organized internally you can then produce
all the output forms say of UML. That means you do not
require a separate source for each UML form you maintain.
The point is you will find no vendor, not even IBM with its
purchase of Rational software and its tools, taking it to this
level. To do so would be committing enterprise suicide. You
will not only fail to make a profit, but you will at the same
automatically decrease your marketplace.
That's why I submit that no vendor can make a profit offering
such a tool; only users in using it. Thus users should become
their own tool vendor, guaranteeing that each gains from the
open source contributions from another.
The reason it hasn't happened is not any excessive effort in
doing it, but the economic consequences occurring after
delivery. Those economic consequences spell disaster for the
vendors however they profit the users. You do not go into
business to have your actions take you out of it.<g>
Re: Part 22
#646 From: Ben Ravago <ben.ravago@...>
Date: Tue Mar 4, 2003 10:59 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> Specifically the goal with the mk lies with
> providing a common environment to have multiple OS
> personalities executing concurrently through a common GUI
> interface, the presentation services.
I take it you mean that there should be a presentation
system server on par with, say, a file system server.
I think this is where the Unix type microkernels fall
short, too, since most seem to be X oriented and so
would have the presentation services running on top
of an OS personality.
Date: Tue Mar 4, 2003 10:59 pm
Subject: Re: Re: Once a Month Progress Report? ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> "Lynn H. Maxson" wrote:
>
> Specifically the goal with the mk lies with
> providing a common environment to have multiple OS
> personalities executing concurrently through a common GUI
> interface, the presentation services.
I take it you mean that there should be a presentation
system server on par with, say, a file system server.
I think this is where the Unix type microkernels fall
short, too, since most seem to be X oriented and so
would have the presentation services running on top
of an OS personality.
Re: Part 22
#647 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Mar 5, 2003 4:58 am
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I take it you mean that there should be a presentation
system server on par with, say, a file system server.
I think this is where the Unix type microkernels fall
short, too, since most seem to be X oriented and so
would have the presentation services running on top
of an OS personality."
If that's the way it works, then I agree. If it turns out that the
presentation services provide a compatibility issue for multiple
OS personalities to execute concurrently off a microkernel
base, then we can challenge at least one of its early promises.
Until we have some means of determining whether this works
or not, I don't want to engage people to pursue a path,
promising something we cannot deliver. You can't tout
microkernel over any other if in the end you have the same
limitations.
Date: Wed Mar 5, 2003 4:58 am
Subject: Re: Re: Once a Month Progress Report? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I take it you mean that there should be a presentation
system server on par with, say, a file system server.
I think this is where the Unix type microkernels fall
short, too, since most seem to be X oriented and so
would have the presentation services running on top
of an OS personality."
If that's the way it works, then I agree. If it turns out that the
presentation services provide a compatibility issue for multiple
OS personalities to execute concurrently off a microkernel
base, then we can challenge at least one of its early promises.
Until we have some means of determining whether this works
or not, I don't want to engage people to pursue a path,
promising something we cannot deliver. You can't tout
microkernel over any other if in the end you have the same
limitations.
Re: Part 22
#648 From: "Thomas Lee Mullins" <jerseywarp@...>
Date: Wed Mar 5, 2003 4:32 pm
Subject: Re: Once a Month Progress Report? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> Also, the l4hurd link is http://www.nongnu.org/l4hurd.
> There are references here to some work being done
> on a "Device Driver Environment".
>
I received a not found error message when I clicked
on the above.
TomLeeM
Date: Wed Mar 5, 2003 4:32 pm
Subject: Re: Once a Month Progress Report? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> Also, the l4hurd link is http://www.nongnu.org/l4hurd.
> There are references here to some work being done
> on a "Device Driver Environment".
>
I received a not found error message when I clicked
on the above.
TomLeeM
Re: Part 22
#649 From: "Thomas Lee Mullins" <jerseywarp@...>
Date: Wed Mar 5, 2003 4:34 pm
Subject: OSFree and MicroWindows or MiniGui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Could one use a version of MicroWindows or
MiniGui with OSFree? They are open source
projects (use the source code and adapt it to
create a version of or an alternative to
presentation manager?).
http://www.microwindows.org
http://www.minigui.org
TomLeeM
Date: Wed Mar 5, 2003 4:34 pm
Subject: OSFree and MicroWindows or MiniGui? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Could one use a version of MicroWindows or
MiniGui with OSFree? They are open source
projects (use the source code and adapt it to
create a version of or an alternative to
presentation manager?).
http://www.microwindows.org
http://www.minigui.org
TomLeeM
Re: Part 22
#650 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Mar 5, 2003 6:49 pm
Subject: Re: [freeos] MicroWindows or MiniGUI with FreeOS? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Thomas Lee Mullins writes:
"Could one use a version of MicroWindows or
MiniGui with FreeOS? They are open source
projects (use the source code and adapt it to
create a version of or an alternative to
presentation manager?). ..."
You have the need to offer a version of OS/2 whose
applications execute concurrently with those of another OS
like Windows or Linux or both. To do this with a layered
approach with OS/2 as a guest OS above a host means
maintaining this layer across changes occurring within possibly
two hosts. Regardless of the frequent porting of applications
from Linux to OS/2, the same application must be ported
multiple times, e.g. emx-gcc. Other than VPC no one has
offered the ability to run OS/2 applications on a Windows host.
Now the microkernel, a common set of lowest level kernel
functions on which all higher level rely, offers a different
form of a layered approach in which OS personalities, i.e. host
OSes, execute side-by-side. In such an approach no dual
maintenance occurs as each host environment exists
independently of each other. You largely reduce even the
need for porting applications. Clearly in terms of total overall
effort the microkernel approach requires less to develop and
considerably less to maintain.
The other common component associated with the
microkernel approach is the presentation services, supporting
a GUI like PM. It also has the need support a desktop layer
like WPS based on PM. It has the need to support these two
hierarchically related layers concurrently with equivalents for
any other OS personality.
Plausibly a similar microkernel approach would work here,
providing a lowest level base on which to build the two
hierarchical levels like PM and WPS. The question remains,
"How would they work concurrently on a single display unit?"
You need to answer that before you invest in the effort
leading up to it. Remember neither Linux nor Windows has a
requirement to support another OS's applications or device
drivers. This does no say that Linux would not like the same
support of both as Windows. It does say that it is OS/2 that
has the "drastic" need. The general feeling is that OS/2 must
"partner" in order to survive.
Your mention of MicroWindows or MiniGUI as an open source
alternative to PM and possibly WPS doesn't address the larger
need for concurrency within a presentation service. For that
we don't know, one, if such is possible, or, two, if possible,
what operational constraints apply. For example, does it
mean that we can have a common desktop or must the user
switch among individual desktops of the various OS
personalities.
Remember the issue is not simply having an open source
replacement for OS/2 which basically includes all that comes
with an IBM OS/2 package, something considerably larger than
a kernel, PM, and WPS, but having one which at the same time
addresses the ability to use the applications and device
drivers of other Intel-based OSes.
Window's users don't have these concerns. They find it
complicated enough without wanting to run to some solution
even more complicated. Linux users to a lesser extent don't
have these concerns. They need more users and are actively
engaged in producing a less complicated desktop solution.
OS/2 users do have these concerns in spades.<g> They need
to make it attractive for Linux and Windows users to come to
their solution.
So you need a better Linux than Linux, Windows than
Windows, and OS/2 than OS/2. Before you undertake an
extensive effort toward an open source OS/2 "package" you
better make sure that you can offer a "better" solution that
will attract other OS users. Otherwise you will place open
source volunteer resource demands on an ever dwindling
population. The fewer you have the longer it will take and
the more likely ultimate failure.
osfree participants argued over which layering approach to
take, that of a microkernel or that of a guest OS on top of a
host. That lead to dividing the OS/2 "package" in two levels,
one below the API and one above. Furthermore those who
favored participating in the above reacted negatively to the
below participants continually engaging in seemingly endless
discussions without actually "doing" anything. Being "doers"
themselves they set up osfree. The talkers remained in
freeos and the doers in osfree.
For reasons not clear to me the talkers now free of the
chastisement of the doers ceased talking and the doers, of
course, didn't want to talk in the first place.<g> Personally
osfree even if it succeeds fails while freeos fails if it doesn't
succeed with the microkernel and the presentation services.
In short osfree's success depends upon that of freeos. The
failure of freeos dooms osfree.
In truth I don't have an answer which covers in necessary
detail all of the above. I don't know how to get the answer
except through a continuing discovery process accompanied
by a peer review through discussions. Basically I do little
surfing of the internet as I do have other lives requiring time
on their own. I rely on others who have more time to devote
to such efforts. I will make time to participate in the needed
discussions to have a detailed conceptual and practical
solution that leads to a better OS environment for all users.
Date: Wed Mar 5, 2003 6:49 pm
Subject: Re: [freeos] MicroWindows or MiniGUI with FreeOS? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Thomas Lee Mullins writes:
"Could one use a version of MicroWindows or
MiniGui with FreeOS? They are open source
projects (use the source code and adapt it to
create a version of or an alternative to
presentation manager?). ..."
You have the need to offer a version of OS/2 whose
applications execute concurrently with those of another OS
like Windows or Linux or both. To do this with a layered
approach with OS/2 as a guest OS above a host means
maintaining this layer across changes occurring within possibly
two hosts. Regardless of the frequent porting of applications
from Linux to OS/2, the same application must be ported
multiple times, e.g. emx-gcc. Other than VPC no one has
offered the ability to run OS/2 applications on a Windows host.
Now the microkernel, a common set of lowest level kernel
functions on which all higher level rely, offers a different
form of a layered approach in which OS personalities, i.e. host
OSes, execute side-by-side. In such an approach no dual
maintenance occurs as each host environment exists
independently of each other. You largely reduce even the
need for porting applications. Clearly in terms of total overall
effort the microkernel approach requires less to develop and
considerably less to maintain.
The other common component associated with the
microkernel approach is the presentation services, supporting
a GUI like PM. It also has the need support a desktop layer
like WPS based on PM. It has the need to support these two
hierarchically related layers concurrently with equivalents for
any other OS personality.
Plausibly a similar microkernel approach would work here,
providing a lowest level base on which to build the two
hierarchical levels like PM and WPS. The question remains,
"How would they work concurrently on a single display unit?"
You need to answer that before you invest in the effort
leading up to it. Remember neither Linux nor Windows has a
requirement to support another OS's applications or device
drivers. This does no say that Linux would not like the same
support of both as Windows. It does say that it is OS/2 that
has the "drastic" need. The general feeling is that OS/2 must
"partner" in order to survive.
Your mention of MicroWindows or MiniGUI as an open source
alternative to PM and possibly WPS doesn't address the larger
need for concurrency within a presentation service. For that
we don't know, one, if such is possible, or, two, if possible,
what operational constraints apply. For example, does it
mean that we can have a common desktop or must the user
switch among individual desktops of the various OS
personalities.
Remember the issue is not simply having an open source
replacement for OS/2 which basically includes all that comes
with an IBM OS/2 package, something considerably larger than
a kernel, PM, and WPS, but having one which at the same time
addresses the ability to use the applications and device
drivers of other Intel-based OSes.
Window's users don't have these concerns. They find it
complicated enough without wanting to run to some solution
even more complicated. Linux users to a lesser extent don't
have these concerns. They need more users and are actively
engaged in producing a less complicated desktop solution.
OS/2 users do have these concerns in spades.<g> They need
to make it attractive for Linux and Windows users to come to
their solution.
So you need a better Linux than Linux, Windows than
Windows, and OS/2 than OS/2. Before you undertake an
extensive effort toward an open source OS/2 "package" you
better make sure that you can offer a "better" solution that
will attract other OS users. Otherwise you will place open
source volunteer resource demands on an ever dwindling
population. The fewer you have the longer it will take and
the more likely ultimate failure.
osfree participants argued over which layering approach to
take, that of a microkernel or that of a guest OS on top of a
host. That lead to dividing the OS/2 "package" in two levels,
one below the API and one above. Furthermore those who
favored participating in the above reacted negatively to the
below participants continually engaging in seemingly endless
discussions without actually "doing" anything. Being "doers"
themselves they set up osfree. The talkers remained in
freeos and the doers in osfree.
For reasons not clear to me the talkers now free of the
chastisement of the doers ceased talking and the doers, of
course, didn't want to talk in the first place.<g> Personally
osfree even if it succeeds fails while freeos fails if it doesn't
succeed with the microkernel and the presentation services.
In short osfree's success depends upon that of freeos. The
failure of freeos dooms osfree.
In truth I don't have an answer which covers in necessary
detail all of the above. I don't know how to get the answer
except through a continuing discovery process accompanied
by a peer review through discussions. Basically I do little
surfing of the internet as I do have other lives requiring time
on their own. I rely on others who have more time to devote
to such efforts. I will make time to participate in the needed
discussions to have a detailed conceptual and practical
solution that leads to a better OS environment for all users.