I decided it would be fun to have a working z-code interpreter in Scratch so I implemented a basic one that handled z3 files well. That was a good proof of concept but I want to be able to handle all versions up to z8 (though possibly not z6) as some of the children using Scratch have asked for it to support games they’ve written with Inform 7. Rather than reinventing the wheel I decided to try to port WinFrotz across and (much to my surprise) I’ve actually got it working reasonably well. There are a handful of bugs which are proving ridiculously difficult to track down (and Scratch isn’t renowned for its debugging capabilities).
If I could get the original code to compile then I’d have a much better shot as I’d be able to compare debug logs at least but it’s failing miserably in VS2017. I’ve cobbled together the libraries it needs (jpeg, png, vorbis, etc), forced the linker to link various libraries in a set way to get around some linking issues, commented out lines that were looking for a nonexistent ScaleGfx.dll and eventually got to the point where it asks for a file to load at which point it crashes out with reports of a memory leak. With the memory leak detection disabled it crashes out soon after anyway.
Has anyone managed to get it compiling on a reasonably new Visual Studio? It would be such a shame if this excellent work doesn’t get updated and maintained. It probably doesn’t need much actual updating really, but having it easily buildable would be a boon for sure
It shouldn’t be too hard to get Windows Frotz to compile with VS2017 and VS2019 - I use VS2019 myself to do development work on Windows Frotz. Releases are compiled with an old Visual Studio just to make sure it runs on the widest possible range of systems.
As noted above, you can get ScaleGfx.dll from the binary distributions of Windows Frotz, from http://www.ifarchive.org/infocom/interpreters/frotz/ Off-hand I can’t see what would cause the problems you describe: we might be able to diagnose further with details of what you changed in the project file, and a callstack from when a debug build crashes.
I’ve reverted to a clean unzip of WindowsFrotzSrc.zip so I can work through the issues I’m having from the beginning. When I open the sln in VS2017 it upgrades the project files. Before I have any problems from libraries, dependency orders, etc., trying to build the solution yields the following -
Increasing the build diagnostic output I get this -
1> No output for J:\SCRATCH\ZORK\NEW FROTZ ATTEMPT\WINDOWSFROTZ\WIN\FROTZ.RC|J:\SCRATCH\ZORK\NEW FROTZ ATTEMPT\WINDOWSFROTZ\WIN\HELP\FROTZ.HHP was found in the tracking log; source compilation required.
1> Frotz.rc will be compiled because it was not found in the tracking log.
1> help\Frotz.hhp will be compiled because it was not found in the tracking log.
1> hhc "help\Frotz.hhp"
1> if not exist "help\Frotz.chm" goto :HelpError
1> copy "help\Frotz.chm" ".\Debug\Frotz.chm"
1> goto :HelpDone
1> :HelpError
1> echo help\Frotz.hhp(1) : error:Problem encountered creating help file
1> echo.
1> :HelpDone
1> echo.
1> "C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\rc" /d _DEBUG /l 0x809 /i Debug /fo Debug/Frotz.res Frotz.rc
1> Making help file...
1> Microsoft HTML Help Compiler 4.74.8702
1>
1>
1>
1> Compiling j:\Scratch\Zork\NEW FROTZ ATTEMPT\WindowsFrotz\Win\help\Frotz.chm
1>
1>
1>
1>
1>
1> Compile time: 0 minutes, 0 seconds
1>
1> 14 Topics
1>
1> 43 Local links
1>
1> 11 Internet links
1>
1> 0 Graphics
1>
1>
1>
1>
1>
1> Created j:\Scratch\Zork\NEW FROTZ ATTEMPT\WindowsFrotz\Win\help\Frotz.chm, 42,490 bytes
1>
1> Compression decreased file by 3,124 bytes.
1>
1> 1 file(s) copied.
1>
1> Compiling resources with SDK resource compiler...
1> The system cannot find the path specified.
1> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5): error MSB6006: "cmd.exe" exited with code 3.
1> Done executing task "CustomBuild" -- FAILED.
1>Done building target "CustomBuild" in project "Frotz.vcxproj" -- FAILED.
Deleting Frotz.rc allows the build to continue so I’m assuming the issue is in there.
The initial conversion process adds the following to the log which may be relevant -
Frotz.vcproj: Due to the requirement that Visual C++ projects produce an embedded (by default) Windows SxS manifest, manifest files in the project are now automatically built with the Manifest Tool. You may need to change your build in order for it to work correctly. For instance, it is recommended that the dependency information contained in any manifest files be converted to "#pragma comment(linker,"<insert dependency here>")" in a header file that is included from your source code. If your project already embeds a manifest in the RT_MANIFEST resource section through a resource (.rc) file, the line may need to be commented out before the project will build correctly.
I don’t know if that’s enough info to go on for the initial problem. I’ve updated VS2017 to include all the most recent patches and updates.
You don’t want to delete “Frotz.rc”. Without the executable resources, the resulting executable definitely won’t work. We can see what goes wrong in all this:
Compiling resources with SDK resource compiler…
The system cannot find the path specified.
This is as it because the resource script needs a version of the resource compiler that supports PNG images in icons: as it was to hand it’s set up to use the Windows SDK 7.0. You could just install that version of the SDK from Microsoft. But Visual Studio 2019 includes an even more recent version of the resource compiler, so a simpler solution is to bring up the properties for “Frotz.rc” in Visual Studio, go to “General” and change the “Item Type” to “Resource compiler”.
Frotz.vcproj: Due to the requirement that Visual C++ projects produce an embedded (by default) Windows SxS manifest, manifest files in the project are now automatically built with the Manifest Tool…
To get round this, bring up the properties window for the overall project, then go to “Linker / Manifest File”, and change “Generate Manifest” to “No”.
Thanks to both of you, @DavidK and @borg323. The fixes suggested for the .rc and manifest files worked seamlessly. The order of libs fixed linking issues. Playing around with pnglibconf.h sorted out other linking issues. I dug out scalegfx.dll and scalegfx.lib from other sources. And, hey presto, it works! I would have ripped out most of my hair by now if not for you two so thank you both very much I’m hoping that having this running in Scratch might introduce a younger generation to the wonders of text adventuring!
