Dependencia de la máquina GZipStream

Me estoy topando con algún extraño comportamiento GZipStream dependiente de la máquina / SO en .NET 4.0. Este es el código relevante:

public static string Compress(string input) { using(var ms = new MemoryStream(Encoding.UTF8.GetBytes(input))) using(var os = new MemoryStream()) { using(var gz = new GZipStream(os,CompressionMode.Compress,true)) { ms.CopyTo(gz); } return string.Join("",os.ToArray().Select(b=>b.ToString("X2"))); } } 

Running Compress (“freek”) me da

 1F8B08000000000004004B2B4A4DCD06001E33909D05000000 

en Windows 7 y

 1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF040000FFFF1E33909D05000000 

en Windows Server 2008R2. Ambos son de 64 bits. Espero que los resultados sean los mismos.

Ambas máquinas dan el resultado correcto cuando descomprimo cualquiera de los resultados. Ya descubrí que en W7 ms.Length == 25 mientras que en W2K8R2 ms.Length == 128, pero no tengo idea de por qué.

¿Que esta pasando?

Se anunció que .NET 4.5 Beta incluye mejoras de compresión zip para reducir el tamaño :

Comenzando con .NET Framework 4.5 RC, la clase DeflateStream usa la biblioteca zlib para la compresión. Como resultado, proporciona un mejor algoritmo de compresión y, en la mayoría de los casos, un archivo comprimido más pequeño que el que proporciona en versiones anteriores de .NET Framework.

¿Quizás tiene instalado .Net 4.5+ en la máquina Win7?

Parece que hay un cambio en el algoritmo utilizado por DeflateStream en .NET 4.5 :

Comenzando con .NET Framework 4.5 Beta, la clase DeflateStream usa la biblioteca zlib para la compresión. Como resultado, proporciona un mejor algoritmo de compresión y, en la mayoría de los casos, un archivo comprimido más pequeño que el que proporciona en versiones anteriores de .NET Framework.

Desde que tenía instalado 4.5, esto estaba causando el problema.

A diferencia de la respuesta de Abel , obtengo el resultado de

 1F8B08000000000004004B2B4A4DCD06001E33909D05000000 

en mi Windows 7 x64 Ultimate SP1. ¿Quizás hay una actualización de .NET Framework que no tienes en una de las cajas? La versión de mi mscorlib.dll es 4.0.30319.17379.

ETA: Si vuelvo a redirigir a .NET 2 (y cambio las construcciones específicas de .NET 4 a sus equivalentes de .NET 2), obtengo el resultado de

 1F8B0800000000000400EDBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22CEEB3C7FFBFF001E33909D05000000 

en la misma máquina / sistema operativo.

Ejecuté su código en mi máquina con Windows 7 de 64 bits y obtuve lo siguiente, que es igual a su Win2k8SP2:

 1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F229ED579FEF6FF090000FFFF1A1C515C05000000 

Esencialmente, creo que el resultado tiene que ver con la longitud de palabra de la máquina. Es decir, ¿su máquina Windows-7 es quizás de 32 bits?

NOTA: Escribí un poco de descompresión para sus cuerdas y tengo que decir que realmente se descomprimen bien. Ejecuté mi versión en 32 y 64 bits y el resultado fue igual. Sólo queda la posible diferencia: ¿diferentes tiempos de ejecución?

EDITAR:

diferentes tiempos de ejecución?

Aparentemente, como Henk Holterman sugirió a continuación y Robert Levy formalizó en su respuesta , este fue ciertamente el caso no obvio aquí.

Sospecho que uno de los sistemas operativos es de 32 bits y el otro es de 64 bits.