#1180 Re: [osFree] what status is osfree
Expand Messages
Lynn H. Maxson
Feb 3, 2005
In truth very little in terms of planning has occurred. The two
major sources include "OS/2 for the PPC" and the OS/2 toolkit
(Version 4.5) with the different reference manuals on the APIs
as well as the "include" libraries. Together these will allow
an extensive and detailed look at the analysis and design of
the eventual personality. That should allow plenty of time
along with the familiarity of the design detail to gain the
necessary programming skill.
The language, unfortunately, is C and C++. The problem is
not the languages, but the tools available. We have the GCC
compiler. It's free. However, it's the same used in other
projects like Linux and ReactOS, subjecting us to the same
limitations. Those limitations jack up the human resources
required. The more you have, even if you have what you
need, decreases the rate at which you can introduce change.
If you don't have a detailed and complete analysis and design
before you start programming, that means you will complete
them within programming. Any analysis or design flaws
detected then will extend the development period even
further.
I'm willing to participate in providing that detailed analysis and
design, which basically is language independent even though
the OS/2 APIs themselves are published in C. In parallel with
this I will continue work on my project regarding SL/I
(specified in SL/I) and The Developer's Assistant (specified in
SL/I).
For further support, though not intending by its authors as
such, I refer you to:
Extensible Programming for the 21st Century
Is an open, more flexible programming environment just
around the corner?
http://www.acmqueue.com/modules.php?name=Content&pa=sh
owpage&pid=247
Part 40 - Feb 03 2005
Re: osFree
#1181 Re: osFree
Expand Messages
Tom Lee Mullins
Feb 4, 2005
> Hi everyone,
>
> There's a full page article on ReactOS
> in the Christmas edition of Linux Format. It states that impressive
> progress is being made with new releases every few months.
> I think it's a pity that the majority of the osFree
> group rejected the request to join the ReactOS group
> to develop an OS/2 personality for it. At least it's a going
> project.
>
> Regards,
>
> Alan Duval
Or even to 'port' it to 'OS/2'(as in compile it using
OpenWatcom for OS/2 other compiler for OS/2?)?
TomLeeM/BWG
Expand Messages
Tom Lee Mullins
Feb 4, 2005
> Hi everyone,
>
> There's a full page article on ReactOS
> in the Christmas edition of Linux Format. It states that impressive
> progress is being made with new releases every few months.
> I think it's a pity that the majority of the osFree
> group rejected the request to join the ReactOS group
> to develop an OS/2 personality for it. At least it's a going
> project.
>
> Regards,
>
> Alan Duval
Or even to 'port' it to 'OS/2'(as in compile it using
OpenWatcom for OS/2 other compiler for OS/2?)?
TomLeeM/BWG
Re: osFree
#1182 Re: osFree
Expand Messages
Tom Lee Mullins
Feb 4, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> I don't remember that a majority or even a vote taken on the
> issue of joining ReactOS. That occurred some time ago. It
> relates to the relatively slow, however continuous progress
> that occurs on it as well as on other open source operating
> systems, e.g. Linux, generally.
>
> Writing an OS/2 personality requires considerable more effort
> than that of a microkernel. In theory, given the common APIs
> for microkernels, we could develop an OS/2 personality
> independent of a specific microkernel. It would begin at the
> OS/2 API level, working downward to the eventual
> microkernel APIs.
>
> The pity does not lie in any unwillingness to join the ReactOS
> effort, but in our inability to begin the analysis and design of
> an OS/2 personality. Having a working, full featured ReactOS
> solves one problem, but a far larger one remains.
There seems to be a project to create an OS/2 personality for
Linux. It is located at http://www.netlabs.org .
http://elfldr.netlabs.org/
TomLeeM/BWG
Expand Messages
Tom Lee Mullins
Feb 4, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> I don't remember that a majority or even a vote taken on the
> issue of joining ReactOS. That occurred some time ago. It
> relates to the relatively slow, however continuous progress
> that occurs on it as well as on other open source operating
> systems, e.g. Linux, generally.
>
> Writing an OS/2 personality requires considerable more effort
> than that of a microkernel. In theory, given the common APIs
> for microkernels, we could develop an OS/2 personality
> independent of a specific microkernel. It would begin at the
> OS/2 API level, working downward to the eventual
> microkernel APIs.
>
> The pity does not lie in any unwillingness to join the ReactOS
> effort, but in our inability to begin the analysis and design of
> an OS/2 personality. Having a working, full featured ReactOS
> solves one problem, but a far larger one remains.
There seems to be a project to create an OS/2 personality for
Linux. It is located at http://www.netlabs.org .
http://elfldr.netlabs.org/
TomLeeM/BWG
Re: [osFree] Re: osFree
#1183 Re: [osFree] Re: osFree
Expand Messages
Lynn H. Maxson
Feb 4, 2005
Tom,
I'm not going to rain on anyone's parade. To create an OS/2
emulation layer on Linux differs from creating an OS/2
personality on a microkernel. It differs in that a microkernel
contains functions common to and necessary for all
personalities. Thus above the microkernel level the OS
personality exists as "the" native environment. In this
instance concurrently sharing with other native OS
personalities and independent of each other.
This implies independent GUI interfaces all based on a core API
operating as a microkernel in this area. The one reservation I
have had about a microkernel approach and its theoretical
support of multiple OS personalities concurrently lies in not
understanding its implementation to allow independent GUIs. I
have this feeling that only one GUI exists at a time with the
user switching between them to get to the personality of his
choice.
I don't favor placing an OS/2 layer, effectively an application
layer on top of Linux. We not only haven't collected the
human resources to develop an OS/2 personality on a
microkernel, the easier task, but it leaves us further short of
the skills and extra people resources we would require to
maintain synchronization with the changes undergoing in
Linux.
Remember that OpenOffice for OS/2 as provided by Innotek
uses work developed in ODIN. The Innotek runtime which
replaces "links" to dll's for Windows with those for OS/2
effectively changes the personality on which the application
runs. The OpenOffice code is the Windows code unchanged.
No emulation layer is involved. It is not an OS/2 layer on
Windows.
The question then becomes do you want to maintain an
independent OS/2 environment executing its applications or do
you want to run OS/2 applications in a Linux environment?
This latter has proven most elusive in both WINE (Linux) and
ODIN (OS/2).
I would simply maintain that it is Linux that needs moving to a
common microkernel. That would allow a Windows
personality developed independent of Microsoft, as currently
envisioned in ReactOS. To this we could add an OS/2
personality. Given that we somehow have a clear picture on
resolving the issue of concurrent GUIs this represents the best
possible of worlds for the user community. It frees us from
Microsoft (Windows), IBM (OS/2), and Linus Torvalds (Linux).
Our real issue remains to collect the human resources and
skills necessary, one, to develop an OS/2 personality, and,
two, to maintain it competitively with the other personalities.
Without that number actively engaged you basically have a
losing situation. My approach in tackling the tool issue intends
to reduce that number significantly by factor of at least 50.
So you will excuse me if I focus on the tool as the best means
of achieving a future for OS/2. That means instead of 500
dedicated people to bring the number to 10.
Expand Messages
Lynn H. Maxson
Feb 4, 2005
Tom,
I'm not going to rain on anyone's parade. To create an OS/2
emulation layer on Linux differs from creating an OS/2
personality on a microkernel. It differs in that a microkernel
contains functions common to and necessary for all
personalities. Thus above the microkernel level the OS
personality exists as "the" native environment. In this
instance concurrently sharing with other native OS
personalities and independent of each other.
This implies independent GUI interfaces all based on a core API
operating as a microkernel in this area. The one reservation I
have had about a microkernel approach and its theoretical
support of multiple OS personalities concurrently lies in not
understanding its implementation to allow independent GUIs. I
have this feeling that only one GUI exists at a time with the
user switching between them to get to the personality of his
choice.
I don't favor placing an OS/2 layer, effectively an application
layer on top of Linux. We not only haven't collected the
human resources to develop an OS/2 personality on a
microkernel, the easier task, but it leaves us further short of
the skills and extra people resources we would require to
maintain synchronization with the changes undergoing in
Linux.
Remember that OpenOffice for OS/2 as provided by Innotek
uses work developed in ODIN. The Innotek runtime which
replaces "links" to dll's for Windows with those for OS/2
effectively changes the personality on which the application
runs. The OpenOffice code is the Windows code unchanged.
No emulation layer is involved. It is not an OS/2 layer on
Windows.
The question then becomes do you want to maintain an
independent OS/2 environment executing its applications or do
you want to run OS/2 applications in a Linux environment?
This latter has proven most elusive in both WINE (Linux) and
ODIN (OS/2).
I would simply maintain that it is Linux that needs moving to a
common microkernel. That would allow a Windows
personality developed independent of Microsoft, as currently
envisioned in ReactOS. To this we could add an OS/2
personality. Given that we somehow have a clear picture on
resolving the issue of concurrent GUIs this represents the best
possible of worlds for the user community. It frees us from
Microsoft (Windows), IBM (OS/2), and Linus Torvalds (Linux).
Our real issue remains to collect the human resources and
skills necessary, one, to develop an OS/2 personality, and,
two, to maintain it competitively with the other personalities.
Without that number actively engaged you basically have a
losing situation. My approach in tackling the tool issue intends
to reduce that number significantly by factor of at least 50.
So you will excuse me if I focus on the tool as the best means
of achieving a future for OS/2. That means instead of 500
dedicated people to bring the number to 10.
Re: osFree
#1184 Re: osFree
Expand Messages
Tom Lee Mullins
Feb 7, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom,
>
> I'm not going to rain on anyone's parade. To create an OS/2
> emulation layer on Linux differs from creating an OS/2
> ..
I only mentioned it as a possible reason why this group
and/or effort seems to have so little acitivity.
Thank you for the information.
TomLeeM/BWG
Expand Messages
Tom Lee Mullins
Feb 7, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom,
>
> I'm not going to rain on anyone's parade. To create an OS/2
> emulation layer on Linux differs from creating an OS/2
> ..
I only mentioned it as a possible reason why this group
and/or effort seems to have so little acitivity.
Thank you for the information.
TomLeeM/BWG
Re: [osFree] Re: osFree
#1185 Re: [osFree] Re: osFree
Expand Messages
Lynn H. Maxson
Feb 7, 2005
Tom,
This group has so little activity, because basically it perceives
no imminent threat to OS/2 itself. It works. It will continue to
do so. It could work better. Technically we have millions of
cheap licenses available.
We took a hit on drivers and applications. Not sure the effect
of the drivers, but with the advent of OpenOffice, Mozilla, and
the Innotek runtime we have done some catching up in the
application arena. I use OS/2 exclusively for my work. I only
use Windoze to satisfy client needs.
I just recently received a copy of Suse Linux Desktop from
Novell. I have an 80GB hardrive to replace the 40GB that
came with my ThinkPad. I will have Windoze XP, Linux, and
eCS on that machine. That will cover my client needs plus my
personal ones.
That doesn't mean I have any less interest in the goal of this
group. It does mean that I believe we should develop a detail
architecture (analysis and design) before we do any coding.
The biggest myth of this profession says you're not doing
anything unless you are coding. Somehow the thought
process that should precede this gets continually disparaged.
The fact is that we cannot afford to code it with the current
set of tools. You only have to look at other projects based on
those tools, at the resources they consume, at the time they
take, at the effort they require, at the testing they cannot
perform, to know that will bring us to our knees.
Do not look at these other projects, those that remain active,
as successes. The ratio of active to inactive should prove
instrumental that a fundamental problem exists. It's in the
tools. The solutions vary.
I have a different view of "the" solution which differs
drastically from others now under consideration. They are
mired in third generation language mode. In my mind they are
simply digging a deeper hole for themselves by making even
worse an already discredited methodology.
I'm not willing to pursue a losing venture. I am willing to
pursue architecting an OS/2 replacement. With that you have
your choice of open source tools if you desire to go beyond
that point. The detailed architecture will give you the lowest
development cost and if pursued the lowest maintenance cost.
I don't think we can assemble the resources necessary even
for the lowest cost. That is, the lowest cost is still to high for
us to afford.
That decision is a personal opinion and in terms of this group
not up to me to make. We can defer that decision while we
work on that on which we do agree: a detailed architecture.
If anyone wants to join in this, then we can increase the
activity of this group.
Expand Messages
Lynn H. Maxson
Feb 7, 2005
Tom,
This group has so little activity, because basically it perceives
no imminent threat to OS/2 itself. It works. It will continue to
do so. It could work better. Technically we have millions of
cheap licenses available.
We took a hit on drivers and applications. Not sure the effect
of the drivers, but with the advent of OpenOffice, Mozilla, and
the Innotek runtime we have done some catching up in the
application arena. I use OS/2 exclusively for my work. I only
use Windoze to satisfy client needs.
I just recently received a copy of Suse Linux Desktop from
Novell. I have an 80GB hardrive to replace the 40GB that
came with my ThinkPad. I will have Windoze XP, Linux, and
eCS on that machine. That will cover my client needs plus my
personal ones.
That doesn't mean I have any less interest in the goal of this
group. It does mean that I believe we should develop a detail
architecture (analysis and design) before we do any coding.
The biggest myth of this profession says you're not doing
anything unless you are coding. Somehow the thought
process that should precede this gets continually disparaged.
The fact is that we cannot afford to code it with the current
set of tools. You only have to look at other projects based on
those tools, at the resources they consume, at the time they
take, at the effort they require, at the testing they cannot
perform, to know that will bring us to our knees.
Do not look at these other projects, those that remain active,
as successes. The ratio of active to inactive should prove
instrumental that a fundamental problem exists. It's in the
tools. The solutions vary.
I have a different view of "the" solution which differs
drastically from others now under consideration. They are
mired in third generation language mode. In my mind they are
simply digging a deeper hole for themselves by making even
worse an already discredited methodology.
I'm not willing to pursue a losing venture. I am willing to
pursue architecting an OS/2 replacement. With that you have
your choice of open source tools if you desire to go beyond
that point. The detailed architecture will give you the lowest
development cost and if pursued the lowest maintenance cost.
I don't think we can assemble the resources necessary even
for the lowest cost. That is, the lowest cost is still to high for
us to afford.
That decision is a personal opinion and in terms of this group
not up to me to make. We can defer that decision while we
work on that on which we do agree: a detailed architecture.
If anyone wants to join in this, then we can increase the
activity of this group.
Re: osFree
#1186 Re: osFree
Expand Messages
Tom Lee Mullins
Feb 8, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom,
>
> This group has so little activity, because basically it perceives
> no imminent threat to OS/2 itself. It works. It will continue to
> do so. It could work better. Technically we have millions of
> cheap licenses available.
>
...
I am not referring to coding but to any activity showing
that something is being done; like you said in the planning
or archetecting of OSFree. Even if it is to say 'it is still
be worked on and ..'. If there is little or no activity at this
group, many would assume that it was totally abandoned.
TomLeeM/BigWarpGuy
PS Thanks for the reply.
Expand Messages
Tom Lee Mullins
Feb 8, 2005
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom,
>
> This group has so little activity, because basically it perceives
> no imminent threat to OS/2 itself. It works. It will continue to
> do so. It could work better. Technically we have millions of
> cheap licenses available.
>
...
I am not referring to coding but to any activity showing
that something is being done; like you said in the planning
or archetecting of OSFree. Even if it is to say 'it is still
be worked on and ..'. If there is little or no activity at this
group, many would assume that it was totally abandoned.
TomLeeM/BigWarpGuy
PS Thanks for the reply.
Re: [osFree] Re: osFree
#1187 Re: [osFree] Re: osFree
Expand Messages
Lynn H. Maxson
Feb 8, 2005
Tom,
Substituting "leaderless" for "abandoned" puts you closer to
the mark. I don't have an answer to it. Perhaps we should
consider it as a project under either Netlabs or SourceForge. I
have the basic material, IBM's toolkit documentation, to deal
with the architecting. At one time after several iterations I
managed to do a compiled listing of all OS/2 APIs. That would
serve as a starting point for analysis and design. One,
something less than a group, could within a reasonable period
produce a design based on a specific microkernel.
Therein, in my opinion, lies the problem: implementing the
design. That means coding. Coding for initial development.
Re-coding for ongoing maintenance. Look about you, not
simply at those projects which have somehow gathered
human resources for ongoing work, but at the much larger
number which lie dormant, languished. Even those with
resources proceed at too slow a pace.
I don't regard the architecting, either the analysis or design,
as a big deal technically, only clerically. The greater effort
lies in its documentation, writing it in a manner to attract the
greatest level of "attentive" readers. I do regard the coding,
not so much the development, but the ongoing maintenance
as the stopper. We don't have the resources either in number
or skills or dedication to achieve success, to compete with
other OSes, with the current tool set.
To me I address solving the tool set problem first, because it's
the stopper. When I am close to its resolution, then I will
begin to shift my focus on architecting a design. I don't have
a real concern about activity on this mailing list. We can use
it to discuss various aspects related to analysis and design for
those who wish to increase their skill set. Otherwise we can
allow it to remain "dormant" until we have the needed tool
set with its productivity gains that will allow us to achieve
"take off". I prefer flying after a take off, i.e. coding, over
crashing.
Anyone who wants to start coding before then can do so.
One, they will gain experience. Two, they will come to have
some understanding of tool set limits. All the material they
need is available and free. More power to them.
Expand Messages
Lynn H. Maxson
Feb 8, 2005
Tom,
Substituting "leaderless" for "abandoned" puts you closer to
the mark. I don't have an answer to it. Perhaps we should
consider it as a project under either Netlabs or SourceForge. I
have the basic material, IBM's toolkit documentation, to deal
with the architecting. At one time after several iterations I
managed to do a compiled listing of all OS/2 APIs. That would
serve as a starting point for analysis and design. One,
something less than a group, could within a reasonable period
produce a design based on a specific microkernel.
Therein, in my opinion, lies the problem: implementing the
design. That means coding. Coding for initial development.
Re-coding for ongoing maintenance. Look about you, not
simply at those projects which have somehow gathered
human resources for ongoing work, but at the much larger
number which lie dormant, languished. Even those with
resources proceed at too slow a pace.
I don't regard the architecting, either the analysis or design,
as a big deal technically, only clerically. The greater effort
lies in its documentation, writing it in a manner to attract the
greatest level of "attentive" readers. I do regard the coding,
not so much the development, but the ongoing maintenance
as the stopper. We don't have the resources either in number
or skills or dedication to achieve success, to compete with
other OSes, with the current tool set.
To me I address solving the tool set problem first, because it's
the stopper. When I am close to its resolution, then I will
begin to shift my focus on architecting a design. I don't have
a real concern about activity on this mailing list. We can use
it to discuss various aspects related to analysis and design for
those who wish to increase their skill set. Otherwise we can
allow it to remain "dormant" until we have the needed tool
set with its productivity gains that will allow us to achieve
"take off". I prefer flying after a take off, i.e. coding, over
crashing.
Anyone who wants to start coding before then can do so.
One, they will gain experience. Two, they will come to have
some understanding of tool set limits. All the material they
need is available and free. More power to them.
Re: osFree
#1188 Re: osFree
Expand Messages
Tom Lee Mullins
Feb 22, 2005
> Tom,
>
> Substituting "leaderless" for "abandoned" puts you closer to
> the mark. I don't have an answer to it. Perhaps we should
> consider it as a project under either Netlabs or SourceForge. I
> have the basic material, IBM's toolkit documentation, to deal
> with the architecting. At one time after several iterations I
> managed to do a compiled listing of all OS/2 APIs. That would
> serve as a starting point for analysis and design. One,
> something less than a group, could within a reasonable period
> produce a design based on a specific microkernel.
>
Like a boat without a rudder.
A Sourceforge or Netlabs site for OSFree would be a good idea.
> Therein, in my opinion, lies the problem: implementing the
> design. That means coding. Coding for initial development.
> Re-coding for ongoing maintenance. Look about you, not
> simply at those projects which have somehow gathered
> human resources for ongoing work, but at the much larger
> number which lie dormant, languished. Even those with
> resources proceed at too slow a pace.
>
> I don't regard the architecting, either the analysis or design,
> as a big deal technically, only clerically. The greater effort
> lies in its documentation, writing it in a manner to attract the
> greatest level of "attentive" readers. I do regard the coding,
> not so much the development, but the ongoing maintenance
> as the stopper. We don't have the resources either in number
> or skills or dedication to achieve success, to compete with
> other OSes, with the current tool set.
>
> To me I address solving the tool set problem first, because it's
> the stopper. When I am close to its resolution, then I will
> begin to shift my focus on architecting a design. I don't have
> a real concern about activity on this mailing list. We can use
> it to discuss various aspects related to analysis and design for
> those who wish to increase their skill set. Otherwise we can
> allow it to remain "dormant" until we have the needed tool
> set with its productivity gains that will allow us to achieve
> "take off". I prefer flying after a take off, i.e. coding, over
> crashing.
>
> Anyone who wants to start coding before then can do so.
> One, they will gain experience. Two, they will come to have
> some understanding of tool set limits. All the material they
> need is available and free. More power to them.
Thanks for the information.
BigWarpGuy
Expand Messages
Tom Lee Mullins
Feb 22, 2005
> Tom,
>
> Substituting "leaderless" for "abandoned" puts you closer to
> the mark. I don't have an answer to it. Perhaps we should
> consider it as a project under either Netlabs or SourceForge. I
> have the basic material, IBM's toolkit documentation, to deal
> with the architecting. At one time after several iterations I
> managed to do a compiled listing of all OS/2 APIs. That would
> serve as a starting point for analysis and design. One,
> something less than a group, could within a reasonable period
> produce a design based on a specific microkernel.
>
Like a boat without a rudder.
A Sourceforge or Netlabs site for OSFree would be a good idea.
> Therein, in my opinion, lies the problem: implementing the
> design. That means coding. Coding for initial development.
> Re-coding for ongoing maintenance. Look about you, not
> simply at those projects which have somehow gathered
> human resources for ongoing work, but at the much larger
> number which lie dormant, languished. Even those with
> resources proceed at too slow a pace.
>
> I don't regard the architecting, either the analysis or design,
> as a big deal technically, only clerically. The greater effort
> lies in its documentation, writing it in a manner to attract the
> greatest level of "attentive" readers. I do regard the coding,
> not so much the development, but the ongoing maintenance
> as the stopper. We don't have the resources either in number
> or skills or dedication to achieve success, to compete with
> other OSes, with the current tool set.
>
> To me I address solving the tool set problem first, because it's
> the stopper. When I am close to its resolution, then I will
> begin to shift my focus on architecting a design. I don't have
> a real concern about activity on this mailing list. We can use
> it to discuss various aspects related to analysis and design for
> those who wish to increase their skill set. Otherwise we can
> allow it to remain "dormant" until we have the needed tool
> set with its productivity gains that will allow us to achieve
> "take off". I prefer flying after a take off, i.e. coding, over
> crashing.
>
> Anyone who wants to start coding before then can do so.
> One, they will gain experience. Two, they will come to have
> some understanding of tool set limits. All the material they
> need is available and free. More power to them.
Thanks for the information.
BigWarpGuy
Petition at OS/2 World?
#1189 Petition at OS/2 World?
Expand Messages
Tom Lee Mullins
Feb 22, 2005
There is some discussion of a petition being
developed at http://www.os2world.com to get
IBM to release the source code. The idea is to
write the petition of open sourcing OS/2 as
not only potentially profitable to IBM but
also show that they support open source
projects while giving OS/2 users what they
want (continued use of OS/2).
TomLeeM/BigWarpGuy
Expand Messages
Tom Lee Mullins
Feb 22, 2005
There is some discussion of a petition being
developed at http://www.os2world.com to get
IBM to release the source code. The idea is to
write the petition of open sourcing OS/2 as
not only potentially profitable to IBM but
also show that they support open source
projects while giving OS/2 users what they
want (continued use of OS/2).
TomLeeM/BigWarpGuy