Re: Open a COMM port on Win32

[John K Luebs <jkluebs luebsphoto com>]

On Mon, Nov 29, 2004 at 03:21:32PM -0300, Jorge Monsalvo wrote:
> Hi,
>
> I want to know if somebody did a program using glib/gtk using a comm port in win32. My first idea is open 
> COMx with "createfile" as Win32 API says, get a handler and then convert it to IO_Channel with 
> g_io_channel_unix_new but before leave other things and test my idea, I think is a good practice ask for a 
> different opinion.
In Win32, strictly speaking, there is no such thing as a file descriptor.
The basic Win32 abstraction for kernel objects is called a HANDLE. 
It is the C runtime library (usually MSVCRT) that implements a
UNIX file descriptor abstraction. These file descriptors are integers
just like in UNIX and they are not the same thing as a handle.
The underlying C runtime maintains the mapping from each file descriptor
to a HANDLE.
You can obtain a file descriptor for an existing handle with the
_open_osfhandle function that is documented in MSDN.

The file descriptor implementation has no clue about poll or
non-blocking mode, so glib actually uses a thread for each GIOChannel to
provide poll/non-blocking like functionality. For what it supports, it
works rather well.

Note that this will only work as long as you are NOT using overlapped
I/O. If for some reason you need to use OVERLAPPED handles then you
cannot use the g_io_channel implementation. It will simply not work,
because the MSVCRT read() implementation does not handle overlapped
handles. In this case you will have to directly add a g_source with the
overlapped EVENT as the PollFD (in the PollFD the fd member is a HANDLE,
not a CRT file descriptor, and you will see that the glib mainloop is
based on MsgWaitForMultipleObjectsEx to which the PollFD fds are passed).

This involves calling g_source_new with source functions that either
perform special handling for the handle you're dealing with, or they do
the bare minimum with dispatch calling callback(user_data). The PollFD
is registered with g_source_add_poll. You can use a simple "dispatch
only" source like this for any waitable Win32 object, not just events.

It seems a little convoluted at first, but it works well and allows
direct integration of OVERLAPPED I/O libraries and Win32 waitable
objects with the glib mainloop.

 -jkl