locked
App-V File Format Document: Directory Map Reserved2 RRS feed

  • General discussion

  • Page 18 describes this item as reserved and should be all zeros.

    In practice this 8 bytes may contain data (unrecognizable to me so far).
    Thursday, March 19, 2009 1:09 PM
    Moderator

All replies

  • Hi Tim

    Can you please add the URL to the doc you're referring to so we can evaluate for an update if necessary?

    Thanks,
    Dan Bernhardt [MSFT]
    Monday, March 23, 2009 2:47 PM
    Answerer
  • The URL is too long and ugly to type in.

    Download the Application Virtualization File Format Specification


    I will have additional feedback on errors in the document shortly.
    Monday, March 23, 2009 9:05 PM
    Moderator
  • Here is additional "eratta".

    1) General Comment.  Field values should be more specific.  In particular, many quantities are specified as "32 bits".  Some of these will be 32bit unsigned and some 32-bit signed quantities.  This is especially important when dealing with offset or location values in a potential 4GB file.

    2) Pg 7 States that all currently defined header sections are mandatory but Pg 9 hints that DSFT might not be.  I believe Pg 9 is correct.


    3)  Pg13 States that only 32k and 64k block sizes are currently supported.  Pg 41 states the correct block sizes supported.

    4)   Pg 18 Compression type:  Unclear.  More likely it should read "Currently, the sft compression defined in the PROP section dictates whether this section's subsections are compressed and the compression type, so this field is not used."

    5)   CIDX new format - 3 byte reserved not zero (as mentioned in original post in this thread).

    Monday, March 23, 2009 11:34 PM
    Moderator
  • Here is additional "eratta".

    1) General Comment.  Field values should be more specific.  In particular, many quantities are specified as "32 bits".  Some of these will be 32bit unsigned and some 32-bit signed quantities.  This is especially important when dealing with offset or location values in a potential 4GB file.

    2) Pg 7 States that all currently defined header sections are mandatory but Pg 9 hints that DSFT might not be.  I believe Pg 9 is correct.


    3)  Pg13 States that only 32k and 64k block sizes are currently supported.  Pg 41 states the correct block sizes supported.

    4)   Pg 18 Compression type:  Unclear.  More likely it should read "Currently, the sft compression defined in the PROP section dictates whether this section's subsections are compressed and the compression type, so this field is not used."

    5)   CIDX new format - 3 byte reserved not zero (as mentioned in original post in this thread).


    1) If I remember correctly, none of the 32-bit values used in SFT are signed.

    2) DSFT is not mandatory as it's used only for differential-SFT files. All others pretty much are, unless you have pre-4.0 package in which case CONT is not present.

    3) Officially supported != can be used ;-)

    4) This field is used and set according the compression type used in subsections (which of course match to overall package compression type).

    5) Meaning of those 3 bytes is unknown to me as well, but I suspect that they come from some non-cleared out buffer and do not actually mean anything.

    /Kalle
    Thursday, April 9, 2009 8:06 AM
    Moderator
  • I am appreciative for the document so please don't take posts here as complaints.  However, I am hoping that with feedback the next version will be even better.

    When I read a document like this, I think along two lines.
    A. How would I code a reader (aka: what does the client look at when opening the sft)?

    B. How would I code a writer (aka: how would a third party, like a msi tool) generate an sft from this?

    Thus in areas of ambiguity where there is dulplication (see #4 above) it is good to be very clear.  In #4, for exaple, we have a compression type field in the PROP section for certain things and the compression field within other blocks for the specifics within the blocks.  The only current writer is the sequencer which keeps these in sync, but with third party writers it is possible for them to not do so unless it is prohibited in this spec.  So if the client actually reads and acts on the secondary compression settings and it is not supported that the fields be different then the text of the document should state this.

    Another example of this I recently found I will list as #6.

    6) In the CP format, virtual registry information appears more than once in different formats.  One has the entire machine and user hives, then each hive is copied (in a different format in one case) in different sections of the file.  The document should (probably) state more clearly that these copies must be kept in sync.  I am assuming in that statement that the client reads both copies for different purposes.

    These are a couple of examples, but if a new version is generated, it could use to be reviewed with an eye towards clarity in this way.  It is always harder to write the format after the code is written (and modified many many times), but hopefully as people use this document and ask these kinds of questions it can be improved.

    Sunday, April 26, 2009 3:09 PM
    Moderator