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


Groups > comp.programming > #10036 > unrolled thread

OS Design thinking in objects?

Started byG G <gdotone@gmail.com>
First post2019-07-02 16:12 -0700
Last post2019-07-04 19:15 +0100
Articles 9 — 5 participants

Back to article view | Back to comp.programming


Contents

  OS Design thinking in objects? G G <gdotone@gmail.com> - 2019-07-02 16:12 -0700
    Re: OS Design thinking in objects? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2019-07-03 10:52 +0200
      Re: OS Design thinking in objects? Horizon68 like Menz <cdalten@gmail.com> - 2019-07-03 05:16 -0700
        Re: OS Design thinking in objects? Horizon68 like Menz <cdalten@gmail.com> - 2019-07-03 05:17 -0700
        Re: OS Design thinking in objects? G G <gdotone@gmail.com> - 2019-07-03 14:45 -0700
          Re: OS Design thinking in objects? Horizon68 like Menz <cdalten@gmail.com> - 2019-07-04 16:25 -0700
      Re: OS Design thinking in objects? G G <gdotone@gmail.com> - 2019-07-03 14:43 -0700
        Re: OS Design thinking in objects? nobody@example.org (Scott) - 2019-07-04 17:45 +0000
        Re: OS Design thinking in objects? Richard Heathfield <rjh@cpax.org.uk> - 2019-07-04 19:15 +0100

#10036 — OS Design thinking in objects?

FromG G <gdotone@gmail.com>
Date2019-07-02 16:12 -0700
SubjectOS Design thinking in objects?
Message-ID<77714daf-c2c3-4bc0-b547-5bd2939c562e@googlegroups.com>
my question has to do with thinking in terms of
objects when it comes to writing an OS.

would one using an OOPL think of 
the CPU, Processes, Scheduler, drivers, etc 

in terms of objects. like
the CPU is a class with data members (maybe the registers and 
alike) and member function ( the thing that it does )

[toc] | [next] | [standalone]


#10039

From"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Date2019-07-03 10:52 +0200
Message-ID<qfhqd9$2gl$1@gioia.aioe.org>
In reply to#10036
On 2019-07-03 01:12, G G wrote:
> my question has to do with thinking in terms of
> objects when it comes to writing an OS.
> 
> would one using an OOPL think of
> the CPU, Processes, Scheduler, drivers, etc
> 
> in terms of objects. like
> the CPU is a class with data members (maybe the registers and
> alike) and member function ( the thing that it does )

In fact it was always this way. If you take a look at the design of 
drivers even in the most early OSes written in Assembler, they expose OO 
design with typical OO methods. E.g. read/write driver entry points used 
to dispatch to the actual driver's implementation etc. This is what in 
OO is called "dynamic polymorphism". HAL abstracts CPU in a much OO way etc.

What did not happen, due to the Dark Ages we were plunged into thanks to 
the C/UNIX/Windows triade, is OO OS API. In particular, getting rid of 
files and using fully typed persistent memory-resident objects with 
corresponding methods instead of untyped read/write mess never happened.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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


#10040

FromHorizon68 like Menz <cdalten@gmail.com>
Date2019-07-03 05:16 -0700
Message-ID<f1c44343-36dd-4ba4-9e90-6a192fc88668@googlegroups.com>
In reply to#10039
On Wednesday, July 3, 2019 at 1:53:01 AM UTC-7, Dmitry A. Kazakov wrote:
> On 2019-07-03 01:12, G G wrote:
> > my question has to do with thinking in terms of
> > objects when it comes to writing an OS.
> > 
> > would one using an OOPL think of
> > the CPU, Processes, Scheduler, drivers, etc
> > 
> > in terms of objects. like
> > the CPU is a class with data members (maybe the registers and
> > alike) and member function ( the thing that it does )
> 
> In fact it was always this way. If you take a look at the design of 
> drivers even in the most early OSes written in Assembler, they expose OO 
> design with typical OO methods. E.g. read/write driver entry points used 
> to dispatch to the actual driver's implementation etc. This is what in 
> OO is called "dynamic polymorphism". HAL abstracts CPU in a much OO way etc.
> 
> What did not happen, due to the Dark Ages we were plunged into thanks to 
> the C/UNIX/Windows triade, is OO OS API. In particular, getting rid of 
> files and using fully typed persistent memory-resident objects with 
> corresponding methods instead of untyped read/write mess never happened.
> 

