Hyperion Entertainment Message Boards

Support Forum
https://forum.hyperion-entertainment.com/

c:version bug

https://forum.hyperion-entertainment.com/viewtopic.php?t=1504

Page 1 of 2

c:version bug

Posted: Tue Jan 15, 2013 1:37 pm
by lazi
Something wrong with OS4 version command.
It affects at least the Hollywood created applications. The correct $VER:blabla text is in the file, but can't supply version information for the version command or for rawbinfo.

Here is how I compared it with the old version from OS3.1:

6.RAM Disk:> wget *>NIL: http://www.os4depot.net/share/graphics/ ... howgeo.lha showgeo.lha -O showgeo.lha
6.RAM Disk:> lha x -N showgeo.lha
Extracting from archive 'showgeo.lha':
9 files extracted, all files OK.

Operation successful.

6.RAM Disk:> version ShowGeo/showgeo full
VERSION: Could not find version information for "ShowGeo/showgeo".
6.RAM Disk:> classic:wb/c/version ShowGeo/showgeo full
ShowGeo 1.1 (2013.01.03.)
6.RAM Disk:>

Here is the version's of the version commands:

7.RAM Disk:> version c:version full
Version 53.5 (2011.02.19.)
7.RAM Disk:> version classic:wb/c/version full
Version 44.4 (1999.09.30.)
7.RAM Disk:>

(Maybe that is not an official Version :)

Re: c:version bug

Posted: Tue Jan 15, 2013 3:15 pm
by tbreeden
6.RAM Disk:> version ShowGeo/showgeo full
VERSION: Could not find version information for "ShowGeo/showgeo".
6.RAM Disk:> classic:wb/c/version ShowGeo/showgeo full
ShowGeo 1.1 (2013.01.03.)
Maybe the embedded version needs a null byte at the beginning.

I had not seen the announcement, but at some point the AOS 4 version command began requiring that the embedded version string be bracketed by null bytes.

I found the same thing in my Modula-2 programs until I realized what was happening.

Here is one definition of the requirement:
OpenAmiga doc

Tom Aglet M2

Re: c:version bug

Posted: Tue Jan 15, 2013 8:10 pm
by xenic
tbreeden wrote: Maybe the embedded version needs a null byte at the beginning.

I had not seen the announcement, but at some point the AOS 4 version command began requiring that the embedded version string be bracketed by null bytes.

I found the same thing in my Modula-2 programs until I realized what was happening.

Here is one definition of the requirement:
OpenAmiga doc

Tom Aglet M2
I don't think that requirement is completely true. It may be true of compiled programs but version strings also work in text files. I have numerous AmigaDOS scripts and ARexx scripts that contain version strings and work with the version command. I HEX edited the "showgeo" file and added NULL bytes before and after the version string and the OS4 version command still didn't find it.

This "version command" issue was discussed in a forum at one of the major Amiga WEB sites a long time ago. The conclusion at that time was that the version string could not be near the bottom of a large file or it will not work with the OS4 version command. To test that hypothesis, I HEX edited the ShowGeo file and placed a version string further from the end of the file. Unfortunately, I created a file that causes the "OS4 version command" to crash! In order to confirm the version command crash I HEX edited the "C:Avail" command and removed about half of the file from the center of the command; yielding a file about half the size of the original. The OS4 version command crashes on that file too. I tried to attach the file so others could confirm the problem but uploading an attachment in this forum won't work for me. To confirm the problem just cut a couple of hundred bytes from the center of the "Avail" command and run the version command on it.

Re: c:version bug

Posted: Tue Jan 15, 2013 8:54 pm
by lazi
@Xenic:

I made similar tests with the same results.

The Hollywood generated executable links the applet to the end of the code which is far from the beginning of the file.
I think that it shouldn't be a problem for Version.

@tbreeden:

Thanks to point out to the docs. It looks like it accepts a CR too for the end of the string.

Re: c:version bug

Posted: Tue Jan 15, 2013 10:39 pm
by gazelle
@lazi:

I think it's because version uses LoadSeg() for executeable files to load them into memory. The old version command doesn't understand the ELF format, so it does use a different approach.
Maybe if you are assigning the versionstring to an actual variable inside the program it may work.

@xenic:

If you destroy the structure of the executable file, who knows what the LoadSeg() will do.

Re: c:version bug

Posted: Wed Jan 16, 2013 1:24 am
by xenic
gazelle wrote:@lazi:

I think it's because version uses LoadSeg() for executeable files to load them into memory. The old version command doesn't understand the ELF format, so it does use a different approach.
Maybe if you are assigning the versionstring to an actual variable inside the program it may work.

@xenic:

If you destroy the structure of the executable file, who knows what the LoadSeg() will do.
Regardless, it shouldn't crash. If it does use LoadSeg() then both LoadSeg() and the Version command need some additional error checking. This needs to go into the bug tracker. Files from other OS's are common now and it wouldn't be unusual to D/L a corrupt file.

Re: c:version bug

Posted: Mon Jan 21, 2013 9:57 am
by lazi
gazelle wrote: I think it's because version uses LoadSeg() for executeable files to load them into memory. The old version command doesn't understand the ELF format, so it does use a different approach.
Maybe if you are assigning the versionstring to an actual variable inside the program it may work.
I do not know about the ELF format, but the problem look like that the Hollywood linker put the script after the scope of version. The script is whereabouts the Hollywood "coder" can put anything.

So if it is the intended behaviour of version to check only the code chunk, then Hollywood needs to hold some place in the interpreter code part for version string which the linker could alter. I don't think that Hollywood author would love to do that.

In the other case if version should check the entire file then it is a bug.

Anyway the OpenAmiga doc said this:
To add a version string to your program you must make sure that the binary contains a string of characters that represent the version string. All version tools then parse your binary, byte by byte, to find the version string that you have defined for it.
How can we define "binary" in this context?

Re: c:version bug

Posted: Mon Jan 21, 2013 12:47 pm
by tonyw
How can we define "binary" in this context?
Probably "binary" means a file which contains stuff that you can't control, like headers and checksums.

I've looked at the code for C:Version and I can assure you that it knows nothing about where in the file it is looking. It relies on DOS to LoadSeg() the file first. If the file can't be loaded fully or if the Version string is in a part of the file that is not loaded as executable code, then it won't be found.

If someone can provide a crash log for the failing case, I'll look into it. Give me the crash log or the binary of a file that causes C:Version to crash.

Re: c:version bug

Posted: Tue Jan 22, 2013 12:43 am
by xenic
@tonyw
I've looked at the code for C:Version and I can assure you that it knows nothing about where in the file it is looking. It relies on DOS to LoadSeg() the file first. If the file can't be loaded fully or if the Version string is in a part of the file that is not loaded as executable code, then it won't be found.

If someone can provide a crash log for the failing case, I'll look into it. Give me the crash log or the binary of a file that causes C:Version to crash.
Considering the size of programs for OS4 now (RA-OWB 18+ megabytes) it's absurd to LoadSeg() entire programs just to find a version string in the first couple of hundred bytes (in most cases). Apparently it also leads to the kind of proglems we are having with the OS4 version command. I've replaced mine with the OS3 version command. Here is a crashlog for the version command used on the OS4 Avail command with Hex bytes 0x44 through 0x49 corrupted:
Hidden Text - Click to Show :
Crash log for task "version"
Generated by GrimReaper 53.2
Crash occured in module kernel at address 0x02029274
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 00000000 594FA200 00000000 7E1C2020 00000000 FFFFF00F FFFFFFFF 6FF8F000
8: 7E1C2020 7E1C3000 00000000 02048C20 0000079C 00000000 00000001 00000001
16: 594FA2FC 594FA2C6 00000000 48842022 48844088 02820000 6FFA9E40 00000008
24: 0000008C 5D629F38 00000005 00000078 5D629E50 7E1C2020 00000000 5B0DB518


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0.0996094 0.99999 0
4: 0 0 25000 2.14748e+09
8: 1 4.5036e+15 556 104
12: 120 615 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 0 0

FPSCR (Floating Point Status and Control Register): 0x82004000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0000D030
Condition (cr) : 0x24442044
Instruction Pointer (ip) : 0x02029274
Xtended Exception (xer) : 0x00000000
Count (ctr) : 0x02048C20
Link (lr) : 0x02048C44
DSI Status (dsisr) : 0x42000000
Data Address (dar) : 0x7E1C3000



680x0 emulated registers:
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x02029274 belongs to module "kernel" (HUNK/Kickstart)

Stack trace:
native kernel module kernel+0x00029274
native kernel module newlib.library.kmod+0x00007960
native kernel module elf.library.kmod+0x00004fb0
native kernel module elf.library.kmod+0x00000da4
native kernel module elf.library.kmod+0x000003d8
native kernel module dos.library.kmod+0x0003b768
native kernel module dos.library.kmod+0x000195f0
module version at 0x7FA7FE10 (section 5 @ 0xDF0)
module version at 0x7FA8026C (section 5 @ 0x124C)
module version at 0x7FA80CF8 (section 5 @ 0x1CD8)
version:_start()+0x1D0 (section 1 @ 0x1eb8)
native kernel module dos.library.kmod+0x00022a0c
native kernel module kernel+0x00043054
native kernel module kernel+0x000430d4


PPC disassembly:
0202926c: 409d002c ble- cr7,0x2029298
02029270: 38a5fff0 subi r5,r5,16
*02029274: 90090000 stw r0,0(r9)
02029278: 2b85000f cmplwi cr7,r5,15
0202927c: 90090004 stw r0,4(r9)

System information:

CPU
Model: P.A. Semi PWRficient PA6T-1682M VB1
CPU speed: 1800 MHz
FSB speed: 900 MHz
Extensions: altivec

Machine
Machine name: AmigaOne X1000
Memory: 2097152 KB
Extensions: bus.pci bus.pcie

