#281 From: Kris Steenhaut <kris.steenhaut@...>
Date: Sun Feb 24, 2002 3:40 am
Subject: Re: Re: My perspective krissteenhaut
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
JMA schreef:
>
> (*) Can someone that really knows (the law) tell me, can
> sourcecode by copyrighted in the EU ??
>
Source code can be copyrighted in the EU (quite useles in reality)
Source code can't be patented in the EU.
Meaning, you can write your own strings to acquire exactly the same results.
All what matters you can read here (Didn't I post already this links?)
http://www.freepatents.org/
http://swpat.ffii.org/vreji/papri/eubsa-swpat0202/
--
Groeten uit Gent,
Kris
Part 10 - Feb 23 2002
Re: Part 10
#282 From: Kris Steenhaut <kris.steenhaut@...>
Date: Sun Feb 24, 2002 3:42 am
Subject: Re: The Law (was: My perspective) krissteenhaut
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
klaus_h_fuchs schreef:
> --- In osFree@y..., "JMA" <mail@j...> wrote:
>
> >(*) Can someone that really knows (the law) tell me, can
> >sourcecode by copyrighted in the EU ??==
>
> how about reading Ulrich M�ller's (djmutex) mail?
>
> He really KNOWS what he's talking about!
>
He is a sollicitor too. And speaking for his own benefits. Of which he is
entitled to of course.
--
Groeten uit Gent,
Kris
Date: Sun Feb 24, 2002 3:42 am
Subject: Re: The Law (was: My perspective) krissteenhaut
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
klaus_h_fuchs schreef:
> --- In osFree@y..., "JMA" <mail@j...> wrote:
>
> >(*) Can someone that really knows (the law) tell me, can
> >sourcecode by copyrighted in the EU ??==
>
> how about reading Ulrich M�ller's (djmutex) mail?
>
> He really KNOWS what he's talking about!
>
He is a sollicitor too. And speaking for his own benefits. Of which he is
entitled to of course.
--
Groeten uit Gent,
Kris
Re: Part 10
#283 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sun Feb 24, 2002 8:01 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"Would you try to apply manufacturing processes to music, movies,
books?"
Certainly. But then again I would probably use the same
manufacturing processes others have used. I take it that you feel
that programming is a creative process, more an art form than one
of science. That's strange for something 100% based on logic to
believe that art can supplant science.
Besides consider the five stages of the software development
cycle: specification, analysis, design, construction, and testing.
Input to this process are user requirements/changes. The fact is
that for the solution set, the version released after testing, to
match the problem set, the set of user requirement changes, each
transformation from one stage to the next maintains the logical
equivalence of each output form to the next.
Thus what's in specification is logical equivalent to what appears
in requirements, in analysis to what's in specification, in design
to what's in analysis, in construction to what's in design, and in
testing to verify that what's in construction matches what in
requested in requirments. So why in a process based on logic and
the transparency of logical equivalence would you in a single
stage like construction (where programming occurs) expect it to
create anything not already covered in the previous stages, why
would you think it an art form if none of the others are?
That doesn't mean that what appears in a program (content) and how
it appears (context) is deterministic, allowing only one form of
presentation. It doesn't mean it can't be "clever", "innovative",
or "inventive" or even perhaps "creative". Certainly
"expressions" in a program statement can be elaborate or succinct.
In either case the basic IPO model, that a given output is
produced from a given input, prevails. Most would consider and in
fact considerable competition exists to see minimal expressions.
The context long ago in the late 70's became dominated by the use
of structured programming and the three basic control structures
of sequence, decision, and iteration along with the elimination of
the goto and spagetti code. The fact is that this form produces
the most readable code sequences as well as the most succinct
form. The visual "art" of such programs, the "cleanness" of the
control flow, from following structured programming guidelines
prevents one from getting sidetrack into some other form of
"creative expression".
Logical equivalence, its maintenance across transformations, lies
at the heart of logic whether geometry, algebra, computer logic in
hardware, or software logic in programming. While transformations
may result in different logically equivalent forms, some of those
forms are "better" than others. The object is to produce from
these "better" choices that which is "best", i.e. none better.
Any programmer so whetted by his "creative juices" to do less does
his client and himself an injustice.
"OK, I follow you so far. I also think storing statements in
a database is pointless."
You have two choices (other than not storing them at all): (1)
store them in files or (2) store them in a database. No matter
how you cut it a file is an assembly. That means that any
statement which appears more than once in all of them is reused,
but not reusable, i.e. a separate copy must exist. If you store
them in a database, then each statement has an associated name.
Then you only need the name of a statement to appear in every
assembly in which it is used as the software using the name can
retrieve the full source. This means that only a single copy of
the source statement exists and it is that copy which is reused
(retrieved) in all use instances.
That means that assemblies--functions, modules, procedures,
programs, etc.--exist as ordered collections of names instead of
source statements. This means that everything has a name: data
elements have names, data aggregates (assemblies) have names,
program elements (statements) have names, and program aggregates
have names.
These names exist in a data directory, a central, administered
repository where all access occurs through the submission of
names. It would appear that there is a whole lot of naming going
on, which to some appears like unnecessary people work.
Fortunately people don't have to do it as it can be automated in
software.
[I made a mistake before by calling these names "context-based",
when in reality they are "content-based", i.e. determined by the
content of the source.]
The point is not to automate documentation, but to permit a
greater automation than currently exists by turning certain
clerical tasks for naming, storing, retrieving, and maintaining
source over to software. For example, software can determine a
content-based name of a source statement with no outside help.
The software can take a content-based name of an entered source
statement and see if it already exists. If it does it will insert
the unique name (proper name plus index) of that source statement.
Thus the writer does nothing to achieve reuse: it is done
automatically in the software.
Now you can do something not possible otherwise in terms of reuse.
You can use the same source to create different assembly forms of
source text only, source code only, or any combination thereof.
This permits you to have "documented" code, a combination of
source text and code in a logical relationship without them having
to be "physically" stored together. Contrast this to "commented"
code where the only place such comments can appear is physically
within the source code itself. Thus if you want to use the same
comments as part of a separate document (assembly) you must copy
or replicate them, i.e. reuse them, without their being reusable,
i.e. a single maintained source.
Thus you have the problem of maintaining multiple documents from
multiple sources (files) instead of multiple documents from a
single source database. Thus you must use outside means when
changing a reused statement to insure synchronization across
documents and uses, whereas with a database you do not.
"And what is the point? BTW Have you ever used tools like
Sourcelink? Visual SlickEdit?"
Two questions here. The answer to the first lies in the previous
descriptions: the point is to make multiply-used (reused) source
reusable. From a source code or documentation perspective it
means change maintenance from a single source with none of the
synchronization associated with having multiple sources. The
answere to the second question (Sourcelink, Visual SlickEdit) is
"yes".
"...I'm certain of is that I don't believe in silver bullets. You
seem to think that it is somehow possible to automate writing
of software. ..."
If you look closely, you will see that the writing of software is
not automated, only its storage, retrieval, and maintenance, i.e.
once it is written. It follows the guidelines of "let people do
what software cannot, and software what people need not". It is
not a silver bullet. It does not guarantee either "correct" or
"complete" source. Those are concerns beyond its purposes.
Date: Sun Feb 24, 2002 8:01 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"Would you try to apply manufacturing processes to music, movies,
books?"
Certainly. But then again I would probably use the same
manufacturing processes others have used. I take it that you feel
that programming is a creative process, more an art form than one
of science. That's strange for something 100% based on logic to
believe that art can supplant science.
Besides consider the five stages of the software development
cycle: specification, analysis, design, construction, and testing.
Input to this process are user requirements/changes. The fact is
that for the solution set, the version released after testing, to
match the problem set, the set of user requirement changes, each
transformation from one stage to the next maintains the logical
equivalence of each output form to the next.
Thus what's in specification is logical equivalent to what appears
in requirements, in analysis to what's in specification, in design
to what's in analysis, in construction to what's in design, and in
testing to verify that what's in construction matches what in
requested in requirments. So why in a process based on logic and
the transparency of logical equivalence would you in a single
stage like construction (where programming occurs) expect it to
create anything not already covered in the previous stages, why
would you think it an art form if none of the others are?
That doesn't mean that what appears in a program (content) and how
it appears (context) is deterministic, allowing only one form of
presentation. It doesn't mean it can't be "clever", "innovative",
or "inventive" or even perhaps "creative". Certainly
"expressions" in a program statement can be elaborate or succinct.
In either case the basic IPO model, that a given output is
produced from a given input, prevails. Most would consider and in
fact considerable competition exists to see minimal expressions.
The context long ago in the late 70's became dominated by the use
of structured programming and the three basic control structures
of sequence, decision, and iteration along with the elimination of
the goto and spagetti code. The fact is that this form produces
the most readable code sequences as well as the most succinct
form. The visual "art" of such programs, the "cleanness" of the
control flow, from following structured programming guidelines
prevents one from getting sidetrack into some other form of
"creative expression".
Logical equivalence, its maintenance across transformations, lies
at the heart of logic whether geometry, algebra, computer logic in
hardware, or software logic in programming. While transformations
may result in different logically equivalent forms, some of those
forms are "better" than others. The object is to produce from
these "better" choices that which is "best", i.e. none better.
Any programmer so whetted by his "creative juices" to do less does
his client and himself an injustice.
"OK, I follow you so far. I also think storing statements in
a database is pointless."
You have two choices (other than not storing them at all): (1)
store them in files or (2) store them in a database. No matter
how you cut it a file is an assembly. That means that any
statement which appears more than once in all of them is reused,
but not reusable, i.e. a separate copy must exist. If you store
them in a database, then each statement has an associated name.
Then you only need the name of a statement to appear in every
assembly in which it is used as the software using the name can
retrieve the full source. This means that only a single copy of
the source statement exists and it is that copy which is reused
(retrieved) in all use instances.
That means that assemblies--functions, modules, procedures,
programs, etc.--exist as ordered collections of names instead of
source statements. This means that everything has a name: data
elements have names, data aggregates (assemblies) have names,
program elements (statements) have names, and program aggregates
have names.
These names exist in a data directory, a central, administered
repository where all access occurs through the submission of
names. It would appear that there is a whole lot of naming going
on, which to some appears like unnecessary people work.
Fortunately people don't have to do it as it can be automated in
software.
[I made a mistake before by calling these names "context-based",
when in reality they are "content-based", i.e. determined by the
content of the source.]
The point is not to automate documentation, but to permit a
greater automation than currently exists by turning certain
clerical tasks for naming, storing, retrieving, and maintaining
source over to software. For example, software can determine a
content-based name of a source statement with no outside help.
The software can take a content-based name of an entered source
statement and see if it already exists. If it does it will insert
the unique name (proper name plus index) of that source statement.
Thus the writer does nothing to achieve reuse: it is done
automatically in the software.
Now you can do something not possible otherwise in terms of reuse.
You can use the same source to create different assembly forms of
source text only, source code only, or any combination thereof.
This permits you to have "documented" code, a combination of
source text and code in a logical relationship without them having
to be "physically" stored together. Contrast this to "commented"
code where the only place such comments can appear is physically
within the source code itself. Thus if you want to use the same
comments as part of a separate document (assembly) you must copy
or replicate them, i.e. reuse them, without their being reusable,
i.e. a single maintained source.
Thus you have the problem of maintaining multiple documents from
multiple sources (files) instead of multiple documents from a
single source database. Thus you must use outside means when
changing a reused statement to insure synchronization across
documents and uses, whereas with a database you do not.
"And what is the point? BTW Have you ever used tools like
Sourcelink? Visual SlickEdit?"
Two questions here. The answer to the first lies in the previous
descriptions: the point is to make multiply-used (reused) source
reusable. From a source code or documentation perspective it
means change maintenance from a single source with none of the
synchronization associated with having multiple sources. The
answere to the second question (Sourcelink, Visual SlickEdit) is
"yes".
"...I'm certain of is that I don't believe in silver bullets. You
seem to think that it is somehow possible to automate writing
of software. ..."
If you look closely, you will see that the writing of software is
not automated, only its storage, retrieval, and maintenance, i.e.
once it is written. It follows the guidelines of "let people do
what software cannot, and software what people need not". It is
not a silver bullet. It does not guarantee either "correct" or
"complete" source. Those are concerns beyond its purposes.
Re: Part 10
#284 From: "JMA" <mail@...>
Date: Sun Feb 24, 2002 1:04 pm
Subject: Re: IBM OS/2 Open Source (was: Digest Number 9) mailjmase
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:
>On Sat, 23 Feb 2002 22:57:31 -0000, klaus_h_fuchs wrote:
>
>>> Even if IBM wanted to (which they don't), they can't since they are
>>> not the only ones that have rights to the code. And believe me, the
>>> other one(s) would definitely not support the idea
If you mean MS I'm not so sure. Would they admit they are still
affraid of OS/2 ? I a(nother) public petition was put to IBM and IBM
blamed the "other" copyright holder I wonder how MS would response
in public "No we dare not help release an opensource OS/2 since
it would be a serious threat to Windows"
>>
>
> 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".
>
Since the OS/2 source code is "leaked" this would be pretty easy to
check out. You people with the source could just read it through and
see what parts are IBM only or IBM shared with others.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Sun Feb 24, 2002 1:04 pm
Subject: Re: IBM OS/2 Open Source (was: Digest Number 9) mailjmase
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:
>On Sat, 23 Feb 2002 22:57:31 -0000, klaus_h_fuchs wrote:
>
>>> Even if IBM wanted to (which they don't), they can't since they are
>>> not the only ones that have rights to the code. And believe me, the
>>> other one(s) would definitely not support the idea
If you mean MS I'm not so sure. Would they admit they are still
affraid of OS/2 ? I a(nother) public petition was put to IBM and IBM
blamed the "other" copyright holder I wonder how MS would response
in public "No we dare not help release an opensource OS/2 since
it would be a serious threat to Windows"
>>
>
> 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".
>
Since the OS/2 source code is "leaked" this would be pretty easy to
check out. You people with the source could just read it through and
see what parts are IBM only or IBM shared with others.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 10
#285 From: "JMA" <mail@...>
Date: Sun Feb 24, 2002 1:30 pm
Subject: Re: NewOS mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sat, 23 Feb 2002 14:04:31 -0800 (PST), Jason Filby wrote:
>>-- JMA <mail@...> wrote:
>>>Wouldn't ReactOS -- aiming to be an NT clone -- be a better fit?
>>Why ?
>
As a OS/2 user I cannot resist ;>
From the back of my Windows NT 4 shrinkwrap package.
NT is a registered trademark of Northen Telecom Inc.
(If anyone wondered why I always say Win NT and not plain NT)
>>I dont know that much about kernels and I'm not capable to compare
>>alternatives but the Win NT kernel is far from modern.
>
>Well originally OS/2 and NT were the same thing -- jointly developed
>by IBM and MS. Then MS broke off and went their own way, at least,
>that's the story I read. Since NT supports subsystems on the kernel
>by design, an OS/2 subsystem is an easy addition. In fact, NT was
>once able to run some OS/2 apps (16 bit, I think) while OS/2 was able
>to run NT apps (but MS changed the API faster than what IBM could
>keep up).
>
You just gave a no answer or rather tell me that the Win NT kernel
is just like the OS/2 kernel an old hack.
>>Also, what as important for osFree is that the kernel is capable of
>>easily supporting the OS/2 APIs we need to implement.
>
>See above.
>
Yup, but (I hope) you are not going to release the Win NT kernel but
something built that will a) run Windows NT apps and b) run Windows
NT drivers. None of these tells it will be much like the Win NT kernel inside.
>>What I found out about ReactOS is that is uses lots of Linux code
>>and has very litte indication that it does. Does not say on the
>>webpage and does not say in the binary distro. But thats not hard to
>>fix I assume.
>
Source and inspiration from
WINE (http://www.winehq.com)
WinFree (http://www.stack.nl/~onno/win32/)
Linux (http://www.kernel.org)
There is Minix and ext2 and a vfat that has lots of Linux code.
And if you really did the code the tcpip layer yourself then hmmm.
Hey, I'm not saying you did anything wrong. Any opensource kernel
will reuse as much as possible or you would be dumb.
>ReactOS uses a layered microkernel (as does NT).
>
Win NT is no real mk and it has become less and less of a mk with
every release. You stand a good risk of getting flamed in a group
with lots of OS/2 users if you say that
>>If not we should graft it on the Linux kernel at once.
>>Linux is GNU opensource, has hoards of developers and lots
>>and lots of drivers.
>
>Linux is a monolith kernel -- that is the old design. NT (and
>ReactOS) use a layered microkernel design. Linux may have lots of
>drivers, but I think NT has much, much more. We aim for ReactOS to be
>able to use NT drivers. We're getting closer, especially since our
>registry is growing more and more complete.
>
Hmmm.
While this kernel thing is up to people that know much more than me
our objective is mainly above the kernel. We want to build a relativly
generic interface for the OS/2 api twards the kernel.
We could either build a OS/2 kernel clone that would allow us to use OS/2
drivers and make it very easy to graft the OS/2 API ontop.
Or we could choose a as modern as possible kernel with good driver
support and spend more time making a API layer.
I'm not saying your kernel is the wrong choice -
What I'm saying is that just since your kernel is built to be Win NT compatibe
does not mean its our best choice.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Sun Feb 24, 2002 1:30 pm
Subject: Re: NewOS mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sat, 23 Feb 2002 14:04:31 -0800 (PST), Jason Filby wrote:
>>-- JMA <mail@...> wrote:
>>>Wouldn't ReactOS -- aiming to be an NT clone -- be a better fit?
>>Why ?
>
As a OS/2 user I cannot resist ;>
From the back of my Windows NT 4 shrinkwrap package.
NT is a registered trademark of Northen Telecom Inc.
(If anyone wondered why I always say Win NT and not plain NT)
>>I dont know that much about kernels and I'm not capable to compare
>>alternatives but the Win NT kernel is far from modern.
>
>Well originally OS/2 and NT were the same thing -- jointly developed
>by IBM and MS. Then MS broke off and went their own way, at least,
>that's the story I read. Since NT supports subsystems on the kernel
>by design, an OS/2 subsystem is an easy addition. In fact, NT was
>once able to run some OS/2 apps (16 bit, I think) while OS/2 was able
>to run NT apps (but MS changed the API faster than what IBM could
>keep up).
>
You just gave a no answer or rather tell me that the Win NT kernel
is just like the OS/2 kernel an old hack.
>>Also, what as important for osFree is that the kernel is capable of
>>easily supporting the OS/2 APIs we need to implement.
>
>See above.
>
Yup, but (I hope) you are not going to release the Win NT kernel but
something built that will a) run Windows NT apps and b) run Windows
NT drivers. None of these tells it will be much like the Win NT kernel inside.
>>What I found out about ReactOS is that is uses lots of Linux code
>>and has very litte indication that it does. Does not say on the
>>webpage and does not say in the binary distro. But thats not hard to
>>fix I assume.
>
Source and inspiration from
WINE (http://www.winehq.com)
WinFree (http://www.stack.nl/~onno/win32/)
Linux (http://www.kernel.org)
There is Minix and ext2 and a vfat that has lots of Linux code.
And if you really did the code the tcpip layer yourself then hmmm.
Hey, I'm not saying you did anything wrong. Any opensource kernel
will reuse as much as possible or you would be dumb.
>ReactOS uses a layered microkernel (as does NT).
>
Win NT is no real mk and it has become less and less of a mk with
every release. You stand a good risk of getting flamed in a group
with lots of OS/2 users if you say that
>>If not we should graft it on the Linux kernel at once.
>>Linux is GNU opensource, has hoards of developers and lots
>>and lots of drivers.
>
>Linux is a monolith kernel -- that is the old design. NT (and
>ReactOS) use a layered microkernel design. Linux may have lots of
>drivers, but I think NT has much, much more. We aim for ReactOS to be
>able to use NT drivers. We're getting closer, especially since our
>registry is growing more and more complete.
>
Hmmm.
While this kernel thing is up to people that know much more than me
our objective is mainly above the kernel. We want to build a relativly
generic interface for the OS/2 api twards the kernel.
We could either build a OS/2 kernel clone that would allow us to use OS/2
drivers and make it very easy to graft the OS/2 API ontop.
Or we could choose a as modern as possible kernel with good driver
support and spend more time making a API layer.
I'm not saying your kernel is the wrong choice -
What I'm saying is that just since your kernel is built to be Win NT compatibe
does not mean its our best choice.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 10
#286 From: "sandervl2000" <sandervl2000@...>
Date: Sun Feb 24, 2002 3:02 pm
Subject: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) sandervl2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Jason Filby <jasonfilby@y...> wrote:
> Linux is a monolith kernel -- that is the old design. NT (and
> ReactOS) use a layered microkernel design. Linux may have lots of
> drivers, but I think NT has much, much more. We aim for ReactOS to
be
> able to use NT drivers. We're getting closer, especially since our
> registry is growing more and more complete.
Is ReactOS compatible with Windows 2000 drivers? You probably
know that the NT driver model has changed quite a bit in Win2k (PnP).
If ReactOS can't handle those drivers, then you will not be able
to use many recent drivers.
Although I respect what you and the ReactOS team are trying to do, I
think you are taking the wrong approach. I know from experience (I'm
the Odin lead developer) that it's hard to play catch-up with
Microsoft. Trying to be 100% compatible with MS from an application
point of view is difficult. Building a clone of the whole OS is
several orders of magnitude more difficult.
If your primary aim is to use NT/Win2k device drivers, then a far
easier
solution would be to build a compatibility layer on top of an existing
OS. That is possible as I have done this in OS/2 for Linux drivers (SB
Live) and for Win9x (a win9x audio driver I had to port).
To run win32 applications you obviously don't have to build an NT like
operating system from scratch.
Returning to the osFree subject. I and some other programmers I know
will never work on osFree or a derative of this project.A lot of
people on this list have strong opinions and ignore all legal issues.
The funny
thing is that most (if not all) of them are not programmers or don't
have the skills to work on an operating system.
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.
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)
Sander
Date: Sun Feb 24, 2002 3:02 pm
Subject: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) sandervl2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@y..., Jason Filby <jasonfilby@y...> wrote:
> Linux is a monolith kernel -- that is the old design. NT (and
> ReactOS) use a layered microkernel design. Linux may have lots of
> drivers, but I think NT has much, much more. We aim for ReactOS to
be
> able to use NT drivers. We're getting closer, especially since our
> registry is growing more and more complete.
Is ReactOS compatible with Windows 2000 drivers? You probably
know that the NT driver model has changed quite a bit in Win2k (PnP).
If ReactOS can't handle those drivers, then you will not be able
to use many recent drivers.
Although I respect what you and the ReactOS team are trying to do, I
think you are taking the wrong approach. I know from experience (I'm
the Odin lead developer) that it's hard to play catch-up with
Microsoft. Trying to be 100% compatible with MS from an application
point of view is difficult. Building a clone of the whole OS is
several orders of magnitude more difficult.
If your primary aim is to use NT/Win2k device drivers, then a far
easier
solution would be to build a compatibility layer on top of an existing
OS. That is possible as I have done this in OS/2 for Linux drivers (SB
Live) and for Win9x (a win9x audio driver I had to port).
To run win32 applications you obviously don't have to build an NT like
operating system from scratch.
Returning to the osFree subject. I and some other programmers I know
will never work on osFree or a derative of this project.A lot of
people on this list have strong opinions and ignore all legal issues.
The funny
thing is that most (if not all) of them are not programmers or don't
have the skills to work on an operating system.
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.
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)
Sander
Re: Part 10
#287 From: Jason Filby <jasonfilby@...>
Date: Sun Feb 24, 2002 3:29 pm
Subject: Re: NewOS jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- JMA <mail@...> wrote:
>As a OS/2 user I cannot resist ;>
>From the back of my Windows NT 4 shrinkwrap package.
>NT is a registered trademark of Northen Telecom Inc.
Heh -- you know which NT I meant, I'm sure
>You just gave a no answer or rather tell me that the Win NT kernel
>is just like the OS/2 kernel an old hack.
An "old hack"? How is the Win NT kernel a hack? Ok.. lets do some
research:
http://www.os2bbs.com/os2news/OS2Warp.html:
"The Windows NT kernel was partially based on the OS/2 kernel that
they created with IBM, and Windows 95 also borrows heavily from this
code."
Now from what you say, you want a kernel similar to that of OS/2. An
kernel designed to be like Win NT is the obvious answer because of
their history. Then you call both kernels "old hacks"... so you want
something more modern? Linux is based on Minux -- hardly a new
design! If you want to go for something much more cutting edge, like
NewOS, then fine. But don't say that NewOS is closer to the OS/2
kernel than ReactOS. What's more, the Win NT design has been proven
by years of widespread use. A cutting edge OS has not yet proven its
design in this way.
>Yup, but (I hope) you are not going to release the Win NT kernel
>but something built that will a) run Windows NT apps and b) run
>Windows NT drivers. None of these tells it will be much like the Win
>NT kernel inside.
In order to run Windows NT drivers, the kernel must provide APIs that
much what the drivers require. Our kernel follows the Win NT design
as close as we can, for compatibility.
>Source and inspiration from
>WINE (http://www.winehq.com)
>WinFree (http://www.stack.nl/~onno/win32/)
>Linux (http://www.kernel.org)
WINE is obvious for win32 -- reduce redundant coding. WinFree? Never
heard of it. Linux -- only for the internals of some functions --
_not_ for design.
>There is Minix and ext2 and a vfat that has lots of Linux code.
>And if you really did the code the tcpip layer yourself then hmmm.
Minix and ext2 will filesystem drivers will _obviously_ contain Linux
code. Why rewrite it all from scratch? The design of those drivers
still matches the design of a Win NT driver. I've not looked at the
TCPIP code myself -- who cares if a lot of the code came from Linux
or FreeBSD? Win NT's TCPIP stack is from *BSD! Honestly, what's the
problem, it still functions as an NT driver. Also, these are just
drivers, not the kernel.
>Hey, I'm not saying you did anything wrong. Any opensource kernel
>will reuse as much as possible or you would be dumb.
Of course -- we aim to reduce reinventing the wheel whereever
possible. It is one of the strengths of an Open Source project.
>Win NT is no real mk and it has become less and less of a mk with
>every release. You stand a good risk of getting flamed in a group
>with lots of OS/2 users if you say that
I never said it was a pure microkernel. Is OS/2 a pure microkernel? A
pure microkernel is not practical.
>While this kernel thing is up to people that know much more than me
>our objective is mainly above the kernel. We want to build a
>relativly generic interface for the OS/2 api twards the kernel.
>We could either build a OS/2 kernel clone that would allow us to
>use OS/2 drivers and make it very easy to graft the OS/2 API ontop.
Why would you care about OS/2 drivers? There are many more Win NT
drivers out there.
>Or we could choose a as modern as possible kernel with good driver
>support and spend more time making a API layer.
Well, you've heard my arguments for ReactOS.
>I'm not saying your kernel is the wrong choice -
>What I'm saying is that just since your kernel is built to be Win
>NT compatibe does not mean its our best choice.
What else could be better? What else has more driver support and a
design closer to that of the OS/2 kernel? What else has all of this
_and_ support for subsystems -- _designed_ so that an OS/2 subsystem
can be added.
- Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Date: Sun Feb 24, 2002 3:29 pm
Subject: Re: NewOS jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- JMA <mail@...> wrote:
>As a OS/2 user I cannot resist ;>
>From the back of my Windows NT 4 shrinkwrap package.
>NT is a registered trademark of Northen Telecom Inc.
Heh -- you know which NT I meant, I'm sure
>You just gave a no answer or rather tell me that the Win NT kernel
>is just like the OS/2 kernel an old hack.
An "old hack"? How is the Win NT kernel a hack? Ok.. lets do some
research:
http://www.os2bbs.com/os2news/OS2Warp.html:
"The Windows NT kernel was partially based on the OS/2 kernel that
they created with IBM, and Windows 95 also borrows heavily from this
code."
Now from what you say, you want a kernel similar to that of OS/2. An
kernel designed to be like Win NT is the obvious answer because of
their history. Then you call both kernels "old hacks"... so you want
something more modern? Linux is based on Minux -- hardly a new
design! If you want to go for something much more cutting edge, like
NewOS, then fine. But don't say that NewOS is closer to the OS/2
kernel than ReactOS. What's more, the Win NT design has been proven
by years of widespread use. A cutting edge OS has not yet proven its
design in this way.
>Yup, but (I hope) you are not going to release the Win NT kernel
>but something built that will a) run Windows NT apps and b) run
>Windows NT drivers. None of these tells it will be much like the Win
>NT kernel inside.
In order to run Windows NT drivers, the kernel must provide APIs that
much what the drivers require. Our kernel follows the Win NT design
as close as we can, for compatibility.
>Source and inspiration from
>WINE (http://www.winehq.com)
>WinFree (http://www.stack.nl/~onno/win32/)
>Linux (http://www.kernel.org)
WINE is obvious for win32 -- reduce redundant coding. WinFree? Never
heard of it. Linux -- only for the internals of some functions --
_not_ for design.
>There is Minix and ext2 and a vfat that has lots of Linux code.
>And if you really did the code the tcpip layer yourself then hmmm.
Minix and ext2 will filesystem drivers will _obviously_ contain Linux
code. Why rewrite it all from scratch? The design of those drivers
still matches the design of a Win NT driver. I've not looked at the
TCPIP code myself -- who cares if a lot of the code came from Linux
or FreeBSD? Win NT's TCPIP stack is from *BSD! Honestly, what's the
problem, it still functions as an NT driver. Also, these are just
drivers, not the kernel.
>Hey, I'm not saying you did anything wrong. Any opensource kernel
>will reuse as much as possible or you would be dumb.
Of course -- we aim to reduce reinventing the wheel whereever
possible. It is one of the strengths of an Open Source project.
>Win NT is no real mk and it has become less and less of a mk with
>every release. You stand a good risk of getting flamed in a group
>with lots of OS/2 users if you say that
I never said it was a pure microkernel. Is OS/2 a pure microkernel? A
pure microkernel is not practical.
>While this kernel thing is up to people that know much more than me
>our objective is mainly above the kernel. We want to build a
>relativly generic interface for the OS/2 api twards the kernel.
>We could either build a OS/2 kernel clone that would allow us to
>use OS/2 drivers and make it very easy to graft the OS/2 API ontop.
Why would you care about OS/2 drivers? There are many more Win NT
drivers out there.
>Or we could choose a as modern as possible kernel with good driver
>support and spend more time making a API layer.
Well, you've heard my arguments for ReactOS.
>I'm not saying your kernel is the wrong choice -
>What I'm saying is that just since your kernel is built to be Win
>NT compatibe does not mean its our best choice.
What else could be better? What else has more driver support and a
design closer to that of the OS/2 kernel? What else has all of this
_and_ support for subsystems -- _designed_ so that an OS/2 subsystem
can be added.
- Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Re: Part 10
#288 From: Jason Filby <jasonfilby@...>
Date: Sun Feb 24, 2002 3:34 pm
Subject: Re: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- sandervl2000 <sandervl2000@...> wrote:
>Is ReactOS compatible with Windows 2000 drivers? You probably
>know that the NT driver model has changed quite a bit in Win2k
>(PnP). If ReactOS can't handle those drivers, then you will not be
>able to use many recent drivers.
We are doing most of the work looking at Win NT. However, we are also
looking ahead to Win2k/XP drivers. We aren't there yet, but we're
working on it.
>Although I respect what you and the ReactOS team are trying to do,
>I think you are taking the wrong approach. I know from experience
>(I'm the Odin lead developer) that it's hard to play catch-up with
>Microsoft. Trying to be 100% compatible with MS from an application
>point of view is difficult. Building a clone of the whole OS is
>several orders of magnitude more difficult.
Well I think Miguel (of GNOME fame) said it best about MONO:
We will try to be compatible -- and being Open Source helps. Even if
MS change too quickly for us, we at least have a great OS design --
for free.
>If your primary aim is to use NT/Win2k device drivers, then a far
>easier solution would be to build a compatibility layer on top of an
>existing OS. That is possible as I have done this in OS/2 for Linux
>drivers (SB Live) and for Win9x (a win9x audio driver I had to
port).
Most of our developers prefer the design of the Win NT kernel to that
of Linux.
>To run win32 applications you obviously don't have to build an NT
>like operating system from scratch.
All in all, the crazy people down at reactos.com think this is the
best approach. Look at WINE -- even though they are getting really
close to application compatibility, they'll never get 100% because of
trying to run win32 apps on Linux, which is a different OS design.
- Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Date: Sun Feb 24, 2002 3:34 pm
Subject: Re: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- sandervl2000 <sandervl2000@...> wrote:
>Is ReactOS compatible with Windows 2000 drivers? You probably
>know that the NT driver model has changed quite a bit in Win2k
>(PnP). If ReactOS can't handle those drivers, then you will not be
>able to use many recent drivers.
We are doing most of the work looking at Win NT. However, we are also
looking ahead to Win2k/XP drivers. We aren't there yet, but we're
working on it.
>Although I respect what you and the ReactOS team are trying to do,
>I think you are taking the wrong approach. I know from experience
>(I'm the Odin lead developer) that it's hard to play catch-up with
>Microsoft. Trying to be 100% compatible with MS from an application
>point of view is difficult. Building a clone of the whole OS is
>several orders of magnitude more difficult.
Well I think Miguel (of GNOME fame) said it best about MONO:
We will try to be compatible -- and being Open Source helps. Even if
MS change too quickly for us, we at least have a great OS design --
for free.
>If your primary aim is to use NT/Win2k device drivers, then a far
>easier solution would be to build a compatibility layer on top of an
>existing OS. That is possible as I have done this in OS/2 for Linux
>drivers (SB Live) and for Win9x (a win9x audio driver I had to
port).
Most of our developers prefer the design of the Win NT kernel to that
of Linux.
>To run win32 applications you obviously don't have to build an NT
>like operating system from scratch.
All in all, the crazy people down at reactos.com think this is the
best approach. Look at WINE -- even though they are getting really
close to application compatibility, they'll never get 100% because of
trying to run win32 apps on Linux, which is a different OS design.
- Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Re: Part 10
#289 From: "JMA" <mail@...>
Date: Sun Feb 24, 2002 3:52 pm
Subject: Re: NewOS mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 24 Feb 2002 04:29:17 -0800 (PST), Jason Filby wrote:
>--- JMA <mail@...> wrote:
>>As a OS/2 user I cannot resist ;>
>>From the back of my Windows NT 4 shrinkwrap package.
>>NT is a registered trademark of Northen Telecom Inc.
>
>Heh -- you know which NT I meant, I'm sure
>
Thats not the point. There is a reason why Microsoft put this on their package.
And your in a OS/2 group, just a fair warning
>>You just gave a no answer or rather tell me that the Win NT kernel
>>is just like the OS/2 kernel an old hack.
>
>An "old hack"? How is the Win NT kernel a hack? Ok.. lets do some
>research:
>
>http://www.os2bbs.com/os2news/OS2Warp.html:
>"The Windows NT kernel was partially based on the OS/2 kernel that
>they created with IBM, and Windows 95 also borrows heavily from this
>code."
>
>Now from what you say, you want a kernel similar to that of OS/2.
>
No, I seems people prefer either want a *very* similar kernel or a as
modern kernel as possible. I would like to build a generic OS/2
API layer allowing us to (with mixed workload though) graft it on
almost any kernel.
>Then you call both kernels "old hacks"...
>
Did I ever call the OS/2 kernel anything else that a old hack. Its is !
But since our objective is to run OS/2 binaries (as yours are to run
Windows binaries) a *very* OS/2 alike kernel would help us.
>If you want to go for something much more cutting edge, like
>NewOS, then fine. But don't say that NewOS is closer to the OS/2
>kernel than ReactOS. What's more, the Win NT design has been proven
>by years of widespread use. A cutting edge OS has not yet proven its
>design in this way.
>
Yes, a cutting edge kernel is mush less tested.
But the OS/2 kernel is as or even more tested than the Windows NT kernel.
Also, you are not building a Windows NT kernel - you are mimicing it, just
like we would mimic the OS/2 kernel if we decided to go that way.
Unless you base your kernel on the real Windows NT kernel source it will
be as untested as anything else. You cannot do that, we cannot (and have
little interest) of doing that.
>>Yup, but (I hope) you are not going to release the Win NT kernel
>>but something built that will a) run Windows NT apps and b) run
>>Windows NT drivers. None of these tells it will be much like the Win
>>NT kernel inside.
>
>In order to run Windows NT drivers, the kernel must provide APIs that
>much what the drivers require. Our kernel follows the Win NT design
>as close as we can, for compatibility.
>
>>Source and inspiration from
>>WINE (http://www.winehq.com)
>>WinFree (http://www.stack.nl/~onno/win32/)
>>Linux (http://www.kernel.org)
>
>WINE is obvious for win32 -- reduce redundant coding. WinFree? Never
>heard of it. Linux -- only for the internals of some functions --
>_not_ for design.
>
THIS TEXT IS FROM THE README FILE IN YOUR OWN SOURCE DISTRO.
I DOWNLOADED IT TODAY !
Something is wrong, I though you were the maintainer of ReactOS ??
>>Win NT is no real mk and it has become less and less of a mk with
>>every release. You stand a good risk of getting flamed in a group
>>with lots of OS/2 users if you say that
>
>I never said it was a pure microkernel. Is OS/2 a pure microkernel? A
>pure microkernel is not practical.
>
While a do agree, get ready to be flamed
PS: Dont even get close to the FreeOS yahoogroup ;--)
>>While this kernel thing is up to people that know much more than me
>>our objective is mainly above the kernel. We want to build a
>>relativly generic interface for the OS/2 api twards the kernel.
>>We could either build a OS/2 kernel clone that would allow us to
>>use OS/2 drivers and make it very easy to graft the OS/2 API ontop.
>
>Why would you care about OS/2 drivers? There are many more Win NT
>drivers out there.
>
Yes, but ReactOS still dont have that support in place, does it ?
>>I'm not saying your kernel is the wrong choice -
>>What I'm saying is that just since your kernel is built to be Win
>>NT compatibe does not mean its our best choice.
>
>What else could be better? What else has more driver support and a
>design closer to that of the OS/2 kernel? What else has all of this
>_and_ support for subsystems -- _designed_ so that an OS/2 subsystem
>can be added.
>
Linux would be the best choice if I had anything to say.
Its opensource, developed by hoards of people, there are mk distros and
its quite mature.
Would it be much harder to put our OS/2 API layer ontop a Linux kernel
than ontop any other kernel ? The only other kernel I would think to be
easier is the Windows kernel (the real one I mean) but thats out of the
question in so many ways.
Linux is mature, very well known, has everything we need though maybe
not in a perfect way. It would be the perfect place to (at least test)
implementing
a OS/2 API layer.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Sun Feb 24, 2002 3:52 pm
Subject: Re: NewOS mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 24 Feb 2002 04:29:17 -0800 (PST), Jason Filby wrote:
>--- JMA <mail@...> wrote:
>>As a OS/2 user I cannot resist ;>
>>From the back of my Windows NT 4 shrinkwrap package.
>>NT is a registered trademark of Northen Telecom Inc.
>
>Heh -- you know which NT I meant, I'm sure
>
Thats not the point. There is a reason why Microsoft put this on their package.
And your in a OS/2 group, just a fair warning
>>You just gave a no answer or rather tell me that the Win NT kernel
>>is just like the OS/2 kernel an old hack.
>
>An "old hack"? How is the Win NT kernel a hack? Ok.. lets do some
>research:
>
>http://www.os2bbs.com/os2news/OS2Warp.html:
>"The Windows NT kernel was partially based on the OS/2 kernel that
>they created with IBM, and Windows 95 also borrows heavily from this
>code."
>
>Now from what you say, you want a kernel similar to that of OS/2.
>
No, I seems people prefer either want a *very* similar kernel or a as
modern kernel as possible. I would like to build a generic OS/2
API layer allowing us to (with mixed workload though) graft it on
almost any kernel.
>Then you call both kernels "old hacks"...
>
Did I ever call the OS/2 kernel anything else that a old hack. Its is !
But since our objective is to run OS/2 binaries (as yours are to run
Windows binaries) a *very* OS/2 alike kernel would help us.
>If you want to go for something much more cutting edge, like
>NewOS, then fine. But don't say that NewOS is closer to the OS/2
>kernel than ReactOS. What's more, the Win NT design has been proven
>by years of widespread use. A cutting edge OS has not yet proven its
>design in this way.
>
Yes, a cutting edge kernel is mush less tested.
But the OS/2 kernel is as or even more tested than the Windows NT kernel.
Also, you are not building a Windows NT kernel - you are mimicing it, just
like we would mimic the OS/2 kernel if we decided to go that way.
Unless you base your kernel on the real Windows NT kernel source it will
be as untested as anything else. You cannot do that, we cannot (and have
little interest) of doing that.
>>Yup, but (I hope) you are not going to release the Win NT kernel
>>but something built that will a) run Windows NT apps and b) run
>>Windows NT drivers. None of these tells it will be much like the Win
>>NT kernel inside.
>
>In order to run Windows NT drivers, the kernel must provide APIs that
>much what the drivers require. Our kernel follows the Win NT design
>as close as we can, for compatibility.
>
>>Source and inspiration from
>>WINE (http://www.winehq.com)
>>WinFree (http://www.stack.nl/~onno/win32/)
>>Linux (http://www.kernel.org)
>
>WINE is obvious for win32 -- reduce redundant coding. WinFree? Never
>heard of it. Linux -- only for the internals of some functions --
>_not_ for design.
>
THIS TEXT IS FROM THE README FILE IN YOUR OWN SOURCE DISTRO.
I DOWNLOADED IT TODAY !
Something is wrong, I though you were the maintainer of ReactOS ??
>>Win NT is no real mk and it has become less and less of a mk with
>>every release. You stand a good risk of getting flamed in a group
>>with lots of OS/2 users if you say that
>
>I never said it was a pure microkernel. Is OS/2 a pure microkernel? A
>pure microkernel is not practical.
>
While a do agree, get ready to be flamed
PS: Dont even get close to the FreeOS yahoogroup ;--)
>>While this kernel thing is up to people that know much more than me
>>our objective is mainly above the kernel. We want to build a
>>relativly generic interface for the OS/2 api twards the kernel.
>>We could either build a OS/2 kernel clone that would allow us to
>>use OS/2 drivers and make it very easy to graft the OS/2 API ontop.
>
>Why would you care about OS/2 drivers? There are many more Win NT
>drivers out there.
>
Yes, but ReactOS still dont have that support in place, does it ?
>>I'm not saying your kernel is the wrong choice -
>>What I'm saying is that just since your kernel is built to be Win
>>NT compatibe does not mean its our best choice.
>
>What else could be better? What else has more driver support and a
>design closer to that of the OS/2 kernel? What else has all of this
>_and_ support for subsystems -- _designed_ so that an OS/2 subsystem
>can be added.
>
Linux would be the best choice if I had anything to say.
Its opensource, developed by hoards of people, there are mk distros and
its quite mature.
Would it be much harder to put our OS/2 API layer ontop a Linux kernel
than ontop any other kernel ? The only other kernel I would think to be
easier is the Windows kernel (the real one I mean) but thats out of the
question in so many ways.
Linux is mature, very well known, has everything we need though maybe
not in a perfect way. It would be the perfect place to (at least test)
implementing
a OS/2 API layer.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 10
#290 From: "JMA" <mail@...>
Date: Sun Feb 24, 2002 4:05 pm
Subject: Re: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 24 Feb 2002 12:02:10 -0000, sandervl2000 wrote:
>Returning to the osFree subject. I and some other programmers I know
>will never work on osFree or a derative of this project.A lot of
>people on this list have strong opinions and ignore all legal issues.
>
Ignoring any legal aspect that I'm trying to get rid of *very* hard !
What stops you from participating ?
>
>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.
>
FreeOS is talk <period>
>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)
>
I agree that we should try to rip out what we want(*) and place it
onto a suitable kernel. I would recomend exploring Linux since
all its benefits.
(*)
What I would want is binary compatibility for OS/2 usermode programs
and things like batchfiles. To do that I thing we should start with a
OS/2 API layer and a loader that would allow us to run ontop a test
kernel (Linux). we should try to build the API layer/loader using a
layered approach where most "doscalls1" stuff can be reused if we
select to use another kernel.
Ontop of that other developers simulatniously should be command line
tools (yes they are needed) and our PM/WPS implementation.
Supporting lots of operating systems using a personality layer method
is a great thing but its aiming to high *for just us*. Other groups are/should
work with that, we should concentrate on the OS/2 compatible personality.
Parts of the ReactOS team could concentrate on the Windows personality with
help from the Wine team.
I must give Timur Tabu credit for the thought of placing a OS/2 layer ontop
Linux.
I supported him in the FreeOS list but the reaction got me to unsubcribe.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Sun Feb 24, 2002 4:05 pm
Subject: Re: ReactOS / base for OS/2 compatible kernel (Was Re: NewOS) mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sun, 24 Feb 2002 12:02:10 -0000, sandervl2000 wrote:
>Returning to the osFree subject. I and some other programmers I know
>will never work on osFree or a derative of this project.A lot of
>people on this list have strong opinions and ignore all legal issues.
>
Ignoring any legal aspect that I'm trying to get rid of *very* hard !
What stops you from participating ?
>
>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.
>
FreeOS is talk <period>
>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)
>
I agree that we should try to rip out what we want(*) and place it
onto a suitable kernel. I would recomend exploring Linux since
all its benefits.
(*)
What I would want is binary compatibility for OS/2 usermode programs
and things like batchfiles. To do that I thing we should start with a
OS/2 API layer and a loader that would allow us to run ontop a test
kernel (Linux). we should try to build the API layer/loader using a
layered approach where most "doscalls1" stuff can be reused if we
select to use another kernel.
Ontop of that other developers simulatniously should be command line
tools (yes they are needed) and our PM/WPS implementation.
Supporting lots of operating systems using a personality layer method
is a great thing but its aiming to high *for just us*. Other groups are/should
work with that, we should concentrate on the OS/2 compatible personality.
Parts of the ReactOS team could concentrate on the Windows personality with
help from the Wine team.
I must give Timur Tabu credit for the thought of placing a OS/2 layer ontop
Linux.
I supported him in the FreeOS list but the reaction got me to unsubcribe.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================