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

Groups > alt.os.development > #9124 > unrolled thread

New OS opportunities?

Back to article view | Back to alt.os.development

Contents

  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

#9124 — New OS opportunities?

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

2) Node.js and Google V8 (Javascript engine)

BFN,


Rod Pemberton

[toc] | [next] | [standalone]

#9125

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.

> 2) Node.js and Google V8 (Javascript engine)

AFAICS you mean to run such an OS under the V8 JavaScript engine.

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.

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.

James

[toc] | [prev] | [next] | [standalone]

#9131

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

[toc] | [prev] | [next] | [standalone]

#9139

On 23/01/2016 18:24, Rod Pemberton wrote:
> 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.

AFAICT it needs an underlying OS, as is true of any normal library.

>>> 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.

Isn't node.js a library of components written in JavaScript and thus 
needing a JS engine to run on ... which, itself, would need a host OS?

>> [...]
>
> 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).

It might be worth porting LibSDL to one's own OS and implementing or 
porting a JS engine. Then the above could be used. But I am not sure 
that any of the above will get you direct hardware control. I might be 
wrong, though. These are not packages that I am familiar with.

James

[toc] | [prev] | [next] | [standalone]

#9145

On Wed, 27 Jan 2016 13:48:22 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 23/01/2016 18:24, Rod Pemberton wrote:
> > 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.  
> 
> AFAICT it needs an underlying OS, as is true of any normal library.

I'm not sure why you're always fixated on needing a host OS.

Unix and POSIX OSes are coded in C and use the exact same C
libraries that they host.  This isn't a catch-22.  Yes, it
is a bootstrap, porting, and/or cross-compiling issue.  I.e.,
Linux can produce it's own kernel, DOS probably could too.
And, you're well aware of compiler flags that can eliminate
dependence on host specific code, or allow code to be
cross-compiled.  E.g., I coded my OS using C and portions of
the C library intended for another OS ...

Think of doing this as a dynamic process.  You do a bit of
work either porting or filling in the back-end, develop,
re-work, which allows you to do more, implement more, repeat
until working.  At some point, you must produce standalone
bootable code, and then develop the ability to execute other
code.

Languages were once coded in assembly, rewritten in the host
language, and then bootstrapped via the assembly executable.
If you ever tried out Steve Dubrovich's Small C code, then
you know exactly how this works.  Assemble the NASM code, use
the executable to bootstrap the C code via repeated compilation.
I'm sure Alexei Frounze's Smaller C is bootstrapped similarly,
but perhaps with existing C compilers.

> >>> 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.  
> 
> Isn't node.js a library of components written in JavaScript and thus 
> needing a JS engine to run on ... which, itself, would need a host OS?

I wouldn't call it a library:

"Dahl presented Node.js, which combined Google's V8
JavaScript engine, an event loop and a low-level I/O API."
https://en.wikipedia.org/wiki/Node.js

So, he wrote an event loop.  :-)

Apparently, it needs "libuv" too.  It doesn't sound like
he did much, other than give JavaScript the ability to
access low-level I/O and run other JavaScript code.

Yes, you'll most likely need to figure out how to compile
JavaScript for your OS, i.e., port it, and/or bootstrap it,
cross-compile it, and/or whatever else from a host OS, e.g.,
Windows or Linux.

> >> [...]  
> >
> > 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).  
> 
> It might be worth porting LibSDL to one's own OS and implementing or 
> porting a JS engine. Then the above could be used. But I am not sure 
> that any of the above will get you direct hardware control. I might
> be wrong, though. These are not packages that I am familiar with.

Early Linux only had 40 OS functions, while modern Linux has
over 290 syscalls.  A few C libraries only need 18 external
functions.  I.e., many such libraries are only dependent on
a small amount of external functionality.  So, it still might
be easy to implement.

I haven't inventoried what is required for either.  I'd think
it's likely that libSDL might be ported to a game machine or
embedded environment.  If so, then libSDL likely already has
the basic low-level code functionality for an external I/O API
implemented as part of the main library.  If present, that would
need to be ported or reworked for your target.  It's entirely
possible that it might even have host-specific low-level I/O,
like GNU's GLIBC C library, which can be used as a template.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9148

