You mean the Windows executable?
Both Windows & Linux. On Windows, a lot of people don't like dozens of DLLs in the program folder (including me), and on Linux I didn't want to fuck around with library problems. "Hey my demo didn't load" ... days and days of debugging ... "oh my libarchive wasn't build with XZ support, lolz".
EECS has dependencies that EE doesn't: GnuTLS, libcurl, libarchive, etc. There are very few Linux distributions that keep up with current versions of all those dependencies, so rather than force users to fight with their package manager or distribution, I just statically linked everything. If small binary size is really important to a user, 99% of the time they're capable enough to compile EE themselves. If not they shouldn't be fucking around with it, and I certainly don't want to deal with their problems (of all support issues, compilation/installation are just the worst). In fact, my first suggestion to someone having trouble with EECS and who wasn't using the static distribution would be to use it, and see if the problem still happens.
I also had a cross-compilation system setup on a Linux machine to build for Windows. It was easier to script this way; whenever I wanted to release a new test build I just ran a script instead of firing up the XP VM, loading Code::Blocks (or whatever), updating SVN, loading the project, opening up WinSCP, blah blah blah.
Anyway, enough OT.
1. Gorilla Audio + PortMidi seems workable if the Windows MIDI sounds are acceptable (i.e., no one deeply wants to change the synth sounds).
2. SFML seems like it has audio support, but its MIDI support seems like it's through a 3rd party library called sfmidi, which uses FluidSynth. Dunno exactly what that means, do we still have to build FluidSynth? Does FluidSynth suck?
The other thing is that someone should figure out if there are stupid problems under Mac or Linux with either Gorilla or SFML.