Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
71 user(s) are online (52 user(s) are browsing Forums)

Members: 0
Guests: 71

more...

Headlines

 
  Register To Post  

(1) 2 »
Another OS4 bug report
Just popping in
Just popping in


See User information
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

Go to top
Re: Another OS4 bug report
Home away from home
Home away from home


See User information
@Minuous

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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Another OS4 bug report
Just can't stay away
Just can't stay away


See User information
@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.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: Another OS4 bug report
Just can't stay away
Just can't stay away


See User information
@Minuous

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

Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
@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 :-/

Go to top
Re: Another OS4 bug report
Amigans Defender
Amigans Defender


See User information
@Minuous

Quote:

Minuous wrote:
$VER: AmiArcadia 14.06 (2.6.2010)

I have checked against the official specification in the RKRM Style Guide and it is compliant.


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.

Go to top
Re: Another OS4 bug report
Just can't stay away
Just can't stay away


See User information
@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:
Just tried it and it works here (update2 + beta updates).

Maybe it's fixed in the beta version of the OS you're using.

@Chris
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 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.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
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.

Go to top
Re: Another OS4 bug report
Just can't stay away
Just can't stay away


See User information
@Minuous

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

$VER: AmiArcadia 14.06 (02.06.2010)

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.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Go to top
Re: Another OS4 bug report
Quite a regular
Quite a regular


See User information
@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.


Edited by tonyw on 2010/6/7 1:29:07
Edited by tonyw on 2010/6/7 1:30:11
Edited by tonyw on 2010/6/7 1:31:11
Edited by tonyw on 2010/6/7 1:36:56
cheers
tony
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
@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.)

Go to top
Re: Another OS4 bug report
Quite a regular
Quite a regular


See User information
@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.

cheers
tony
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
@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.


Edited by Minuous on 2010/6/12 6:54:20
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
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?

Go to top
Re: Another OS4 bug report
Just can't stay away
Just can't stay away


See User information
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.


Edited by xenic on 2011/5/1 18:08:46
Go to top
Re: Another OS4 bug report
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Another OS4 bug report
Not too shy to talk
Not too shy to talk


See User information
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.

AmigaOne X5000 OS4.1 FEU1 And Lubuntu 10.04
1200 towered with Blizzard PPC - BVision and Mediator
And a new fantastic Chameleon64
Go to top
Re: Another OS4 bug report
Home away from home
Home away from home


See User information
@RIBDEVIL

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

Native version is ok, the 68k not

Go to top
Re: Another OS4 bug report
Not too shy to talk
Not too shy to talk


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

AmigaOne X5000 OS4.1 FEU1 And Lubuntu 10.04
1200 towered with Blizzard PPC - BVision and Mediator
And a new fantastic Chameleon64
Go to top
Re: Another OS4 bug report
Home away from home
Home away from home


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

Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project