[openbeos] Re: Hi from the PetrOS camp.

  • From: Peter Tattam <peter@xxxxxxxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 8 Nov 2001 18:13:12 +1100 (EST)

Fair enough.  However, I can see the OpenBeos project being split into two
parts that could operate in parallel to complete the project faster and
allowing for the BeOS API to be ported to other operating systems.  If you know
of alternative projects which might be more suitable, I'd be interested.

To answer your other question as to what we'd gain, well we'd gain possibly a
larger user base than we might get if we stuck to Win32 only, plus it would
demonstrate that our OS is more powerful than being just a Win32 workalike.
The design philosophy is of being able to support more than one user API.

If the idea works well, your project might gain a little momentum and perhaps
credibility from a commercial point of view by having a commercial developer
willing to work with you.

So I guess the answer is "thanks, but no thanks", no?


On Thu, 8 Nov 2001, Daniel Reinhold wrote:

> Hello Peter!
> I think it's interesting that you are aware of OpenBeOS and are 
> offering kernel support for it. I'm a bit confused as to what you 
> (Trumpet Software) would get out of such an endeavor. A licensing deal, 
> I presume? I would need to hear more specifics about that before I 
> could really say one way or the other.
> For myself, I'm perfectly happy with the path we've chosen with using 
> NewOS. Outsourcing the kernel would have some obvious advantages, but 
> it would also have some drawbacks. The idea of designing our own kernel 
> was that the source code for the entire OS from top to bottom would be 
> in our hands and under our control. Unless NewOS has hit some major 
> obstacle that has the kernel team ready to jump ship, I would prefer to 
> continue the track we have already chosen.
> >
> >Hi.  Just thought I'd introduce myself.
> >
> >I have been talking to Michael Phipps about the possibility of 
> building a
> >BeOS layer to our PetrOS operating system.
> >
> >We have a lot of the hard work of networking, OS kernel design and 
> stuff, and
> >our kernel probably has facilities close to that which a BeOS user
> >implementation might require.
> >
> >While we also do Win32, I've tried to design our kernel so that it's 
> not tied
> >to any one OS philosophy.
> >
> >Anyway, after discussions with Michael, we think we could get some 
> suitable
> >layer that could graft a beOS subsystem onto it by doing two things.
> >
> >1) creating a BeOS kernel driver module to provide BeOS kernel 
> services.
> >
> >2) adding an ELF loader as another executable format supported by 
> PetrOS. Our
> >native format is PE executables.
> >
> >Although you are working on your own OS, I estimate that the bulk of 
> your work
> >is likely to be at the application layer, not the 1/3 as suggested by 
> some.  If
> >we can provide some basic kernel services, it may be a way to 
> acceralte your
> >development.   Also as our networking stack and FS drivers are fairly 
> mature,
> >you could save yourselves the headaches of reinventing the wheel.
> >
> >What is the general opinion and consensus regarding our suggested 
> input into
> >the project?
> >
> >Regards
> >
> >Peter
> >
> >--
> >Peter R. Tattam                            peter@xxxxxxxxxxx
> >Managing Director,    Trumpet Software International Pty Ltd
> >Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> >
> >

Peter R. Tattam                            peter@xxxxxxxxxxx
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

Other related posts: