none
Breaking Change on Windows 8 for .NET development? RRS feed

  • Question

  • Guys,

    I'm not sure if I've made anything wrong but I found Windows 8 has breaking changes when I'm using some simplest features in .NET framework. One of my machine is Windows 7 X64 with Visual Studio 2010 premium, the other is Windows 8 X64 with exactly the same Visual Studio. Both of the Win7 / Win8 system are downloaded as MSDN subscriber so they are all official.  However for the following code:
      static void Main(string[] args)
            {
                byte[] dataBytes = new byte[256 * 256 * 4 + 256];
                MemoryStream resultStream = new MemoryStream();
                DeflateStream deflateStream = new DeflateStream(resultStream, CompressionMode.Compress);
                deflateStream.Write(dataBytes, 0, dataBytes.Length);
                Console.WriteLine(resultStream.Length);//2330
     
                Bitmap a = new Bitmap(256, 256);
                MemoryStream memoryStream1 = new MemoryStream();
                a.Save(memoryStream1, ImageFormat.Png);
                byte[] byteArray1 = memoryStream1.ToArray();
                Console.WriteLine(byteArray1.Length);//1275
     
                Console.Read();
            }

    it returns 2330/1275 on  Window 7 but returns 0/384 on Windows 8. the codes are identical and are both under .NET Framework 4 Client Profile. 

    So I did anything wrong or it is a breaking change on Windows 8?

    Thanks very much in advance. 

    Ben

    Monday, September 3, 2012 6:32 AM

Answers

  • Hmm, I don't see why the second case would be a breaking change. As far as I can tell the resulting image file is a valid png file, 256x256 in size. Is the size smaller? Good, it means that the png encoder got better at compressing or writes less crap to the file.

    The first is a bit more interesting. Not because the resulting size is smaller (DeflateStream got better at compressing the data) but because the result is 0. But your code is wrong to begin with, you can't get the size of a compressed stream before closing it, such a stream may very well have data left in its own compression buffer. You need to close the deflate stream and use resultStream.ToArray().Length to get the actual size of the compressed data. If you use the same method in .NET 4.0 you'll find out that the actual result is 2334, the 2330 you've got in .NET 4.0 isn't any better than the 0 you get in .NET 4.5.

    • Marked as answer by ByminBen Monday, September 3, 2012 8:09 AM
    Monday, September 3, 2012 6:55 AM
    Moderator

All replies

  • Hmm, I don't see why the second case would be a breaking change. As far as I can tell the resulting image file is a valid png file, 256x256 in size. Is the size smaller? Good, it means that the png encoder got better at compressing or writes less crap to the file.

    The first is a bit more interesting. Not because the resulting size is smaller (DeflateStream got better at compressing the data) but because the result is 0. But your code is wrong to begin with, you can't get the size of a compressed stream before closing it, such a stream may very well have data left in its own compression buffer. You need to close the deflate stream and use resultStream.ToArray().Length to get the actual size of the compressed data. If you use the same method in .NET 4.0 you'll find out that the actual result is 2334, the 2330 you've got in .NET 4.0 isn't any better than the 0 you get in .NET 4.5.

    • Marked as answer by ByminBen Monday, September 3, 2012 8:09 AM
    Monday, September 3, 2012 6:55 AM
    Moderator
  • Thanks very much Mike! I tried the following code: 

                byte[] dataBytes = new byte[256 * 256 * 4 + 256];
                MemoryStream resultStream = new MemoryStream();
                DeflateStream deflateStream = new DeflateStream(resultStream, CompressionMode.Compress);
                deflateStream.Write(dataBytes, 0, dataBytes.Length);
                deflateStream.Close();
                Console.WriteLine(resultStream.ToArray().Length);

    on Win7 it returns 2338, on Win8 it returns 271. Seems Win8 does made some optimizations on the size?

    Monday, September 3, 2012 8:34 AM
  • "Seems Win8 does made some optimizations on the size?"

    Yes, the compression code has been changed to use the well known zlib library.

    Monday, September 3, 2012 8:43 AM
    Moderator
  • By the way, I installed .NET 4.5 on Win7 and tested again, the result is 0/1275. So seems .NET 4.5 makes one optimization and Win8 makes the other. 
    Tuesday, September 4, 2012 5:59 AM
  • System.Drawing's PNG compression depends on GdiPlus which in turns depends on WIC (Windows Imaging Codecs) on Win7 and higher. WIC is a OS component and it may be updated independently of .NET.

    Before Win7 GdiPlus had its own PNG codec so if you try on WinXP/Vista you may get yet another different result.

    Tuesday, September 4, 2012 6:11 AM
    Moderator