#151 From: "JMA" <mail@...>
Date: Thu Feb 21, 2002 8:06 pm
Subject: Re: Summing up ! mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 15:50:26 +0100, criguada@... wrote:
>Hi JMA,
>
>> **osFree/CMD**
>> command line tools
>> I hope the JBP(?) tools will be opened for us. This will save us LOTS of
work.
>> But if you dont understand why a) we need them or b) why they must be
opensource,
>> then either ignore it and do something else or unsubscribe from this list.
>
>JdeBP has done the CPI also (a 32bit implementation with unicode
>support), so I really hope he is willing to opensource it. I don't see
>why he shouldn't, since his tools are already free.
>But if he doesn't, than we'll have to redo it.
>
Sorry, its "only" a replacement for Kdb/Mou/Vio and as I understand from reading
his
pages its API is more like The WinNT console API than the OS/2 API.
Dont get me wrong, its great code but it just dont fit osFree (yet).
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Part 6 - Feb 21 2002
Re: Part 6
#152 From: "JMA" <mail@...>
Date: Thu Feb 21, 2002 8:18 pm
Subject: Re: OSFree and our future mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 16:29:36 +0100 (CET), ShadoW wrote:
>On Thu, 21 Feb 2002 15:19:56 +0100, criguada@... wrote:
>
>>And in fact, eCS isn't what it could be, because IBM is too blind to
>>give their complete sources to Serenity.
>
>Serenity doesn't has the resources to handle the complete sources.
>And the _full_ community wouldn't support Serenity, because it wouldn't be GPL.
>
>It is possible to get some source from IBM. Look at this.
>
>I forward a message from the FreeOS mailing list:
>
<SNIP>
This is VERY interesting and if someone could get a contact with IBM about this
it would be very good.
Its funny how IBM sees OpenSourcing as something very costly.
Sybase got a team working free for then opensourcing Watcom C++ and Fortran.
IBM could easily do the same and "only" pay for the legal department.
From what understand this works great.
But sadly (for us), Oliver is no longer with IBM.
While at IBM he did a very nice app to connect to your mobile phone (cellular in
english?)
that allow to handle the numbers list and send SMS.
After he quit IBM the drivers needed for this (IR drivers) were released by IBM
US and
they no longer works on my ThinkPad (.
The old drivers he sent me still works so I can live with it, thanks for the app
Oliver )
Hope you will find time to enhance it even more !
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Thu Feb 21, 2002 8:18 pm
Subject: Re: OSFree and our future mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 16:29:36 +0100 (CET), ShadoW wrote:
>On Thu, 21 Feb 2002 15:19:56 +0100, criguada@... wrote:
>
>>And in fact, eCS isn't what it could be, because IBM is too blind to
>>give their complete sources to Serenity.
>
>Serenity doesn't has the resources to handle the complete sources.
>And the _full_ community wouldn't support Serenity, because it wouldn't be GPL.
>
>It is possible to get some source from IBM. Look at this.
>
>I forward a message from the FreeOS mailing list:
>
<SNIP>
This is VERY interesting and if someone could get a contact with IBM about this
it would be very good.
Its funny how IBM sees OpenSourcing as something very costly.
Sybase got a team working free for then opensourcing Watcom C++ and Fortran.
IBM could easily do the same and "only" pay for the legal department.
From what understand this works great.
But sadly (for us), Oliver is no longer with IBM.
While at IBM he did a very nice app to connect to your mobile phone (cellular in
english?)
that allow to handle the numbers list and send SMS.
After he quit IBM the drivers needed for this (IR drivers) were released by IBM
US and
they no longer works on my ThinkPad (.
The old drivers he sent me still works so I can live with it, thanks for the app
Oliver )
Hope you will find time to enhance it even more !
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#153 From: "JMA" <mail@...>
Date: Thu Feb 21, 2002 8:31 pm
Subject: Re: Re: Official WWW ? mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 16:25:47 -0000, khaverblad wrote:
>--- In osFree@y..., "JMA" <mail@j...> wrote:
>
>> The website is on its way. It will be hosted on
>os2world.com but we need someone
>> that can do the pages.
>
>Well, since I can't really support the team with
>any developer skills; I can then always start to
>build up a basic homepage for osFree so people that
>have interest in this project can find
>documentation and downloads.
>
Since you seem to have the time...
This is a quick scetch of pages needed:
- Welcome, latest news
- What is osFree, What is our goal and how do we plan to get there
- Our licence (BSD style with some GNU)
- Members and a credit section
- project pages
kernel
CPI
cmd line tools
documentation
...
- Resources
links
CVS
who to contact
- I want to participate what do I do
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Thu Feb 21, 2002 8:31 pm
Subject: Re: Re: Official WWW ? mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 16:25:47 -0000, khaverblad wrote:
>--- In osFree@y..., "JMA" <mail@j...> wrote:
>
>> The website is on its way. It will be hosted on
>os2world.com but we need someone
>> that can do the pages.
>
>Well, since I can't really support the team with
>any developer skills; I can then always start to
>build up a basic homepage for osFree so people that
>have interest in this project can find
>documentation and downloads.
>
Since you seem to have the time...
This is a quick scetch of pages needed:
- Welcome, latest news
- What is osFree, What is our goal and how do we plan to get there
- Our licence (BSD style with some GNU)
- Members and a credit section
- project pages
kernel
CPI
cmd line tools
documentation
...
- Resources
links
CVS
who to contact
- I want to participate what do I do
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#154 From: "JMA" <mail@...>
Date: Thu Feb 21, 2002 8:41 pm
Subject: CVS suggestion mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I will set up a CVS server for osFree in a day or two.
It will be quite empty initially but I'm playing with a directory structure.
Can someone that knows this better than me comment ?
CVS
-- osfree
----- docs
----- ----- spec
----- ----- API_docs
----- ----- tools_docs
----- ----- usr_docs
...
----- kernel
----- ----- boot
----- ----- loader
----- ----- kernel
----- pdd
----- ----- common
----- ----- disk
----- ----- io
----- ----- ifs
...
----- network
----- ----- tcpip
----- ----- netbios
...
----- cmd
----- ----- ansi
----- ----- attrib
...
----- pm
----- ----- base_dll
----- ----- drivers
----- ----- ----- video
----- ----- ----- io
----- ----- ----- printer
...
----- pm_tools
----- ----- e
----- ----- fdiskpm
----- ----- pmformat
...
----- wps
----- ----- base_dll
...
----- mvdm
----- ----- base
----- ----- v_drv
----- ----- dos
----- ----- winos2
...
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Thu Feb 21, 2002 8:41 pm
Subject: CVS suggestion mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
I will set up a CVS server for osFree in a day or two.
It will be quite empty initially but I'm playing with a directory structure.
Can someone that knows this better than me comment ?
CVS
-- osfree
----- docs
----- ----- spec
----- ----- API_docs
----- ----- tools_docs
----- ----- usr_docs
...
----- kernel
----- ----- boot
----- ----- loader
----- ----- kernel
----- pdd
----- ----- common
----- ----- disk
----- ----- io
----- ----- ifs
...
----- network
----- ----- tcpip
----- ----- netbios
...
----- cmd
----- ----- ansi
----- ----- attrib
...
----- pm
----- ----- base_dll
----- ----- drivers
----- ----- ----- video
----- ----- ----- io
----- ----- ----- printer
...
----- pm_tools
----- ----- e
----- ----- fdiskpm
----- ----- pmformat
...
----- wps
----- ----- base_dll
...
----- mvdm
----- ----- base
----- ----- v_drv
----- ----- dos
----- ----- winos2
...
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#155 From: "Lynn H. Maxson" <lmaxson@...>
Date: Thu Feb 21, 2002 9:43 pm
Subject: A gift horse... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
As one of the remaining principal "talkers" of the FreeOS group
and one in 100% agreement on approach with Adrian Geschwind my
offer to assist in documenting still holds. Code is not my
"security blanket" as I am not uncomfortable without it, knowing
full well that if my thoughts are complete, the code will be also.
I note that I do have a copy (unautographed) of Kogan's "The
Design of OS/2". I will follow Adrian's advice on reading it.
I do not argue the differences in terms of purpose between drivers
and applications. I do note that you have kernel functions (APIs)
and applications. You write drivers to these APIs, applications
to these APIs, and utilities to these APIs. That indicates to me
that drivers, utilities, and applications fall generically into
the applications class relative to the kernel.
Another difference of some importance lies in the close
association of device drivers (the software), devices (the
hardware), and the device vendors. This has resulted in device
vendors choosing which OSes they would support for their drivers.
As the devices probably contain proprietary hardware with
translates to proprietary software unless you use "reverse
engineering", a practice for the most part forbidden in the
accompanying license, you have to support the driver architecture
selected by the vendor. Otherwise you have a problem on your
hand. The essence in producing an open source clone of OS/2 lies
in both solving and avoiding problems.
Thus utilities, drivers, and applications run on the "application
interface", the APIs, relative to the kernel. This "application
layer", set of APIs, in turn relies on the existence of "lower
level" APIs, ultimately on a set of "core" APIs, APIs dependent
possibly on each other but on none either below or above them. So
to have a kernel from the "core" to the "application" level, means
having a design, a logical hierarchy of API interconnections.
Now the statement has been made that you can implement anything.
If you find that you have to re-implement, you can do it
completely with 1/10th the effort. That flies in the face of
empirical evidence in every IT enterprise. For the record
"maintenance", modification to an existing version, is far more
expensive relative to development, as the primary expense in
development is the maintenance which occurs on the way to getting
the version.
When the enterprises in the 60's and 70's found themselves engaged
in expending their resources 90+% in software maintenance in a
losing battle, i.e. increasing backlog of change request, they
adopted OO and its promise of reusability as a means to reverse
this. Of course, billions of dollars later and millions of
man-years later (the latter being the largest portion of the
former) that didn't happen. If it hasn't happened their with the
obvious financing available, it won't happen here using
essentially the same set of tools. None of the suggestions made
thus far on tools, what and whose, will solve this problem.
As in anything else the level of reuse affects the total effort.
What may not be as clear is that you have reuse of source code as
well a souce documentation to consider. Remarks elsewhere made
about "heavily" commenting code, i.e. use of comments, has
automatically separated such comments from documenting the code
itself: two different sets of text describing the same function.
Thus no reuse without manually copying from one to the other and
no means of automatically reflecting changes between them that
occur over time.
All code reuse is based on code segments with each segment
existing as a separate file. Thus there is only segment reuse
possible and not statement reuse. If you had statement reuse, the
maximum reuse level possible, you could have segment reuse without
the necessity of storing each segment separately, i.e. as a file.
You see documentation exist as source code, with or without
comments, and associate source text. They may appear singularly
as in text-only documentation or input to a compiler (which has to
have extra code to excise comments from its processing) or
together as a structured document with complete source code. In
this last the structure of the document may differ from the
procedural structure of the source code necessary for proper
compilation.
However, having this ability to associate (loosely coupled) source
text and source code offers a level of reuse and automatic single
source update not possible with commented (tightly coupled) source
code. The cost to maintain documentation (source text) in sync
with source code in time and effort is equal to or greater than
that for the source code alone. This is why documentation gets
short shift relative to code in most implementations and why the
documentation complaints normally exceed those of code.
Even if IBM were able and willing to make the source for OS/2 open
and available the time to a new, improved implementation,
something competitive to the other OS choices available at time of
release, would not differ significantly from writing the complete
documentation of source code and source text from scratch. I
realize this sounds somewhat incredulous. However, IBM making
OS/2 open source with a working, though "old" version, puts us
into maintenance mode to produce a version anywhere close to what
is necessary to compete successfully. It is maintenance mode, not
development mode, and its associated cost which drove IBM to
forego retail support of OS/2. It could (and did) recoup its
development costs. It could not its maintenance costs.
The point is that we can afford to develop an open source OS/2
clone, at least initially. At some point we will find ourselves
in maintenance mode, i.e. having to make changes to existing code.
It is at that point which configuration management associated with
test cases, test data, and regressive testing rear their ugly
head. This says even before you get out an initial version and
investment you have to make beyond that of simply writing source
code, possibly the easiest writing task of all to achieve.
While I appreciate those eager to code, i.e. to produce source
code, theirs is the easiest to do overall in development and of
lesser concern in maintenance, where change impact before
(analysis and design) and after (regressive testing) code writing
consumes more resources. Once you "know" what to do it is easier
to do it than attempting to do it without that knowledge. In any
instance a little more upfront knowledge with cost less in terms
of maintenance, the long-term, ongoing, major cost of software.
I, of course, have a greater interest in minimizing investment
costs and maximising their duration, i.e. long-term value. Thus a
greater interest in supporting the documentation effort than the
coding effort, which should derive from the documentation and not
vice versa. That says that nothing should exist in code which is
not driven from the documentation, regardless of an initial state
of undocumented (only commented) code. The point is to have
complete specifications (documentation) describing all aspects of
what the code is to do or not do before committing to code
writing.
In that manner we can have the most complete peer review possible
of programmers and non-programmers alike in a language which both
understand.
Date: Thu Feb 21, 2002 9:43 pm
Subject: A gift horse... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
As one of the remaining principal "talkers" of the FreeOS group
and one in 100% agreement on approach with Adrian Geschwind my
offer to assist in documenting still holds. Code is not my
"security blanket" as I am not uncomfortable without it, knowing
full well that if my thoughts are complete, the code will be also.
I note that I do have a copy (unautographed) of Kogan's "The
Design of OS/2". I will follow Adrian's advice on reading it.
I do not argue the differences in terms of purpose between drivers
and applications. I do note that you have kernel functions (APIs)
and applications. You write drivers to these APIs, applications
to these APIs, and utilities to these APIs. That indicates to me
that drivers, utilities, and applications fall generically into
the applications class relative to the kernel.
Another difference of some importance lies in the close
association of device drivers (the software), devices (the
hardware), and the device vendors. This has resulted in device
vendors choosing which OSes they would support for their drivers.
As the devices probably contain proprietary hardware with
translates to proprietary software unless you use "reverse
engineering", a practice for the most part forbidden in the
accompanying license, you have to support the driver architecture
selected by the vendor. Otherwise you have a problem on your
hand. The essence in producing an open source clone of OS/2 lies
in both solving and avoiding problems.
Thus utilities, drivers, and applications run on the "application
interface", the APIs, relative to the kernel. This "application
layer", set of APIs, in turn relies on the existence of "lower
level" APIs, ultimately on a set of "core" APIs, APIs dependent
possibly on each other but on none either below or above them. So
to have a kernel from the "core" to the "application" level, means
having a design, a logical hierarchy of API interconnections.
Now the statement has been made that you can implement anything.
If you find that you have to re-implement, you can do it
completely with 1/10th the effort. That flies in the face of
empirical evidence in every IT enterprise. For the record
"maintenance", modification to an existing version, is far more
expensive relative to development, as the primary expense in
development is the maintenance which occurs on the way to getting
the version.
When the enterprises in the 60's and 70's found themselves engaged
in expending their resources 90+% in software maintenance in a
losing battle, i.e. increasing backlog of change request, they
adopted OO and its promise of reusability as a means to reverse
this. Of course, billions of dollars later and millions of
man-years later (the latter being the largest portion of the
former) that didn't happen. If it hasn't happened their with the
obvious financing available, it won't happen here using
essentially the same set of tools. None of the suggestions made
thus far on tools, what and whose, will solve this problem.
As in anything else the level of reuse affects the total effort.
What may not be as clear is that you have reuse of source code as
well a souce documentation to consider. Remarks elsewhere made
about "heavily" commenting code, i.e. use of comments, has
automatically separated such comments from documenting the code
itself: two different sets of text describing the same function.
Thus no reuse without manually copying from one to the other and
no means of automatically reflecting changes between them that
occur over time.
All code reuse is based on code segments with each segment
existing as a separate file. Thus there is only segment reuse
possible and not statement reuse. If you had statement reuse, the
maximum reuse level possible, you could have segment reuse without
the necessity of storing each segment separately, i.e. as a file.
You see documentation exist as source code, with or without
comments, and associate source text. They may appear singularly
as in text-only documentation or input to a compiler (which has to
have extra code to excise comments from its processing) or
together as a structured document with complete source code. In
this last the structure of the document may differ from the
procedural structure of the source code necessary for proper
compilation.
However, having this ability to associate (loosely coupled) source
text and source code offers a level of reuse and automatic single
source update not possible with commented (tightly coupled) source
code. The cost to maintain documentation (source text) in sync
with source code in time and effort is equal to or greater than
that for the source code alone. This is why documentation gets
short shift relative to code in most implementations and why the
documentation complaints normally exceed those of code.
Even if IBM were able and willing to make the source for OS/2 open
and available the time to a new, improved implementation,
something competitive to the other OS choices available at time of
release, would not differ significantly from writing the complete
documentation of source code and source text from scratch. I
realize this sounds somewhat incredulous. However, IBM making
OS/2 open source with a working, though "old" version, puts us
into maintenance mode to produce a version anywhere close to what
is necessary to compete successfully. It is maintenance mode, not
development mode, and its associated cost which drove IBM to
forego retail support of OS/2. It could (and did) recoup its
development costs. It could not its maintenance costs.
The point is that we can afford to develop an open source OS/2
clone, at least initially. At some point we will find ourselves
in maintenance mode, i.e. having to make changes to existing code.
It is at that point which configuration management associated with
test cases, test data, and regressive testing rear their ugly
head. This says even before you get out an initial version and
investment you have to make beyond that of simply writing source
code, possibly the easiest writing task of all to achieve.
While I appreciate those eager to code, i.e. to produce source
code, theirs is the easiest to do overall in development and of
lesser concern in maintenance, where change impact before
(analysis and design) and after (regressive testing) code writing
consumes more resources. Once you "know" what to do it is easier
to do it than attempting to do it without that knowledge. In any
instance a little more upfront knowledge with cost less in terms
of maintenance, the long-term, ongoing, major cost of software.
I, of course, have a greater interest in minimizing investment
costs and maximising their duration, i.e. long-term value. Thus a
greater interest in supporting the documentation effort than the
coding effort, which should derive from the documentation and not
vice versa. That says that nothing should exist in code which is
not driven from the documentation, regardless of an initial state
of undocumented (only commented) code. The point is to have
complete specifications (documentation) describing all aspects of
what the code is to do or not do before committing to code
writing.
In that manner we can have the most complete peer review possible
of programmers and non-programmers alike in a language which both
understand.
Re: Part 6
#156 From: "Michal Necasek" <michaln@...>
Date: Thu Feb 21, 2002 9:52 pm
Subject: Re: OSFree and our future michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 15:19:56 +0100, criguada@... wrote:
>> so what? Linux wasn't done like this and Be neither I guess (with money
>> but with much less).
>
>I know, and I agree with you. The point BTW is that Linux was built upon
>an ultra-known design. I, and every other university student with a
>background in informatics, have studied the unix design in the classes
>about Operating Systems Design. Every student, given enough time, could
>write a simple unix kernel in C. Most have done it for their exams.
>Linus did more or less this, perhaps toying a little more with his
>creation.
>
Hear, hear! Linux is NOTHING new. It is a reimplementation of an
extremely well known commercially developed kernel (hmm, sounds a bit
like osFree maybe?).
As for the microkernel question, I know ukernel sounds cool. OS/2
for PPC sounded cool (go read the redbook). Look how far it got.
The most widely used OSes of our time, ie. Win9x, WinNT, Unix, are
NOT ukernel based. Maybe it means something. Maybe not.
>But you can have a good product (and good design) if you're not scared
>about reimplementing. That's it: start coding, but keep as open as
>possible to change. When you learn enough to think that you didn't take
>the right approach, REIMPLEMENT without fear! You'll discover that the
>reimplementation will take a tenth of the original implementation, you
>will have a better (or "the best") design, and it will be done earlier.
>NO AMOUNT OF FORETHOUGHT will give you the necessary mind-clarity about
>what you're gonna do.
>
That's a VERY good point. These guys got it all wrong. They think
they can design a working kernel while sitting in an armchair. That
is unfortunately nonsense. It doesn't work that way and there is one
simple reason: until you implement something, you do not know what
problems you will face.
Some silly people compare software engineering to civil engineering
to prove how stupid SW engineers are. They say, look, an engineer can
build a bridge or a building without schedule slippages and delays
and additional expenses and whatnot. If you SW guys can't do it, you
must be doing it all wrong. Well, to that I say, this analogy would
hold if every building, every bridge was considerably different from
previous ones, built with new and unproven materials and if the
builders several times changed their minds where the bridge was to
actually stand.
Getting back on topic, it is impossible to create completely useable
blueprints for the "software bridge" because there are far too many
unknowns. Some people think they're geniuses and there are no unknowns.
Well, we'll see
>And in fact, eCS isn't what it could be, because IBM is too blind to
>give their complete sources to Serenity.
>
I'd say "disinterested", not blind. They just don't care.
It's not like IBM is evil, they just care about their bottom
line and nothing else.
Michal
Date: Thu Feb 21, 2002 9:52 pm
Subject: Re: OSFree and our future michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 15:19:56 +0100, criguada@... wrote:
>> so what? Linux wasn't done like this and Be neither I guess (with money
>> but with much less).
>
>I know, and I agree with you. The point BTW is that Linux was built upon
>an ultra-known design. I, and every other university student with a
>background in informatics, have studied the unix design in the classes
>about Operating Systems Design. Every student, given enough time, could
>write a simple unix kernel in C. Most have done it for their exams.
>Linus did more or less this, perhaps toying a little more with his
>creation.
>
Hear, hear! Linux is NOTHING new. It is a reimplementation of an
extremely well known commercially developed kernel (hmm, sounds a bit
like osFree maybe?).
As for the microkernel question, I know ukernel sounds cool. OS/2
for PPC sounded cool (go read the redbook). Look how far it got.
The most widely used OSes of our time, ie. Win9x, WinNT, Unix, are
NOT ukernel based. Maybe it means something. Maybe not.
>But you can have a good product (and good design) if you're not scared
>about reimplementing. That's it: start coding, but keep as open as
>possible to change. When you learn enough to think that you didn't take
>the right approach, REIMPLEMENT without fear! You'll discover that the
>reimplementation will take a tenth of the original implementation, you
>will have a better (or "the best") design, and it will be done earlier.
>NO AMOUNT OF FORETHOUGHT will give you the necessary mind-clarity about
>what you're gonna do.
>
That's a VERY good point. These guys got it all wrong. They think
they can design a working kernel while sitting in an armchair. That
is unfortunately nonsense. It doesn't work that way and there is one
simple reason: until you implement something, you do not know what
problems you will face.
Some silly people compare software engineering to civil engineering
to prove how stupid SW engineers are. They say, look, an engineer can
build a bridge or a building without schedule slippages and delays
and additional expenses and whatnot. If you SW guys can't do it, you
must be doing it all wrong. Well, to that I say, this analogy would
hold if every building, every bridge was considerably different from
previous ones, built with new and unproven materials and if the
builders several times changed their minds where the bridge was to
actually stand.
Getting back on topic, it is impossible to create completely useable
blueprints for the "software bridge" because there are far too many
unknowns. Some people think they're geniuses and there are no unknowns.
Well, we'll see
>And in fact, eCS isn't what it could be, because IBM is too blind to
>give their complete sources to Serenity.
>
I'd say "disinterested", not blind. They just don't care.
It's not like IBM is evil, they just care about their bottom
line and nothing else.
Michal
Re: Part 6
#157 From: "JMA" <mail@...>
Date: Thu Feb 21, 2002 10:42 pm
Subject: Re: A gift horse... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 10:43:29 -0800 (PST), Lynn H. Maxson wrote:
Lynn, sorry for snipping lots, but I assume you will not take to much
offense if I say you are good at elaborating
I remember having the problem writing short enough until I was to write
product reviews in PC-World (swedish ed.). Suddenly I found it hard
to find enough words to fill the pages...
(and that you will see in my horribly long reply
>offer to assist in documenting still holds.
Please contact the webmaster at os2world.com.
He has volontaired to handle the webpage and do some initial pages.
We definitly need help documenting.
>I do not argue the differences in terms of purpose between drivers
>and applications. I do note that you have kernel functions (APIs)
>and applications. You write drivers to these APIs, applications
>to these APIs, and utilities to these APIs. That indicates to me
>that drivers, utilities, and applications fall generically into
>the applications class relative to the kernel.
>
This is a bit dependant of the kernel (OS). There are usermode drivers
in some kernels where drivers "live" in the same protection "ring" as
ordinary apps. But in OS/2 and WinNT/2K/XP for example the drivers
use an entirely different set of API calls and have rights that ordinary
apps does not have.
>The essence in producing an open source clone of OS/2 lies
>in both solving and avoiding problems.
>
I do agree.
>Now the statement has been made that you can implement anything.
>If you find that you have to re-implement, you can do it
>completely with 1/10th the effort. That flies in the face of
>empirical evidence in every IT enterprise. For the record
>"maintenance", modification to an existing version, is far more
>expensive relative to development.
>
Yes and no.
I hve had to do this many times myself for my clients.
Reimplementing by using old source with old tools is very timeconsuming.
Reimplementing using knowledge and some sourcecopying is 1/10 tenth time.
This means two things, a) you must know what the old code do and what
business process (in my cases) it supports and b) the code must be
initially cleanly written an thourougly commented.
There has been tools that would assist you in this. For example JSP
(Jackson Structured Programing) was a good way to keep the
business logic but the code it produced was horrible.
I'm unsure how good these tools can be but its probably an indication
that lots and lots of stuff are written in C and Visual BASIC these days.
My reply would be that knowledge is much more important than code.
Unless I know how to build a kernel the source will not do me any good.
I can probably learn how to build a kernel by reading through its sources
but I doubt it would be a timeefficiant way
>Even if IBM were able and willing to make the source for OS/2 open
>and available the time to a new, improved implementation,
>something competitive to the other OS choices available at time of
>release, would not differ significantly from writing the complete
>documentation of source code and source text from scratch. I
>realize this sounds somewhat incredulous. However, IBM making
>OS/2 open source with a working, though "old" version, puts us
>into maintenance mode to produce a version anywhere close to what
>is necessary to compete successfully. It is maintenance mode, not
>development mode, and its associated cost which drove IBM to
>forego retail support of OS/2. It could (and did) recoup its
>development costs. It could not its maintenance costs.
>
Nope, not quite. If they released we would gain knowledge. I assume
this is why lots of people has gotten hold of the "leaked" sourcecode
and even more people wants it.
The inner workings of a kernel can be compared to a business process.
It has its main features, you must know all the details and it changes
over time.
Software is never the business process in itself, it is and will always
be a supportive function. Just as you have to retrain your employees
when you get new machineries or when the tax laws changes you
will have to retrain your software.
Just as you sooner or later have to upgrade your machinery and
your personell will leave you or retire (I did not say sack them
you must upgrade your software. Thats a fact of life.
What we here try to do is to keep it compatible enough to allow
us to continue to use all tools we already had in the old version.
New machinery is nice but we cannot afford to rebuild the house
or hire employees that are all over 190 cm.
>While I appreciate those eager to code, i.e. to produce source
>code, theirs is the easiest to do overall in development and of
>lesser concern in maintenance, where change impact before
>(analysis and design) and after (regressive testing) code writing
>consumes more resources. Once you "know" what to do it is easier
>to do it than attempting to do it without that knowledge. In any
>instance a little more upfront knowledge with cost less in terms
>of maintenance, the long-term, ongoing, major cost of software.
>
On developing a kernel (as the FreeOS list is about) I cannot say.
A osFree kernel must be able to support enough to run our old tools
but I'm not quite capable of saying what is must do.
Developing a kernel from scratch is - I'm sad to say - not realistic
even if we had a perfect formalized documentation.
To begin with it would take years to put together the docs and
the amount of coding and testing would be staggering.
However, doing the upper parts like for example a format.exe
clone is much more easy.
We can start now since the docs on how format.exe should
work is already there !
Lots of people knows how to build this tool. We must use the
API's to do the actual formatting. We must allow the exact
input parameters and the screen display must look like and
so on.
I'd assume you know yourself how the format screen should look
and what parameters it must have.
And, yes these things must work like the OS/2 original version
or we will break lots of stuff.
Also, and this may be the most important thing. In a perfect world
I would do it the way you want to do it.
First you should document the business process and then you
should use the docs to write any code you need.
BUT...
Even the larges companies rushes things into production. I have a
relativly large customer that just released a new website with
ecommerse and so on. It was rushed to the market. The docs were
incomplete and the development team (based in another country)
ignored or missread it quite much.
Now this was a comersial project, we are talking about a opensource
volontair project. If we step on to many toes here we fail.
Also, in our case, we must show people that we mean "business".
We cannot wait - if we do the whole target audience may have
switched to Linux/Windows before we have anything to show.
So, I would love you to help us with documentation.
But, you must understand that the state of the project and the limited
resources means we must do many things the "wrong way".
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Thu Feb 21, 2002 10:42 pm
Subject: Re: A gift horse... mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 10:43:29 -0800 (PST), Lynn H. Maxson wrote:
Lynn, sorry for snipping lots, but I assume you will not take to much
offense if I say you are good at elaborating
I remember having the problem writing short enough until I was to write
product reviews in PC-World (swedish ed.). Suddenly I found it hard
to find enough words to fill the pages...
(and that you will see in my horribly long reply
>offer to assist in documenting still holds.
Please contact the webmaster at os2world.com.
He has volontaired to handle the webpage and do some initial pages.
We definitly need help documenting.
>I do not argue the differences in terms of purpose between drivers
>and applications. I do note that you have kernel functions (APIs)
>and applications. You write drivers to these APIs, applications
>to these APIs, and utilities to these APIs. That indicates to me
>that drivers, utilities, and applications fall generically into
>the applications class relative to the kernel.
>
This is a bit dependant of the kernel (OS). There are usermode drivers
in some kernels where drivers "live" in the same protection "ring" as
ordinary apps. But in OS/2 and WinNT/2K/XP for example the drivers
use an entirely different set of API calls and have rights that ordinary
apps does not have.
>The essence in producing an open source clone of OS/2 lies
>in both solving and avoiding problems.
>
I do agree.
>Now the statement has been made that you can implement anything.
>If you find that you have to re-implement, you can do it
>completely with 1/10th the effort. That flies in the face of
>empirical evidence in every IT enterprise. For the record
>"maintenance", modification to an existing version, is far more
>expensive relative to development.
>
Yes and no.
I hve had to do this many times myself for my clients.
Reimplementing by using old source with old tools is very timeconsuming.
Reimplementing using knowledge and some sourcecopying is 1/10 tenth time.
This means two things, a) you must know what the old code do and what
business process (in my cases) it supports and b) the code must be
initially cleanly written an thourougly commented.
There has been tools that would assist you in this. For example JSP
(Jackson Structured Programing) was a good way to keep the
business logic but the code it produced was horrible.
I'm unsure how good these tools can be but its probably an indication
that lots and lots of stuff are written in C and Visual BASIC these days.
My reply would be that knowledge is much more important than code.
Unless I know how to build a kernel the source will not do me any good.
I can probably learn how to build a kernel by reading through its sources
but I doubt it would be a timeefficiant way
>Even if IBM were able and willing to make the source for OS/2 open
>and available the time to a new, improved implementation,
>something competitive to the other OS choices available at time of
>release, would not differ significantly from writing the complete
>documentation of source code and source text from scratch. I
>realize this sounds somewhat incredulous. However, IBM making
>OS/2 open source with a working, though "old" version, puts us
>into maintenance mode to produce a version anywhere close to what
>is necessary to compete successfully. It is maintenance mode, not
>development mode, and its associated cost which drove IBM to
>forego retail support of OS/2. It could (and did) recoup its
>development costs. It could not its maintenance costs.
>
Nope, not quite. If they released we would gain knowledge. I assume
this is why lots of people has gotten hold of the "leaked" sourcecode
and even more people wants it.
The inner workings of a kernel can be compared to a business process.
It has its main features, you must know all the details and it changes
over time.
Software is never the business process in itself, it is and will always
be a supportive function. Just as you have to retrain your employees
when you get new machineries or when the tax laws changes you
will have to retrain your software.
Just as you sooner or later have to upgrade your machinery and
your personell will leave you or retire (I did not say sack them
you must upgrade your software. Thats a fact of life.
What we here try to do is to keep it compatible enough to allow
us to continue to use all tools we already had in the old version.
New machinery is nice but we cannot afford to rebuild the house
or hire employees that are all over 190 cm.
>While I appreciate those eager to code, i.e. to produce source
>code, theirs is the easiest to do overall in development and of
>lesser concern in maintenance, where change impact before
>(analysis and design) and after (regressive testing) code writing
>consumes more resources. Once you "know" what to do it is easier
>to do it than attempting to do it without that knowledge. In any
>instance a little more upfront knowledge with cost less in terms
>of maintenance, the long-term, ongoing, major cost of software.
>
On developing a kernel (as the FreeOS list is about) I cannot say.
A osFree kernel must be able to support enough to run our old tools
but I'm not quite capable of saying what is must do.
Developing a kernel from scratch is - I'm sad to say - not realistic
even if we had a perfect formalized documentation.
To begin with it would take years to put together the docs and
the amount of coding and testing would be staggering.
However, doing the upper parts like for example a format.exe
clone is much more easy.
We can start now since the docs on how format.exe should
work is already there !
Lots of people knows how to build this tool. We must use the
API's to do the actual formatting. We must allow the exact
input parameters and the screen display must look like and
so on.
I'd assume you know yourself how the format screen should look
and what parameters it must have.
And, yes these things must work like the OS/2 original version
or we will break lots of stuff.
Also, and this may be the most important thing. In a perfect world
I would do it the way you want to do it.
First you should document the business process and then you
should use the docs to write any code you need.
BUT...
Even the larges companies rushes things into production. I have a
relativly large customer that just released a new website with
ecommerse and so on. It was rushed to the market. The docs were
incomplete and the development team (based in another country)
ignored or missread it quite much.
Now this was a comersial project, we are talking about a opensource
volontair project. If we step on to many toes here we fail.
Also, in our case, we must show people that we mean "business".
We cannot wait - if we do the whole target audience may have
switched to Linux/Windows before we have anything to show.
So, I would love you to help us with documentation.
But, you must understand that the state of the project and the limited
resources means we must do many things the "wrong way".
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#158 From: "JMA" <mail@...>
Date: Fri Feb 22, 2002 1:52 am
Subject: [osfree] First source release from osFree TPE mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Please read "What is it" section !!
--------------------------------------------------------------------------------
------------
readme for osFree disassembly distro of IBM OS/2 Warp resource.sys
--------------------------------------------------------------------------------
------------
TERMS AND CONDITIONS
Important - you MUST read the following terms and conditions.
Downloading the osf_resource.zip package indicates your acceptance
of the following terms and conditions:
1. You must be, and agree that you are, a current licensee of
IBM OS/2 Warp 4(*)
2. You may make copies of this Package fixes equal to the number of
licensed copies of IBM OS/2 Warp 4(*) you possess.
3. Neither IBM nor the osFree development team gives any warranty
and/or service for this distro.
(*)
OS/2 is a registered trademark of International Business Machines Corporation
All rights Reserved.
resource.asm decompile !
---------------------------------
I was given these files from the osFree team.
The package contains:
makefile - file used to build resource.asm (se below)
RESOURCE.ASM - disassembly of resource.sys
version.mak - used by makefile
==== What is it ?
The source of the resource.sys file included in the osFree TPE release.
After getting this I now understand that they should have included the
above licence text in their release.
I dont know if this was the method they used on the whole kit but there
are fixes/changes to the .asm file so it may be that way.
==== How do I build ?
To build this you need the IBM OS/2 DDK (free) that can be downloaded from
<http://www7.software.ibm.com/2bcprod.nsf>
or
<ftp://ddkdnld:its5now@testcase.boulder.ibm.com/>
I have not built this myself so I cannot speak about how and were to
place the DDK or this source. Please read the makefile and the DDK
documentation
osFree TPE development team
via John Martin Alfredsson (jma@...)
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Fri Feb 22, 2002 1:52 am
Subject: [osfree] First source release from osFree TPE mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Please read "What is it" section !!
--------------------------------------------------------------------------------
------------
readme for osFree disassembly distro of IBM OS/2 Warp resource.sys
--------------------------------------------------------------------------------
------------
TERMS AND CONDITIONS
Important - you MUST read the following terms and conditions.
Downloading the osf_resource.zip package indicates your acceptance
of the following terms and conditions:
1. You must be, and agree that you are, a current licensee of
IBM OS/2 Warp 4(*)
2. You may make copies of this Package fixes equal to the number of
licensed copies of IBM OS/2 Warp 4(*) you possess.
3. Neither IBM nor the osFree development team gives any warranty
and/or service for this distro.
(*)
OS/2 is a registered trademark of International Business Machines Corporation
All rights Reserved.
resource.asm decompile !
---------------------------------
I was given these files from the osFree team.
The package contains:
makefile - file used to build resource.asm (se below)
RESOURCE.ASM - disassembly of resource.sys
version.mak - used by makefile
==== What is it ?
The source of the resource.sys file included in the osFree TPE release.
After getting this I now understand that they should have included the
above licence text in their release.
I dont know if this was the method they used on the whole kit but there
are fixes/changes to the .asm file so it may be that way.
==== How do I build ?
To build this you need the IBM OS/2 DDK (free) that can be downloaded from
<http://www7.software.ibm.com/2bcprod.nsf>
or
<ftp://ddkdnld:its5now@testcase.boulder.ibm.com/>
I have not built this myself so I cannot speak about how and were to
place the DDK or this source. Please read the makefile and the DDK
documentation
osFree TPE development team
via John Martin Alfredsson (jma@...)
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#159 From: "Cristiano Guadagnino" <criguada@...>
Date: Fri Feb 22, 2002 3:01 am
Subject: Re: Summing up ! criguada
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi JMA,
On Thu, 21 Feb 2002 18:06:40 +0100, JMA wrote:
>>JdeBP has done the CPI also (a 32bit implementation with unicode
>>support), so I really hope he is willing to opensource it. I don't see
>>why he shouldn't, since his tools are already free.
>>But if he doesn't, than we'll have to redo it.
>>
>
>Sorry, its "only" a replacement for Kdb/Mou/Vio and as I understand from
reading his
>pages its API is more like The WinNT console API than the OS/2 API.
You're right, sorry. It is missing the whole Dos* APIs and
more. Anyway, it would save us lots of work if he would
donate it.
Bye
Cris
Date: Fri Feb 22, 2002 3:01 am
Subject: Re: Summing up ! criguada
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi JMA,
On Thu, 21 Feb 2002 18:06:40 +0100, JMA wrote:
>>JdeBP has done the CPI also (a 32bit implementation with unicode
>>support), so I really hope he is willing to opensource it. I don't see
>>why he shouldn't, since his tools are already free.
>>But if he doesn't, than we'll have to redo it.
>>
>
>Sorry, its "only" a replacement for Kdb/Mou/Vio and as I understand from
reading his
>pages its API is more like The WinNT console API than the OS/2 API.
You're right, sorry. It is missing the whole Dos* APIs and
more. Anyway, it would save us lots of work if he would
donate it.
Bye
Cris
Re: Part 6
#160 From: "Michal Necasek" <michaln@...>
Date: Fri Feb 22, 2002 3:09 am
Subject: Re: Summing up ! michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 01:01:07 +0100 (CET), Cristiano Guadagnino wrote:
>>Sorry, its "only" a replacement for Kdb/Mou/Vio and as I understand from
reading his
>>pages its API is more like The WinNT console API than the OS/2 API.
>
>You're right, sorry. It is missing the whole Dos* APIs and
>more. Anyway, it would save us lots of work if he would
>donate it.
>
I'm surprised that Jonathan hasn't said a word so far... since
he _is_ subscried to this mailing list.
Michal
Date: Fri Feb 22, 2002 3:09 am
Subject: Re: Summing up ! michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 01:01:07 +0100 (CET), Cristiano Guadagnino wrote:
>>Sorry, its "only" a replacement for Kdb/Mou/Vio and as I understand from
reading his
>>pages its API is more like The WinNT console API than the OS/2 API.
>
>You're right, sorry. It is missing the whole Dos* APIs and
>more. Anyway, it would save us lots of work if he would
>donate it.
>
I'm surprised that Jonathan hasn't said a word so far... since
he _is_ subscried to this mailing list.
Michal