Run-time error 104 in PC version

[codefenix-ConChaos]

https://github.com/Kirkman/mythyn-archive/tree/master/thieves-guild#pc

Regarding the remark "It is worth noting that the THIEVES.EXE in /distribution/ will not run under DOSBOX", it seems that this is actually not unique to DOSBox. Running the game both locally with the /L switch at a Win32 command prompt and as an external program in Synchronet both produce the same outcome in ERROR.LOG as what's documented in the one within the "source" folder. Here's mine from today:

Error Log Generated by Thieves' Guild
Date : 1/20/2021
Run-time error occurred
Exitcode = 104
I/O ERROR      :File not open for input
Address of error:
  Segment: 0000
  Offset:  0630

Exit code 104 means File not open for input, so what may be happening is the program is trying to read from a file that it hasn't opened yet.

According to the link, exit code 104 is "Reported by Read, BlockRead, Eof, Eoln, SeekEof or SeekEoln if the file is not opened with Reset." I'm having a glance through the PAS source files to try to determine where this could be happening, but I'm admittedly not very well-versed in Pascal. Maybe the "segment" and "offset" of the error can point someone more skilled toward an obvious solution.

[Kirkman]

Correct. That's exactly what I meant by the sentence immediately after the one you quoted:

The same errors that display in DOSBOX apparently were occurring at the time it was compiled, since they match what is recorded in ERROR.LOG in the /source/ directory.

(emphasis added)

[codefenix-ConChaos]

In an effort to troubleshoot the error, I downloaded Turbo Pascal with DOSBox and tried compiling the game with it, and interestingly enough, it seems to work without recreating the error.

Haven't spent a lot of time with it yet, but intend to fully test it out. Looks promising.

EDIT: Almost forgot to mention, I did have to make just a few modifications in order for the code to compile. I don't believe these changes had anything to do with the run-time error 104 though.

• THIEVES.PAS: Removed the "OVER" argument from the SAVEINFO call on line 74 (the SAVEINFO procedure doesn't have a parameter list, so unsure why this was included.
• MISC.PAS: Same as previous; removed the "OVER" argument from the SAVEINFO call on line 1653.
• ELOG.PAS: Included "comunit" and "io" in the uses list at the top, because it references identifiers conained in both.

[Kirkman]

@CraigEMP, that's fantastic. I will try to reproduce your results.

[Kirkman]

I have a copy of Turbo Pascal 7 installed within DOSBOX. I made the changes you described, but there were further problems I had to resolve before I could successfully compile THIEVES.PAS.

I went through the code and made several other changes (mostly wrong variable types). Then I found copies of the DDPLUS library, and NETFILEP.PAS, neither of which was included in the original PC source disk.

After that, I was able to compile THIEVES and TGEDIT with no problems using TP7 under DOSBOX. The resulting THIEVES.EXE runs fine in local mode under DOSBOX (THIEVES \L).

I think what I'll do is create a new directory in this repo with the updated code, and some rearranged folders, to allow people to compile it themselves. I'll also include a release ZIP with the compiled EXEs for any sysops who want to try installing on their board.

[codefenix-ConChaos]

Ah, that's right. Been looking at this off and on over the course of a few months, so forgot the fact that I also had to go find DDPLUS and NETFILEP.

I also turned off strict var-strings under Syntax options in Compiler Options. I believe that's what allowed me to compile with mismatched variables, although I agree that fixing them like you did is the better way to go.

When testing from my BBS, I did have to run PATCHCRT on my resulting EXEs in order to run them natively within Windows 32-bit, otherwise they produce a runtime 200. There are better ways of overcoming this error other than patching, such as avoidance of the CRT unit and/or the Delay function, but I haven't gone down that road yet.

[Kirkman]

My BBS runs under Linux, and I run old doors via DOSEMU, so hopefully I won't need to patch the EXEs.

But if there are easy, nonintrusive ways to alter the source so that Win32-compatible EXEs can be compiled, that might be a good thing to do.

[Kirkman]

@CraigEMP I've put the revised code in a new repo, reorganized the files, added some shell scripts to handle the compiling. https://github.com/Kirkman/thieves-guild-pc

Just out of curiosity -- are you running into problems with the player database getting corrupted? It's happened on my end several times. Haven't nailed down pattern/cause yet, though one guess is that it might have to do with interrupted sessions.

[codefenix-ConChaos]

I haven't yet run into any data corruption issues, but I'll be certain to be on the lookout for it. Thanks for the heads up.

Are you allowing multiple concurrent players in?

Checked out the new repo. Looks solid.

[Kirkman]

I don't believe I'm allowing concurrent users, but in any case so far it has only been my daughter and I playing -- at separate times.

I'm going to test a different build where instead of removing the parameters from the SAVEINFO() function, I'm going to restore it to the function definition. (The Atari ST code uses the SAVEINFO(OVER) throughout)