Removing Windows and Solaris from the Downloads page

Steven Edwards winehacker at
Sun Nov 18 20:55:20 CST 2007


On Nov 18, 2007 8:03 PM, Juan Lang <juan.lang at> wrote:
> 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.

I understand that, I'm just not being very pragmatic today.

> > 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.

The headers are not an issue because we use the Wine headers and
import libraries for the dlls. The only place there is a problem is
with wine/programs and the regression tests. They use the native
import libraries. I don't really understand Alexandre's reasoning on
this as myself and Dmitry have both sent patches in to correct this
issue and his answer has always been that we should fix mingw w32api.
Wine always tends to break when cross-compiling because of this. If we
always defaulted to using the Wine headers and Import libs there never
would be a problem in that regards.

/rant off. I understand the reasoning behind it breaking and just
needed to vent about it because sometimes going back over old
problems, presents new solutions.

Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

More information about the wine-devel mailing list