none
Xpress (plain) compression discrepency RRS feed

  • Question

  • Hi there,

    I'm writing an xpress algorithm compressor based on the documentation provided at the following location in the open specifications section of MSDN:

    http://msdn.microsoft.com/en-us/library/hh554053.aspx

    My existing de-compressor is able to decompress Microsoft generated data and data that I've personally generated using my compressor.  However, my compressor creates output that is difference from the Microsoft xpress algorithm output.

    I've narrowed the issue down to the Microsoft implementation locating a smaller match in the sliding match window, where as my implementation always finds the longest match possible.

    I'm wondering if this is a performance trade-off or just a bug.  The specification seems to suggest it might be a bug as it suggests that the best match is supposed to be found.

    Does anyone possibly know why the Microsoft implementation doesn't always find the longest match and if so, how does it do it differently?

    I've found a reference to what is likely the exact same issue i'm experiencing at this location on nabble, but the thread is long dead and no details were ever posted with respect to a possible solution:

    http://samba.2283325.n4.nabble.com/LZ77-DIRECT2-compression-MS-OXCRPC-td2516367.html

    Any info would be greatly appreciated.

    Thanks,

    Vince

    Wednesday, March 6, 2013 9:17 PM

Answers

  • Vince,

    As we discussed offline, this issue is not related to MS-XCA but ratter MS-OXCRPC. As you clarified to us, Outlook was not showing the attachment when you transmitted the compressed data to an Exchange server.  

    We are working with you to investigate the missing piece so that your protocol implementation can have the attachment working. Then my colleague who is helping you on this issue can determine whether MS-OXCRPC needs any clarification or not.

    Your implementation needs to follow MS-OXCRPC. MS-OXCRPC should provide sufficient detail to implement compatible LZ77 compression/decompression to interoperate with Exchange Server or Outlook.

    Specific methodology used to determine the longest match are implementation details. Various implementations of LZ77 produce compatible but differing outputs upon compression.

    The fact that your existing de-compressor is able to decompress Microsoft generated data and the data that you have personally generated using your compressor implementation suggests that you have a successful implementation.

    Thanks,

    Edgar

    Monday, March 18, 2013 7:22 PM
    Moderator

All replies

  • Hi Vince,

    Thank you for your question regarding [MS-XCA].  One of the Open Specifications team members will respond here shortly to begin working with you.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Wednesday, March 6, 2013 9:37 PM
    Moderator
  • Vince,

    Can you contact dochelp at microsoft dot com. Please mention this thread.

    I will post a summary of resolution on the forum once we conclude our investigation.

    Thanks,

    Edgar

    Wednesday, March 6, 2013 10:07 PM
    Moderator
  • Hi Edgar,

    Will do.  Thank you

    Vince

    Thursday, March 7, 2013 3:30 PM
  • Vince,

    As we discussed offline, this issue is not related to MS-XCA but ratter MS-OXCRPC. As you clarified to us, Outlook was not showing the attachment when you transmitted the compressed data to an Exchange server.  

    We are working with you to investigate the missing piece so that your protocol implementation can have the attachment working. Then my colleague who is helping you on this issue can determine whether MS-OXCRPC needs any clarification or not.

    Your implementation needs to follow MS-OXCRPC. MS-OXCRPC should provide sufficient detail to implement compatible LZ77 compression/decompression to interoperate with Exchange Server or Outlook.

    Specific methodology used to determine the longest match are implementation details. Various implementations of LZ77 produce compatible but differing outputs upon compression.

    The fact that your existing de-compressor is able to decompress Microsoft generated data and the data that you have personally generated using your compressor implementation suggests that you have a successful implementation.

    Thanks,

    Edgar

    Monday, March 18, 2013 7:22 PM
    Moderator