Good question. Short answer: on Linux, curl doesn't grow SO_SNDBUF itself; it leaves the send buffer to the kernel's autotuning. It's on Windows that libcurl actively grows it: because Windows doesn't autotune the send buffer the same way, libcurl periodically queries the ideal send backlog (SIO_IDEAL_SEND_BACKLOG_QUERY) and sets SO_SNDBUF from that. (That came out of curl's "Upload speed in Windows may be diminished", issue #2224.) But I don't think buffer size is the actual variable here; the stall is about writability reporting, and it reproduces independently of SNDBUF tuning. That's what the conformance test isolates: pure ws2_32 sockets, no curl, default buffers, just the invariant "select() reports writable iff send() would still accept data." Windows holds that invariant; unmodified Wine breaks it once the send queue passes ~2/3 of SO_SNDBUF (the Linux POLLOUT threshold), reporting not-writable while sends keep succeeding. Growing SNDBUF only moves that boundary to a larger absolute size; it doesn't close the gap. As for why native Linux curl never hits it: its multi loop waits with poll(), which is level-triggered, so it's woken the moment the socket is writable again, the Linux threshold just means it wakes slightly later, not that it stalls. The path that stalls is the Windows backend, which waits on WSAEventSelect/FD_WRITE (edge-triggered) behind a select() writability pre-check (curl #6146). Under Wine, that pre-check returns the wrong answer, so curl falls through to a full ~1s WSAWaitForMultipleEvents per burst. Making Wine's select() match Windows is what lets curl's existing pre-check work as designed. (Happy to also check whether Wine even implements SIO_IDEAL_SEND_BACKLOG_QUERY. If it doesn't, curl can't grow the buffer under Wine at all, but that'd be an orthogonal gap; the reporting fix stands either way, per the test.) Martyn