Re: fdopen() and winsock

Re: fdopen() and winsock

[Bob Crispen]

Mumit Khan <khan@xraylith.wisc.EDU> sez:

> JRSON@NetZero.Net (John R Hanson) writes:
> > Actually They are regular file handles, just like any other.
> > There is a bug in all 9x/kernel32 libc/msv/crtdll interface
> > implementations GetFileType() returns TYPE_UNKNOWN for handles to
> > sockets. Since this is AFAIK the only unknown type there is, you know you hav
> > e
> > a socket handle;-)
> 
> Thanks for the clarification. My MSDN CD does document this and I guess
> that makes it a "feature" rather than a bug ;-)
> 
> I may consider adding a GetFileType interface in mingw runtime (under
> a "bug fix" library that you have to explicitly link to).
> 
> > there is a fix in the more recent perl distrib's
> > that you can use as a general solution.
> > -loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
> > for socket handles. that are put into an fd with _open_osfhandle()
> > also fixes several other nasty bugs in the MS libcXXX.
> 
> I see references to PerlCRT DLL, but can't find the source nor any
> mention of what license it's disributed under. Anyone with more info
> on it?  If it's not free (in either the GNU/gratis or BSD-style free
> software sense), then, as far as I'm concerned, it's irrelevant.

I have a slightly different take on it.  For use at home or
for distribution to folks who are known to have a given system,
the version I compiled that uses the Cygwin DLL is perfectly
fine.  But if I want to distribute the software to the general
public, I don't think I do them any favors by requiring *any*
DLL that they won't automatically find on their systems, be
it MFC, Cygwin, or one from a perl distribution.

Of course, my goal for this particular project has been to
replace the bloated, slow, buggy, and fragile Newsrover with
something lightweight and bulletproof.

I'm making some progress by using winsock the way it's documented
(though only a mother could love the code that I had to write
that does the equivalent of fscanf() and getc()) and I expect
to continue on that way, with occasional curses in the direction
of the Microsoft people who felt they had to "improve" BSD
sockets.

Bob Crispen
crispen at hiwaay dot net

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Bob Crispen]

Mumit Khan <khan@xraylith.wisc.EDU> sez:

> JRSON@NetZero.Net (John R Hanson) writes:
> > Actually They are regular file handles, just like any other.
> > There is a bug in all 9x/kernel32 libc/msv/crtdll interface
> > implementations GetFileType() returns TYPE_UNKNOWN for handles to
> > sockets. Since this is AFAIK the only unknown type there is, you know you hav
> > e
> > a socket handle;-)
> 
> Thanks for the clarification. My MSDN CD does document this and I guess
> that makes it a "feature" rather than a bug ;-)
> 
> I may consider adding a GetFileType interface in mingw runtime (under
> a "bug fix" library that you have to explicitly link to).
> 
> > there is a fix in the more recent perl distrib's
> > that you can use as a general solution.
> > -loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
> > for socket handles. that are put into an fd with _open_osfhandle()
> > also fixes several other nasty bugs in the MS libcXXX.
> 
> I see references to PerlCRT DLL, but can't find the source nor any
> mention of what license it's disributed under. Anyone with more info
> on it?  If it's not free (in either the GNU/gratis or BSD-style free
> software sense), then, as far as I'm concerned, it's irrelevant.

I have a slightly different take on it.  For use at home or
for distribution to folks who are known to have a given system,
the version I compiled that uses the Cygwin DLL is perfectly
fine.  But if I want to distribute the software to the general
public, I don't think I do them any favors by requiring *any*
DLL that they won't automatically find on their systems, be
it MFC, Cygwin, or one from a perl distribution.

Of course, my goal for this particular project has been to
replace the bloated, slow, buggy, and fragile Newsrover with
something lightweight and bulletproof.

I'm making some progress by using winsock the way it's documented
(though only a mother could love the code that I had to write
that does the equivalent of fscanf() and getc()) and I expect
to continue on that way, with occasional curses in the direction
of the Microsoft people who felt they had to "improve" BSD
sockets.

Bob Crispen
crispen at hiwaay dot net

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Emanuele Aliberti]

>Ah, as far as I know, one of the big limitations of winsock is that
>the SOCKET type is *not* equivalent to file descriptor unlike that
>using BSD or POSIX sockets. That's one of the major reasons for using
>a separate data type, SOCKET, as opposed to int, typical type of a
>file descriptor. This implies that you cannot mix SOCKETs and stdio,
>sorry. This is the case when you use -mno-cygwin.

socket handles are NOT file handles only under win9x. Under WNT they ARE 
file handles.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Mumit Khan]

Bob Crispen <crispen@hiwaay.net> writes:
> This has come up several times in the archives, but the only
> reply I've seen so far is "you can't do that" so I thought
> I'd try again, just in case.
> 
> When I compile with Cygwin 2.95 and don't set the -mno-cygwin
> flag, then the following works just fine:
> 
>     /*
>     * Convert the socket to a stream
>     */
>     if (0 > (sf = fdopen(s, "r+"))) {
> 	fprintf(stderr, "fdopen failed: %s\n", strerror(errno));
> 	close(s);
> 	exit (EXIT_FAILURE);
>     }
> 

