[Tom Emerson's info on old CP/M, Mac, etc computer snipped]
 
If you want to go to extremes, let me mention the early IBM 360 machines
(for certain the 360/30 and probably others) with an IBM 1401 emulation
mode incorporated in microcode.  For performance hounds, the 360/30 was
a machine with a 1 microsecond clock.
 
Multiple "CPUs" have been around awhile, but not as long as emulation.
Problem is that they co-exist, but not necessarily co-operate.  Even IBM's
VM/ESA which does emulate multiple virtual physical machines (albeit all
IBM platforms) only allows them to co-exist, not co-operate.  They made a
really big deal not that long ago about "shared code segments" that multiple
users could share, and elaborated on converting your code to localize all of
your data references to your assigned "data area" (non-trivial).  This
seemingly "ground-breaking" breakthrough was years after MPE and it's
explicit code/data sharing/separation.  And if the IBM systems programmer
lets things stay "as is" then every user running a given application (or
even platform operating system as their "shell" OS) duplicates code that is
assigned to them.
 
I'd like to hear the "Reader's Digest Condensed Edition" of how Unix in
particular, and HP-UX specifically handles code sharing and data protection
and run-time shared libraries like MPE does; plus how fork() really works.
Given my understanding of how fork() really works, both processes share the
same code and data areas (somewhat scary...?).  But I digress...
 
As I stated in my Proposition 3000 presentation, the idea of MPE being "well
behaved in a Unix environment" was a great idea that we participated in as a
customer representative.  However, the emphasis was on "co-existance".  I
made a statement (don't have video, can't quote myself verbatim) to the
effect that "dogs and cats can co-exist given adequate management supervision;
what we need is co-operation".
 
When regarding multiple platforms these days, machine-code level emulation is
disappearing, whether implemented at the hardware, software, or mushware
level.  Machine code compatibility is non-existant on Unix, and significantly
so is source code compatibility between releases.  While Unix is working hard
to remove source level issues, MPE has yet to bow to object code differences.
Perhaps they should (to incorporate back-end code generators for newer HPPA
RISC processors instead of sticking to the base level 1.0 code).  If you want
to draw a parallel, "classic" MPE was source code compatible (by the Unix
definition) with native mode RISC machines; but you had the added benefit of
compatibility mode execution.  If you thought classic-to-Spectrum migration
was a pain, this is almost the norm for Unix *upgrades* (not migration).
 
If you are confronted with the "Unix proposition", see if you can't counter
with a 3000 alternative.  Keep your legacy apps and 3000 trained staff, but
compete with the Unix offering.  You can compete to some extent now, but we
really need a push in the Posix/Unix APIs front which has been ignored.  If
you are considering Unix and haven't tried Posix, you should be ashamed. It
has it's problems, but it won't get any better by our apathy.  Very few
people have bothered to try the offerings on jazz and elsewhere which only
enforces my suspicions of apathy; if you take a few hours to download the
Gnu toolkit, BSD libraries, and interesting applications (NCSA httpd) and
take some time to setup the Posix environment you can significantly increase
your "Unix-like" Posix environment.  Play it from the factory HP tapes and
you will not be terribly pleased.  It takes a little initial effort.  The
5.5 release will make things better (supplied libraries required by gcc that
you can get for free).
 
If this post rings a bell in your head, you might want to pause a minute and
thank Mike Belshe, Steve Elmer, and others for their efforts in the ported
code.  All have gone in other directions than CSY.  And perhaps the most
significant contributor, Mark Klein, for the Gnu developer's kit which offers
you so much functionality for *free* if you only bother to download it.  And
I think it significant that Mark is not affiliated with HP, he's just doing
this as a labor of love.  Same applies to Dan Hollis, Randy Medd and the rest
of the gang doing the FREEVT3K project which is kicking some serious butt :-)
Ironically, FREEVT3K won't work under MPE/iX POSIX due to quirks in the API.
With that said, I rest my case.  Demand POSIX maturity.  It's a d****d shame
when a Sun, Linux, VMS, etc box can NS/VT to your machine while you can't do
the same to your own machine via loopback unless you spend umpteen-thousand
dollars for NS/3000 and the included NS/VT client.  With FREEVT3K, if you
have a Unix box on site, it's now cheaper to telnet to the Unix box and then
freevt3k to your 3000 than purchase OpenView/DTC Manager and related quirks.
Maybe less relevant for 5.5's telnet server, but freevt3k does conversion to
vt100 emulation (so kiss Reflection, even MS/92 goodbye).
 
We're all living in dangerous times.  Don't make hasty decisions <yet>.
 
Jeff Kell <[log in to unmask]>