What is the Windows equivalent to the capabilities defined in sys/select.h and termios.h

Solution 1:

The Windows API is structurally and stylistically very different from the blend of system calls and library routines provided by any flavor of Unix.

termio.h

Windows does terminal I/O with a very different model from any *nix system. As a result, there really is no direct equivalent to the termios.h header and its friends.

You want to read at MSDN about the Windows Communications Resources.

Some things to learn more about include:

• The DCB structure
• The COMMTIMEOUTS structure
• BuildCommDCB()
• SetCommState()
• ... and many more ...

In general, you will find that you need to deal a lot more with the Windows API directly because stdio will add to the confusion when doing device I/O.

select.h

There isn't a direct equivalent to the Unix select(2) system call.

In Windows, many kernel objects can be in either a signaled or non-signaled state, and the act of signalling the object can be used to release a thread that called WaitForMultipleObjects(). Some but not all HANDLE objects are signaled when data is available. Specifically, I know that HANDLEs from WinSock have that capability, but I don't know about the Comm API. I know that HANDLEs to an open file do not.

If you need to wait for an event in a thread that is processing window messages, then you should probably use MsgWaitForMultipleObjects() instead, since it will properly deliver messages while the thread is otherwise blocked.

Read about the Windows synchronization primitives at the MSDN article Using Synchronization.

However, there are several kinds of asynchronous I/O built into Windows that can replace the need for select() by a change of design. Both will require extensive use of features that cannot be used in combination with the C stdio library.

MSDN has several articles on I/O techniques, as well as numerous examples:

• I/O Concepts
• Synchronous and Asynchronous I/O
• Synchronization and Overlapped Input and Output
• CreateFile() (especially the Remarks section)

Note that much of the information on how Windows works is scattered among the overview articles and the remarks sections of the reference material for the API functions and structures. This can give the impression that nothing is completely documented on a first reading.

Porting with Cygwin

Another approach is to use Cygwin to do the port. It provides most of a POSIX layer over the Windows API. However, you will end up with an application that is dependent on the Cygwin DLL which is GPL unless you purchase a commercial use license from them. It can be tricky to use Cygwin to get an application that works well for a Windows user with no Unix experience also, since so many other assumptions about the way the two systems are setup and used differ.

Cygwin has done a fair amount of heavy lifting to build an implementation of select() that works on Windows given a mix of different open file descriptors. This effort is described in the User's Guide.

Do be aware that building against Cygwin is only documented and supported if done from within the Cygwin environment. It usually is not sufficient to just put Cygwin's bin on the Windows PATH and work from a command prompt. You really need to launch Cygwin's build of bash and compile from there so that everything is using the same Cygwin-style mount points and simulated Unix file structure.

Mixing Cygwin header files with third-party tool header files is a sure path to madness.

Edit: I've rearranged a bit, and added some material in response to comments.