Ah, as far as I know, one of the big limitations of winsock is that
the SOCKET type is *not* equivalent to file descriptor unlike that
using BSD or POSIX sockets. That's one of the major reasons for using
a separate data type, SOCKET, as opposed to int, typical type of a 
file descriptor. This implies that you cannot mix SOCKETs and stdio,
sorry. This is the case when you use -mno-cygwin.

Cygwin of course implements POSIX sockets and there is no problem
there. Case without -mno-cygwin.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

fdopen() and winsock

[Bob Crispen]

This has come up several times in the archives, but the only
reply I've seen so far is "you can't do that" so I thought
I'd try again, just in case.

When I compile with Cygwin 2.95 and don't set the -mno-cygwin
flag, then the following works just fine:

    /*
    * Convert the socket to a stream
    */
    if (0 > (sf = fdopen(s, "r+"))) {
	fprintf(stderr, "fdopen failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

    /*
    * Get news server acknowledgement of logon
    */
    bzero(reply, sizeof(reply));
    if (2 > (fscanf(sf, "%d %[^\r\n]", &status, reply))) {
	fprintf(stderr, "Logon ack read failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

[I defined bzero as a macro.  I just got lazy and didn't want
to change it everywhere in the code.]

When I compile with -mno-cygwin and use winsock.h and -lwsock32,
(and use WSAStartup to start up winsock) then the fscanf fails
with a "bad file descriptor" error, even though the file descriptor
inside the FILE is in fact the same value as the socket.  The only
thing that works is

    bzero(reply, sizeof(reply));
    bzero(sockbuf, sizeof(sockbuf));
    if (recv(s, sockbuf, sizeof(sockbuf), 0) < 0) {
	fprintf(stderr, "Logon ack read failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }
    if (2 > (sscanf(sockbuf, "%d %[^\r\n]", &status, reply))) {
	fprintf(stderr, "Logon ack convert failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

Has anyone solved the problem of using fdopen to convert a socket
to a read-write stream?
--
Bob Crispen
crispen at hiwaay dot net
What we're looking for: destinations.
What we end up getting: journeys.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[John R Hanson]

Actually They are regular file handles, just like any other.
There is a bug in all 9x/kernel32 libc/msv/crtdll interface
implementations GetFileType() returns TYPE_UNKNOWN for handles to
sockets. Since this is AFAIK the only unknown type there is, you know you have
a socket handle;-)
there is a fix in the more recent perl distrib's
that you can use as a general solution.
-loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
for socket handles. that are put into an fd with _open_osfhandle()
also fixes several other nasty bugs in the MS libcXXX.

On Sun, 22 Aug 1999 17:53:18 CEST, you wrote:

>>Ah, as far as I know, one of the big limitations of winsock is that
>>the SOCKET type is *not* equivalent to file descriptor unlike that
>>using BSD or POSIX sockets. That's one of the major reasons for using
>>a separate data type, SOCKET, as opposed to int, typical type of a
>>file descriptor. This implies that you cannot mix SOCKETs and stdio,
>>sorry. This is the case when you use -mno-cygwin.
>
>socket handles are NOT file handles only under win9x. Under WNT they ARE 
>file handles.
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com

________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Mumit Khan]

JRSON@NetZero.Net (John R Hanson) writes:
> Actually They are regular file handles, just like any other.
> There is a bug in all 9x/kernel32 libc/msv/crtdll interface
> implementations GetFileType() returns TYPE_UNKNOWN for handles to
> sockets. Since this is AFAIK the only unknown type there is, you know you hav
> e
> a socket handle;-)

Thanks for the clarification. My MSDN CD does document this and I guess
that makes it a "feature" rather than a bug ;-)

I may consider adding a GetFileType interface in mingw runtime (under
a "bug fix" library that you have to explicitly link to).

> there is a fix in the more recent perl distrib's
> that you can use as a general solution.
> -loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
> for socket handles. that are put into an fd with _open_osfhandle()
> also fixes several other nasty bugs in the MS libcXXX.

I see references to PerlCRT DLL, but can't find the source nor any
mention of what license it's disributed under. Anyone with more info
on it?  If it's not free (in either the GNU/gratis or BSD-style free 
software sense), then, as far as I'm concerned, it's irrelevant. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Mumit Khan]

JRSON@NetZero.Net (John R Hanson) writes:
> Actually They are regular file handles, just like any other.
> There is a bug in all 9x/kernel32 libc/msv/crtdll interface
> implementations GetFileType() returns TYPE_UNKNOWN for handles to
> sockets. Since this is AFAIK the only unknown type there is, you know you hav
> e
> a socket handle;-)

Thanks for the clarification. My MSDN CD does document this and I guess
that makes it a "feature" rather than a bug ;-)

I may consider adding a GetFileType interface in mingw runtime (under
a "bug fix" library that you have to explicitly link to).

