Another OS4 bug report

Hello, I received the following bug report about http://aminet.net/misc/emu/AmiArcadia.lha:

"Here I can't get any info about version, if I open the info icon (with right mouse button on the bin file) I'm getting "not availible" in version part."

The version string in question is:

$VER: AmiArcadia 14.06 (2.6.2010)

and it is null terminated.
Apparently the CLI VERSION command works fine with it even under OS4, and of course both the CLI and WB version commands work fine with it under OS3.9.
I have checked against the official specification in the RKRM Style Guide and it is compliant.
Other similar version strings (eg. from Report+) work fine, it seems to be a bug in the OS4 WB icon info program.
The user is using AmigaOS 4.1 Update 2 on SAM Flex 800.

Regards

James Jacobs
Amigan Software

@Minuous

Imho for making good bug report, you need prepare a small as possible source code which show the problem.

@Minuous

Do you have zero/null in front of $VER as well ? I have that one there too. Otherwise it looks correct. What type of variable you have that string stored ? Show us the whole code line.

@Minuous

Just tried it and it works here (update2 + beta updates).

@TSK

>Do you have zero/null in front of $VER as well ? I have that one there too. Otherwise it looks correct.

#define SHORTVERSION "14.06"
#define VERSION "$VER: AmiArcadia " SHORTVERSION " (5.6.2010)"
...
WriteChunkRecords(Handle, VERSION, strlen(VERSION), 1);
...

I looked at a hex dump of the generated executable, the string is embedded as I described.
I actually tried putting a leading null at the front of the $VER, however the user didn't report any improvement so I removed it again. I should note that there is no requirement for leading nulls in the Style Guide. I assume this is still considered the official reference for what constitutes a valid version string.

@Elwood

That is odd, I will tell him it works for others who have the same setup as him :-/

@Minuous

Quote:

Hmm... I'm not completely sure about that. I don't think the version or revision parts should have leading zeros, so it should be 14.6, not 14.06.

I'd expect the version to still display though, I've never seen problems with version numbers which are clearly in the wrong format.

@Minuous

There's two versions 68k v14.06 and OS4 specific version v8.3 (by abalaban) in AmiNet. OS4 version shows the version string but your 68k version doesn't. 68k version doesn't give version string with Version command from Shell either.

@Elwood
Quote:
Maybe it's fixed in the beta version of the OS you're using.

@Chris
Quote:
I just tested with my own app and those leading zeros doesn't matter.

@thread
I tested with MOS v14.05 version also and it gives the version string just fine. 68k version is the only one with problem.

Just re-tested under OS3.9 CLI Version and WBInfo, both AA8.3 for OS4 and AA14.06 for OS3.

OS3.9 is not having any problems with the version strings.

I assume it doesn't require zeroes in the date field like this:

$VER: AmiArcadia 14.06 (02.06.2010)

because I have seen a lot of version strings which don't have zeroes in the date field. The actual version part (14.06) shouldn't matter I would think because it isn't parsed.

@Minuous

Quote:
Yes. The style guide was changed for AmigaOS version 4 so you should not include those zeros in dates AFAIK (and they're not needed anyway).

Maybe it's fixed already in the betas like Elwood said.

@Minuous

Forget about the leading zeroes in the date strings, that's a red herring and nothing to do with the problem (if there is one).

TSK was right, you should have a null in front of the "$VER" token, but that's only a safeguard, in our case there are several before this string so it doesn't matter.

From the 68K binary, it looks as though your version string is:
"($VER: AmiArcadia 14.06 (2.6.2010)"

Get rid of the opening parenthesis at the beginning of the string and it should work on all systems:

"$VER: AmiArcadia 14.06 (2.6.2010)"

If you don't have an opening parenthesis at the start of the string, then what appears as an opening parenthesis in the binary is confusing the version command, which is looking for strings. Put a null at the beginning of the string just to make sure:

"\0$VER: AmiArcadia 14.06 (2.6.2010)" This is the standard format used by all OS components these days and will work no matter what the compiler and/or loader put immediately before it.

@tonyw

OK, thanks for ascertaining what the problem is. I will modify the version string for V14.08 to be work around this issue.

(I still maintain that the parser should not be so easy to break, it shouldn't be put off by anything preceding the $VER. Apparently it's fixed in the latest beta though which is good.)

@Minuous

I'm using the latest version here, there isn't any later than this. I don't think it's going to change.

IIRC, the early versions did a character-by-character parse of the binary file, which was extremely slow, but OK on 68K binaries, because they were so small.
The later version for PPC binaries uses a different approach, although I can't remember the details. As a result of the changes, the program reads in all strings starting with printable characters and parses them (IIRC). Thus the characters $-V-E-R- must be the first four characters in the string, which means no printable characters in the bytes immediately preceding the $VER sub-string. Adding a null before the $VER means the $VER can always be found.

@tonyw

There are lots of existing version strings in existing files which are not going to be parsable by this method. At least, if it fails to find the version string in the string table, it should do a byte-by-byte search as a fallback. Also, the program in question is a 68K program not a PPC program so it should be using the byte-by-byte search on it anyway.
Also, the parser should stop when it gets a valid version string. There is another version string later in the file, seems like it is using that instead of the first one. (So the problem is still there in V14.08.) It would be more efficient and also more correct to stop after the first valid version string.

AmiArcadia 15.7 for OS3 has a version string that is completely compliant with all the rules (even these new and frankly silly rules) but still OS4 can't recognize the version. Why?

I don't think the problem has anything to do with the format of the version string. If I split the file in 2 (SDK:local/C/split -b 518756 AmiArcadia), the version command works on the half of the file that contains the version string. That indicates that the version command is capable of recognizing the version string itself but for some reason cannot traverse the original file to find it. I also tried Hex editing the file and adding a version string near the beginning of the file (The file probably will not execute properly then). The version command could not find the version string there either. Something else about the file is causing the version command to fail; it's not the version string itself. I also tested with a copy of the OS 3.9 (68k) version command. It fails to find the string too. Some function that both the OS3 (68k) and OS4 version commands are calling is failing. I think this is a bug in an OS4 library.

EDIT: I'm using SAM Flex 800 with OS4.1u2
EDIT2: If I add an icon for the half of the split file containing the version string, WorkBench Info also finds the version.
EDIT3: Above testing was with OS3 (68k) AmiArcadia.

@xenic:

That's interesting.
I'm getting somewhat different results to you. I just tested with the OS3.9 Version command (V44.4 from 1999) under OS3.9+BB4, on the complete file, and it parses the version string fine. Also, the BB4 Workbench Info command (ie. RAWBInfo V1.36 from 2011) is parsing it fine too. So as you surmise it is probably an OS4 library bug.

All work fine here,

Version trough Icon shows 15.7 (29-04-2011)
In the shell, the same.
Trough DirOpus 15.7 (29-04-2011).

So no error or bug here.

@RIBDEVIL

Mmm did you test it with AmiArcadia 15.7 68k or AmiArcadia 15.7 OS4 ?

Native version is ok, the 68k not

Uppps, OS4.1u2
Now is to late, tomorrow test it with the 1200.
Sorry

Please test both versions, native and emulated (only) under OS4, our problem is that version command into the 68k bin doesn't work :-/