[Bug 52250] New: windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Bug ID: 52250
           Summary: windows.h WINE_NOWINSOCK check has been removed
           Product: Wine
           Version: 6.8
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winelib
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

I'm using winelib to compile a Windows/Linux application, where we want to use
the Linux code for threads, files system handling, network code, shared
memory... and we want WINE just for the Win32 GUI code (as we did not implement
a GUI in the Linux/Unix side just on Windows)

Since WINE 6.8 (due this commit
https://source.winehq.org/git/wine.git/commit/9603fba8943f9699e3af6fcfe4acbe...)
the WINE_NOWINSOCK check:

#ifndef WINE_NOWINSOCK
#include <winsock.h>
#endif /* WINE_NOWINSOCK */

Has been removed, now my application does not compile as I'm mixing Linux
socket definitions with the WINE/Windows "winsock.h" file.

If I add this check to the file, the application does compile as with WINE 6.7

Is it possible to add the check back? or should this be done in another way
now?

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Marcos Gutiérrez Batz  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Marcos Gutiérrez Batz  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #1 from Alexandre Julliard  ---
You could try defining _WINSOCKAPI_ instead.

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #2 from Marcos Gutiérrez Batz  ---
(In reply to Alexandre Julliard from comment #1)
> You could try defining _WINSOCKAPI_ instead.

Thanks Alexandre, good idea it makes sense, but it has two problems:

1) Defining WINE_NOWINSOCK is "selfdocumenting" while the _WINSOCKAPI_ is not
so obvious (this can easily be solved with a proper comment, though)

2) There are other libraries that check if this value is defined, in our case
we use libcurl and now we have other errors like:

/sc/pub/curl_v7.51.0/include/curl/multi.h:155:40: error:
‘Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library’ has not been
declared

I guess this second problem can be solved undef'ing the _WINSOCKAPI_, but it
makes the solution quite complex to maintain.

While this small check doesn't have this issues and is neat.

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #3 from Marcos Gutiérrez Batz  ---
Looking further, the second error was not libcurl checking the definition
(sorry!). It's due to the first part of the winsock.h, the one in the
__WINE_WINSOCKAPI_STDLIB_H "section".

So the solution can be:

#define _WINSOCKAPI_
#define __WINE_WINSOCKAPI_STDLIB_H

Maybe the #ifdef __WINE_WINSOCKAPI_STDLIB_H "section" could be moved inside the
_WINSOCKAPI_ one, so to just have the first define...

Anyway, with this two defines is working, but I think the previous solution was
neater (not so "hacky").

So I leave the bug open for you to close if you think it is not worth the
effort.

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #4 from Alexandre Julliard  ---
Created attachment 71389
  --> https://bugs.winehq.org/attachment.cgi?id=71389
Use WS prefix on Unix

How about something like that instead? Does it work for your setup?

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Zebediah Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from Zebediah Figura  ---
(In reply to Alexandre Julliard from comment #4)
> Created attachment 71389 [details]
> Use WS prefix on Unix
>
> How about something like that instead? Does it work for your setup?

That seems dangerous; surely there are winelib applications out there that are
trying to use ws2_32 instead?

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #6 from Alexandre Julliard  ---
(In reply to Zebediah Figura from comment #5)
> (In reply to Alexandre Julliard from comment #4)
> > Created attachment 71389 [details]
> > Use WS prefix on Unix
> >
> > How about something like that instead? Does it work for your setup?
>
> That seems dangerous; surely there are winelib applications out there that
> are trying to use ws2_32 instead?

Are there? And do they actually work?

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #7 from Zebediah Figura  ---
(In reply to Alexandre Julliard from comment #6)
> (In reply to Zebediah Figura from comment #5)
> > (In reply to Alexandre Julliard from comment #4)
> > > Created attachment 71389 [details]
> > > Use WS prefix on Unix
> > >
> > > How about something like that instead? Does it work for your setup?
> >
> > That seems dangerous; surely there are winelib applications out there that
> > are trying to use ws2_32 instead?
>
> Are there? And do they actually work?

Of course I don't know of any winelib applications (at all, really), but a
simple program like

#include <winsock2.h>

int main(int argc, char **argv)
{
    socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
}

compiled with winegcc, and explicitly linked to ws2_32 (assuming I've done it
right) seems to work, and link to ws2_32 rather than glibc.

(I'm also a little confused, because last time I tried proposing that we remove
the ability to use host headers together with winsock.h and without
USE_WS_PREFIX, you seem to have been of the opinion that we should preserve
that for winegcc [1].)

[1] https://www.winehq.org/pipermail/wine-devel/2021-April/185656.html

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #8 from Alexandre Julliard  ---
Sure, my patch is too drastic since it's disabling everything, that was mostly
for testing.

I do think we want to preserve the ability to use winsock functions, but maybe
that's the case that should require a #define, since it would need careful
coding anyway. Another approach would be to disable only the problematic
functions like select().

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

Zebediah Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
    Regression SHA1|                            |9603fba8943f9699e3af6fcfe4a
                   |                            |cbed09bcb48d9

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #9 from Zebediah Figura  ---
Actually it occurs to me that the WS_ prefix is completely broken now, since
ws2_32.dll itself doesn't use it. I.e. you can use WS_* definitions, but you
can't link to WS_* functions.

It is a bit out of scope of this bug report (which isn't trying to use windows
sockets at all), but I guess I can't figure out how to answer the original
question without knowing what exactly we want to preserve in terms of backwards
compatibility. E.g. should we preserve the ability to use the WS prefix? should
we preserve the ability to link to either Win32 or Unix sockets simply
depending on whether -lws2_32 is specified?

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #10 from Alexandre Julliard  ---
Linking to WS_* functions is not supported, the WS_ prefix is only for when you
need the definitions (e.g. to map them to the Unix ones and call the Unix
functions). The function prototypes could probably be simply disabled when
using WS_.

I'd say the goals are, in priority order:

1. Properly support winsock.h and ws2_32 in MSVCRT mode.

2. Allow using winsock.h with WS_ prefix in Wine's Unix libs to get the winsock
definitions.

3. Not get in the way for Winelib apps that don't need sockets, or that will
simply use Unix sockets.

4. Allow using winsock.h and ws2_32 in Winelib apps if building them against
Unix sockets is hard for some reason. It's OK if you have to jump through some
hoops to enable that case.

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

--- Comment #11 from Zebediah Figura  ---
Okay, I guess that makes sense. I'll try to prepare some patches.

[Bug 52250] windows.h WINE_NOWINSOCK check has been removed

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52250

franziska  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]