#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
==================================