On 27/01/2016 21:34, Rod Pemberton wrote:
> On Wed, 27 Jan 2016 13:48:22 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
>> On 23/01/2016 18:24, Rod Pemberton wrote:
>>> 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.
>>
>> AFAICT it needs an underlying OS, as is true of any normal library.
>
> I'm not sure why you're always fixated on needing a host OS.

I am not 'fixated' on needing a host OS but it seemed to me that the 
main problem with your two suggestions was that unless there was an 
existing OS they would not work. (That's fine if that's what you want.)

> Unix and POSIX OSes are coded in C and use the exact same C
> libraries that they host.  This isn't a catch-22.  Yes, it
> is a bootstrap, porting, and/or cross-compiling issue.  I.e.,
> Linux can produce it's own kernel, DOS probably could too.
> And, you're well aware of compiler flags that can eliminate
> dependence on host specific code, or allow code to be
> cross-compiled.  E.g., I coded my OS using C and portions of
> the C library intended for another OS ...
>
> Think of doing this as a dynamic process.  You do a bit of
> work either porting or filling in the back-end, develop,
> re-work, which allows you to do more, implement more, repeat
> until working.  At some point, you must produce standalone
> bootable code, and then develop the ability to execute other
> code.

Yes, though isn't there a big transition from using Clib calls and 
syscalls in order to get the existing OS to make things happen, to 
having to do the following?

1. handling interrupts yourself
2. controlling hardware directly (needing an IO subsystem design, and 
drivers for each device type)
3. separating address spaces and running multiple tasks

It is not just a case of handling system calls. You would also need to 
mimic certain features of the OS that once was the host.

One of the worst potential examples of that: Imagine that you started 
from a Windows host. Some software installed on it might expect scores 
or even hundreds of system calls to work as they do in Windows. And to 
implement those system calls adequately you might need a bunch of 
structures that Windows uses such as a basic Windows registry. And you 
might need to pre-populate that registry with many settings that Windows 
provides. And, if so, you need to find out what those settings are.

That said, there may be more mileage if you start from an old Unix, as 
long as it could run Node.js or LibSDL etc. That could have fewer system 
calls and simpler structures to replicate.

> Languages were once coded in assembly, rewritten in the host
> language, and then bootstrapped via the assembly executable.

Yes. And I agree that something similar /could/ be done to develop an 
OS. I was going to say that it could be a lot of work. But, I suppose, 
that's true of any route to an independent OS.

James

[toc] | [prev] | [next] | [standalone]

#9155

On Thu, 28 Jan 2016 09:48:18 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 27/01/2016 21:34, Rod Pemberton wrote:
> > On Wed, 27 Jan 2016 13:48:22 +0000
> > James Harris <james.harris.1@gmail.com> wrote:
> >> On 23/01/2016 18:24, Rod Pemberton wrote:  
> >>> 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.  
> >>
> >> AFAICT it needs an underlying OS, as is true of any normal
> >> library.  
> >
> > I'm not sure why you're always fixated on needing a host OS.  
> 
> I am not 'fixated' on needing a host OS but it seemed to me that the 
> main problem with your two suggestions was that unless there was an 
> existing OS they would not work. (That's fine if that's what you
> want.)

I'd doubt that a full featured OS is required.  Best case scenario
is that only a minimal amount of low-level code is needed.  The
next best case scenario is that a microkernel with module support
and drivers for a few devices is needed.  There are a bunch of
those now.  I'd really doubt that a full featured OS like Windows
or Linux would be required.

> > Unix and POSIX OSes are coded in C and use the exact same C
> > libraries that they host.  This isn't a catch-22.  Yes, it
> > is a bootstrap, porting, and/or cross-compiling issue.  I.e.,
> > Linux can produce it's own kernel, DOS probably could too.
> > And, you're well aware of compiler flags that can eliminate
> > dependence on host specific code, or allow code to be
> > cross-compiled.  E.g., I coded my OS using C and portions of
> > the C library intended for another OS ...
> >
> > Think of doing this as a dynamic process.  You do a bit of
> > work either porting or filling in the back-end, develop,
> > re-work, which allows you to do more, implement more, repeat
> > until working.  At some point, you must produce standalone
> > bootable code, and then develop the ability to execute other
> > code.  
> 
> Yes, though isn't there a big transition from using Clib calls and 
> syscalls in order to get the existing OS to make things happen, to 
> having to do the following?
> 
> 1. handling interrupts yourself
> 2. controlling hardware directly (needing an IO subsystem design, and 
> drivers for each device type)
> 3. separating address spaces and running multiple tasks