> there is a fix in the more recent perl distrib's
> that you can use as a general solution.
> -loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
> for socket handles. that are put into an fd with _open_osfhandle()
> also fixes several other nasty bugs in the MS libcXXX.

I see references to PerlCRT DLL, but can't find the source nor any
mention of what license it's disributed under. Anyone with more info
on it?  If it's not free (in either the GNU/gratis or BSD-style free 
software sense), then, as far as I'm concerned, it's irrelevant. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[John R Hanson]

Actually They are regular file handles, just like any other.
There is a bug in all 9x/kernel32 libc/msv/crtdll interface
implementations GetFileType() returns TYPE_UNKNOWN for handles to
sockets. Since this is AFAIK the only unknown type there is, you know you have
a socket handle;-)
there is a fix in the more recent perl distrib's
that you can use as a general solution.
-loldnames -lperlcrt -lmsvcrt will get you TYPE_CHAR
for socket handles. that are put into an fd with _open_osfhandle()
also fixes several other nasty bugs in the MS libcXXX.

On Sun, 22 Aug 1999 17:53:18 CEST, you wrote:

>>Ah, as far as I know, one of the big limitations of winsock is that
>>the SOCKET type is *not* equivalent to file descriptor unlike that
>>using BSD or POSIX sockets. That's one of the major reasons for using
>>a separate data type, SOCKET, as opposed to int, typical type of a
>>file descriptor. This implies that you cannot mix SOCKETs and stdio,
>>sorry. This is the case when you use -mno-cygwin.
>
>socket handles are NOT file handles only under win9x. Under WNT they ARE 
>file handles.
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com

________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Emanuele Aliberti]

>Ah, as far as I know, one of the big limitations of winsock is that
>the SOCKET type is *not* equivalent to file descriptor unlike that
>using BSD or POSIX sockets. That's one of the major reasons for using
>a separate data type, SOCKET, as opposed to int, typical type of a
>file descriptor. This implies that you cannot mix SOCKETs and stdio,
>sorry. This is the case when you use -mno-cygwin.

socket handles are NOT file handles only under win9x. Under WNT they ARE 
file handles.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: fdopen() and winsock

[Mumit Khan]

Bob Crispen <crispen@hiwaay.net> writes:
> This has come up several times in the archives, but the only
> reply I've seen so far is "you can't do that" so I thought
> I'd try again, just in case.
> 
> When I compile with Cygwin 2.95 and don't set the -mno-cygwin
> flag, then the following works just fine:
> 
>     /*
>     * Convert the socket to a stream
>     */
>     if (0 > (sf = fdopen(s, "r+"))) {
> 	fprintf(stderr, "fdopen failed: %s\n", strerror(errno));
> 	close(s);
> 	exit (EXIT_FAILURE);
>     }
> 

Ah, as far as I know, one of the big limitations of winsock is that
the SOCKET type is *not* equivalent to file descriptor unlike that
using BSD or POSIX sockets. That's one of the major reasons for using
a separate data type, SOCKET, as opposed to int, typical type of a 
file descriptor. This implies that you cannot mix SOCKETs and stdio,
sorry. This is the case when you use -mno-cygwin.

Cygwin of course implements POSIX sockets and there is no problem
there. Case without -mno-cygwin.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

fdopen() and winsock

[Bob Crispen]

This has come up several times in the archives, but the only
reply I've seen so far is "you can't do that" so I thought
I'd try again, just in case.

When I compile with Cygwin 2.95 and don't set the -mno-cygwin
flag, then the following works just fine:

    /*
    * Convert the socket to a stream
    */
    if (0 > (sf = fdopen(s, "r+"))) {
	fprintf(stderr, "fdopen failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

    /*
    * Get news server acknowledgement of logon
    */
    bzero(reply, sizeof(reply));
    if (2 > (fscanf(sf, "%d %[^\r\n]", &status, reply))) {
	fprintf(stderr, "Logon ack read failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

[I defined bzero as a macro.  I just got lazy and didn't want
to change it everywhere in the code.]

When I compile with -mno-cygwin and use winsock.h and -lwsock32,
(and use WSAStartup to start up winsock) then the fscanf fails
with a "bad file descriptor" error, even though the file descriptor
inside the FILE is in fact the same value as the socket.  The only
thing that works is

    bzero(reply, sizeof(reply));
    bzero(sockbuf, sizeof(sockbuf));
    if (recv(s, sockbuf, sizeof(sockbuf), 0) < 0) {
	fprintf(stderr, "Logon ack read failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }
    if (2 > (sscanf(sockbuf, "%d %[^\r\n]", &status, reply))) {
	fprintf(stderr, "Logon ack convert failed: %s\n", strerror(errno));
	close(s);
	exit (EXIT_FAILURE);
    }

Has anyone solved the problem of using fdopen to convert a socket
to a read-write stream?
--
Bob Crispen
crispen at hiwaay dot net
What we're looking for: destinations.
What we end up getting: journeys.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com