Removing Windows and Solaris from the Downloads page

[Juan Lang]

Hi Steven,

> The problem is not in the makefiles, a lot of the problem is that we
> are not clear on which dlls would be of use for testing in windows. I
> had to go through hoops to get wininet buildable on Windows because it
> uses unix sockets on Wine rather than winsock. There was quite a
> performance issue when running under Wine with winsock that did not
> show up when using Unix sockets and I felt, and still do that hacking
> around the problem rather than finding where the bottleneck was, is
> not the right answer.

The problem with using winsock rather than UNIX sockets is in the I/O
between a client process and the wineserver.  The extra overhead it
imposes is really unavoidable, AFAICT.  We're doing a context switch
to a separate process that a UNIX socket call (or a winsock call on
Windows) does not require.  While we could speed up such I/O in
certain cases with hacks like the shared memory wineserver, or with a
wineserver kernel module, doing so is very error prone, and we'd lose
a lot of time chasing down errors that's better spent improving our
implementation of Windows dlls.  It may not be the "right" thing to do
in a purely abstract sense, but it's clearly the right thing given our
resources and our priorities.  If wineserver performance is ever the
thing preventing a large number of apps from working correctly, we
might invest more time in it.  Switching wininet to winsock might make
sense then, but not before.

> Mingw/MSVC and friends will always be second class citzen to Wine on Unix.

It's true, for several reasons:
1. We don't use MSVC to develop Wine (nor should we) so we don't catch
errors there as quickly.
2. MinGW's headers aren't in synch with ours, so building with it is
for the very patient.  I'm happy someone does it, but we can't all do
it without losing a lot of time.
3. We don't use MinGW in compile Wine, nor, again, should we.

--Juan