Recent TADS 3 games often incompatible with old interpreters?
Eriorg
versions of TADS 3 interpreters, which means that they don't work with
not quite up-to-date interpreters, like QTADS on Linux for instance.
(I also noticed that problem myself, when I had to download new
versions of HTML-TADS on Windows when recent games required it.)
Is it true? And if it is: why does TADS have that regrettable problem,
whereas recent Z-code and Glulx games seem to be more often compatible
with (relatively) old interpreters?
Nikos Chantziaras
AFAIK, this was not the case anymore when the final (non-beta) version
of Tads 3 came out. It was common though when Tads 3 was still in its
beta development stages.
As to Z-Code and Glulx, they target already existing virtual machines,
especially Z-Code. Inform has no control over the Z-Machine; it has to
create code that runs in it no matter what. If there's a problem in the
virtual machine, it can't be fixed; a workaround has to be done in
Inform instead. People wrote Z-Code interpreters in the past to play
Infocom games; Inform can't break compatibility to those interpreters.
It has to live with whatever they have to offer.
Tads 3 on the other hand has its own virtual machine, which evolved as
part of Tads 3 in whole. But after the first non-beta version came out,
the format was frozen so the requirement to update was no longer the
case. If a serious bug in encountered though, then this could warrant a
change, but this is avoided. I'm not sure if it ever happened yet.
Eric Forgeot
> Tads 3 on the other hand has its own virtual machine, which evolved as
> part of Tads 3 in whole. But after the first non-beta version came out,
I was also wondering myself, qtads is GPL, while tads2 and tads3 are not.
(released as freeware, with no derivative works allowed, including the
interpreters).
I read in a forum at
http://lists.v-space.org/archive/tads3/200706/msg00005.html
"Mike actually already GPLed the interpreter by allowing QTads to be GPLed.
But that's just a special permission to release that particular port under
the GPL."
What does it mean ? This seems to cover the qtads interpreter (which is no
longer able to read new tads3 games), but not the frobtads interpreter.
Isn't it possible to recompile qtads with the newest tads3 specifications ?
Nikos Chantziaras
> Nikos Chantziaras wrote:
>
>> Tads 3 on the other hand has its own virtual machine, which evolved as
>> part of Tads 3 in whole. But after the first non-beta version came out,
>
> I was also wondering myself, qtads is GPL, while tads2 and tads3 are not.
> (released as freeware, with no derivative works allowed, including the
> interpreters).
>
> I read in a forum at
> http://lists.v-space.org/archive/tads3/200706/msg00005.html
>
> "Mike actually already GPLed the interpreter by allowing QTads to be GPLed.
> But that's just a special permission to release that particular port under
> the GPL."
>
> What does it mean ?
Well, what it says really. The code that comes with QTads is
dual-licensed (GPL and Tads Freeware License). It's the same code as
the reference VM implementation. But that particular distribution of it
was allowed to be placed under the GPL in order to make the port
possible at all, since it uses a Shared library/DLL that is GPLed (Qt).
> This seems to cover the qtads interpreter (which is no
> longer able to read new tads3 games), but not the frobtads interpreter.
> Isn't it possible to recompile qtads with the newest tads3 specifications ?
It won't compile without fixing QTads first. The problem is not the GPL
or anything like that. It's simply that the design of QTads was
somewhat broken since its beginnings with changes being more and more
difficult with each release (too many hacks in it to fix stuff that
shouldn't been in there in the first place) and no banner support
without rewriting about 80% of the code. Updating the Tads core often
broke too much stuff (because of my bad design). A needed change in
someplace in the interface for example resulted in a chain reaction that
broke half the code because everything had dependencies upon everything
else. Also, I've designed the interface by using a GUI designer which
generated C++ code instead of coding the GUI by hand. Turned out the
generated code would not compile under different versions of Qt.
That's *not* how you design a piece of software that is intended to be
distributed in source form rather than some "take it and run it"
executable :P
And since there were Zoom, Spatterlight and Gargoyle, QTads became
somewhat redundant. If I was to update QTads, I would throw it in the
bin first and begin from scratch (this time using the same build system
as Frob.)
As for Frob, of course I would prefer it to be open source (if GPLed or
something else doesn't really matter to me); people were submitting it
to be included in many Linux distributions, but the non-open source
license was the bottleneck. But that's not my call. Mike mentioned in
the past that he's thinking about open sourcing the whole thing, so
maybe it will happen at some point.
In any event, Frob is not *required* to be GPL or open source since the
library it uses on Linux systems (ncurses) does not require it (probably
one of the fewer FSF products that aren't GPLed).
Andrew Plotkin
>
> Is it true? And if it is: why does TADS have that regrettable problem,
> whereas recent Z-code and Glulx games seem to be more often compatible
> with (relatively) old interpreters?
I don't know how TADS is running, but you picked a bad time for that
comparison. The I7 compiler has recently added features that *are*
incompatible with old Glulx interpreters. (Dynamic string objects,
which require memory-allocation in the VM layer and Unicode in the I/O
layer.)
(Those haven't broken old Z-machine interpreters, but that's because
the Z-machine's notion of both Unicode and dynamic memory are both
shaky hacks to begin with, so the I7 features can't be used too
heavily.)
In general, I think you're right -- Inform has a better record for
maintaining compatibility with old interpreters. This is because both
the Z-machine and Glulx are low-level VMs; they operate on the level
of blocks of bytes. Whereas the T3 VM deals directly with objects and
properties and so on. So a whole lot of Inform improvements (including
the entire jump from I6 to I7) are built in library code, which is
compiled into the game file, rather than being VM upgrades.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're an American.
Eriorg
>
> Tads 3 on the other hand has its own virtual machine, which evolved as
> part of Tads 3 in whole. But after the first non-beta version came out,
> the format was frozen so the requirement to update was no longer the
> case. If a serious bug in encountered though, then this could warrant a
> change, but this is avoided. I'm not sure if it ever happened yet.
>
Ah, I understand. Well, if that problem was only for the beta version
(and the interpreters which weren't updated since then), then it's
definitely not as annoying as I feared.
Thank you for your answers!
Nikos Chantziaras
Still curious though why you think updating the software on your machine
is so annoying. Nowadays it's a 5-minute task, unless you're still
connecting what a 56k modem. And even when an update is there that is
not mandatory, there are other enhancements and bug fixes in it.
Most people usually don't "fear" updates (as you've put it). It's
rather the opposite; they want them.
Eriorg
> Eriorg wrote:
>
> Still curious though why you think updating the software on your machine
> is so annoying. Nowadays it's a 5-minute task, unless you're still
> connecting what a 56k modem. And even when an update is there that is
> not mandatory, there are other enhancements and bug fixes in it.
>
> Most people usually don't "fear" updates (as you've put it). It's
> rather the opposite; they want them.
>
I don't "fear" updates, when they do exist(*). What I feared was that
the same problem with QTADS might happen again with other
interpreters, which would then become less and less useful because
nobody would update them. You could always use another interpreter,
but that would still reduce the choice... And if *every* TADS 3
interpreter available on an OS (Linux or Mac OS X, for instance) was
abandoned, that would be a problem, wouldn't it?
(*) Although I admit I often download them only when I absolutely need
them, but that's laziness, not fear :-) . Occasionally, there were
also new versions of programs which I didn't find as good as the old
ones, or (more often) which required a more powerful computer than the
one I had; but that's pretty rare, and none of these programs were
about IF.
Mike Roberts
> In general, I think you're right -- Inform has a better record for
> maintaining compatibility with old interpreters. This is because both
> the Z-machine and Glulx are low-level VMs; they operate on the level
> of blocks of bytes. Whereas the T3 VM deals directly with objects and
> properties and so on. So a whole lot of Inform improvements (including
> the entire jump from I6 to I7) are built in library code, which is
> compiled into the game file, rather than being VM upgrades.
That's the gist of it, but the actual practical reason that a given T3 game
requires a minimum terp version is that the terp has a set of built-in
utility functions that games rely upon. New functions are added from time
to time, and new games use the new functions, so to run a game that depends
on function F you need an interpreter new enough to feature function F.
It's not a VM dependency per se; the VM has been virtually unchanged for at
least five years now. It's pretty much exactly like how applications on
Windows are dependent upon particular DLL versions. For Windows apps, you
don't need to install a new CPU, but you do need to get the latest DLLs.
For TADS 3 apps, the DLLs and CPU are linked together into the interpreter
executable, so you do need to upgrade the whole thing.
Why anyone would look at the Windows DLL nightmare and say "hey, I should do
the same thing with my great new modern text adventure VM!" is beyond me :).
The supposedly good part of the design is that you can take a newer version
of the compiler and create a .t3 game that will run under any particular
older version of the interpreter. The DLL dependencies aren't built into
the compiler, but are all exported to headers, so you can create an "old"
game simply by compiling with old headers. I did this specifically to
address the forced-upgrade problem, so that authors could, if they wanted,
prepare games for older terps to the extent they didn't actually require
more recent function additions. In practice this was overengineering that
no one uses. The bad part of the design is that the DLL version
dependencies have DLL granularity: if you compile with version X of the
header, you'll require a version >=X of the DLL, *even if you don't use any
of the newer functionality*. If I were to design this part again, I'd at
least make the granularity at the function level, so you could run with any
version that includes merely the functions you actually use. If I were to
design the whole thing again, I'd probably assume a JIT so that performance
is not a factor in deciding whether something goes in the library or in a
DLL; this would eliminate 90% of the built-ins, leaving only the I/O and
other system-level functions.
--Mike Roberts
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote:
> > In general, I think you're right -- Inform has a better record for
> > maintaining compatibility with old interpreters. This is because both
> > the Z-machine and Glulx are low-level VMs; they operate on the level
> > of blocks of bytes. Whereas the T3 VM deals directly with objects and
> > properties and so on. So a whole lot of Inform improvements (including
> > the entire jump from I6 to I7) are built in library code, which is
> > compiled into the game file, rather than being VM upgrades.
>
> That's the gist of it, but the actual practical reason that a given T3 game
> requires a minimum terp version is that the terp has a set of built-in
> utility functions that games rely upon. New functions are added from time
> to time, and new games use the new functions, so to run a game that depends
> on function F you need an interpreter new enough to feature function F.
>
> It's not a VM dependency per se; the VM has been virtually unchanged for at
> least five years now.
The Glulx design can be described this way as well. All the recent
additions are new opcodes, which are more or less callable functions.
And game code can test for an opcode's availability, either by
"module" or by checking the VM version number (which increments as new
modules go in).
However, when the compiler's built-in library uses a new feature, the
effect is that all games built with that compiler require a new
interpreter. So, again, the ability to test by feature is
overengineering -- or at best a graceful error message.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
Nikos Chantziaras
> [...]
> It won't compile without fixing QTads first. The problem is not the GPL
> or anything like that. It's simply that the design of QTads was
> somewhat broken since its beginnings with changes being more and more
> difficult with each release (too many hacks in it to fix stuff that
> shouldn't been in there in the first place) and no banner support
> without rewriting about 80% of the code.
Hmm, that was quite a rant targeted at myself. It seems there are
people who would like to use an up to date version of QTads. So I've
patched up the holes that accumulated in the last 3 years (bit rot
exists, I swear!) and will prepare for a new release based on TADS
2.5.10/3.0.15.3, and fixing a few bugs along.
It's even 64-bit ready, what a deal :P