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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list