[Bug 52250] New: windows.h WINE_NOWINSOCK check has been removed
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: wine-bugs(a)winehq.org Reporter: sacrom(a)gmail.com 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 Marcos Gutiérrez Batz <sacrom(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sacrom(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 Marcos Gutiérrez Batz <sacrom(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #1 from Alexandre Julliard <julliard(a)winehq.org> --- You could try defining _WINSOCKAPI_ instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #2 from Marcos Gutiérrez Batz <sacrom(a)gmail.com> --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #3 from Marcos Gutiérrez Batz <sacrom(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zebediah Figura <z.figura12(a)gmail.com> --- (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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- (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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #7 from Zebediah Figura <z.figura12(a)gmail.com> --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- 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(). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |9603fba8943f9699e3af6fcfe4a | |cbed09bcb48d9 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #9 from Zebediah Figura <z.figura12(a)gmail.com> --- 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #11 from Zebediah Figura <z.figura12(a)gmail.com> --- Okay, I guess that makes sense. I'll try to prepare some patches. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52250 franziska <fscheefuss(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fscheefuss(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52250 Ali <Alimahi0627(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Alimahi0627(a)gmail.com --- Comment #12 from Ali <Alimahi0627(a)gmail.com> --- Unlocked my account Remove the all of the following -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52250 --- Comment #13 from Ali <Alimahi0627(a)gmail.com> --- Unlocked my account Remove the all of the following -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla