Jon writes:
> Would you agree that some of the functional details of the emulator can
> be hammered out by open discussion?

Of course I think I know *exactly* how such an emulator should work, but
feel free to discuss away :-)

> For example, the format, need, and execution of HPCPUNAME and HPSUSAN.

My original plan was as follows:

HP would license one or more Platform Emulator developers to include the
MPE/iX operating system with their product.  In exchange, the emulator
vendors would agree to enforce the requirement of only executing on
HP/Compaq systems (at least for some period of time) and would provide
HPSUSAN and HPCPUNAME values that were of the same trustworthiness as their
counterparts on a physical 3000 box.

This would have certain implications (assuming for the moment that all
3rd-party licensed software does HPSUSAN and HPCPUNAME checking):

The emulator vendor would have to convince the 3rd party developers that
their virtual 3000 was stable and reliable enough that the 3rd party vendor
should support their software on it, because without a licensing change, 3rd
party software would not run on the virtual 3000 because it would see that
the HPSUSAN number was different, and that the HPCPUNAME returned a model
string that was different.

It would encourage 3rd party vendors to support the virtual 3000 platform
because they could count on the HPSUSAN and HPCPUNAME continuing to provide
a functional anti-theft mechanism.

It would mean that a customer would have to perform a license transfer (or
purchase a new 3rd party license) for their 3rd party software.

This all makes the effects and requirements for a virtual 3000 *exactly* the
same as if there were a new HPe3000 model from HP (which would also come
with a new HPSUSAN / HPCPUNAME).

The currently proposed environment is different:

HP would generate licenses, but would have no agreement with any emulator
developer to enforce the HP platform requirement or the HPSUSAN / HPCPUNAME
information.

It would be entirely up to the customer to live up to the requirements of
their software license agreements, including the requirement to only run
MPE/iX on an emulator that's running on an "HP" box, and whatever their 3rd
party agreements might be.

The 3rd party companies would be less likely to "support" the virtual 3000
platform, but at the same time they would lose the ability to prevent (from
a technical point of view) a user from running the software on a machine he
is not licensed for.

This assumes, of course, that there is no benefit to the emulator developer
to putting in the license restrictions unless they are required to do so by
contract.  In the original scenario, these restrictions would have been made
a requirement to obtain the license to distribute MPE.  Without this
leverage from HP, it is possible that an emulator developer would see more
potential profit from an unrestricted emulator than from one which tries to
enforce other people's software licenses for them.  There is a non-trivial
amount of engineering effort and the on-going administrative license
maintenance in order to add the license-restricting features to the product,
and this might simply reduce the number of people willing to buy it.

Now it is also possible that if customers are honest (as we indeed we hope
most of them to be) that an emulator that enforces the license restrictions
might still be more profitable because if you can convince 3rd party
developers to "support" their software in this environment then you could
end up with more customers than you would with an emulator that failed to
provide HPSUSAN type restrictions and thus could be shunned by 3rd party
companies.

In either case it is important to realize that even if you get your spiffy
virtual-3000 Platform Emulator and your spiffy MPE/iX license for it, and it
works really well, that you still probably haven't acquired the right to run
any of your (3rd party) application or tools software on it.

While some software licenses may be transferable without the vendor's
approval, most will require that the vendor "allow" the transfer to the new
virtual 3000.

[The issue of what to do about software from vendors who have gone out of
business is an entirely different can-of-worms-wearing-pinstripe-suits]

Before a 3rd party is likely to allow their software to run on a "new" 3000
model that's as unusual as a virtual 3000 is, they are going to have to
become comfortable with the idea.  The common initial reaction may be
something like "what's this goofy emulator thing and how much pain and
suffering is it going to cause me?".  The issue is most likely to be: When a
customer calls up with a problem, how do they differentiate Emulator
bugs/features from MPE bugs/features from their own bugs/features.  To
succeed, an emulator has to be seen to be a rock-solid simulation of the
HPe3000 hardware, one that does not significantly increase the costs to
support software running on it (of course a vendor could simply charge 10x
their normal support rates for running on the emulator).

There are quite a number of technical features that could actually make
supporting software substantially *easier* than on a physical 3000 system.
For example with a virtual 3000 it's not impossible to imagine that you
could ask a customer to "email me your computer and I'll look at it here"
since both the software *and* the hardware are simply files on another
computer.

But an emulator product that is seen to be unstable is basically doomed.
And of course the emulator has to provide enough performance to make it
useful for some productive use.  And it has to potentially compete on
price/performance with $10,000 N-Class MPE boxes for sale on eBay in a few
years.  So yes, there are many challenges ahead.

But even with all those problems, a good platform emulator is still a
fraction of the effort (in my opinion) that an "MPE simulator" would be (a
system that attempts to replace MPE completely without actually using any of
HP's own object code or source code).

Gavin