Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9131

Re: New OS opportunities?

Show key headers only | View raw

On Sat, 23 Jan 2016 10:37:52 +0000
James Harris <james.harris.1@gmail.com> wrote:
> On 22/01/2016 23:07, Rod Pemberton wrote:

> > Just a quick comment on new OS opportunities ...
> >
> > It appears we have at least two newer methods of
> > creating an OS from existing components:
> >
> > 1) libSDL and OpenGL  
> 
> AFAICS that would require there to be a host OS.

I'm not sure what back end libSDL needs, but if it's like most code,
then it could use an OS library, like those which you cited, or be
rewritten for direct use on hardware.  I'm sure more than a few people
have "failed" or stalled OS projects that could be used.

> > 2) Node.js and Google V8 (Javascript engine)  
> 
> AFAICS you mean to run such an OS under the V8 JavaScript engine.

Node.js, from the brief description I read, is a fully scalable
execution environment for V8 JavaScript code.  So, it's essentially
a bare bones OS in the sense that you can run apps, CLIs, and GUIs,
etc upon the execution environment.  Supposedly, it only requires a
small bit of low-level host I/O too.

> [...]

IMO, the key bit for both combinations being used as the base of
an OS is popularity of code being developed for these code bases.
OpenGL and libSDL already have numerous applications and games
written for them.  Node.js is going to have much gaming and web
server code written for it. So, I think it's worthwhile to
attempt to use them as the base of an OS.

Depending on an inventory of what each project implements, it might
make more sense to do something like, Google V8 and libSDL and OpenGL
on top of Node.js, plus low-level etc. That should provide, graphics
(OpenGL), portable hardware (libSDL), gaming, networking, and execution
environment (Google V8).

> Since both of the above require some form of hosting how are you 
> defining the term "OS"? It would apparently not include direct
> hardware control.

It may require a little or a lot, but either way, it appears to
me that a large portion of the work for implementing an OS has
been completed, is available for free, and has access to a large
amount or potentially large amount of modern code.  I.e., you
just need to get libSDL and/or Node.js executing on your environment
to act as the core of the OS.

> While we are talking about using ready-made components there are
> also these
> 
>    https://www.cs.utah.edu/flux/oskit/
>    http://cottontail-os.tripod.com/
>    http://oslib.sourceforge.net/overview.html
> 
> I have not used any of them but they seem to provide lower-level
> control.

Of course, there are other projects, similar to Flux OSKit, like
Coreboot's (LinuxBIOS) FILO project which provides all of Linux'
device driver code which could also be used in/for the back end.

Yes, I've mentioned Flux OSKit and OSLib in the past on various
newsgroups including a.o.d., c.o.m.d., comp.programming, etc,
i.e., 2006, 2009, 2013, 2015.

I have CottonTail bookmarked twice, but recently, in 2013 instead
of 2007 or so.  Maybe you mentioned it a few years ago.

OSLib is used for FreeDOS-32.  This project stalled circa 2007.
It was making some great progress at implementing a 32-bit DOS.
I ran what they had developed, and it worked very well.  It
wasn't designed the way I would've done things, but the way
they combined the two or perhaps three code bases, worked.

Flux OSKit is used with MOSS which is a DOS Extender. This was
for the game called Inner Worlds by Bryan Ford.  The game ran
very well on my last machine.  I don't think I've tried it on
this one, but suspect it'll run just as flawlessly.  It looks
like a late 1980's arcade video game.  Of course, we have MAME
and MESS projects today to emulate arcade games and consoles.
I discussed porting/reworking this in 2009 with Rugxulo on
comp.os.msdos.djgpp.  The first big problem for me was the BSD
code was littered with numerous licenses.  The second problem
was that the BSD library was modified to work with the MOSS DOS
Extender.  I.e., it didn't make sense to replace the BSD library
with DJGPP's.  It might make sense to compile it with OpenWatcom,
since OW produces fast code and BSD code is usually fast too.
Of course, the OSKit hasn't been maintained.  I.e., you get old
BSD code.  Since I was working on my own OS at the time, I felt
that updating or actually recreating an updated version of the
Flux OSKit from BSD code was simply too much work for me.


Rod Pemberton

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

New OS opportunities? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-22 18:07 -0500
  Re: New OS opportunities? James Harris <james.harris.1@gmail.com> - 2016-01-23 10:37 +0000
    Re: New OS opportunities? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:24 -0500
      Re: New OS opportunities? James Harris <james.harris.1@gmail.com> - 2016-01-27 13:48 +0000
        Re: New OS opportunities? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-27 16:34 -0500
          Re: New OS opportunities? James Harris <james.harris.1@gmail.com> - 2016-01-28 09:48 +0000
            Re: New OS opportunities? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-28 19:30 -0500
          Re: New OS opportunities? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-01-28 23:00 -0800

csiph-web