WinAGI Version 1.2.5

[AGKorson]

I got a request to add some shortcut keys to the view editor in version 1.2.3. I also wanted to include some additional support for non-standard characters in message text, so I added an option to insert characters by using 'slash codes'. For example, "\x01" will insert character 0x01, "\x1A" will insert character 0x1A, and so on. There are also a couple more minor bug fixes.

You can find the install file on the AGI Wiki page for WinAGI.

And for those who are hoping for a Linux version of WinAGI, I have decided to begin work on re-writing WinAGI in C#. It is going to take me a lot of time, as I am looking at a pretty steep learning curve. I'm not making any promises on a completion date, but I'll try to provide occasional updates.

[Collector]

Thanks for updating the Wiki, too, though I see that the source is still is for 1.2.3.

And for those who are hoping for a Linux version of WinAGI, I have decided to begin work on re-writing WinAGI in C#. It is going to take me a lot of time, as I am looking at a pretty steep learning curve. I'm not making any promises on a completion date, but I'll try to provide occasional updates.

Or you could build on top of Visual AGI for a bit of a head start. Lance's work should have filled in the logic and sound backend, so it mostly needs the sound editor and compiler.

[AGKorson]

Thanks for updating the Wiki, too, though I see that the source is still is for 1.2.3.

Yeah, I didn't bother. I don't think anybody is actually interested in the source anyway. But I suppose for completeness, I'll upload it eventually.

Or you could build on top of Visual AGI for a bit of a head start. Lance's work should have filled in the logic and sound backend, so it mostly needs the sound editor and compiler.

Maybe. I haven't seen what they've done yet. I would want to make sure all the enhancements of WinAGI are included, especially the additional tools. And I'm not interested in a joint SCI/AGI tool; I think they are too different (and the user bases are also too different).  I figure I will use this exercise as a way to finally learn a modern dev language. It's a bucket list thing. So porting WinAGI as its own program is of interest to me.

[Collector]

I'll email Lance and see if he'll give you access to his branch since it probably has a more complete backend for his C# interpreter.

[obscurenforeign]

Another burst of productivity from me, another wine bug I find. This time in the WORDS.TOK editor (which I guess I never played with before...)

Trying to save a modified WORDS.TOK gives this error:

Error during WORDS.TOK compilation:

55: File already open

Existing WORDS.TOK has not been modified.

Trying to export one, it just fails silently. No file is written.

I couldn't find a topic specifically for 1.2.7 but it's affected.

edit: saving as .agw seems to work but it appears to be a completely different format. Not sure if this opens up a workaround yet.

[AGKorson]

That's certainly odd. To be clear, the error you got was "WORDS.TOK compile error(55: File already open)"? if it was formatted differently then it's not coming from WinAGI.

The compile (save) function for WORDS.TOK is not complicated; it creates a temporary file, adds the content, then replaces the existing WORDS.TOK file with the newly created temporary file.

If the existing WORDS.TOK file has an open handle, then the OS can't delete it in order to copy over the new file. That seems to be what you are experiencing. But WinAGI doesn't hold the WORDS.TOK file open - when the file is loaded for any reason (editing, previewing, etc) it opens the file, extracts the data to memory, then immediately closes the file.

So I don't know why the file has an open handle. If you are doing something else with it (maybe it's selected in a file explorer?) that may be holding it open. Is there anything else you were doing with any of the game files when this happened?

I'm pretty sure it's not being held open within WinAGI. There is literally only one place where a file handle is opened for WORDS.TOK - in the Load function - and it only opens it long enough to copy the file data into memory. Also, even if there was an error on opening, the error handler makes sure the file is closed and the handle released.

Oh, and regarding the .agw format, don't bother- it's basically a text dump of the words. Fifteen years ago, when I first made this program, I had this idea of creating an updated AGI interpreter, that would support improved graphics, sound, mouse support, etc. I've long since given up on that idea. The alternate formats for words and inventory objects were one of the first things I played around with. I left them in, but they really don't have any useful purpose, other than providing a human-readable version of words and objects.

[obscurenforeign]

The way I transcribed the error reflects how it appeared. I've attached a screenshot of it now. (Should've done that to begin with.)

The first time this occurred, I had admittedly been testing my game (to what extent it can be described as such) in ScummVM. However by the time I posted my previous message I had already tried saving the file again under every possible scenario, including completely rebooting the OS. Surely, its file handles can't persist across reboots.

