Re: RE: MinGW patch

> * socketx.c needs to include config.h as socketx.h
uses
> HAVE_INET_SOCKETS

Okay.

> * There is an issue with build-aux/inet.m4  The MinGW
libwsock32.a only
> exports __stdcall decorated names (listen8 etc)
and so the test there
> does not detect it. I enclose a possible patch for
this.

I just moved your test in place of the old AC_CHECK_LIB.

> * I stared getting 
>       alloc.h:76: warning: declaration does not declare
anything
> and alloc.c failed to compile. I traced the problem to
a definition in
> rpcndr.h which is included by winsock.h and does

Indeed alloc.c already had a workaround for this.  I moved
it up from 
alloc.c to alloc.h.

If you have time, could you improve win_recv so that it
works for 
sockets and pipes, as well as restoring support for the
third set in 
win_select? (Long term, it's probably just better to merge
win_select 
and win_recv into a Windows-specific implementation of poll,
but for now 
let's keep your solution).

Thanks!

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> If you have time, could you improve win_recv so that it
works for 
> sockets and pipes, as well as restoring support for the
third set in 
> win_select? (Long term, it's probably just better to
merge win_select 
> and win_recv into a Windows-specific implementation of
poll, but for
now 
> let's keep your solution).

Socket support on windows may need a bit more work as
descriptors
returned by socket() and fd's returned by open() can, in
principle,
clash. In the Microsoft implementation of the Winsock API
socket
descriptors are related to windows file handles and you can
use
_open_osfhandle() and related functions to allocate a C RTL
file
descriptor to work with. This would take care of keeping the
numbers
unique, but I'm not sure if all of the usual CRTL functions
work as
expected with these. We may need to keep a separate list of
all socket
CRTL fd we generate and so lookup the fd later and treat
sockets
differently on a read/write call etc. If we end up doing
this lookup,
then it would be more general to create dummy fd's via e.g.
open("/dev/null") for our book keeping as we are
not then relying on a
Microsoft implementation of the Winsock API.  

I was wondering if GNU Smalltalk preserves the identity of
socket and
file descriptors inside its instances and so only calls
recv()/send() on
sockets and read()/write() on CRTL file descriptors? If so
that will
make life easier and we only need to handle poll() as you
mention above.

Freddie



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> If you have time, could you improve win_recv so that it
works for 
> sockets and pipes, as well as restoring support for the
third set in 
> win_select? (Long term, it's probably just better to
merge win_select 
> and win_recv into a Windows-specific implementation of
poll, but for
now 
> let's keep your solution).

Socket support on windows may need a bit more work as
descriptors
returned by socket() and fd's returned by open() can, in
principle,
clash. In the Microsoft implementation of the Winsock API
socket
descriptors are related to windows file handles and you can
use
_open_osfhandle() and related functions to allocate a C RTL
file
descriptor to work with. This would take care of keeping the
numbers
unique, but I'm not sure if all of the usual CRTL functions
work as
expected with these. We may need to keep a separate list of
all socket
CRTL fd we generate and so lookup the fd later and treat
sockets
differently on a read/write call etc. If we end up doing
this lookup,
then it would be more general to create dummy fd's via e.g.
open("/dev/null") for our book keeping as we are
not then relying on a
Microsoft implementation of the Winsock API.  

I was wondering if GNU Smalltalk preserves the identity of
socket and
file descriptors inside its instances and so only calls
recv()/send() on
sockets and read()/write() on CRTL file descriptors? If so
that will
make life easier and we only need to handle poll() as you
mention above.

Freddie



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk