HUNK_END optional in Amiga load files?

[Keir]

I'm picking apart Amiga load files and I noticed that some do not have a HUNK_END block between hunks. Instead it seems that the hunk number is implicitly incremented when the next CODE/DATA/BSS block is reached.

Question is: Is this legit? Will all Kickstart versions load such binaries okay?

I have always observed HUNK_END at the very end of a load file -- I assume that one is absolutely necessary?

I am generating packed executables so it would be nice to elide these HUNK_END blocks if they're not needed. Otoh it doesn't save much, so I won't bother if it's going to cause hassle.

[Hedeon]

I am not sure. Could you give an example of an offending binary?

[Keir]

Originally Posted by Hedeon

I am not sure. Could you give an example of an offending binary?

Seems common in small demos. Possibly because this is a common packed-exe trick. eg, first two I looked at:

Strukton by Focus Design: https://files.scene.org/view/parties...d_strukton.zip

Imacennial by Dekadence: http://www.dekadence64.org/dkd-imac.lha

[ross]

Originally Posted by kaffer

I'm picking apart Amiga load files and I noticed that some do not have a HUNK_END block between hunks. Instead it seems that the hunk number is implicitly incremented when the next CODE/DATA/BSS block is reached.

Question is: Is this legit? Will all Kickstart versions load such binaries okay?

I have always observed HUNK_END at the very end of a load file -- I assume that one is absolutely necessary?

I am generating packed executables so it would be nice to elide these HUNK_END blocks if they're not needed. Otoh it doesn't save much, so I won't bother if it's going to cause hassle.

Yes, common practice in different exe-packers and exe-tampered to save some bytes.
Works in every existing kickstart so far. So definitely a "feature" that will be maintained for compatibility in 'future'() kickstarts.

EDIT: long time ago I had also tested for the last HUNK_END and from what I remember was never excludable

[Keir]

Originally Posted by ross

Yes, common practice in different exe-packers and exe-tampered to save some bytes.
Works in every existing kickstart so far. So definitely a "feature" that will be maintained for compatibility in 'future'() kickstarts.

EDIT: long time ago I had also tested for the last HUNK_END and from what I remember was never excludable

Excellent, thank you. I have literally just had the first successful test run of my exe packer, so this is a nice finishing touch.

I have another question, about extra space at the end of relocatable blocks: That is, when the longword count in HUNK_HEADER (3f3) is longer than the longword count in the CODE/DATA/BSS block itself. It looks like DOS will allocate this extra space, but may not initialise it to zeroes (like it does for the first N longwords declared within a BSS block). Can I rely on this as it may make my packs a bit smaller?

EDIT: KS2+ seem to zero the extra BSS space. Earlier KS seem not to. Perhaps it is best to zero it then.

[ross]

Originally Posted by kaffer

I have another question, about extra space at the end of relocatable blocks: That is, when the longword count in HUNK_HEADER (3f3) is longer than the longword count in the CODE/DATA/BSS block itself. It looks like DOS will allocate this extra space, but may not initialise it to zeroes (like it does for the first N longwords declared within a BSS block). Can I rely on this as it may make my packs a bit smaller?

EDIT: KS2+ seem to zero the extra BSS space. Earlier KS seem not to. Perhaps it is best to zero it then.

Yes, zeroed only in KS2+.