Currently, the Winter Wonderland DLC does NOT work on Mac or Linux. This is a known issue.
If you would like an excruciatingly detailed explanation of the issue, keep on readin'. Otherwise, this may bore/torture you, so you can stop reading here. The main point: it was a Mono dependency issue, and we apologize for the inconvenience.
Anyway, here's what's up:
The issue is caused by a .NET/Mono dependency within XNA, and as a result, the original AVNT game. Rather than loading the texture data via the XNA content pipeline (.xnb files), the DLC is loaded directly as PNG and JPEG files, using the Texture2D.FromStream() call:http://msdn.microsoft.com/en-us/library/ff434103.aspx
This seems harmless at first, but the problem is this method's dependency on the "System.Drawing.Imaging" .NET library in MonoGame:https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Graphics/Texture2D.cs#L869
The above block of code is MonoGame's "generic" method of loading texture data from a stream.
This library depends on a native library called libgdiplus, which sounds like it'd just be a matter of adding this one library, but then you look at the dependency list...
This is the unedited `ldd` output of Fedora 17's libgdiplus library:
[flibitijibibo@flibitTower ~]$ ldd /usr/lib64/libgdiplus.so.0
linux-vdso.so.1 => (0x00007fffd7bfe000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2542125000)
libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f2541e79000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2541bd8000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f25419ce000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f2541693000)
libtiff.so.3 => /lib64/libtiff.so.3 (0x00007f254142f000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f25411df000)
libgif.so.4 => /lib64/libgif.so.4 (0x00007f2540fd4000)
libpng12.so.0 => /lib64/libpng12.so.0 (0x00007f2540dad000)
libexif.so.12 => /lib64/libexif.so.12 (0x00007f2540b67000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f254094a000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2540715000)
libc.so.6 => /lib64/libc.so.6 (0x00007f254035e000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2540155000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f253febd000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f253fc93000)
libz.so.1 => /lib64/libz.so.1 (0x00007f253fa7b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f253f780000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f253f562000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f253f35d000)
libSM.so.6 => /lib64/libSM.so.6 (0x00007f253f155000)
libICE.so.6 => /lib64/libICE.so.6 (0x00007f253ef39000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f253ed0f000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f253eb0b000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f253e905000)
You'll notice such gems as Cairo, FreeType, TIFF, both libpng 1.2 and 1.5, pixman, and glib.
All of this, just for a couple of PNG/JPEG files. I'm not kidding.
Well, actually, if you self-build libgdiplus, you can actually shrink this list down a little bit (for instance, you can require only _one_ version of libpng!), and I've actually done this before in the Linux version of Proteus, with an admittedly decent level of success:http://store.steampowered.com/app/219680/
However, even if we were to grab _all_ of these libraries for Linux, we still need to account for OSX, and getting this set up on OSX is nothing short of pure, unadulterated agony. I don't want to know what Jon had to do to make Proteus OSX happy.
So, uh, I sort of just disabled the DLC for the 1.0 ports. Christmas is in a few months anyway, right...?
I wanted to try and open it to where you could at least _attempt_ to load it if you had this library somehow, but it turned out to be _very_ error-prone and crashy, so the "DLC load error" is pretty much built-in at the moment.
"So what's the solution," I hear you ask. My current idea is to load the images ourselves using SDL2# and SDL2_image; SDL2_image would only add 3 library files (SDL2_image, libpng, libjpeg), and we already use SDL2# for MonoGame. I would like to implement this in the MonoGame library, as this is a pretty nasty issue for what could be a very large amount of XNA games out there. Instead of passing a stream, we would create a new method, `Texture2D.FromFile(string)`, where we pass in a file name and then let MonoGame do the rest. It looks simple on paper, but it could take a lot of time to get the data marshaling working on multiple architectures... this is actually why Proteus for Linux is only available in 32-bit!
That's partially why I wrote this whole mess, to be honest. If you managed to get through this without your eyes running for the escape pods, and you're really interested in fixing this issue yourself, I'd love to see someone implement this! I will definitely be busy working on general support issues (both for this game and FEZ), so if you're _really_ eager to see this DLC working, feel free to make a patch for MonoGame-SDL2, and I'll try update AVNT's MG-SDL2 library! That's not to say that I'm just abandoning this bug, but I will definitely admit that this is currently a low-priority issue for the Humble launch.
I've even hooked AVNT up to the FromFile method already, which you can find here:https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Graphics/Texture2D.cs#L893
You can implement this method, and the library you compile should be compatible with AVNT. Errors are printed to stdout.
If someone else ends up patching this, I'd be happy to credit you in some form on future releases, and I'm sure the team at Misfits Attic would be just as appreciative of your work.