Z-Machine 1.1 Standard

With the revisions to the 1.0 Standard (hopefully) complete, I’ve made an attempt at integrating the new features from the 1.1 Standard into the main document.

It’s currently available at frobnitz.co.uk/zmachine/1.1/

I should have mentioned, the changes are mostly in sections 8, 9, 11, 14 and 15.

I’m curious about something in the 1.1 Standard, and this seems as good a place as any to see if anyone knows the answer. In the 3rd draft of the spec, a feature was added to make printing Unicode strings easier. In the 9th draft, which is more or less the final product, this feature abruptly vanishes.

I’m assuming someone on the Z-Machine Mailing List had some problem with it, but that list is gone and my archives are missing a few years. Does anyone know what happened?

As I recall, there was a somewhat interminable debate about how this could be done that went round and round, without reaching any conclusion. At some point Graham suggested we get a 1.1 spec out by simply discarding anything that there wasn’t agreement on, so out it went.

As far as I’m aware there’s not been anything released that really made any use of the 1.1 features, so it’s all a bit academic at this point.

You’re probably right about nobody using it, but I’d say part of the reason for that is that the existence of the 1.1 standard was kind of hidden away in a text file in the depths of the ifarchive. I’m not sure how many people even knew about it. Hopefully now that problem will go away to some extent.

Of course, the other obvious problem is that the features the 1.1 spec adds are mostly only useful if you’re creating a z6 game, and nobody does that, and that’s really not likely to change.

Tiny syntax correction: the zspec.css file contains the line

table caption { font-weight: solid; text-align: center; }

“solid” should be “bold”.

I’ve updated the ‘Resources Available’ appendix (frobnitz.co.uk/zmachine/1.1/appc.html) with more recent information.

I’d appreciate it if people could take a look over that and mention anything important I’ve missed, particularly in the ‘Utility programs’
section, which I haven’t changed at all.

That’ll be in the css file you’ve uploaded for the 1.0 site as well, then.

Not sure why it’s there at all, actually, since it doesn’t seem make a difference
to how the captions are displayed.

I’m going to go ahead and assume that the lack of discussion means everybody’s more or less fine with the document as it is, so unless anything comes up, I’ll get it cleaned up, check it a few dozen more times for obvious mistakes, and hand it over to zarf tomorrow.

I thought I was done with the 1.1 Standard, but after a brief conversation on ifMUD, it has occurred to me that the 1.1 ‘prompt’ addition to the @save and @restore opcodes allows games to silently create files on the user’s hard disk, and nothing in the specification prohibits a game from creating the file anywhere on the disk it pleases.

With this in mind, I’d like to make one minor alteration to the 1.1 standard, which would prohibit games from specifying a location for saved files, and encourage interpreters to ensure games don’t save outside a set directory.

Anyone have any issues with this?

The way I handled this in Glk was recommendations, not requirements:

The idea is that the game may (legally) pass any filename argument, but the game should not expect an argument like “/etc/passwd” to be accepted at face value.

(I explicitly named the characters that are meaningful to the Unix shell, just because people write code using shell-out features. Like os.system() in Python, etc. They shouldn’t, but they do.)

Hmm, yeah. I may just steal the wording from Glk and modify it a bit.

The Inform site has been updated with Marvin’s final 1.1 document.


I’m almost sorry to mention this, but I missed this thread until today (sorry).

In the last paragraph of

That should be buffer_screen, I think (somehow that’s been there unchanged since the first draft of the proposal, so it may well be my mistake in the first place).


The spec presumes that game authors can set flags-3 bit 0: “If set, game wants to use transparency”.

I6 currently can’t do this. I’ve filed an issue on adding it. I’m not sure what the syntax should be, though. My very-simple proposal is “$ZCODE_FLAGS_3=1”. Not general, but it doesn’t sound like we’ll ever have a flags-4 field, so maybe good enough?

Please comment here or at inform7.com/mantis/view.php?id=1199 .

The flags may still be useful in the future, not so much for letting the game know what an interpreter can do, but so the game can tell the interpreter what it wants. For instance, Windows Frotz currently doesn’t enable transparency unless the relevant flag is set. We’ve got 15 bits left in Flags 3, though, and this doesn’t seem like it’ll come up very often, so as long as we can set $ZCODE_FLAGS_3=5 or whatever to set the relevant bits, this should do for the foreseeable future.

Also, the $ZCODE_HEADER_EXT_WORDS idea: yes please.

The thing about the $ZCODE_FLAGS_3 plan is that you’d have to set it all at once. You can’t put $ZCODE_FLAGS_3=1 in one library and $ZCODE_FLAGS_3=4 in another and expect them to “or” together. (Inform’s named-option system is simple.)

I’m okay with this, I’m just saying.

I hadn’t thought of that, but yeah, I think we can cope.

Going back to this issue (the game passing a file name to the @save opcode), we now have

Problem: this is inconsistent in handling of file names with an extension in them: the first three sections indicate that a full stop followed by a three-letter file extension is okay, but the last section says that the interpreter will strip off any extension by truncating at the first full stop.

Thoughts? If we’re making it compatible with the Glk file handling model then we should loose the rest of the text talking about filename extensions.