Great!

Great news- thanks for all the hard work - it is appreciated.

Thanks for that! Well done.

TrevorD

May I put in a request for consideration for a minimum alteration to the IFF standard that will allow, hopefully, for current and future resistant use.

The size of fields in IFF are 32 bit words, giving 4 billion, 4 Gig unsigned, +- 2 Gig signed.

I hopefully propose that the idea of signed 32 bit values are used, and that the existance of a negative value, the MSB being set, is used to extend the size by a further size value, as in another 32 bit signed structure. This initself also has the MSB available, giving a 2 stage decode of only 62bit, but allowing auto extension into 128 bit MAC and 256 bit UUID etc.

I apologise if this is already under consideration.

great :)

@RodTerl:

That suggestion would be better made on the Hyperion AmigaOS forum than in a news item thread.

@RodTerl

Quote:

I hopefully propose that the idea of signed 32 bit values are used, and that the existance of a negative value, the MSB being set, is used to extend the size by a further size value, as in another 32 bit signed structure. This initself also has the MSB available, giving a 2 stage decode of only 62bit, but allowing auto extension into 128 bit MAC and 256 bit UUID etc.

Over the years I've been giving this very subject a thought as well: the limit of 2 Gb CAN be a problem in the future. The chance is not that big as a file of some 2Gb in signed format (or 4 Gb in unsigned format as you propose) is quite a file, but anyway. Whatever is done should be done with current limitation of signed 32 bit values in mind. Backwards compatabillity. That was the expression i was looking for.

I have been thinking of extending the arithmetical aspect of IFF to even 64 bit unsigned. This could be achieved by prefixing any chunk that exceeds the 2^32 limit by a special disignator like 'E','X','T','-', in which case the chunksize is represented as 64 bit.

So a file exceeding 2Gb would start like this:
'E','X','T','-','F','O','R','M' , .
Old applications/libraries won't be able to deal with this file as they don't now the 'E','X','T','-' ID.
Some kind of trouble kicks in when a file (or chunk) is to be written of an uknown size. This can be remedied by taking 8 bytes more size for the chunkheader, Is the size of the chunk less then can be contained in 32 bits, then an empty chunk is writen with an ID of 'N','U','L','L' and size of 0. 'N','U','L','L' is currently defined in the headerfile.
A file of unknown size gets a header of 20 bytes in stead of the current 12.
In case the file turns out to be less then 2^32 in size the first 12 bytes are used as per current implemetation. The remaing 8 bytes are used with a 'N','U','L','L' ID and a 0 for size. And current apps will still be able to read it.

Resumé:
Backwards compatibillity retained. Not to complicated to implement. Files can take on a size of 2^64 bytes. For the time being I dare say that this is sufficient for a long, long time.

OldFart

EDIT:
Come to think of it: by introducing the 'EXT-' ID the size field could be set to contain either a value in LittleEndian or in BigEndian. Offering the sign bit for this in anywhich representation by setting it to result in this rules:
BE: even number of bits set.
LE: Odd number of bits set.
As you can't see beforehand in which way a size is represented, a count of the bits set gives you a perfect clue: Odd means LE an even means BE. Simple.
File/chunk sizes are hereby reduced by 1 bit, though.

Last edited by OldFart on 13-May-2012 at 07:21 AM.

Quote:

Some kind of trouble kicks in when a file (or chunk) is to be written of an uknown size. This can be remedied by taking 8 bytes more size for the chunkheader, Is the size of the chunk less then can be contained in 32 bits, then an empty chunk is writen with an ID of 'N','U','L','L' and size of 0. 'N','U','L','L' is currently defined in the headerfile. A file of unknown size gets a header of 20 bytes in stead of the current 12. In case the file turns out to be less then 2^32 in size the first 12 bytes are used as per current implemetation. The remaing 8 bytes are used with a 'N','U','L','L' ID and a 0 for size. And current apps will still be able to read it.

