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

Groups > alt.os.development > #9155

Re: New OS opportunities?

Show all headers | View raw

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

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