It was thus said that the Great Tomasz Rola via cctalk once stated:
Ok guys, just to make things clearer, here are two
pages from wiki:
https://en.wikipedia.org/wiki/Object-oriented_operating_system
https://en.wikipedia.org/wiki/Object-oriented_programming
What I was thinking back at the time of premiere: classes, objects
derived from the classes, user able to make his own object from
system-provided class or define class of his own, or define his own
class and inherit from other class, including system-provided one.
Yes, the typical method of OOP, which is not what Alan Kay had in mind
when he developed Smalltalk:
I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages (so
messaging came at the very beginning -- it took a while to see how
to do messaging in a programming language efficiently enough to be
useful).
-- Alan Kay
Basically, very small programs that talk to each other to do stuff. Today
this is known as "microservices" [1].
Examples:
- an object pretends to be a disk object, but is double-disk
partition or zip file
You can do this now on Linux using the FUSE driver---this allows a user
process to service file system requests. To bring this back to topic, QNX
(from the 80s) and Plan-9 (from the 90s) also allowed this, and were easier
to use than FUSE (to be honest). But of not one of Linux, QNX or Plan-9
could be considered an "object oriented operating system." Fancy that.
- an object pretends to be file object but in fact
it is a
composition of few different files, mapped into virtual file-like
object (so as to avoid costly copying)
I think I would classify this as a variant on the first example.
- an object says it is a printer but is a proxy,
connected via
serial-line object to another such serial-line object on remote
computer where the real printer sits (connected via parallel, as
usually)
Under QNX, this was a trivial operation. It was probably pretty trivial
under Plan-9 (depending upon how they handled printer queues). Unix
(including Linux) has something like this, but the name escapes me since I
do almost no printing what-so-ever.
I do know that of the last N printers I've had [2] (actually, my
girlfriend has---she's the one who prints more than I do) were all "plug on,
turn on, oh look! The computer found it on the network---print!"
- object with execution thread, aka active object
(in 199x
nomenclature -> aka process), can be serialized and migrated to
another computer without big fuss either via system provided
migration service or via (really easy to write in such setup)
user's own
- same active object, serialized and stored to file because I gotta
go home and have to turn computer off, so I can resurrect it next
morning
These two are related, and the later one is actually a bit easier to
accomplish if you are doing it to all the processes on a computer. The
major problem though is dealing with resources other than the CPU. For
instance, a process has an open file its working with when it's migrated.
Problems I see right off the bat:
* Does the file exist on the destination?
* If it does, does the process have permissions?
* Now you have issues with syncing the file to the destination.
And if the file is served off a network, then you have issues with network
connections---i.e. they break! (Which is an issue today with hibernation)
You can't reliably provide this functionality invisibly---you have to pretty
much involve the process in question in the process.
Plus, some kind of system programming language - I had
no idea what
Smalltalk was and I still have no idea but I might have swallowed
that.
An object-oriented image based programming language. Except for some
critical routines written in assembler, the entire system (operating system,
compiler, GUI, utilities, etc.) were all written in Smalltalk and every
"object" could be inspected and modified at runtime (including the operating
system, compiler, GUI, utilties, etc.).
I think it was possible to have this. But, not from
MS. And as time
shows, not from anybody.
Citation needed.
On Mon, Oct 22, 2018 at 07:34:32PM -0700, Chris Hanson
wrote:
A lot of Windows 95 is implemented using COM,
which is probably
where the description of it as ?object-oriented? comes from.
Well, I am not going to bet my money on this. What you wrote might be true
but I would like something, say a blog or article, in which author shows
how I can count those COM objects.
How many threads are running? There's your count.
I tried to verify your statement and the earliest
Windows which could be
claimed to be built from many COMs was Windows 8. But the truth is, I have
departed from Win-Win land long ago, and only use Windows when someone
wants me to unscrew a Windows laptop.
Well, COM (Component Object Model) was first developed by Microsoft in
1993, but was based off an earlier technology Microsoft developed call OLE,
which in turn came from DDE in 1987.
And while I
have never been a Windows user, to denigrate it as some
sort of non-achievement given the constraints under which it was
developed, both in terms of target systems and backwards
compatibility, is myopic at best.
C'mon, we are not talking about windows on 8-bit computer. I think
they had loads of cash even back then and could pick from heaps of
CVs. According to ReactOS wikipage:
He's talking about Windows on a 16-bit computer with a limit of 1M of
memory (but really 640K due to the architecture of the IBM PC [3]).
https://en.wikipedia.org/wiki/Reactos
On 1 May 2012 a 30,000 euro funding campaign was started to finance
additional development projects.[43][44] On the end of the year
approximately 50% of the funding goal was achieved and it was
decided to continue the funding campaign without deadlines.
(...) The development progress is influenced by the size of the
development team and the level of experience among them. As an
estimate of the effort required to implement Windows 7, Microsoft
employed 1,000 or so developers, organized into 25 teams, with each
team averaging 40 developers.[85] As of 2 September 2011, in the
ReactOS entry in Ohloh, the page followed through the "Very large,
active development team" link lists 33 developers who have
contributed over a 12-month period and a cumulative total of 104
present and former users who have contributed code to the project
via Subversion since its inception.[86] In his presentation at
Hackmeeting 2009 in Milan, ReactOS developer Michele C. noted that
most of the developers learn about Windows architecture while
working on ReactOS and have no prior knowledge.
With this funding and so few people those noble folks achieved quite a
lot. Do you think MS limitations were bigger?
Reactos is a team building something which already exists---they're
keeping up with Microsoft. It's Microsoft that spends the money to extend
and enhance the features of their operating system in reponse to customer
demand.
For a more apples-to-pears type of comparison, the number of active Linux
developers in 2013 was nearly 1,400 [4], which compares nicely to Windows
for active, new development.
On Mon, Oct 22, 2018 at 04:14:34PM +0200, Liam Proven
wrote:
On Sat, 20 Oct 2018 at 19:31, Tomasz Rola via
cctalk
<cctalk at classiccmp.org> wrote:
Oooh. [...] touting [...] "object oriented
operating system" [...]
objection [...] scam [...]
I think the explanation for that is fairly clearly there in the history.
NT 3.1 came soon after Windows 3.
[... Chicago and Cairo ... multiplied ...]
Very true, but if someone promises and does not deliver, who is he?
A marketer, a politician or a liar.
There have been plenty of projects announced and not delivered (Taligent
anyone? Xanadu?) for a variety of reasons. It's nothing new.
And nobody makes a small print saying "this is
just marketing
material, so do not count on it". If I cannot count on it, why waste
my time?
To disuade you from buying from a competitor? Because they truely believe
it at the time?
-spc (Oh, the i432 from Intel! Announced, then disappeared with nary a
trace ... )
[1]
https://en.wikipedia.org/wiki/Microservices
[2] Modern printers are crap, and it's sad that it's often cheaper to
*buy* a new printer than it is to replace the ink. Grumble.
[3] There were computers based on the 8088 that were *not* IBM PC
comptabible but did run MS-DOS that allowed for memory to exceed the
640K barrier. But they died in the market for not being IBM PC
compatible.
[4]
https://www.cnet.com/news/linux-development-by-the-numbers-big-and-getting-…