Funny story. Back in the early 90s, the late Steve Jobs had an entire Operating System built using Dr. Kay's original definition of OOP. He then proceeded to give a series of coding demo showing how to connected the operating system to the database using methods as the message that got passed as a form of communication between these two distinct object. 

And on an unfunny note, Larry Ellison, who was hanging out with Steve Jobs, attempted to pull the same stunt at Oracle Open World in 2012. He told the audience that Marketing told him that he wasn't allowed to do that.

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


#10041

FromHorizon68 like Menz <cdalten@gmail.com>
Date2019-07-03 05:17 -0700
Message-ID<1008c074-588e-417c-9120-b44fb1a00714@googlegroups.com>
In reply to#10040
On Wednesday, July 3, 2019 at 5:16:03 AM UTC-7, Horizon68 like Menz wrote:
> On Wednesday, July 3, 2019 at 1:53:01 AM UTC-7, Dmitry A. Kazakov wrote:
> > On 2019-07-03 01:12, G G wrote:
> > > my question has to do with thinking in terms of
> > > objects when it comes to writing an OS.
> > > 
> > > would one using an OOPL think of
> > > the CPU, Processes, Scheduler, drivers, etc
> > > 
> > > in terms of objects. like
> > > the CPU is a class with data members (maybe the registers and
> > > alike) and member function ( the thing that it does )
> > 
> > In fact it was always this way. If you take a look at the design of 
> > drivers even in the most early OSes written in Assembler, they expose OO 
> > design with typical OO methods. E.g. read/write driver entry points used 
> > to dispatch to the actual driver's implementation etc. This is what in 
> > OO is called "dynamic polymorphism". HAL abstracts CPU in a much OO way etc.
> > 
> > What did not happen, due to the Dark Ages we were plunged into thanks to 
> > the C/UNIX/Windows triade, is OO OS API. In particular, getting rid of 
> > files and using fully typed persistent memory-resident objects with 
> > corresponding methods instead of untyped read/write mess never happened.
> > 
> 
> Funny story. Back in the early 90s, the late Steve Jobs had an entire Operating System built using Dr. Kay's original definition of OOP. He then proceeded to give a series of coding demo showing how to connected the operating system to the database using methods as the message that got passed as a form of communication between these two distinct object. 
> 
> And on an unfunny note, Larry Ellison, who was hanging out with Steve Jobs, attempted to pull the same stunt at Oracle Open World in 2012. He told the audience that Marketing told him that he wasn't allowed to do that.

Ack. I pulled a Horizon68, and like,  hit the post button before correcting my typo. But at least I don't like guys what this idiot does!

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


#10046

FromG G <gdotone@gmail.com>
Date2019-07-03 14:45 -0700
Message-ID<47e430d1-375a-419e-95a5-6722f653550b@googlegroups.com>
In reply to#10040
> Funny story. Back in the early 90s, the late Steve Jobs had an entire Operating System built using Dr. Kay's original definition of OOP. He then proceeded to give a series of coding demo showing how to connected the operating system to the database using methods as the message that got passed as a form of communication between these two distinct object. 


what was the name of the OS? not NEXT? next was bsd with mach on top somewhere right?

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


#10055

FromHorizon68 like Menz <cdalten@gmail.com>
Date2019-07-04 16:25 -0700
Message-ID<9fc9d503-fb5a-4a6d-acd2-02e286b42787@googlegroups.com>
In reply to#10046
On Wednesday, July 3, 2019 at 2:45:29 PM UTC-7, G G wrote:
> > Funny story. Back in the early 90s, the late Steve Jobs had an entire Operating System built using Dr. Kay's original definition of OOP. He then proceeded to give a series of coding demo showing how to connected the operating system to the database using methods as the message that got passed as a form of communication between these two distinct object. 
> 
> 
> what was the name of the OS? not NEXT? next was bsd with mach on top somewhere right?

