none
[MS-MCI / MS-OXOAB] Problems decompressing OAB v2 files RRS feed

  • Question

  • Hi,

    I'm having trouble with decompressing the OAB version 2 files downloaded from my test server.

    Here is a simple example, "browse2.oab"
    [bradh@conferta ~]$ od -t x1 browse2.oab
    0000000 02 00 00 00 01 00 00 00 00 80 00 00 6c 00 00 00
    0000020 01 00 00 00 46 00 00 00 6c 00 00 00 43 4b e3 62
    0000040 60 60 98 de f2 2f 8c 19 48 1f 00 62 1e 20 ee 65
    0000060 60 60 2b 03 d2 19 40 ac c1 80 00 cf 80 78 26 10
    0000100 27 33 30 72 84 02 e9 c3 50 f5 30 c0 c6 c8 c0 f0
    0000120 07 48 e7 01 99 73 81 74 17 10 7b 41 e5 56 02 d5
    0000140 01 00
    0000142

    It looks OK for the initial headers. We start off with the MDI_HDR structure (32 bytes) per MS-OXOAB Section 2.8.1 with ulTargetSize of 0x6c. We then get MDI_BLK per MS-OXOAB Section 2.8.2 with ulFlags of 0x00000001 (i.e. this is a compressed block requiring MCI decompression), ulCompSize of 0x00000046, ulUncompSize of 0x00000063, and then the Data block starting with 0x43 0x4b 0xe3 0x62.

    Referring to MS-MCI Section 2, we see that the first two bytes (0x43 and 0x4B) match the expected MSZIP header. 
    For the the next byte (0xe3 or binary 1110 0011), MS-MCI refers out to RFC1951, since this the start of the RFC1951 deflate block

    Referring to RFC1951, we get this:
    3.2.3. Details of block format
    
             Each block of compressed data begins with 3 header bits
             containing the following data:
    
                first bit       BFINAL
                next 2 bits     BTYPE
    .
    ...
    
             BFINAL is set if and only if this is the last block of the data
             set.
    
             BTYPE specifies how the data are compressed, as follows:
    
                00 - no compression
                01 - compressed with fixed Huffman codes
                10 - compressed with dynamic Huffman codes
                11 - reserved (error)
    
    So for our example (0xe3 or binary 1110 0011), BFINAL is set (as expected, the example file only has one block starting with 0x43 0x4b, and ulCompSize matches the remaining number of bytes in the file) and BYTPE is set to 11. RFC1951 says that is a reserved (error) value.

    {For what it is worth, I've tried feeding the compressed data block to zlib using a range of combinations, and it objects to all of them so far, although I've previously used similar code to decompress MSZIP compressed document in the .CAB format}

    So I'm a bit stuck now. Could be a problem in my understanding of the documentation, could be a bug in the documentaiton, could be the file format isn't consistent with the documentation.

    Any suggestions?

    Brad


    Saturday, April 25, 2009 12:27 AM

Answers

  • Brad,                                                                                                                               

    You have the following bit order: 1110 0011.

    BFINAL is the following bit: 1110 0011

    BTYPE is the following bits: 1110 0011 (indicating compressed with fixed Huffman codes)

    The remaining bits: 1110 0011 belong to the block body.

    Does this information assist you?

    Dominic Salemno
    Senior Support Escalation Engineer

    Friday, May 22, 2009 1:55 PM

All replies

  • Brad,

    We have received your request. Someone from our team will be investigating this issue and subsequently be following-up with you.

    Dominic Salemno
    Senior Support Escalation Engineer

    Saturday, April 25, 2009 1:07 PM
  • Brad,

    I am the engineer who has taken ownership of this issue. I am investigating this and will update you as things progress.

    Dominic Salemno
    Senior Support Escalation Engineer
    Tuesday, April 28, 2009 4:53 PM
  • Dominic,

    Look forward to working with you on it. Let me know if you need anything more, or have any suggestions you'd like me to explore.

    Brad
    Tuesday, April 28, 2009 9:03 PM
  • Brad,

    If possible, could you send a sample file to dochelp@microsoft.com containing this series of bits?

    Dominic Salemno
    Senior Support Escalation Engineer
    Thursday, April 30, 2009 4:19 PM
  • Dominic,

    Just set. Let me know if you have any issue with it.

    Brad
    Friday, May 1, 2009 9:40 AM
  • Brad,

    I am still investigating this issue and will follow-up with you shortly in regards to your question.

    Dominic Salemno
    Senior Support Escalation Engineer

    Monday, May 18, 2009 1:09 PM
  • Dominic,

    Thanks. I'm looking forward to a resolution on this one.

    Brad
    Monday, May 18, 2009 8:35 PM
  • Brad,                                                                                                                               

    You have the following bit order: 1110 0011.

    BFINAL is the following bit: 1110 0011

    BTYPE is the following bits: 1110 0011 (indicating compressed with fixed Huffman codes)

    The remaining bits: 1110 0011 belong to the block body.

    Does this information assist you?

    Dominic Salemno
    Senior Support Escalation Engineer

    Friday, May 22, 2009 1:55 PM