13 May
2013
13 May
'13
6:05 p.m.
On Tue, May 14, 2013 at 6:59 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
Taligent was to be part of the application framework.
The microkernel used by Pink and
the object model were "toys". Much of the consternation over Taligent at IBM
was fighting
over trying to get fundamental issues addressed (which I won't go into here...it
would take
many hours to compose a sane account).
Did some of the Taligent codebase end up in SUN's Java implementation,
perhaps the libraries?
I encourage you to add to the story of Taligent. I remember at the
time Taligent gained a lot of press attention, particularly when Apple
was struggling with what to do with their operating system and Pink
was seen as the answer.
13 May
13 May
7:04 p.m.
On May 13, 2013, at 3:05 PM, Nigel Williams <nigel.d.williams at gmail.com> wrote:
On Tue, May 14, 2013 at 6:59 AM, Guy Sotomayor <ggs
at shiresoft.com> wrote:
It's a time I'd rather forget. ;-) I still have the scars from some of the
"discussions".
TTFN - Guy
Taligent was to be part of the application
framework. The microkernel used by Pink and
the object model were "toys". Much of the consternation over Taligent at IBM
was fighting
over trying to get fundamental issues addressed (which I won't go into here...it
would take
many hours to compose a sane account).
Did some of the Taligent codebase end up in SUN's Java implementation,
perhaps the libraries?
I encourage you to add to the story of Taligent. I remember at the
time Taligent gained a lot of press attention, particularly when Apple
was struggling with what to do with their operating system and Pink
was seen as the answer.
7:34 p.m.
On May 13, 2013, at 3:05 PM, Nigel Williams <nigel.d.williams at gmail.com> wrote:
On Tue, May 14, 2013 at 6:59 AM, Guy Sotomayor <ggs
at shiresoft.com> wrote:
Crap. Now I'm remembering all of the stuff about Taligent that I'd thought
I'd
forgotten.
Here's a few of the "gems":
- Reportedly it was really hard to port to new processors (they were on 68K).
Why? One of the foundation objects was written in 68K assembler. It was
needed to stream and unstream an object. It needed to know the object's
size. A normal person would have said "put the size of the object in the
object".
Did they do that? Noooo. They had to be clever. They wrote a method that
looked up "new" of the object, *diassembled* it and analyzed it to determine
the size that new was allocating.
Clever: yes, product quality: NO
- They were extremely proud of the fact that they were *only* executing 6
(count them six) machine instructions between method calls. No work was getting
done, just setting up for the next method invocation.
- They had a messaging microkernel (just like we did...except theirs was *very*
primitive). As such, messaging was fundamental to both OS's. They had
decided that the fundamental object in a messaging system was a message.
What that meant was that anything you wanted to do involved invoking a
method on the message. So, if you wanted to say create a new task, you'd
say something like msg(task.create) rather than something more sensible
like task.create(msg).
It may sound a bit esoteric but it was fundamental and their code looked
really strange and made adapting it very difficult to situations that they
hadn't originally considered.
- They were based in C++. Everything had to be in C++ (except at the very
bottom which was 68K assembler). This wouldn't fly for a number of reasons.
The most obvious being that not all code that needed to run on this system
was in C++ and wouldn't be re-written in C++. The thing that really nailed
the problem was one of software updates. Because their object model was
C++ it meant that if the object changed from one release to another everything
using that object would have to be re-compiled...the OS, *all* applications,
everything.
- They created a TCP/IP stack. In C++. It was an interesting research project.
I felt pity for the poor folks at IBM who actually had to take that code and
make it work. I think eventually, they (the IBMers) gave up and took a version
of the BSD stack and put the appropriate wrappers around it and called it a day.
I think that's enough for now.
TTFN - Guy
Taligent was to be part of the application
framework. The microkernel used by Pink and
the object model were "toys". Much of the consternation over Taligent at IBM
was fighting
over trying to get fundamental issues addressed (which I won't go into here...it
would take
many hours to compose a sane account).
Did some of the Taligent codebase end up in SUN's Java implementation,
perhaps the libraries?
I encourage you to add to the story of Taligent. I remember at the
time Taligent gained a lot of press attention, particularly when Apple
was struggling with what to do with their operating system and Pink
was seen as the answer. 
9:11 p.m.
On 5/13/13 4:34 PM, Guy Sotomayor wrote:
- They had a messaging microkernel (just like we
did...except theirs was *very*
primitive). As such, messaging was fundamental to both OS's. They had
decided that the fundamental object in a messaging system was a message.
What that meant was that anything you wanted to do involved invoking a
method on the message. So, if you wanted to say create a new task, you'd
say something like msg(task.create) rather than something more sensible
like task.create(msg).
The people that did it were fans of Cheriton's V Kernel.
What became Pink's kernel can be traced back to an ATG project called 'Opus'
done by Chris Mohler and Chris McFall. There were two camps in ATG back then (1987)
working on what would be Apple's new operating system. Note that ATG was not
a product development group, and in fact, was not liked by product development
because it was rarely concerned with backwards compatibility. The other kernel
was heavily influenced by RSX and VMS (Nukernel) and was done by Steve Williams and Tom
Saulpaugh. Well, Opus 'won', Steve and Tom went off to the printer group to
work on embedded systems there and the two Chris' went to Pink.
Then, ANOTHER group of people who came out of Cheriton's group ended up in ATG
Ross Finlayson and Steve Goldberg, and did ANOTHER microkerel, which AFAIK only
resulted in a couple of research papers.
http://dl.acm.org/citation.cfm?id=1295471
This all happened before Moto RISC CPUs were being worked on.
10:48 p.m.
On May 13, 2013, at 7:34 PM, Guy Sotomayor wrote:
Here's a few of the "gems":
- Reportedly it was really hard to port to new processors (they were on 68K).
Why? One of the foundation objects was written in 68K assembler. It was
needed to stream and unstream an object. It needed to know the object's
size. A normal person would have said "put the size of the object in the
object".
Did they do that? Noooo. They had to be clever. They wrote a method that
looked up "new" of the object, *diassembled* it and analyzed it to determine
the size that new was allocating.
Clever: yes, product quality: NO
There's a line between "clever" and "overwrought", and that's
WAY on
the other side.
- They were based in C++. Everything had to be in C++
(except at the very
bottom which was 68K assembler). This wouldn't fly for a number of reasons.
The most obvious being that not all code that needed to run on this system
was in C++ and wouldn't be re-written in C++. The thing that really nailed
the problem was one of software updates. Because their object model was
C++ it meant that if the object changed from one release to another everything
using that object would have to be re-compiled...the OS, *all* applications,
everything.
Oh, BARF. Python had the same problem up until VERY recently (3.2),
when they FINALLY made a stable, abstracted interface to the C API
instead of having you bind directly to low-level structures which
tended to change from version to version. So you need a version
compiled for 2.5, 2.6, 2.7, 3.0, 3.1, etc. if you want your extension
to support them.
- They created a TCP/IP stack. In C++. It was an
interesting research project.
I felt pity for the poor folks at IBM who actually had to take that code and
make it work. I think eventually, they (the IBMers) gave up and took a version
of the BSD stack and put the appropriate wrappers around it and called it a day.
I actually have a coworker who came up with a pretty inventive way
of making a TCP/IP stack run efficiently in C++. It exploited the
virtual dispatch for polymorphic objects to essentially run each
connection as a dynamically recast object. From what I understand,
it actually ran OK on the embedded devices it was meant for, though
I'm not sure I would have wanted to debug it.
- Dave
14 May
14 May
12:26 a.m.
New subject: TCP stacks - Re: Taligent
On 13/05/13 10:48 PM, David Riley wrote:
...
Crazy! Ocaml is much more sensible (and likely simpler, faster and more
maintainable as a bonus):
https://github.com/mirage/mirage-net
--Toby
- They created a TCP/IP stack. In C++. It was
an interesting research project.
I felt pity for the poor folks at IBM who actually had to take that code and
make it work. I think eventually, they (the IBMers) gave up and took a version
of the BSD stack and put the appropriate wrappers around it and called it a day.
I actually have a coworker who came up with a pretty inventive way
of making a TCP/IP stack run efficiently in C++. It exploited the
virtual dispatch for polymorphic objects to essentially run each
connection as a dynamically recast object. From what I understand,
it actually ran OK on the embedded devices it was meant for, though
I'm not sure I would have wanted to debug it.
- Dave
13 May
13 May
8:23 p.m.
On Tue, 14 May 2013, Nigel Williams wrote:
On Tue, May 14, 2013 at 6:59 AM, Guy Sotomayor <ggs
at shiresoft.com> wrote:
I was sent to CommonPoint training at Taligent in 1995. I believe I
still have a virgin copy of the CommonPoint software at the office. I
found a note to my boss in the email archives, with some thoughts about
the training:
------------------------------------------------------------------------
1. The training environment was excellent, and the instructor was one of
the best I've worked with: very knowledgeable.
2. CommonPoint looks like it will be a good environment to develop
graphical, client/server and multimedia applications, when it's finished
(it isn't).
3. CommonPoint is still very much under development, and only graduated
Taligent was to be part of the application
framework. The microkernel used by Pink and
the object model were "toys". Much of the consternation over Taligent at IBM
was fighting
over trying to get fundamental issues addressed (which I won't go into here...it
would take
many hours to compose a sane account).
Did some of the Taligent codebase end up in SUN's Java implementation,
perhaps the libraries?
I encourage you to add to the story of Taligent. I remember at the
time Taligent gained a lot of press attention, particularly when Apple
was struggling with what to do with their operating system and Pink
was seen as the answer. from beta status, the week before our class.
CommonPoint applications
must run in their own CommonPoint window area, rather then
on the native
desktop (Xwindows, for instance).
4. The development tools used in class were very slow, resulting in
compile and link times of up to 20 minutes, for simple applications. A
test version of "CommonPoint Professional", an Integrated Development
Environment, was demonstrated to us later in the week, and the speed gains
were drastic. The IDE is just entering Alpha test, and will only be
available to a small number of developers, at first. The IDE is going to
be a necessity, for any serious development work. CommonPoint
Professional is a separate product.
--------------------------------------------------------------------------
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
4087
days inactive
4088
days old
6 comments
6 participants
participants (6)
-
aek＠bitsavers.org -
fraveydank＠gmail.com -
ggs＠shiresoft.com -
mloewen＠cpumagic.scol.pa.us -
nigel.d.williams＠gmail.com -
toby＠telegraphics.com.au