I would like to make some additions to the interpreter, but I can’t get the source code build. Can anyone help?
(it can’t find the file “os.h”, and others)
1 Like
CAVEAT: I’m neither a TADS user nor a TADS developer.
I’d suggest getting in contact with the author of the specific TADS package that you’re trying to work with.
What version of TADS? Where did you get it? There are several variants, some on github and some elsewhere, including tads.org.
I took a quick look at the source code that’s in the t3_src.zip download available on tads.org at TADS Downloads
The build files included in the zip file’s Win32 directory are ancient and are not compatible with Microsoft’s current native Windows development system.
If I were to try to build it (which I’m not, sorry), I’d probably start with the Linux source code and build it under Cygwin (a free linux-like envorinment for Windows).
First, if you were to compile the T3 interpreter, you need three separate source packages: the T3 sources, the T2 sources (this is where os.h lives), and the HTML TADS sources (the GUI frontend).
Unfortunately, as @selden mentioned, the included project/make files are written for a compiler toolchain that is quite literally from the last millennium (Visual C++ 5.0, released in 1997), so you’ll either need to set up a VM with Windows NT 4.0 and VC++5, or port everything over to a modern build system like MSBuild (a Visual Studio .vcxproj project file) or CMake.
(Alternatively, you could make your extensions to QTads, a port of the HTML T2/T3 interpreters that is cross-platform and currently maintained, so it should be more straightforward to build.)
2 Likes
Yeah, I l’d suggest QTads too, I’ve downloaded the source for that before…
1 Like
Thanks for the information. I am torn between Ubunu in a VirtualBox VM and trying to use Window’s Bash shell with VS Code. I am watching some videos about that now.
Now, this is interesting. My aim is to develop a plugin system for extensions. The idea is to offer a socket based interface which plugins/addons can use without having to rebuild the code. If I an get that working with QTads, maybe I can persuade Mike to port it into the official interpreter.
Thanks for the advice. I am off to look at Qtads
If you mean Mike Roberts, I don’t think he’s anywhere to be found…
1 Like
I emailed him over Xmas, with my idea for a plugin system and he sent a very encouraging reply
4 Likes
You have an active email for Mike Roberts?!
2 Likes
Unless it’s supposed to be private, I’d love to have it… I’ve always wanted to give him
my compliments and thanks for making T3…
2 Likes
Absolutely, he has an enormous legacy that should be honored.
2 Likes
do you still have this email…?
3 Likes
I was able to compile the tads interpreter and even the workbench on Windows 11 with Visual Studio 2022 as 64-Bit executable. It was much more work than I had initially expected, but also a lot of fun. 
What I did:
- I wrote a new CMake-based build system for Tads.
- Fixed the issues that prevented 64-Bit compatibility.
- Fixed the things in the source code that the Visual Studio 2022 compiler could not understand, were missing or wrong.
Open Points:
- The htmltads source code is not really open source. I had to make changes to it to get it to work. If I understand the license terms of Michael J. Roberts correctly, he allows/encourages the porting of Tads to new systems and prohibits all other changes. As I would consider Windows 10/11 64-Bit a “new system”, the exception to the no modification rule should be valid. Moreover, there is this github repository tads-sources from tajmone out there with similar goals. and this project was permitted by Michael J. Roberts. However, I’m not a legal expert and therefore not entirely sure if my interpretation is correct. So if anyone knows a way how to contact Michael J. Roberts, it would great to explicitly get his permission for my project.
- The original Tads distribution comes with a docsearch.dll. I could not find the source code of the docsearch/textindex component anywhere. So I just wrote a more or less empty dummy implementation to get the workbench to compile. Therefore, the docsearch feature does not work in my port. In future, I might write a proper docsearch implementation, but it would of course be much easier to port the existing one if the source code is somewhere available.
- The original Tads distribution comes with mksetup.exe to create an installer. I also couldn’t find the source code for that part anywhere. It seems like a huge task to write an installer builder from scratch, therefore, my port does not contain the mksetup tool.
I’m on github as captain-mayhem with the repositories tads-runner and htmltads that contain my adaptions.
Compiled 64-Bit binaries you can find here:
7 Likes
Building the binaries is pretty straightforward now. The instructions how to build them can be found in the repository itself:
2 Likes
Is it now possible to compile with emcmake using enscripten to run the binary in wasm? It would be amazing if a fully compatible HTML tads terp could run in a browser.
Currently, the code (at least the htmltads gui part) only compiles for Windows. But I actually had the same idea: to port the the code further so that the interpreter can be compiled with emscripten into wasm to completely run in a browser.
If you look at my changes, you will find some commits that already made parts of the code and the build system compatible with a unix/linux build. That is a first step in the direction of an emscripten/wasm build.
So, yes, the idea amazes me, too. And after having ported it to 64-Bit-Windows, I’m confident that I can port the interpreter to wasm. But there is still a good amount of work to do for that and it will take some time. But I’ll let you know you when I succeed.
1 Like
HTML TADS is very much a Windows app, which just won’t work with Emscripten. You’d have better luck with QTads.
Or help is welcome any time to improve multimedia support in Glk TADS! (Used by Gargoyle, Parchment, etc.)
3 Likes
I understand your point. HTML Tads as it is is Windows-specific and will never be portable to emscripten. I just over-simplified it a bit in my previous post. But let’s go deeper into the details of the idea:
My current 64-Bit port actually consists of two repositories, one of them is a fork of the Glk TADS repository. This is the actual backbone of the port and the place where main part of the new CMake-Buildsystem is located. This is also the repository where the main work for an emscripten port would need to be done.
The first step of an emscripten port will be to port t3core (the vm) and then t3run (the text-only interpreter) that is entirely located in the Glk TADS repository. The second part will be to bring in the html capabilities. Same approach I used when doing the 64-Bit Windows port. The htmltads repository serves three purposes there:
- Provide a gui framework for Windows
- Provide multimedia capabilities for the interpreter
- Provide headers to be able to build the t3htm and tr32h libraries which are located in the Glk TADS repo
For an emscripten port, point 1 is obviously not feasible. The gui will need to be browser-specific and needs to be written for that. But it could be kept very minimal: basically just an entry point to run a tads game. Point 2 should not be required, as the browser itself has the required multimedia capabilities. So we are left with point 3 where some (minimal) parts of html tads would be pulled in. But these parts could indeed also be pulled from other ports like QTads or Glk Tads.
2 Likes
I wish @RealNC would work on screen reader accessibility for QTads. Then I could finally switch to a more up-to-date interpreter, so to speak.
2 Likes