I have not been able to build a Windows version of Unicon with the Cygwin C++ compiler for a while. I will look into what is required to fix this configuration in the latest update.
One change I will try to make is to avoid the MS-Windows Winsock API whenever possible. As pointed out in a previous post to this group, the Winsock API is a non-standard and limited implementation of Berkeley sockets. Among the problems with Winsock: - In Winsock, the type of a sockets is a Win32 handle, not a POSIX file descriptor. That means that you cannot read from / write to a socket using the _read() / _write() function, nor can you adjust its settings with ioctl, nor can you close a socket using _close. - For a Winsock socket s, (s < 0) does not necessarily mean that s has an invalid value. - The Winsock version of the select() function can monitor I/O events on sockets only; the Winsock select() does not work with consoles, pipes, windows, or anything other than sockets. - A Winsock socket is also a somewhat non-standard Win32 handle. You can read from / write to a Winsock socket using the Win32 functions ReadFile / WriteFile. You cannot close a Winsock socket, however, using CloseHandle. FYI, the proper way to close a socket is with the closesocket() function. Moreover, a Winsock socket cannot be used in Win32 API functions such as WaitForMultipleObjects that could be used as a substitute for select(). For these and other reasons, I urge that Winsock be used only if there is no other available support for Berkeley sockets. For a Windows developer using MSVC, I know of no alternative to Winsock. Fortunately, the Cygwin compiler offers an excellent alternative to Winsock. The Cygwin POSIX implementation uses file descriptors to represent sockets. These file descriptors can be used in the standard POSIX calls (including _read(), _write(), ioctl() and close()), and the Cygwin select() can work with sets of any type of file descriptor. I strongly recommend, therefore, that we add one more config macro to indicate which socket API is being used, and that the NTGCC configuration should NOT use Winsock. ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