It was NEXT. The coding demos were kind of funny since people said Steve Jobs never coded. It was the same time era that he gave a detailed description on how to calculate the greatest common divisor on a teletype. I don't think he wrote the program. But he clearly rendered how it the computer was able to do it.

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


#10045

FromG G <gdotone@gmail.com>
Date2019-07-03 14:43 -0700
Message-ID<664449a1-9663-4f87-93fb-c0d2782f8957@googlegroups.com>
In reply to#10039
On Wednesday, July 3, 2019 at 4:53:01 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2019-07-03 01:12, G G wrote:
> > my question has to do with thinking in terms of
> > objects when it comes to writing an OS.
> > 
> > would one using an OOPL think of
> > the CPU, Processes, Scheduler, drivers, etc
> > 
> > in terms of objects. like
> > the CPU is a class with data members (maybe the registers and
> > alike) and member function ( the thing that it does )
> 
> In fact it was always this way. If you take a look at the design of 
> drivers even in the most early OSes written in Assembler, they expose OO 
> design with typical OO methods. E.g. read/write driver entry points used 
> to dispatch to the actual driver's implementation etc. This is what in 
> OO is called "dynamic polymorphism". HAL abstracts CPU in a much OO way etc.
> 
> What did not happen, due to the Dark Ages we were plunged into thanks to 
> the C/UNIX/Windows triade, is OO OS API. In particular, getting rid of 
> files and using fully typed persistent memory-resident objects with 
> corresponding methods instead of untyped read/write mess never happened.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

C and C++ seems to be a continual hack, well to me. it is so much undefined behavior 
that seems to be allowed but not really because it produces undefined behavior. 
where C once had a small number of keywords now c/c++ has odd additions to the lang, 
to make it more modern?...? funny to me the counting starting at 0 has been
a major cause of errors in the lang forever instead of making that small change
they insist people will get use to it. of they will, but not eliminate the cause 
to start with. 

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


#10047

Fromnobody@example.org (Scott)
Date2019-07-04 17:45 +0000
Message-ID<5d1e3934.560383812@core>
In reply to#10045
On Wed, 3 Jul 2019 14:43:01 -0700 (PDT), G G <gdotone@gmail.com>
wrote:

>C and C++ seems to be a continual hack, well to me. it is so much undefined behavior 
>that seems to be allowed but not really because it produces undefined behavior. 

C lets you do anything you want, the documentation tells you exactly
what to expect if you do. If you do something that's documented as
undefined, you have no room to complain.

>where C once had a small number of keywords now c/c++ has odd additions to the lang, 
>to make it more modern?...?

C and C++ are different languages, one with roots in the other but has
diverged significantly since then. It's trivial to write a legal C
program that cannot be compiled as legal C++.

> funny to me the counting starting at 0 has been
>a major cause of errors in the lang forever instead of making that small change
>they insist people will get use to it. of they will, but not eliminate the cause 
>to start with. 

Well god forbid that a craftsman should need to learn how to use the
tools of his craft.

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


#10048

FromRichard Heathfield <rjh@cpax.org.uk>
Date2019-07-04 19:15 +0100
Message-ID<qflfnv$gdk$1@dont-email.me>
In reply to#10045
On 03/07/2019 22:43, G G wrote:
<snip>
> funny to me the counting starting at 0 has been
> a major cause of errors in the lang forever instead of making that small change
> they insist people will get use to it. of they will, but not eliminate the cause
> to start with.

Fortran and COBOL are 1-based, with the result that array indexing code 
in these languages tends to be clumsy and awkward.

Given that p points to (contains the address of the beginning element 
of) an array, it is very natural and convenient to address other members 
of that array using p + offset, and clearly the beginning element has 
offset 0.

If you label the elements using 1-based notation, 1, 2, 3 etc, then 
somewhere down the line you have to subtract one from the label to get 
the offset, which is inefficient and unnecessary.

But if you want to use Fortran or COBOL, nobody's stopping you.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web