Expansion buses
PCI/AGP
00:1D.0 Vendor 0x1959 Device 0xA004
Range 0: 007F03F8 - 007F0400 (IO)
00:1D.1 Vendor 0x1959 Device 0xA004
Range 0: 007F02F8 - 007F0300 (IO)
00:1A.0 Vendor 0x1959 Device 0xA007
00:00.0 Vendor 0x1959 Device 0xA001
00:01.0 Vendor 0x1959 Device 0xA009
00:14.3 Vendor 0x1959 Device 0xA005
00:1C.0 Vendor 0x1959 Device 0xA003
Range 0: 007F0200 - 007F0240 (IO)
00:1C.1 Vendor 0x1959 Device 0xA003
Range 0: 007F0240 - 007F0280 (IO)
00:1C.2 Vendor 0x1959 Device 0xA003
Range 0: 007F0280 - 007F02C0 (IO)
00:11.3 Vendor 0x1959 Device 0xA002
00:11.2 Vendor 0x1959 Device 0xA002
00:11.1 Vendor 0x1959 Device 0xA002
00:11.0 Vendor 0x1959 Device 0xA002
00:10.0 Vendor 0x1959 Device 0xA002
00:03.0 Vendor 0x1959 Device 0xA00C
00:04.0 Vendor 0x1959 Device 0xA00A
00:05.0 Vendor 0x1959 Device 0xA00A
00:08.0 Vendor 0x1959 Device 0xA000
00:09.0 Vendor 0x1959 Device 0xA000
00:15.0 Vendor 0x1959 Device 0xA006
00:1B.0 Vendor 0x1959 Device 0xA00B
00:1E.0 Vendor 0x1959 Device 0xA008
Range 0: 007F0400 - 007F0500 (IO)
Range 1: 007F0500 - 007F0600 (IO)
0A:12.0 Vendor 0x1002 Device 0x4380
Range 0: 00001040 - 00001048 (IO)
Range 1: 00001058 - 0000105C (IO)
Range 2: 00001048 - 00001050 (IO)
Range 3: 00001050 - 00001054 (IO)
Range 4: 00001000 - 00001010 (IO)
0A:13.0 Vendor 0x1002 Device 0x4387
Range 0: A0208000 - A0209000 (MEM)
0A:13.1 Vendor 0x1002 Device 0x4388
Range 0: A0207000 - A0208000 (MEM)
0A:13.2 Vendor 0x1002 Device 0x4389
Range 0: A0206000 - A0207000 (MEM)
0A:13.3 Vendor 0x1002 Device 0x438A
Range 0: A0204000 - A0205000 (MEM)
0A:13.4 Vendor 0x1002 Device 0x438B
Range 0: A0205000 - A0206000 (MEM)
0A:13.5 Vendor 0x1002 Device 0x4386
Range 0: A0209800 - A0209900 (MEM)
0A:14.0 Vendor 0x1002 Device 0x4385
Range 0: 00001020 - 00001030 (IO)
Range 1: A0209000 - A0209400 (MEM)
0A:14.1 Vendor 0x1002 Device 0x438C
Range 0: 00001038 - 00001040 (IO)
Range 1: 00001058 - 0000105C (IO)
Range 2: 00001030 - 00001038 (IO)
Range 3: 00001050 - 00001054 (IO)
Range 4: 00001010 - 00001020 (IO)
0A:14.2 Vendor 0x1002 Device 0x4383
Range 0: A0200000 - A0204000 (MEM)
0A:14.3 Vendor 0x1002 Device 0x438D
Range 0: 00000000 - 00100000 (MEM)
0A:14.4 Vendor 0x1002 Device 0x4384
0C:05.0 Vendor 0x1102 Device 0x0002
Range 0: 00003100 - 00003120 (IO)
0C:05.1 Vendor 0x1102 Device 0x7002
Range 0: 00003120 - 00003128 (IO)
0C:06.0 Vendor 0x10EC Device 0x8139
Range 0: 00003000 - 00003100 (IO)
Range 1: A0310000 - A0310100 (MEM)
02:00.0 Vendor 0x1002 Device 0x68F9
Range 0: 90000000 - A0000000 (PREF.MEM)
Range 2: A0020000 - A0040000 (MEM)
Range 4: 00002000 - 00002100 (IO)
02:00.1 Vendor 0x1002 Device 0xAA68
Range 0: A0040000 - A0044000 (MEM)
If you want the binary (corrupt Avail command) you will need to tell me how to get it to you.

Re: c:version bug

Posted: Tue Jan 22, 2013 9:45 am
by ktadd
tonyw wrote: I've looked at the code for C:Version and I can assure you that it knows nothing about where in the file it is looking. It relies on DOS to LoadSeg() the file first. If the file can't be loaded fully or if the Version string is in a part of the file that is not loaded as executable code, then it won't be found.
Just today....errr....yesterday now. I wrote a routine for my program using LoadSeg() to check the version of MPlayer. This method is a bit slow. Is there a better way to do it?
All times are UTC+02:00
Page 1 of 2

Powered by phpBB® Forum Software © phpBB Limited