Your description of how WinAGI handles WORDS.TOK got me thinking, Linux handles files slightly differently vs. Windows, and that can sometimes cause bugs. ...The most well-known phenomenon would be files of different cases being treated as different, I seem to recall ScummVM's readme warning that under Linux some games (such as later Humongous games) would need to be renamed to all upper or lowercase in order to work... they had been shipping games with filenames like Pajama.HE0, PAJAMA.(a), and pajama.HE4... and every other combination imaginable... sometimes all at once. This is fine on Windows, but since on Linux PAJAMA and pajama look different, it wouldn't be able to find the files... I think that's been resolved by now and you can use the files as they are, though I'm not sure how.

In the case of WinAGI, I enabled debug output, and within the... over 500MB of text that gave me, I found a few references to a .tok capitalization:

Code: [Select]

0009:Call oleaut32.VarBstrCmp(01a91a64 L".tok",6265a600 L".agw",00000000,00030001) ret=6601b0e8
0009:Call ucrtbase.memcmp(01a91a64,6265a600,00000008) ret=6a35c9a0
0009:Ret  ucrtbase.memcmp() retval=00000001 ret=6a35c9a0
0009:Ret  oleaut32.VarBstrCmp() retval=00000002 ret=6601b0e8
0009:Call oleaut32.SysFreeString(01a9887c L".TOK") ret=660e60df
0009:Call ntdll.RtlSizeHeap(00110000,00000000,01a98878) ret=65232200
0009:Ret  ntdll.RtlSizeHeap() retval=00000010 ret=65232200
0009:Ret  oleaut32.SysFreeString() retval=00000000 ret=660e60df
0009:Call oleaut32.SysFreeString(01a91a64 L".tok") ret=660e60dfHowever, I couldn't find any corresponding references in the WinAGI source code.

My other thought is in how Linux handles file handle exclusivity... with a file open in a program, I can rename it or even delete it... can't do that on Windows. The program it was open in will act as if you hadn't done these things until you close the file, when the program will return to reality... after it's closed, the program will no longer be able to find the file if you try to reopen it. (And in the case of deleted files, the space the file occupies on the partition won't freed until the deleted file's been closed...) However, I can't think of how this would affect WinAGI.

[AGKorson]

OK, that message is the WinAGI generated error message. That confirms what I thought was happening; something is maintaining an open file handle to WORDS.TOK, preventing it from being deleted.

I went through all the code again, line by line; there is just no place in WinAGI where that file is opened for longer than three lines of code; it gets opened, data copied to memory, then closed before anything else happens. It's the same process used for all files, including VOL files, DIR files, and OBJECT, also individual resource files. I can't explain why it would behave differently for WORDS.TOK. I also feel confident that the only direct references to "WORD.TOK" are all upper case; there's nowhere in code where it's referred to by lower case letters. I will continue to look to see if I'm missing something - there is a lot of code to look through.

Are you seeing any problems with updating/modifying any other game files? Can you make changes to OBJECT? What about a full recompile? Does that rewrite all the game files correctly?

[obscurenforeign]

Looks like the object editor works. I was able to add a new item into the OBJECT file and it didn't give any errors. Changes I made persist.

I've done a full recompile many times (habit) and it's always been successful. Heck, I've already done a bit of scripting using WinAGI in Linux. My changes are appearing when I load the game in ScummVM or copy it into Dosbox.

What a strange bug. The only remote thing I can think of is if the VB runtime is "helpfully" converting your code to lowercase somewhere... wouldn't be the first time Microsoft did that, I seem to recall Windows 9x converting all uppercase file names to title case by default, so you'd see Words.tok instead of WORDS.TOK. Can't remember if it was just visual or if it'd change the case when you modify the file.

[AGKorson]

Definitely very strange. All other file operations use lowercase file extensions, so maybe that is the problem. I could try using "words.tok" (lower case) as the filename.

I can build a small test app that tries opening/closing a file with different versions of the file name and extension (upper, lower, title) - if you could run that, it would least confirm or reject the hypothesis that it's related to file extension case. Let me know if you're interested in testing.

[obscurenforeign]

Definitely very strange. All other file operations use lowercase file extensions, so maybe that is the problem. I could try using "words.tok" (lower case) as the filename.

I can build a small test app that tries opening/closing a file with different versions of the file name and extension (upper, lower, title) - if you could run that, it would least confirm or reject the hypothesis that it's related to file extension case. Let me know if you're interested in testing.

I am!

[AGKorson]

OK. I'll send you a PM with a test app.