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