Part 12 - Feb 26 2002

[admin]

#331 From: "poldi42" <poldi42@...>
Date: Tue Feb 26, 2002 12:54 pm
Subject: purpose of ML (was: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS)) poldi42
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


(A)

>
> Returning to the osFree subject. I and some other programmers I know
> will never work on osFree or a derative of this project.

(B)

> A lot of
> people on this list have strong opinions and ignore all legal issues.

is (B) the [only] reason for (A)?


> FreeOS isn't the solution either as (some) people on that list prefer
> to
> talk and pretend they have what it takes to design and implement
> an operating system.

I don't think that it is all that clear, _what_ freeos is or hopes to
be. so I guess it is a bit unfair to say it is no solution...

>
> In my opinion the best option is to either use an existing mature
> operating system (linux/freebsd) or write one from scratch that is
> flexible enough to support multiple operating system personalities
> (application & driver). The latter could for instance be based on
> the l4ka micro kernel (http://l4ka.org)
>

and noone has yet decided otherwise AKAIF. the problem on this list is
that on this list far too different things are getting discussed -
makes it different to see clearly, at last for me.

among the main topics seem to be at least:

- stratagical goals in building an OS/2 clone
- theoretical legal issues concerning the ways to do this
- practical legal issues concerning the binaries recently uploaded on
hobbes and how they were produced
- esotherical sowftware development methods of the next century (sorry
- could not resist )
- organisation of managing all these affords.
- concrete development of drop-in replacements for OS/2-parts on
application and "high-level-API" level
- concrete development of a replacement kernel

details on the last one are completely undecided right now. I guess
there are not even more than 3 people involved in the discussion that
could decide or work on this matter. even worse, 1 of them just
declared he won't do so.

Sander & Achim: while you are still on this list, I'd like to ask you
2 favors:

- legal issues that everyone wants to be resolved aside, will you
please name reasons for not contributing? is this complete nonsens to
you or are we just missing something?

- as Innotek seems to be magnet for ex-IBMler - to you know whom to
contact regarding any OS/2 clonage project. not for help, but to bring
it to IBMs attention and ask for a statement regarding IBMs position?

if there is some hammer to go down on this it'd better be ASAP.

regards,

Carsten

[admin]

#332 From: Richard Gelderblom - Sun Microsystems <richard.gelderblom@...>
Date: Tue Feb 26, 2002 1:00 pm
Subject: Re: Re: Linux + OS/2 layer zwitska
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


+>>Yes, I also agree with this.
+>>
+>>And one could also start using the CONAPI's (fully 32-bit) and get rid of as
+>>much 16-bit code as possible (forgetting the discussion about closed source
for
+>>the mo').
+>>
+>CONAPI ??

http://homepages.tesco.net/~J.deBoynePo ... onapi.html

+>>Then eventually one could go completely 32-bit and there will be no need to
+>>rewrite all the 'old' 16-bit stuff as well.
+>>Also saves a lot of effort and *time* !
+>>
+>>I don't know how many programs (or parts thereof) still use that (16-bit
APIs),
+>>but maybe we can also get other developers interested (again) if they're
asked
+>>to update their apps for a 'good cause'
+>>
+>The biggest problem here is that lots of old stuff are 16bit and its much
harder to
+>get hold of developers for these.

Do we still *need* that old stuff ?

+>But the amount of 16-bit usermode apps (nondrivers) are pretty few.

I don't know.

rg,rg


+>Sincerely
+>
+>JMA
+>Development and Consulting
+>
+>John Martin , jma@...
+>==================================
+>Website: http://www.jma.se/
+>email: mail@...
+>Phone: 46-(0)70-6278410
+>==================================

[admin]

#333 From: Richard Gelderblom - Sun Microsystems <richard.gelderblom@...>
Date: Tue Feb 26, 2002 1:10 pm
Subject: Re: Re: Linux + OS/2 layer zwitska
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


+>>>CONAPI ??
+>>>
+>> That's JdeBP's console API.
+>>
+>Still not opensource.
+>
+>People !!!
+>(not you Michal)
+>
+>A opensource OS/2 clone cannot be build by finding lots of nice OS/2 addons in
+>binary form.
+>
+>It has to have what OS/2 already has but in source.
+>
+>Dont you get this ???

Assuming you mean me.

If you want to rewrite parts of OS/2 aiming for a complete replacement than it
might save you time to initially skip work that is already there.
(Apart from the sheer fact that OS/2 *IS* already there )

If you don't like CONAPI afterwards you can also replace that.

The thing is that there's still a lot of 16-bit code around with 32-bit
counterparts.
If you're going the other way around you'll *never* get rid of it.

What's the big deal anyway ?
OS/2 is closed source and so is CONAPI.
You're replacing OS/2 step by step so nothing stops you from replacing that too.

rg,rg

+>Sincerely
+>
+>JMA
+>Development and Consulting
+>
+>John Martin , jma@...
+>==================================
+>Website: http://www.jma.se/
+>email: mail@...
+>Phone: 46-(0)70-6278410
+>==================================

[admin]

#334 From: "Adrian Gschwend" <ktk@...>
Date: Tue Feb 26, 2002 2:03 pm
Subject: Re: IBM OS/2 Open Source (was: Digest Number 9) netlabsorg
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Sat, 23 Feb 2002 16:26:15 -0800 (PST), Michal Necasek wrote:

> I also do not believe that IBM cannot opensource IBM OS/2 or
>at least large parts of it. That just doesn't make sense.
>Of course I haven't seen the "divorce papers" signed by IBM
>and Microsoft, but I don't think those who say "IBM can't do
>it" have either.
>
> I do know for a fact that one of the primary developers of
>OS/2 2.0 said something to the effect that "sure, IBM can
>do whatever they want to do with the sources, they're just
>too spineless".

I can confirm that part, I had the email discussion with the OS/2 2.0
lead developer and he clearly told that IBM could do whatever they want
with most part of the code and if they didn't open source it they
"don't know it or won't admit it".

Quote from original email contact I had:
---
IBM can do what it wants with the src -- they just don't know it or
won't
admit it. You wouldn't believe the crap that WAS in the contracts. If
it
weren't for IBM, OS/2 could have been what it was planned to be -- MS
was an
awesome partner. Unfortunately MS has become today everything they
correctly
hated about IBM then and then some. Most of the original MS developers
we
worked with are long gone and retired.
---

That was some month ago.

BTW he is the author of the book "Design of OS/2" I recomended

cu

Adrian



--
Adrian Gschwend
@ OS/2 Netlabs

ICQ: 22419590
ktk@...
-------
The OS/2 OpenSource Project:
http://www.netlabs.org

[admin]

#335 From: "tomleem7659" <jersey@...>
Date: Tue Feb 26, 2002 6:47 pm
Subject: osFree and FreeOS? tomleem7659
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Is this similar to the FreeOS project?
http://www.freeos.org
http://groups.yahoo.com/group/freeos

TomLeeM

[admin]

#336 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Feb 26, 2002 8:07 pm
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Gary Renquist writes:
"Just a quick warped-perspective:

I've been skimming through your exchanges...
It seems that y'all are describing one of the
greatest code-database/instruction-processing
systems there is -- DNA/DNA-transcription."

You've provided an interesting perspective, quite correct that two
different programmers using the same source may arise at different
conclusions. The issue is one of reuse, reuse through physical
replication or reuse through logical reference.

If you reuse through physical replication, then you create
multiple sources, each of which you must maintain separately even
when performing a global change within a program or across program
boundaries. If you reuse through logical reference, then you
create only one source to maintain. You can optionally reflect an
individual change on a case by case basis from a "where used" list
of references or you can reflect it globally using the same "where
used" list.

The point is single-source maintenance and software-provided
assist in statement change management. It's having the ability to
"preview" the effect of change prior to commitment, i.e. making
the change. You can also select (again with software support)
those instances where the change applies or where it doesn't.
Then finally with software support reflect the change throughout
the global set of assemblies insuring synchronization.

If the same statement appears more than once in one or more
programs, it is reused. That's a fact. However, if it is
physically present in each use instance, it is not reusable, i.e.
each use requires a separate copy. Reusable modules, code
segments, etc. use a logical reference method implemented in most
systems via an "include" statement. If you bring reusability to
the statement level, you eliminate the need for the 'include' in
the "include statement" as every statement is a reference to a
reusable resource, whether raw material (an individual statement)
or assembly (set of statements).

Now as all assemblies must ultimately decompose into raw material
the only actual source you need to maintain are source statements.
The assemblies exist only as ordered lists of source statement
references (raw material) or other assembly references.

Now as compilers, interpreters, and some editors support syntax
checking of source, that checking occurs against source
statements. That same process can verify if a particular source
statement has been used before. If it has, it can reuse it
through inserting a logical reference. If it has not, it can
create a new logically referenceable, i.e. reusable, source.

None of this has any effect on what a programmer writes or how
well he writes it. It just says that whatever he writes becomes
automatically reusable down to the source statement level. That
says that his change management support, the ability to preview
and control the impact of change at both statement and assembly
level, is complete, i.e. global across all systems.

If you have been involved in change management, particularly where
a change crosses program and application system boundaries, you
know the importance of (1) locating (and determining) all places
where the change must occur and (2) synchronizing the effect of
change, i.e. its occurrence. You also know that this process is
time-consuming and people intensive. Expending people resources
over time accounts for most of the expense in software
development. We need to lower that cost. We can only do it
through the tools we use.

Because a change in source code may necessitate a change in source
text, i.e. documentation, we need a means of associating source
code and source text with respect to change management. That is,
the synchronization of change crosses the boundary between source
code and source text. We want changes to the documentation
(source text) to synchronize with those to source code.

We must have something wrong with our current implementations when
a decision to "rewrite" a system using as much (reusing) as
possible from the existing system normally involves "documenting"
it. This means as a matter of course that we expect our source
text to be out of sync with our source code. Everyone seems to
accept this as "normal" and not an abnormality. This "normal"
acceptance again raises the cost of software development.

So what not have a single data repository/directory for all
source, code and text, in which the stored source are the basic
syntactical units statements (code) and sentences (text). You can
now have assemblies of code only (for compilation), of text only,
or of any combination. Now you have the means via software to
view and control (related to selection and synchronization) change
across all source uses (assemblies). You can do it at a cost in
time and effort far less than provided in currently available
tools.

If we further eliminate the current restriction on scope of
compilation to a single external procedure by allowing to increase
to any number, we can then in a single compile, a single unit of
work, synchronize global changes across programs, across systems.

By using a data repository/directory, substituting a directory
listing (an ordered list of assemblies and statements) for source
files, by allowing any association of code and text, and by
extending the scope of compilation to an unlimited number of
executables, gives us maximum reusability with simplified change
managment at far less cost (and time). Regardless of our interest
in producing a frog leg or bat wing.<g> We can maximise our use
of common code.

[admin]

#337 From: "ShadoW" <ShadoW.FmC@...>
Date: Tue Feb 26, 2002 11:49 pm
Subject: Re: A gift horse... shadow_fmc
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Thu, 21 Feb 2002 20:42:31 +0100, JMA wrote:

>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

Perhaps he is using an editor that assembles phrases which are stored in a
database.

SCNR

Sebastian

[admin]

#338 From: "JMA" <mail@...>
Date: Wed Feb 27, 2002 3:26 am
Subject: Re: Re: Linux + OS/2 layer mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Tue, 26 Feb 2002 11:00:02 +0100 (MET), Richard Gelderblom - Sun Microsystems
wrote:

>+>>Yes, I also agree with this.
>+>>
>+>>And one could also start using the CONAPI's (fully 32-bit) and get rid of as
>+>>much 16-bit code as possible (forgetting the discussion about closed source
>for
>+>>the mo').
>+>>
>+>CONAPI ??
>
>http://homepages.tesco.net/~J.deBoynePo ... onapi.html
>
Dont get me wrong, there is nothing wrong with conapi but I dont see
how it fits (see answer to next mail).







Sincerely

JMA
Development and Consulting

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

[admin]

#339 From: "JMA" <mail@...>
Date: Wed Feb 27, 2002 3:37 am
Subject: Re: Re: Linux + OS/2 layer mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Tue, 26 Feb 2002 11:10:48 +0100 (MET), Richard Gelderblom - Sun Microsystems
wrote:

>+>It has to have what OS/2 already has but in source.
>+>
>+>Dont you get this ???
>
>Assuming you mean me.
>
>If you want to rewrite parts of OS/2 aiming for a complete replacement than it
>might save you time to initially skip work that is already there.
>(Apart from the sheer fact that OS/2 *IS* already there )
>
>If you don't like CONAPI afterwards you can also replace that.
>
That a good though I hope people here will like. Move stuff one bit at a time
and use our current OS/2 install to ensure compatibility.

But CONAPI is no part of OS/2 and should we clone that to ?

>The thing is that there's still a lot of 16-bit code around with 32-bit
>counterparts.
>If you're going the other way around you'll *never* get rid of it.
>
The problem is that apps (binaries) that uses kbd/mou/vio have code
in them (put there by the linker) that requires a 16-bit API.

CONAPI opensource or closed would not help here. We MUST
keep the 16bit support in the OS unless someone can do a
generic patcher that patches away all 16-bit suppport in a .exe.


>What's the big deal anyway ?
>OS/2 is closed source and so is CONAPI.
>You're replacing OS/2 step by step so nothing stops you from replacing that
too.
>
But why CONAPI and if CONAPI why not x, y, z.
Lets start with the IBM OS/2 stuff and port these first. When tis is done we can
add whatever we want. Btw. the conapi binaries must run on our ported
kbd/mou/vio layer anyway since our API layer must work like OS/2.

And, what does conapi do ?
Most likely it takes your 32-bit kbd/mou/vio call, checks/changes parameters and
then call the real kbd/mou/vio api.




Sincerely

JMA
Development and Consulting

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

[admin]

#340 From: "JMA" <mail@...>
Date: Wed Feb 27, 2002 3:45 am
Subject: Re: osFree and FreeOS? mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Tue, 26 Feb 2002 15:47:47 -0000, tomleem7659 wrote:

>Is this similar to the FreeOS project?
>http://www.freeos.org
>http://groups.yahoo.com/group/freeos
>
>
The FreeOS project has been going on for many years andnot
a single line of code has been written.

osFree is about doing things now, not dreaming and talking.

Btw: The freeos.org webpage is a Linux thing and has nothing
to do with the FreeOS yahoogroup.




Sincerely

JMA
Development and Consulting

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