MIME types for various game types

As part of the lurch toward a new release of Gargoyle, I realized it would be useful to have MIME types defined for as many of the game types as is feasible, so Gargoyle can easily be associated with all its supported types. But there are other users than just Gargoyle which could make use of such MIME types, so I’d really like to see if a consensus of sorts can be reached on MIME types. For systems conforming to freedesktop.org, this would consist of an XML file for use in /usr/share/mime. I’ll distribute one with Gargoyle but if possible, I’d like it to just be a copy of an accepted, canonical version.

From what I’ve found, there has been some work toward MIME types. The IF Archive’s .htaccess file has:

  • application/x-zmachine
  • application/x-tads
  • application/x-t3vm-image
  • application/x-glulx
  • application/x-blorb

QTads includes its own XML mime definition with the same MIME types for TADS.

The “file” implementation included with most modern Unix-like operating systems defines, in addition to the above, application/x-adrift.

I’ve created a proof-of-concept which includes these plus others, which I’m attaching here. I’m looking for feedback/additions/changes, in hopes a common accepted MIME collection can be created.
if.xml (2.54 KB)

.gblorb/.glb and .zblorb/.zlb should be these MIME types:


…if the profile qualifier makes sense. If not, application/x-blorb is most correct – you’re representing the format, not the contents.

The file signature for Blorb (including gblorb, zblorb) is FORM in bytes 0-3 and IFRS in bytes 8-11. Not sure if your XML file can represent that.

I’ve never seen a “profile” in the wild and would just as soon use application/x-gblorb (is that what “x-glulx” is supposed to represent?) as a separate type from x-blorb. I think it’s an implementation detail that gblorb has anything to do with “.blorb” zblorbs, and it seems important for interpreters to be able to say “I support zblorbs and not gblorbs” (or vice versa) in a way that every MIME handler will understand.

I’d rather not introduce “application/x-gblorb”, which is currently not used by anyone.

In practice, we’re talking about Gargoyle which does support both Z-code and Glulx. So my plan is not going to cause a problem. There are interpreters which only support one or the other, but I don’t know of any which try to distinguish based solely on MIME type.

Is x-glulx used for gblorbs?

The Blorb entries were the biggest sticking point I saw from a more global perspective: I can see a Z-machine interpreter not wanting to say it supports application/x-blorb so that (for example) Glulx files aren’t associated with it. As far as I can tell, the freedesktop MIME XML spec doesn’t allow anything like the profile setting, although finding good documentation on it is difficult. From Gargoyle’s perspective a global Blorb is fine since it least supports both Z-machine and Glulx files in Blorbs.

And it looks like multiple matches from disparate parts of the file are allowed for magic checking, so I’ll be able to identify Blorb files by looking for FORM and IFRS as well.

The TADS MIME types are here:


According to the Blorb standard by Andrew Plotkin (version 2.0.4) the executable resource chunk can have any of these types:
‘ZCOD’: Z-code
‘GLUL’: Glulx
‘TAD2’: TADS 2
‘TAD3’: TADS 3
‘HUGO’: Hugo
‘ALAN’: Alan
‘LEVE’: Level 9
‘MAGS’: Magnetic Scrolls
‘ADVS’: AdvSys
‘EXEC’: Native executable
Many of these have never been implemented, but ADRIFT Blorbs are quite common and have the extension *.blorb
In the ADRIFT section of the standard it says that ADRIFT Blorb files should use MIME type application/x-blorb;profile=“adrift”.

That was ambitious planning. Only ZCOD and GLUL have been used in real life.

I can imagine it, but it’s Good Enough™ if it does accept application/x-blorb and then displays an error message “Sorry, only Z-code Blorb files.”

(I can equally well imagine a Blorb-editing app which looks for application/x-blorb because that covers all Blorb files. Admittedly, this is imaginary.)

And then what is the one for TAVERN? Should it be “application/x-tavern” or “application/x-hamster-archive;profile=tavern” or what? (In the case of TAVERN, looking in the file may be necessary to determine compatibility with an implementation, although it can be statically analyzed, rather than dynamic like Glulx is.)

That “profile” tag helps though if you have a Z-machine implementation that supports Blorb, in which case the profile tag can tell it what is supports. Clearly, is necessary to specify which. There is also different Z-code version, and different features in use (some of which can only be checked at runtime), etc. So, “application/x-zmachine;version=ezip” or whatever to indicate, maybe.

Using “application/x-zmachine” for Z-machine Blorb files is no good though, since it is not a Z-machine file but rather a Blorb file encasing a Z-machine file.

Also, as far as I know a Glulx Blorb will not even say “Glul” at offset zero (although it is very likely that a Glulx Blorb will be supported by a Glulx implementation, since that is part of the specification I think).

Practically speaking the main (sole?) downside to using application/x-blorb for everything Blorb is that it becomes impossible to associate a Z-machine interpreter with .zblorb and a Glulx interpreter with .gblorb, assuming you go by MIME type only; but on the other hand a proper desktop environment should allow the user to set individual selections based on extension, so it’s not truly a concern. I’m fine making Blorb files application/x-blorb if that’s the general consensus.

I think pragmatically it’s fine, because while technically it’s a Blorb file, as far as the end-user is concerned, it’s a Z-machine game (or Glulx, or whatever), and he won’t care about the container format. But I don’t have a particularly strong opinion one way or the other, in part because I’ll use Gargoyle for all Blorb files anyway, so it doesn’t matter to me if they’re not differentiated.

I’ve put a preliminary copy of the XML file up at github.com/garglk/if-resources.

No, it is different, since different implementations might or might not support Blorb files.