I get a socket fd = accept (), I try (a program from Unix) to do fdopen (). It falls (after a minute of thought, it already seems natural (since fd == 316)).

Question: fdopen () on the socket in Windows - is it possible ???

UPD 1

It is not yet possible, but the function _open_osfhandle () found in http://msdn.microsoft.com/ () inspires hope ...

  • If it doesn't work at all, write to the buffer with sprintf, and then write (or whatever else in Windows) to the socket. Or vice versa - read the buffer, then disassemble sscanf. - skegg
  • Yes, I'll twist it in the evening, it will not work, a piece of stdio will have to be sent to send () / recv (). - avp
  • And why do you even need it? After all, there is already a socket, where do you get another handle for it? In fact, the difference is not what is there to read from the socket, that sort of thing. - cy6erGn0m
  • Ideally (as in unix) I want fgets (), fprintf (), etc. If it fails, then "hide" buffering. Now I’m almost sure that the first will not work directly (with a socket (or the descriptor received from it (_open_osfhandle ())) in Windows it seems read () / write () will not work). - avp

1 answer 1

It turned out, (b ...) yes fdopen (_open_osfhandle (fd, _O_ACCMODE | _O_APPEND), ...) earned.

(for sure Billy will throw some more tricks)

#ifdef WIN32 #define socket(x,y,z) WSASocket (x,y,z,NULL,0,0) #endif

Now the most interesting question to the community Why is this so ???

Those. why in libraries MS there are socket () and WSASocket (), which behave differently ???

  • one
    That's why I prefer to write under the tench. - skegg
  • So do I. Windu, as usual, keeps the customer in mind. You have to go along and figure out for yourself what is easily transferred and what is not. - avp