I'm not familiar with Node.js, but I think it said it:

1) used a shared address space
2) runs multiple tasks

So, #3 wouldn't or shouldn't apply to it.

#2 is unknown by me.  It may or may not.  It most likely
needs at least file I/O, which doesn't necessarily require
device drivers and and I/O subsystem.  If all it needs is
file I/O via JavaScript, then it definitely wouldn't need
full filesystem functionality.

#1 is unknown by me.  It may or may not.  This depends on
whether a given machine is an interrupt driven design or not.
On x86, you'd need some code to handle hardware interrupts
at least for keyboard, mouse, drives, if you're not using
the BIOS.  You'd need ethernet drivers too.  And, you may
need to handle some software interrupts when using the BIOS.

> It is not just a case of handling system calls.
> You would also need to mimic certain features of
> the OS that once was the host.

s/would/may/

Both of these supposedly work on multiple hosts, which means
there is a high likelihood that it supports a variety of OS
features that could reduce, minimize, or simulate what is
needed.  E.g., the code might support signals or emulate
interrupts for hosts which don't have them.

> One of the worst potential examples of that: Imagine that you started 
> from a Windows host. Some software installed on it might expect
> scores or even hundreds of system calls to work as they do in
> Windows.

Sure, that why I started my OS development using DOS, i.e.,
minimal constraints.  In this case, someone would need to
find the bottleneck, or cutoff point which has the fewest
constraints for the developer, use that, then rework later
to eliminate Windows replacement code.

> And to implement those system calls adequately you might
> need a bunch of structures that Windows uses such as a basic Windows
> registry. And you might need to pre-populate that registry with many
> settings that Windows provides. And, if so, you need to find out what
> those settings are.

Yes, but much of such code can be implemented with limited
functionality.  E.g., the KernelEx project enhances Windows
98/SE with some additional functionality and "dummy" functions.
The latter fail with specific failure codes.  This allows most
code from Windows NT, 2000, XP, Vista, and even some for 7 to
run on Windows 98/SE.  The code is forced to use enhanced
functionality, or fallback to implemented functionality,
or fail using the most compatible failure method.  Windows
10 now has a similar compatibility feature which does basically
the same thing.

> That said, there may be more mileage if you start from an old Unix,
> as long as it could run Node.js or LibSDL etc. That could have fewer
> system calls and simpler structures to replicate.

Obviously, someone would need to inventory what is required
for each and attempt to find the best bootstrap solution.

> > Languages were once coded in assembly, rewritten in the host
> > language, and then bootstrapped via the assembly executable.  
> 
> Yes. And I agree that something similar /could/ be done to
> develop an OS. I was going to say that it could be a lot of
> work. But, I suppose, that's true of any route to an
> independent OS.

Be an optimist.  It could be, but doesn't necessarily have to be.

E.g., I once "ported" InfoZip to a system which it didn't support.
I only needed to select a host which was close in functionality
to my host, and then patch in some code from other supported hosts
for the missing features.  InfoZip had been ported to so many systems
that everything I needed was present, but not assembled correctly
for my host OS.  I personally suspect that other widely ported code
may be very similar.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9157

On Wednesday, January 27, 2016 at 1:34:16 PM UTC-8, Rod Pemberton wrote:
...
> Languages were once coded in assembly, rewritten in the host
> language, and then bootstrapped via the assembly executable.
> If you ever tried out Steve Dubrovich's Small C code, then
> you know exactly how this works.  Assemble the NASM code, use
> the executable to bootstrap the C code via repeated compilation.
> I'm sure Alexei Frounze's Smaller C is bootstrapped similarly,
> but perhaps with existing C compilers.

Early versions were indeed compiled with existing compilers.
But since I made it an early goal to make it compile itself
and the code was (and still is) quite restricted in terms of
the language and the library functions used (no struct,
no typedef, no enum used internally (except for fgetpos()/
fsetpos()), no malloc(), etc etc), most changes and
extensions could be and were brought to life by self
compiling. Once you get to successful self compiling,
there's no stopping, you can do it again and again.

Alex

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web