Why not use the already existing 'JUNK' chunk for this purpose instead of defining another one?
http://wiki.amigaos.net/index.php/IFF_FORM_and_Chunk_Registry#.28any.29.JUNK

Quote:

EDIT: Come to think of it: by introducing the 'EXT-' ID the size field could be set to contain either a value in LittleEndian or in BigEndian. Offering the sign bit for this in anywhich representation by setting it to result in this rules: BE: even number of bits set. LE: Odd number of bits set. As you can't see beforehand in which way a size is represented, a count of the bits set gives you a perfect clue: Odd means LE an even means BE. Simple. File/chunk sizes are hereby reduced by 1 bit, though.

Don't make things more complicated than they need to be. There's really no need to have big-endian and little-endian versions of the same file format. Just look at RIFX format (big-endian version of RIFF format) to see why this is a seriously **DUMB** idea (almost nothing uses/supports RIFX, because it's too much work for practically no benefit).

Last edited by salass00 on 13-May-2012 at 07:57 AM.

looks great, thx

Great news.

'Hope I can contribute one of these days.

g0blin

What wonderful work! Right path :)
Could everyone does changes?
I suggest you to use for code example a plugin for mediawiki which support sintax highlight, it world very useful...

I'm not a coder, but I guess it is a very good thing, another step in the right direction...

@SSolie
I would put a link to the wiki in the AmigaOS.net menu.

Last edited by andres on 13-May-2012 at 10:35 AM.

Really important news, we need quality documentation to be able to develop quality software!
Keep up the excellent work!

Excellent

The combination of the Amiga and wiki spirit should produce a very valuable resource for us all.

Regards, Roy Leith

What about AmigaMail Vol2 documents? You should add and update them like other ones, or not?

What about a pdf export plugin for mediawiki? it would be very useful :)

Last edited by ShInKurO on 13-May-2012 at 11:22 AM.
Last edited by ShInKurO on 13-May-2012 at 11:07 AM.

Great work! Very usefull stuff.

Good move

That's excellent news, good work guys If I find some spare time I'll register and contribute, will be great to see this fleshing out, especially for slightly more advanced topics like using the shell and modifying user-startup scripts and so on...

@salass00

Quote:

Why not use the already existing 'JUNK' chunk for this purpose instead of defining another one?

Why not use the already existing 'NULL' chunk for this purpose instead of defining another one?

From iffparse.h:
Quote:

/* Universal IFF identifiers */ #define ID_FORM MAKE_ID('F','O','R','M') #define ID_LIST MAKE_ID('L','I','S','T') #define ID_CAT MAKE_ID('C','A','T',' ') #define ID_PROP MAKE_ID('P','R','O','P') #define ID_NULL MAKE_ID(' ',' ',' ',' ')

NULL is already defined, so...

OldFart

@OldFart

Quote:

I have been thinking of extending the arithmetical aspect of IFF to even 64 bit unsigned. This could be achieved by prefixing any chunk that exceeds the 2^32 limit by a special disignator like 'E','X','T','-', in which case the chunksize is represented as 64 bit.

Or instead of IFF FORM, use 'FOR1' which is a reserved name intended for exactly this sort of incompatible update. Then you extend the remaining namespace to 64-bits with 64-bit size fields. It doesn't matter that it's incompatible with existing IFF readers because they wouldn't be able to read it anyway without being updated. (your EXT- idea doesn't make it compatible with old readers as they will still be skipping past the chunk using whatever 32-bit value is after the EXT-.)

With appropriate updating of iffparse.library to support 64-bit FOR1 existing software might be able to read FOR1 files as long as they don't exceed the 2/4GB size limit (extending the namespace to 64-bit might scupper this though, old 32-bit chunks would need to have NULLs in the second 32-bits or something so readers recognise old chunk names). New read/write functions supporting 64-bit sizes would of course need to be added for new software (and used by datatypes.library and anywhere else in the OS that deals with IFF)