[z-machine] Different 1.1 proposal: put_prop and get_prop

[Cedric Knight]

On 06 August 2003 23:39, David Kinder <d.kinder@btinternet.com> wrote:
> From: "Ben A L Jemmett"
>> None that I know of for put_prop (Zinc will halt on such an
>> operation); get_prop is called in this manner by Christminster
>> though.
>
> Ack. That'll teach me to make statements about whether anyone calls
> an opcode in a certain way ... I don't think it would be a good idea
> to change the spec in a way that would break existing games.

Absolutely.  But it presumably might be a good idea to change the spec
so that any terp meeting it would successfully play existing games.
Within that, it would be good for people developing new games to know
whether there will be portability problems on other terps.

>
> How about @get_prop returning the size of the property for extended
> properties, and @put_prop being a no-op for extended, possibly also
> printing a diagnostic message?

That would make sense, if you make that *definitely* printing a
diagnostic message - most of the other illegal uses in the spec are
required to print a message *and halt*.  As for @get_prop, this
behaviour would at least alert the programmer to the fact that they
have a problem with a two-or-more-word property.

I wonder if Ben found out whether Christminster was expecting the
first two bytes of data, or something else?  I'd bet it was the
former.

There are incipient problems in the unpatched library for at least one
property:
http://groups.google.com/groups?threadm=8df06e254b.kevin%40bracey-grif
fith.freeserve.co.uk

It's the inherent problems which Inform has in implementing 'common
properties', that suggest the terps should return the first two bytes
of data.  Use of any class in any library which defines an additive
property may expose the problem.  It would be possible to add a few
more strict-mode checks to the compiler, I suppose - after all, vile
zero errors from hell were mostly solved in this way.

> People have reverse engineered at least parts of several Infocom
> interpreters. You could always just compile a z-code file with
Inform
> and run it with one
> of Infocom's DOS interpreters, as well.

Yes, I get it now.  Ta.

CK